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
    Commented Jun 2, 2016 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
    Commented Jun 2, 2016 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
    Commented Jun 2, 2016 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
    Commented Jun 3, 2016 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
    Commented Jun 3, 2016 at 23:29

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

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .