8
$\begingroup$

I am not rolling my own crypto or anything - just trying to learn about the Dos and Don'ts of cryptography: specifically about AES encryption and ways to generate keys for that.

As far as I've understand, one of the options when creating cryptographically secure keys would be to gather entropy from /dev/urandom and then feed that data through the Salsa20 cipher.

However I am not quite sure about the next steps, because that’s where search engines stop being useful to me. From what I understand, using the output Salsa20 generates doesn’t seem to be secure enough to be used as key material as-is. If that's correct, what would be the "cryptographically" correct next step after getting the Salsa20 output?

Also, if you know of any relevant papers and are happy to share, they would be very welcome!

Improve this question
$\endgroup$
1
  • $\begingroup$ Comments are not for extended discussion; this conversation has been moved to chat. $\endgroup$
    – e-sushi
    Mar 25, 2018 at 2:56

1 Answer 1

Reset to default
9
$\begingroup$

As stated in the comments, /dev/random already produces cryptographically secure random bytes which are perfectly adequate for use in encryption keys. Running these bytes through another CSPRNG is completely redundant.

As far as I've understood, one of the options to create cryptographically secure keys would be to gather entropy from /dev/urandom and then feed that data through the Salsa20 cipher.

A symmetric cipher such as Salsa20 by itself is not the correct cryptographic primitive. You need a CSPRNG (such as /dev/random).

But I am unsure about the next step, because that’s where search engines stop being useful to me. From what I understand, using the output Salsa20 generates doesn’t seem to be secure enough to be used as key material as-is. Am I correct? If, what would be the cryptographically correct next step after I've retrieved the Salsa20 output?

If you have some reason not to use /dev/random (convenience, mistrust, etc), and you have some other strong (and I do mean strong, not just mouse-movements ala mega) source of entropy, then you should refer to one of the CSPRNGs defined in NIST Special Publication 800-90A. You might be particularly interested in CTR_DRBG, which uses a block cipher internally (running in CTR mode, which is essentially a stream cipher like Salsa20). You can find implementations of this in many languages.

Pro-tip: avoid Dual_EC_DRBG

Improve this answer
$\endgroup$
6
  • $\begingroup$ @hunter But using a symmetric cipher such as AES (or Salsa20) isn't what a Fortuna-based PRNG does? $\endgroup$
    – XCore
    Apr 9, 2014 at 16:40
  • $\begingroup$ @XCore - Yes, Fortuna is another CSPRNG that uses a symmetric block-cipher as one of its internal mechanisms. $\endgroup$
    – hunter
    Apr 9, 2014 at 16:54
  • $\begingroup$ So basically using a Fortuna PRNG or /dev/urandom is pretty much the same thing, is it correct? If so, is there any reason to believe that one is safer that the other? $\endgroup$
    – XCore
    Apr 9, 2014 at 17:26
  • $\begingroup$ They're both CSPRNGs, yes. If you don't have much experience in crypto, and you've got no good reason to implement your own CSPRNG (such as Fortuna), then /dev/random is a much safer bet. You don't have to concern yourself with entropy, seed-life, etc. $\endgroup$
    – hunter
    Apr 9, 2014 at 17:43
  • 1
    $\begingroup$ A correct implementation isn't enough - you also need to know how to use it correctly. There's no "winner", per se. It just depends on your requirements/circumstances... but without having made a case for managing your own CSPRNG (and it is hands on), I'd definitely suggest you use /dev/random. Anything beyond this - I suggest posting another question (assuming your own research doesn't answer any further questions you might have). $\endgroup$
    – hunter
    Apr 9, 2014 at 17:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.