I am working on a real-life project for a firm. I have to encrypt data using AES 256 as per specification. I want to know how are the key and IV are really chosen in real world projects. /dev/urandom is good enough for both? Any other advice regarding these?
-
1i would feed 32+bytes of random into SHA3-256, which outputs an AES256-sized key. the SHA3 part distributes the entropy evenly around the bytes and makes it harder to guess, unless your random is really really broken instead of just sub-optimal. – dandavis Jun 2 '16 at 18:26
-
@dandavis Thanks. Makes sense. Also, how do I ensure that IV is always unique? Do I store and always check? What's the right way? – Maxsteel Jun 2 '16 at 18:31
-
1@dandavis They also need to be unpredictable. That is very predictable. The correct answer is to use a CSPRNG. – Luke Park Jun 2 '16 at 21:16
-
1@dandavis I feel like you might misunderstand. The IV does not need to be, nor did I suggest that it should be, secret, just unpredictable. It is considered best practice to use a CSPRNG when generating IV's. I've never seen anyone hash a timestamp and use it as an IV. – Luke Park Jun 3 '16 at 23:04
-
1@dandavis Unpredictable given any prior IVs from prior messages. E.g. the next IV of the next message can be predetermined if it is the hash of a timestamp. With a CSPRNG, this is not the case. Secret =/= unpredictable. – Luke Park Jun 3 '16 at 23:29
|
Show 5 more comments
All that is necessary is that the values are random and unique. It is perfectly acceptable to pull them from your operating system's cryptographic random API or from a crypto library like OpenSSL that contains its own internal cryptographically secure random number generator (CSPRNG).
