[Cryptography] Question re: Initialization Vector for AES Counter Mode…

[Andrew Donoho]

Gentlefolk,



	I am writing an app that encrypts files. Based upon private communications with members of this list and other crypto recommendation documents, the common advice is that I should use AES counter mode. What should my IV be? I’ve read one IETF standard that puts random bytes in the upper 64 bits and 1 in the lower 64 bits. My naïve view is that I should just choose the same number of random bytes, 16, for the IV as I do for a CBC mode. This is for a file whose length is limited, by the platform API, to an unsigned long long size (i.e. 64 bits). My concern is unsigned overflow of the IV. In practice, this is only ever a problem when the top 68 bits of the IV are all 1s. I can easily test for this situation and just ask the random number system for a new 128 bits. Of course, this is an infinitesimal reduction in the numbers available for an IV (2^128 - 2^60 or thereabouts).

	The bigger question is, I think, that the above problematic IV has lower entropy than I think it should. Perhaps I should be putting my random IV bytes through some kind of entropy test before using them? (Picking the IV is a rare event and much faster than writing the data to the file. Hence, testing before using is totally practical.) This, by design, reduces the pool of values from which the IV can be chosen, albeit in a non-deterministic fashion. Any recommendations of which entropy test to use?

	Or is this not an issue? To hamper plaintext attacks, I suspect it is.

	This group’s sage advice is welcome and thankfully acknowledged in advance.



Anon,
Andrew
____________________________________
Andrew W. Donoho
Donoho Design Group, L.L.C.
awd at DDG.com, +1 (512) 750-7596, twitter.com/adonoho

Essentially, all models are wrong, but some are useful.
	— George E.P. Box

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20170426/0a86c229/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 204 bytes
Desc: Message signed with OpenPGP
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20170426/0a86c229/attachment.sig>