2

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?

  • 1
    i 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
1

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).

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.