4 ms·
Why isn't it possible? The safe versions just do bounds checking, which still seems constant time to me. If you mean that somewhere in the stack something must
by chpatrick 12y ago
Why isn't it possible? The safe versions just do bounds checking, which still seems constant time to me. If you mean that somewhere in the stack something must do pointer math you're right, but that's a given whatever you do crypto or not.
- 4ad 12y agoMy response was to tinco in respect to the use of unsafe in general when writing crypto code, it wasn't about the particular use of unsafe in this article... (which isn't about crypto anyway, so how could it be?).
- chpatrick 12y agoI'm disagreeing with this statement: "You definitely need to use unsafe Haskell code in order to implement most cryptographic primitives in a way making them resistant to timing attacks." Safe indexing is constant time too, unless you're out of bounds and you have to process the exception, in which case your program is wrong anyway.
- tinco 12y agoI think you're right, you could even write a monad/language extension in which it's only possible to perform constant time operations effectively ruling out a class of vulnerabilities.
- chpatrick 12y agoI'm not sure you could do that with a monad. They still let you use whatever pure function you want, which can have arbitrary complexity.
- jonpeda 12y agoYou could use the monad to generate an embedded program that runs in constant time on a given class of problems. Then the challenge is smaller-- ensure that the program generator is not exposed to tainted inputs, and run the generated program in your request-handling loop.
- tinco 12y agoYou could wrap your operands in a type with a bind function that takes a function argument that has to be marked constant time. I guess it wouldnt strictly be a monad. You would then have to trust the implementor that he does not mark any non-constant time functions as being that, but I think that is reasonable.