3 ms·
The author quotes an article referring to using uninitialized memory for additional entropy and that article cites [10]. Let me just say: DON'T do that, ever.
by svckr 9y ago
The author quotes an article referring to using uninitialized memory for additional entropy and that article cites [10].
Let me just say: DON'T do that, ever. Uninitialized memory is rarely random. If you're lucky, it's quasi-constant because your own program always writes something else to it before. Worst case an attacker manages to write something to that memory before you read it, thereby controlling part of your seed. The cited article also recommends to "In short, just don’t use uninitialized memory for more randomness."
Really, exploiting undefined behaviour in crypto code is a bad idea, and you should make sure you compile with flags that at least catch the most common cases, like the one mentioned in the post.
[10] http://kqueue.org/blog/2012/06/25/more-randomness-or-less/ http://kqueue.org/blog/2012/06/25/more-randomness-or-less/
- pjmlp 9y agoActually some well know researchers are quite known to be against UB, but C compiler writers don't seem to be willing to listen to them. https://blog.regehr.org/archives/1054 https://blog.regehr.org/archives/1054
- dom0 9y agoIn the Botan example, masking the operands instead of branching causes GCC to emit no additional code.
- svckr 9y agoI can relate to that. I guess undefined behavior makes it somewhat harder to write correct software. I've definitely read someone make the same point. The problem is, you can't always know if (for example) you're reading from an uninitialized variable, unless you run the program with the possibly infinite number of valid inputs, thereby also solving p != np. In my opinion, undefined behavior is what we have and we had enough time to learn how to deal with it. If at all possible, compilers should be able to detect UB, so I can use compile flags to make UB an error. Changing the language to "define" undefined behavior, might turn it into unexpected behavior and I wouldn't like that. At least we've learned the lesson with newer languages.
- pjmlp 9y ago> At least we've learned the lesson with newer languages. The thing is, we already knew that from older languages as well. C's UB is a consequence of the people involved in ANSI C89 not wanting to fully define the language, like the other languages were doing. I think the lesson is that "Performance trumps correctness" is the wrong path to follow, specially since not everyone using C is a 10x coder that always makes use of best practices.