# Secure AES Key Generation via Salsa20?

I am not creating my own cryptography or anything, but to learn about the Dos and Donts of cryptography, I am looking into AES encryption and ways to generate keys for that.

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.

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?

Also, if there are any references or papers I should be aware about, it would be great if you could mention them too.

-
Is there a specific reason that the output of /dev/urandom is not sufficient to be used as an AES key directly? – user4982 Apr 6 '14 at 18:37
/dev/urandom does produce cryptographically secure bytes. You can just read 16, 24 or 32 bytes and use them as an AES key. (The super-paranoid can use /dev/random if they prefer.) Salsa20 is a stream cipher that is currently considered secure. You could use it in a CSPRNG and maybe even a KDF, but you have no reason to further process your key here. – Matt Nordhoff Apr 6 '14 at 18:40
I think taking a perfectly good cryptographic key, doing unspecified, weird and possibly insecure things to it with a cipher, and using that as a key for a second cipher is a bad idea. You have a cipher and a key. Don't complicate it. At best it's strange, and at worst something goes wrong and it's badly insecure. – Matt Nordhoff Apr 6 '14 at 23:45
@MattNordhoff /dev/random is not "more secure" than /dev/urandom. They use the same CSPRNG as each other on all modern UNIXes. – Stephen Touset Apr 7 '14 at 21:41
@StephenTouset Erm… they don’t use the same CSPRNG all the time! /dev/random blocks while gathering new random data from the system hardware whenever the entropy pool is exhausted, while /dev/urandom falls back to pseudo-random-number generators, resulting in a slightly lesser quality of randomness once the initial buffer is outrun. That marks the main difference between both and shows they don’t use the same CSPRNG all the time. What /dev/urandom returns may theoretically be vulnerable to cryptographic attacks on algorithms used by the driver… for crypto, /dev/random should be used. – e-sushi Apr 7 '14 at 23:56

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

-
[+1] for mentioning /dev/random instead of it’s non-blocking counterpart. – e-sushi Apr 8 '14 at 0:03
@hunter But using a symmetric cipher such as AES (or Salsa20) isn't what a Fortuna-based PRNG does? – XCore Apr 9 '14 at 16:40
@XCore - Yes, Fortuna is another CSPRNG that uses a symmetric block-cipher as one of its internal mechanisms. – hunter Apr 9 '14 at 16:54
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? – XCore Apr 9 '14 at 17:26
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). – hunter Apr 9 '14 at 17:58