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

Thu Apr 27 03:14:23 EDT 2017

Dear,

Dne 27. 4. 2017 v 0:28 Jon Callas napsal(a):
> Personally, I would recommend that you *not* use counter mode or anything resembling it for writing files. There's nothing wrong with CBC mode for your purposes. (Or CFB, for that matter, but I really don't want to digress down that path.)
This is not true. There are bunch of modes based on CBC principle (PCBC,
XCBC, HCBC and there are more than 20 others, more or less advantage) or
CFB. The CBC and CFB found some issues and there are requirement to use
something like MAC value, because there are simply no control for
possible modification of ciphertext. From other point of view, CBC and
CFB has relatively good properties and oposite of other modes from
ad-hoc generation are quite safe. And, what is funny, although the CBC
needs a MAC, can be used to create a MAC by it's properties (CCM mode is
the Counter mode with CBC MAC)
> Counter mode creates a stream cipher. Stream ciphers nearly universally work by creating a stream of random bits (typically called the key stream) that is then XORed on to your plaintext. The first major issue with stream ciphers is that if you reuse a key, you give the attacker a trivial attack on your system. If there is any known plaintext in the first stream, you XOR that known plaintext onto the first ciphertext which yields you the key stream, and then you XOR the known key stream onto the second cipher text yielding its plaintext. In short, a stream cipher is an approximation of a one-time pad and the first rule of one-time pads is that you better use them at most one time. Put another way, when you use counter mode, you must not only keep the key secret, you must keep the key stream secret.
Stream cipher can be imagined as stream of random, XORed with the
plaintext. Stream of random is the vital properties, we use this kind of
technique also in CSPRNG to assure unpredictable output. But, for
CSPRNG, identical initialization leads to the same output, what is also
important for both sides. The counter modes depend of the counter
properties. Basicaly, there are regular integer counter (regular
incrementation or prime number generated field) and GF(2) body, which
can be based on polynoms. This mean, you need to assure IV and key safe
to provide CSPRNG properties. This can be imagined as:
Random_n =Enc(Key;Counter_n )
      or more specific using the GF(2)
Random_n =Enc(Key;GF(2)_n )

The counter are incremented in each step, but it is known for people,
who know IV and method, how the GF field is initialized. For example,
the GF(2) for AES in GCM mode using polynome x128+x7+x2+x+1, which in
one hands allow to generate about 3,83*1036GF(2)s, from other hands you
are limited to use only 54GB of data before rekeying. Simply because
later you will reuse keys ... which mean key collision. The fields is
generated based on 128b IV. 
The CCM mode is little bit slower (because there are no CPU acceleration
for polynomials and you need to do encryption two times, one for CTR and
one for CBC). But CCM recommend do not use only 128-bit key, but
256-bit. Also, there are limits from principle, where you do not
recommend to cross over 2^61 blocks.
> In a communications protocol, this typically isn't a big deal because you're going to pull a key from your random number generator, and if that isn't different, you have bigger problems.
>
> However, when it comes to files, there's going to be the temptation to allow a seek operation. If they seek backwards, then it all starts to unravel. Worse, counter mode makes it easy to seek backwards, and thus increases the chance that someone will. If you seek, you're rewriting in place. If you rewrite in place, then you are reusing your key.  Thus, my advice is not to use counter mode for storage. Even if you do it right, it's like leaving a rake in the yard with the tines up. It's just asking for someone to come along and step on it.
>
> Hence, just use CBC mode. Yeah, I know it sucks. Most of the ways that it sucks either don't matter when you're writing a file (because those problems come from using CBC in an online protocol, where you *should* use a stream cipher) or you can code around them (like using ciphertext stealing instead of padding). But CBC has the added advantage that it's a pain in the butt to seek in a file
I recommend do not use CBC mode, but please take a look on the EME2
mode. There are few advantages. First, EME2 has been standardized (but
not used) for storage. Second, this is AEAD (Authenticated Encryption
with Associated Data). Third - ABL (Arbitrary Block Lenght). And, you
can easily modify it for encrypt files only. This mode allow to provide
good safety about unauthorized modification, chain each value inside. It
is much better than for example XEX/XTS mode also used for storage (disk
encryption) - example bellow:
XTS_Key=K_1 ||K_2
Tweak = Enc(K_2 , sector_number) ⊗α^block_number
Ciphertext = Enc(K_1 , Plaintext ⊕Tweak) ⊕Tweak

What could be important, EME2 can be paralellized for encryption and
decryption. The sad part, if I count it well, require 2,5 encryption per
block oposite of CBC/CFB/CTR (one encryption).
> But that isn't the question you asked, is it?
>
> When you're using counter mode, it doesn't matter what the counter is. The basic construction is that you encrypt 0 and xor that onto plaintext. Then encrypt 1, then 2, and so on. It is, after all, *counter* mode. It doesn't matter at all what you start the counter with. It doesn't even really matter what you increment with. It only matters that you don't repeat a counter value. (And actually it only matters that no one knows you repeated a counter value, but don't tell anyone I said that.)
>
> In fact, one of the really cool things about counter mode is that it doesn't matter what you start the counter with. This is unlike an IV for CBC, CFB, etc. where it *does* matter. Zero is a great counter. It's an awful IV. Counters aren't IVs, even when you pass them into the "iv" parameter in the api.
>
> Since you're probably going to counter mode anyway, you might want to use an AEAD (Authenticated Encryption with Additional Data) mode. I caution against using GCM mode. It has a number of things going for it: it's fast (except when it is slow), and parallelizable. It is, however, brittle. It was originally created for Chuck Jones to use in the famous Road Runner cartoon, "Beep-Beep Blockchain" with Wile E. Coyote using in his famous attempt to take over the Road Runner's mining operation. As he often ended up doing with nitroglycerin, the Coyote disrespected a nonce, and even people who haven't seen the cartoon can guess what happened in the final scene. Either CCM mode or ChaCha20-Poly1305 are reasonable alternatives. OCB might be an option for you, too, but all of that's a different discussion.
You can use the OCB and eventually IAPM, which are quite similar (both
of them described well), but still I would like to avoid cross approx.
the 64GB limit, but this is only probability method, nothing like hard
collision. ChaCha20-Poly1305 is quite better from this point. There are
limits to use signle key for 2^32 blocks, which mean about 256GB of
data. This lead to requirement of some rekeying methods also.
>
> 	Jon
>
I hope that did not make a huge mess about

Regards

Jan

-- 
Jan Dušátko

Phone:		+420 602 427 840
e-mail:		jan at dusatko.org
SkypeID:	darmodej
GPG:		http://www.dusatko.org/downloads/jdusatko.asc

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20170427/227cda0c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jan.vcf
Type: text/x-vcard
Size: 172 bytes
Desc: not available
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20170427/227cda0c/attachment.vcf>