51–60 of 62 posts
> For cryptography, you don’t usually want “true random”. Wait what? I thought I wanted actually random numbers.
Chapter 9 of _Cryptography Engineering_ leads off with a dozen or so paragraphs on why crypto software doesn't use real random.
Earlier quoted context omitted.
Keep reading. I think you stopped too early.
I read it all, don't be a jerk. When you're writing a program for generic use, you can't trust the underlying system to be set up above and beyond a stock install. If you want to use seeding as a workaround, it should be done from every program that requires secure randomness. That doesn't seem to be what you're advocating. And if you're just generating a key, why not read it directly from random instead? You can pre…
Earlier quoted context omitted.
If you're ever in Redmond, stop by and we'll go inspire some confidence with the folks maintaining it.
Two immediate questions: forward secrecy and CryptGenRandom's state relative to other WinAPI processes. As in, I'm very clear how the Unix security model protects /dev/random, and less clear about Windows. Some of my C.G.R. thoughts are probably dated. But it's the system CSPRNG, and I think, just use the system CSPRNG.
Earlier quoted context omitted.
If SecureRandom was simply "pull bytes from urandom" on Linux and "pull bytes from CryptGenRandom" on Windows, I wouldn't care enough to argue. But it's not. It's not even "pull bytes from urandom" on Linux; depending on the specific details of your platform, it can be dramatically different than that. I'm absolutely not recommending that people write their own version of SecureRandom; I'm advising the opposite. Avoi…
So I should write my own cross-platform interface to the system PRNG? Doesn't that strike you as more prone to error than relying on SecureRandom, which at least has the advantage of having many eyes on it.
Look what "many eyes" did for the Harmony PRNG.
Use urandom, but that's not the end of it. It may be that urandom supports non-blocking reads. Most implementations only check if read() returns -1 then abort, without checking for EAGAIN, not to mention EINTR, or some other subtleties like making sure not to request more than SSIZE_MAX bytes. The randombytes function in NaCl does it right, unfortunately libsodium did their own thing. If you use Python, read from os.…
> The randombytes function in NaCl does it right, unfortunately libsodium did their own thing. I don't know what you're talking about. Sodium does the same thing as NaCl, while also being more portable.
NaCl:
https://gist.github.com/anonymous/9234738
libsodium:
https://github.com/jedisct1/libsodium/blob/master/src/libsod...
Earlier quoted context omitted.
> The randombytes function in NaCl does it right, unfortunately libsodium did their own thing. I don't know what you're talking about. Sodium does the same thing as NaCl, while also being more portable.
No, libsodium does not do the same thing as NaCl. NaCl: https://gist.github.com/anonymous/9234738 libsodium: https://github.com/jedisct1/libsodium/blob/master/src/libsod...
I should also point out that randombytes is technically not part of NaCl. The authors maintain that random byte generation is out of scope for NaCl, and what actually happens is that randombytes.o is bundled separately from libnacl.a [1]. In TweetNacl the randombytes implementation is completely omitted.
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=20;bug=694...
Earlier quoted context omitted.
No, libsodium does not do the same thing as NaCl. NaCl: https://gist.github.com/anonymous/9234738 libsodium: https://github.com/jedisct1/libsodium/blob/master/src/libsod...
I'm aware that the implementations are not strictly equal, but how is libsodium doing it 'wrong'? Is it because it does not partition reads into smaller chunks (avoiding the unspecified >= SSIZE_MAX read)? I consider any reasonable answer a valid bug report. I should also point out that randombytes is technically not part of NaCl. The authors maintain that random byte generation is out of scope for NaCl, and what act…
Earlier quoted context omitted.
So I should write my own cross-platform interface to the system PRNG? Doesn't that strike you as more prone to error than relying on SecureRandom, which at least has the advantage of having many eyes on it.
NO. Relying on SecureRandom is riskier than writing the 5-10 lines of code it takes to read from urandom. Prefer urandom to SecureRandom. Look what "many eyes" did for the Harmony PRNG.
I'm pretty sure that's going to be more than 5-10 lines of code.
/dev/urandom is slow. So don't use it if you need lots of non secure random numbers. For example for game, or for a screensaver, etc.
If you want fast non-secure random numbers use Mersenne Twister: http://en.wikipedia.org/wiki/Mersenne_twister