3 ms·

1. The Solaris crypto designers / developers believe their rng is is appropriate for short-term session keys and padding. Read the post I linked before as to w

1. The Solaris crypto designers / developers believe their rng is is appropriate for short-term session keys and padding. Read the post I linked before as to why the believe that. 2. /dev/random basically only uses bits from entropy sources while /dev/urandom just uses a few bits from /dev/random as a seed. Read the post I linked again. Again, I would reiterate, the situation is somewhat different for Solaris. Usage of /dev/random vs. /dev/urandom is actually considered different.

tptacek 12y ago
I read this post, both when you linked to it just now, and, prior to that, while I was researching the urandom blog post I wrote a few months ago. I'm being repetitive, but: * I think the distinction this post is drawing between Solaris random and urandom is functionally very similar to the distinction between Linux random and urandom (I think the distinction on Solaris might be that random has a higher quality rekeying system than urandom). * I can read a straightforward description of a SHA1 PRNG keyed by kernel entropy, which is what this blog post describes, and unless I'm missing something in the article, I don't see how it is any less cryptographically secure than Solaris /dev/random. It seems to be less forward-secure than /dev/random. That's about it. Since you appear to have grokked this article better than I did in either of the two cases I read it, could you give a short summary of the argument it presents for avoiding urandom for long-term secrets?
- binarycrusader 12y ago
  1) You're not completely off here; the primary difference is currently higher quality re-keying for /dev/random, but there are implementation differences. 2) From a cryptography standpoint, the precise implementation of the current framework makes /dev/urandom suitable for short-term session keys and padding. This may not hold true for Linux, but for Solaris it has been reviewed and deemed appropriate usage. Fundamentally, it's about constraints placed on the implementation that currently make /dev/random more "secure". In conversing with one of the crypto developers for Solaris, they are considering whether to lessen the distinction between /dev/random and /dev/urandom further in the future.

tptacek 12y ago

I read this post, both when you linked to it just now, and, prior to that, while I was researching the urandom blog post I wrote a few months ago. I'm being repetitive, but: * I think the distinction this post is drawing between Solaris random and urandom is functionally very similar to the distinction between Linux random and urandom (I think the distinction on Solaris might be that random has a higher quality rekeying system than urandom). * I can read a straightforward description of a SHA1 PRNG keyed by kernel entropy, which is what this blog post describes, and unless I'm missing something in the article, I don't see how it is any less cryptographically secure than Solaris /dev/random. It seems to be less forward-secure than /dev/random. That's about it. Since you appear to have grokked this article better than I did in either of the two cases I read it, could you give a short summary of the argument it presents for avoiding urandom for long-term secrets?

binarycrusader 12y ago
1) You're not completely off here; the primary difference is currently higher quality re-keying for /dev/random, but there are implementation differences. 2) From a cryptography standpoint, the precise implementation of the current framework makes /dev/urandom suitable for short-term session keys and padding. This may not hold true for Linux, but for Solaris it has been reviewed and deemed appropriate usage. Fundamentally, it's about constraints placed on the implementation that currently make /dev/random more "secure". In conversing with one of the crypto developers for Solaris, they are considering whether to lessen the distinction between /dev/random and /dev/urandom further in the future.