Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It only takes a minute to sign up.
Sign up to join this community
I need to generate a key and IV that will be used to encrypt multiple things over a period of time with AES in CFB mode. The decision to use AES in CFB mode is not mine to change and the key will only ever be stored in a secure way or transmitted out-of-band (i.e., not over any network where it could be intercepted)
What's the best tool for generating such a key and IV on Windows in a way that ensures they are secure?
For CFB mode, the main requirement on the IV is that you don't reuse the same IV to encrypt two different messages. If you do, the consequences are only moderately bad (the attacker learns the xor of the two initial plaintext blocks of the two messages, and more if those two plaintext blocks happen to be the same), it's probably best to avoid that. It doesn't matter if the IV is predictable (unlike CBC mode); non-reuse is the only requirement.
That said, there are a number of ways to achieve it. The first obvious one (generate them using a counter) probably doesn't apply to you (as you may not have any place to store them over reboots). On the other hand, picking them randomly works (and, unlike most uses of RNGs in crypto, it doesn't have to be that strong - again, we're only looking to avoid reuse). A third approach would be to generate a Message Authentication Code of the plaintext (based on a secret key) and use that as your IV - that would make it obvious when you are encrypting the same message twice (the ciphertexts will be exactly the same); however it doesn't rely on an external RNG or entropy source.
If you have a (system backed) secure key store then you should create it using the methods provided by that key store. The idea is that a key isn't available outside the key store after all. Getting a good source of randomness is not such a problem; making sure that it doesn't remain in persistent or transient memory is much harder.
For the IV you can use system RNG or one of a known good, cryptographically secure RNG (e.g. the one used by openssl is - uh - usually secure) to create a 16 byte random number. You should create one unique IV per message; in other words: the IV needs to be message specific and it is usually stored with the message. The IV can also be a (hash or encryption of) a unique number (nonce) that is part of the message or message meta-data.
If you're not using a keystore you can also use the secure random number generator to create the 32 byte key and write it directly to a storage device. I'd prefer to overwrite the array with zero's afterward. Note that it could still be cached anywhere in the I/O system; it depends on the use case if that's a problem or not.
