7 ms·

Where does this article say that?

jbaudanza 13y ago
The article lists several userspace libraries (OpenSSL, SecureRandom) and then says not to use them. I had the same question as weavejester.
- tptacek 13y ago
  No. OpenSSL RAND_bytes and Java SecureRandom aren't simply libraries that "call /dev/urandom"; they are full-fledged CSPRNG designs, and must themselves avoid all the possible bugs a CSPRNG can have, in addition to their usual reliance on urandom not itself being vulnerable.
  - weavejester 13y ago
    The NativePRNG algorithm for SecureRandom XORs /dev/urandom with a SHA1PRNG seeded from /dev/urandom, so as long as the XOR is correct, it should be no less secure than reading from /dev/urandom directly.
    - tptacek 13y ago
      I would definitely avoid Java's SecureRandom. It means too many different things depending on what platform you're on. Meanwhile, XORing SHA1PRNG against /dev/urandom seems cryptographically nonsensical.
      - TheLoneWolfling 13y ago
        > XORing SHA1PRNG against /dev/urandom seems cryptographically nonsensical. Untrue! Assuming that the two (/dev/urandom and SHA1PRNG) are not correlated, the resulting output will be at least as secure as the most secure of the two. This means that (for example) if SHA1PRNG is found to be breakable, SecureRandom will still be at least as secure as /dev/urandom, and vice versa.
        tptacek 13y ago
        This is a rabbit hole I don't want to go down and so I will concede the point about NativePRNG, while sticking to my guns on "avoid the Java SecureRandom interface".
      - weavejester 13y ago
        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.
  - jbaudanza 13y ago
    That makes more sense. So which of the following is true: 1) I shouldn't be using OpenSSL to generate keys without somehow injecting bytes directly /dev/urandom 2) The article is wrong, using OpenSSL's CSPRNG is fine. 3) I still don't get it.
    - tptacek 13y ago
      The article doesn't care how you use the OpenSSL commands; it's concerned with code you write that might need a CSPRNG. If you're writing code, don't use OpenSSL's CSPRNG.
      - jbaudanza 13y ago
        So code that I write that generates keys using OpenSSL isn't indirectly depending on OpenSSL's CSPRNG? Sorry for all the questions. I just want to make sure I'm doing it right and I suspect I'm not the only one that is confused by the article's assertions.
        tptacek 13y ago
        The article (I'm its author) is about programming; it doesn't have strong opinions about how you e.g. configure nginx. As for keys: it depends on the kinds of keys you're generating. If you're building on OpenSSL's primitives --- which, don't --- it'll be hard to get an RSA key without invoking the OpenSSL CSPRNG. But it's not at all hard to avoid OpenSSL's CSPRNG for AES.
        jbaudanza 13y ago
        Thanks for clarifying. My project depends on bitcoin-ruby, which uses OpenSSL's EC_KEY_generate_key to generate keys. EC_KEY_generate_key, as far as I can tell, uses OpenSSLs internal PRNG. If I understand you correctly, this is unsafe and it would be better to derive a key from urandom.
        tptacek 13y ago

The article lists several userspace libraries (OpenSSL, SecureRandom) and then says not to use them. I had the same question as weavejester.

tptacek 13y ago
No. OpenSSL RAND_bytes and Java SecureRandom aren't simply libraries that "call /dev/urandom"; they are full-fledged CSPRNG designs, and must themselves avoid all the possible bugs a CSPRNG can have, in addition to their usual reliance on urandom not itself being vulnerable.
- weavejester 13y ago
  The NativePRNG algorithm for SecureRandom XORs /dev/urandom with a SHA1PRNG seeded from /dev/urandom, so as long as the XOR is correct, it should be no less secure than reading from /dev/urandom directly.
  - tptacek 13y ago
    I would definitely avoid Java's SecureRandom. It means too many different things depending on what platform you're on. Meanwhile, XORing SHA1PRNG against /dev/urandom seems cryptographically nonsensical.
    - TheLoneWolfling 13y ago
      > XORing SHA1PRNG against /dev/urandom seems cryptographically nonsensical. Untrue! Assuming that the two (/dev/urandom and SHA1PRNG) are not correlated, the resulting output will be at least as secure as the most secure of the two. This means that (for example) if SHA1PRNG is found to be breakable, SecureRandom will still be at least as secure as /dev/urandom, and vice versa.
      - tptacek 13y ago
        This is a rabbit hole I don't want to go down and so I will concede the point about NativePRNG, while sticking to my guns on "avoid the Java SecureRandom interface".
    - weavejester 13y ago
      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.
- jbaudanza 13y ago
  That makes more sense. So which of the following is true: 1) I shouldn't be using OpenSSL to generate keys without somehow injecting bytes directly /dev/urandom 2) The article is wrong, using OpenSSL's CSPRNG is fine. 3) I still don't get it.
  - tptacek 13y ago
    The article doesn't care how you use the OpenSSL commands; it's concerned with code you write that might need a CSPRNG. If you're writing code, don't use OpenSSL's CSPRNG.
    - jbaudanza 13y ago
      So code that I write that generates keys using OpenSSL isn't indirectly depending on OpenSSL's CSPRNG? Sorry for all the questions. I just want to make sure I'm doing it right and I suspect I'm not the only one that is confused by the article's assertions.
      - tptacek 13y ago
        The article (I'm its author) is about programming; it doesn't have strong opinions about how you e.g. configure nginx. As for keys: it depends on the kinds of keys you're generating. If you're building on OpenSSL's primitives --- which, don't --- it'll be hard to get an RSA key without invoking the OpenSSL CSPRNG. But it's not at all hard to avoid OpenSSL's CSPRNG for AES.
        jbaudanza 13y ago
        Thanks for clarifying. My project depends on bitcoin-ruby, which uses OpenSSL's EC_KEY_generate_key to generate keys. EC_KEY_generate_key, as far as I can tell, uses OpenSSLs internal PRNG. If I understand you correctly, this is unsafe and it would be better to derive a key from urandom.
        tptacek 13y ago