Timeline for If I am about to generate one-time pad, where should I generate my pads from?
Current License: CC BY-SA 3.0
14 events
when toggle format | what | by | license | comment | |
---|---|---|---|---|---|
Jun 13, 2016 at 18:32 | comment | added | rmalayter |
@Stephen_Touset didn't you mean "There is absolutely nothing wrong for using /dev/urandom for long-lived GPG/SSL/SSH keys"?
|
|
Jun 12, 2016 at 22:28 | comment | added | Stephen Touset |
@Mike And even that statement is misleading, if not flat-out wrong. There is absolutely nothing wrong for using /dev/random for long-lived GPG/SSL/SSH keys.
|
|
Jun 11, 2016 at 17:42 | comment | added | CodesInChaos |
@Mike One of many examples: Ruby seeding its CSPRNG from /dev/random and refusing to change it.
|
|
Jun 11, 2016 at 16:05 | comment | added | MichalH | @CodesInChaos Only if you not read the whole page. Maybe you have different one, but mine says: As a general rule, /dev/urandom should be used for everything except long-lived GPG/SSL/SSH keys. | |
Jun 11, 2016 at 15:52 | comment | added | CodesInChaos |
@Mike I can't recommend the man page, since many beginners misunderstand the warning that /dev/urandom might theoretically get broken by cryptoanalysis and thus prefer /dev/random for practical use.
|
|
Jun 11, 2016 at 15:41 | comment | added | MichalH |
All you need to know about /dev/(u)random is at man -s 4 random .
|
|
May 3, 2016 at 12:02 | comment | added | assp1r1n3 | @CodesInChaos Is there any custom kernel module for BSD family? | |
May 3, 2016 at 11:50 | comment | added | CodesInChaos |
@assp1r1n3 Buy a hardware RNG. Or RDSEED from your application, if your CPU supports that instruction (AFAIK few do).
|
|
May 3, 2016 at 11:36 | vote | accept | assp1r1n3 | ||
May 3, 2016 at 11:34 | comment | added | otus |
@CodesInChaos, true, RDSEED if you want to be absolutely sure. (In practice /dev/urandom does not operate fast enough that RDRAND should resort to entropy stretching.)
|
|
May 3, 2016 at 11:31 | comment | added | CodesInChaos |
@otusRDRAND is only computationally secure. Only RDSEED aims of information theoretical security.
|
|
May 3, 2016 at 11:29 | comment | added | assp1r1n3 | And what are the options on BSD? | |
May 3, 2016 at 11:29 | comment | added | otus |
One additional thing to note is that if the CPU has RDRAND/RDSEED, Linux /dev/urandom should get enough hardware randomness and be even information theoretically secure if the implementation is good.
|
|
May 3, 2016 at 11:26 | history | answered | CodesInChaos | CC BY-SA 3.0 |