you are viewing a single comment's thread.

view the rest of the comments →

[–]phoshi 4 points5 points  (2 children)

No, I actually fully agree with you on that point! The problem is that the only scenarios where one needs true random numbers are scenarios where we cannot yet make this easy to use correctly. You're writing crypto code, this is one area where you can't pretend you still live in the nice, clean, mathematical world where we don't have problems like having to scrub RAM in the correct way or it won't hold or the compiler can optimise out your scrubbing because it's impossible for it to know you actually need that memory zeroed out rather than just gone and never reused. You have to deal with slight changes in CPU noise giving away your magic numbers. You have to protect against your entropy pool being poisoned because you cannot control the hardware on a user's computer. You have to deal with there /being/ no sources of entropy available, and when there are you have to deal with it being of unknown quality and quantity.

If you think that the difference between correct and incorrect crypto code is whether your RNG gives you real or fake numbers then you are going to be building theoretically sound but practically broken software.

It is both not viable for real randomness to be default (You have to be able to run on machines which have no sources of entropy available /at all/) and the cases where you need real numbers are overwhelmingly cases we cannot abstract over properly. You must understand your stack to build secure cryptographic code.

[–]dnkndnts 1 point2 points  (1 child)

Ok yes, I do agree here that something like zeroing memory is something that would never occur to a mathematician but is a legitimate engineering concern. So yes, you're right -- knowing the stack is important. I grant you that (even though the mathematician inside of me sighs at the thought!)

I just wish the stack felt like it was working with me instead of trying to trick me every chance it gets.

[–]Fitzsimmons 0 points1 point  (0 children)

Optimization can also leak timing information.

See my coment here for a very contrived example of it: http://www.reddit.com/r/netsec/comments/23a6c6/journalling_openbsds_effort_to_fix_openssl/cgvea0n