5 ms·

If you want a cross-platform secure random source, you can't rely on /dev/urandom existing, so I'm not sure what alternative you're suggesting here.

tptacek 13y ago
You can't on the one hand say that OpenJDK Unix SecureRandom uses urandom so it's OK while on the other hand saying that SecureRandom is preferable because it works on platforms without urandom. That's the problem with SecureRandom: it's hard to know exactly what it's doing, as the Android team discovered last year. (On Windows, I'd use CryptGenRandom, although it inspires even less confidence than Linux /dev/random).
- marshray 13y ago
  If you're ever in Redmond, stop by and we'll go inspire some confidence with the folks maintaining it.
  - tptacek 13y ago
    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.
    - marshray 13y ago
      You have my email right? If you'd like to send me some specific questions and concerns I can try to put them to people who know.
    - pbsd 13y ago
      The forward security issues have been fixed for a long time (since Vista I believe): they now use SP800-90A's CTR_DRBG. But the generator continues to be unprotected in user mode, seeded from kernel.
- weavejester 13y ago
  I don't see any contradiction. SecureRandom uses urandom where it's available, and the next best alternative where it's not. Again, I'd like to know what your suggested solution is. The way I see it, you can either: 1) Don't write cross-platform code 2) Use the language implementation 3) Write your own cross-platform code Assuming (1) isn't an option, it comes down to using SecureRandom or writing your own version of SecureRandom, which strikes me as plain crazy.
  - tptacek 13y ago
    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. Avoid userspace CSPRNGs. Use the system CSPRNG.
    - weavejester 13y ago
      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.
      - tptacek 13y ago
        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.
        weavejester 13y ago
        And urandom is not cross-platform, so if I were going to write a cross-platform library, how would you suggest doing it? By writing an interface to urandom, then an interface to CryptGenRandom (doesn't that require an FFI?), and then manually going through all of the platforms Java can potentially execute on until I can be sure I've covered all my bases? I'm pretty sure that's going to be more than 5-10 lines of code.

tptacek 13y ago

You can't on the one hand say that OpenJDK Unix SecureRandom uses urandom so it's OK while on the other hand saying that SecureRandom is preferable because it works on platforms without urandom. That's the problem with SecureRandom: it's hard to know exactly what it's doing, as the Android team discovered last year. (On Windows, I'd use CryptGenRandom, although it inspires even less confidence than Linux /dev/random).

marshray 13y ago
If you're ever in Redmond, stop by and we'll go inspire some confidence with the folks maintaining it.
- tptacek 13y ago
  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.
  - marshray 13y ago
    You have my email right? If you'd like to send me some specific questions and concerns I can try to put them to people who know.
  - pbsd 13y ago
    The forward security issues have been fixed for a long time (since Vista I believe): they now use SP800-90A's CTR_DRBG. But the generator continues to be unprotected in user mode, seeded from kernel.
weavejester 13y ago
I don't see any contradiction. SecureRandom uses urandom where it's available, and the next best alternative where it's not. Again, I'd like to know what your suggested solution is. The way I see it, you can either: 1) Don't write cross-platform code 2) Use the language implementation 3) Write your own cross-platform code Assuming (1) isn't an option, it comes down to using SecureRandom or writing your own version of SecureRandom, which strikes me as plain crazy.
- tptacek 13y ago
  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. Avoid userspace CSPRNGs. Use the system CSPRNG.
  - weavejester 13y ago
    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.
    - tptacek 13y ago
      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.
      - weavejester 13y ago
        And urandom is not cross-platform, so if I were going to write a cross-platform library, how would you suggest doing it? By writing an interface to urandom, then an interface to CryptGenRandom (doesn't that require an FFI?), and then manually going through all of the platforms Java can potentially execute on until I can be sure I've covered all my bases? I'm pretty sure that's going to be more than 5-10 lines of code.