<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>Dear,<br>
</p>
<div class="moz-cite-prefix">Dne 27. 4. 2017 v 0:28 Jon Callas
napsal(a):<br>
</div>
<blockquote
cite="mid:AF56F496-5DC5-4F1B-BDC3-842A3070E651@callas.org"
type="cite">
<pre wrap="">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.)</pre>
</blockquote>
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)<br>
<blockquote
cite="mid:AF56F496-5DC5-4F1B-BDC3-842A3070E651@callas.org"
type="cite">
<pre wrap="">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.
</pre>
</blockquote>
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:<br>
Random<sub>n</sub>=Enc(Key;Counter<sub>n</sub>)<br>
or more specific using the GF(2)<br>
Random<sub>n</sub>=Enc(Key;GF(2)<sub>n</sub>)<br>
<br>
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
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<span style="font-size:9.0pt;font-family:Calibri;
mso-ascii-font-family:Calibri;mso-fareast-font-family:+mn-ea;mso-bidi-font-family:
+mn-cs;mso-ascii-theme-font:minor-latin;mso-fareast-theme-font:minor-fareast;
mso-bidi-theme-font:minor-bidi;color:black;mso-color-index:1;mso-font-kerning:
12.0pt;language:cs;mso-style-textfill-type:solid;mso-style-textfill-fill-themecolor:
text1;mso-style-textfill-fill-color:black;mso-style-textfill-fill-alpha:100.0%">x</span><span
style="font-size:9.0pt;font-family:Calibri;mso-ascii-font-family:Calibri;
mso-fareast-font-family:+mn-ea;mso-bidi-font-family:+mn-cs;mso-ascii-theme-font:
minor-latin;mso-fareast-theme-font:minor-fareast;mso-bidi-theme-font:minor-bidi;
color:black;mso-color-index:1;mso-font-kerning:12.0pt;language:cs;vertical-align:
super;mso-text-raise:30%;mso-style-textfill-type:solid;mso-style-textfill-fill-themecolor:
text1;mso-style-textfill-fill-color:black;mso-style-textfill-fill-alpha:100.0%">128</span><span
style="font-size:9.0pt;font-family:Calibri;mso-ascii-font-family:Calibri;
mso-fareast-font-family:+mn-ea;mso-bidi-font-family:+mn-cs;mso-ascii-theme-font:
minor-latin;mso-fareast-theme-font:minor-fareast;mso-bidi-theme-font:minor-bidi;
color:black;mso-color-index:1;mso-font-kerning:12.0pt;language:cs;mso-style-textfill-type:
solid;mso-style-textfill-fill-themecolor:text1;mso-style-textfill-fill-color:
black;mso-style-textfill-fill-alpha:100.0%">+x</span><span
style="font-size:
9.0pt;font-family:Calibri;mso-ascii-font-family:Calibri;mso-fareast-font-family:
+mn-ea;mso-bidi-font-family:+mn-cs;mso-ascii-theme-font:minor-latin;mso-fareast-theme-font:
minor-fareast;mso-bidi-theme-font:minor-bidi;color:black;mso-color-index:1;
mso-font-kerning:12.0pt;language:cs;vertical-align:super;mso-text-raise:30%;
mso-style-textfill-type:solid;mso-style-textfill-fill-themecolor:text1;
mso-style-textfill-fill-color:black;mso-style-textfill-fill-alpha:100.0%">7</span><span
style="font-size:9.0pt;font-family:Calibri;mso-ascii-font-family:Calibri;
mso-fareast-font-family:+mn-ea;mso-bidi-font-family:+mn-cs;mso-ascii-theme-font:
minor-latin;mso-fareast-theme-font:minor-fareast;mso-bidi-theme-font:minor-bidi;
color:black;mso-color-index:1;mso-font-kerning:12.0pt;language:cs;mso-style-textfill-type:
solid;mso-style-textfill-fill-themecolor:text1;mso-style-textfill-fill-color:
black;mso-style-textfill-fill-alpha:100.0%">+x</span><span
style="font-size:
9.0pt;font-family:Calibri;mso-ascii-font-family:Calibri;mso-fareast-font-family:
+mn-ea;mso-bidi-font-family:+mn-cs;mso-ascii-theme-font:minor-latin;mso-fareast-theme-font:
minor-fareast;mso-bidi-theme-font:minor-bidi;color:black;mso-color-index:1;
mso-font-kerning:12.0pt;language:cs;vertical-align:super;mso-text-raise:30%;
mso-style-textfill-type:solid;mso-style-textfill-fill-themecolor:text1;
mso-style-textfill-fill-color:black;mso-style-textfill-fill-alpha:100.0%">2</span><span
style="font-size:9.0pt;font-family:Calibri;mso-ascii-font-family:Calibri;
mso-fareast-font-family:+mn-ea;mso-bidi-font-family:+mn-cs;mso-ascii-theme-font:
minor-latin;mso-fareast-theme-font:minor-fareast;mso-bidi-theme-font:minor-bidi;
color:black;mso-color-index:1;mso-font-kerning:12.0pt;language:cs;mso-style-textfill-type:
solid;mso-style-textfill-fill-themecolor:text1;mso-style-textfill-fill-color:
black;mso-style-textfill-fill-alpha:100.0%">+x+1, which in one
hands allow to generate about 3,83*10</span><span
style="font-size:9.0pt;font-family:Calibri;mso-ascii-font-family:
Calibri;mso-fareast-font-family:+mn-ea;mso-bidi-font-family:+mn-cs;mso-ascii-theme-font:
minor-latin;mso-fareast-theme-font:minor-fareast;mso-bidi-theme-font:minor-bidi;
color:black;mso-color-index:1;mso-font-kerning:12.0pt;language:cs;vertical-align:
super;mso-text-raise:30%;mso-style-textfill-type:solid;mso-style-textfill-fill-themecolor:
text1;mso-style-textfill-fill-color:black;mso-style-textfill-fill-alpha:100.0%">36</span><span
style="font-size:9.0pt;font-family:Calibri;mso-ascii-font-family:Calibri;
mso-fareast-font-family:+mn-ea;mso-bidi-font-family:+mn-cs;mso-ascii-theme-font:
minor-latin;mso-fareast-theme-font:minor-fareast;mso-bidi-theme-font:minor-bidi;
color:black;mso-color-index:1;mso-font-kerning:12.0pt;language:cs;mso-style-textfill-type:
solid;mso-style-textfill-fill-themecolor:text1;mso-style-textfill-fill-color:
black;mso-style-textfill-fill-alpha:100.0%"> GF(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. <br>
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<sup>61</sup>
blocks.<br>
</span>
<meta name="ProgId" content="PowerPoint.Slide">
<meta name="Generator" content="Microsoft PowerPoint 15">
<blockquote
cite="mid:AF56F496-5DC5-4F1B-BDC3-842A3070E651@callas.org"
type="cite">
<pre wrap="">
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
</pre>
</blockquote>
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: <br>
<span class="fontstyle01"><span style="font-size: 10.0pt;
font-family: "
calibri",sans-serif;mso-ascii-theme-font: minor-latin;
mso-hansi-theme-font: minor-latin;">XTS_Key=K<sub>1</sub>||K<sub>2</sub></span></span><span
class="fontstyle01"><span style="font-size: 10.0pt; font-family:
" calibri",sans-serif;mso-ascii-theme-font:
minor-latin; mso-hansi-theme-font: minor-latin;"><br>
Tweak = Enc(K<sub>2</sub>, sector_number) </span></span><span
class="fontstyle21"><span style="font-size: 10.0pt; font-family:
" cambria math",serif; mso-bidi-font-family:
"">⊗</span></span><span class="fontstyle21"><span
style="font-size: 10.0pt; font-family: "
calibri",sans-serif;mso-ascii-theme-font: minor-latin;
mso-hansi-theme-font: minor-latin;"> α<sup>block_number</sup></span></span><span
class="fontstyle01"><span style="font-size: 10.0pt; font-family:
" calibri",sans-serif;mso-ascii-theme-font:
minor-latin; mso-hansi-theme-font: minor-latin;"><br>
Ciphertext = Enc(K<sub>1</sub>, Plaintext </span></span><span
class="fontstyle21"><span style="font-size: 10.0pt; font-family:
" cambria math",serif; mso-bidi-font-family:
"">⊕</span></span><span class="fontstyle21"><span
style="font-size: 10.0pt; font-family: "
calibri",sans-serif;mso-ascii-theme-font: minor-latin;
mso-hansi-theme-font: minor-latin;"> </span></span><span
class="fontstyle01"><span style="font-size: 10.0pt; font-family:
" calibri",sans-serif;
mso-ascii-theme-font: minor-latin; mso-hansi-theme-font:
minor-latin;">Tweak) </span></span><span class="fontstyle21"><span
style="font-size: 10.0pt; font-family: " cambria
math",serif; mso-bidi-font-family: "">⊕</span></span><span
class="fontstyle21"><span style="font-size: 10.0pt; font-family:
" calibri",sans-serif;mso-ascii-theme-font:
minor-latin; mso-hansi-theme-font: minor-latin;"> </span></span><span
class="fontstyle01"><span style="font-size: 10.0pt; font-family:
" calibri",sans-serif;
mso-ascii-theme-font: minor-latin; mso-hansi-theme-font:
minor-latin;">Tweak</span></span><br>
<br>
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).<br>
<blockquote
cite="mid:AF56F496-5DC5-4F1B-BDC3-842A3070E651@callas.org"
type="cite">
<pre wrap="">
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.</pre>
</blockquote>
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<sup>32</sup> blocks,
which mean about 256GB of data. This lead to requirement of some
rekeying methods also.<br>
<blockquote
cite="mid:AF56F496-5DC5-4F1B-BDC3-842A3070E651@callas.org"
type="cite">
<pre wrap="">
Jon
</pre>
</blockquote>
I hope that did not make a huge mess about<br>
<br>
Regards<br>
<br>
Jan<br>
<pre class="moz-signature" cols="72">--
Jan Dušátko
Phone: +420 602 427 840
e-mail: <a class="moz-txt-link-abbreviated" href="mailto:jan@dusatko.org">jan@dusatko.org</a>
SkypeID: darmodej
GPG: <a class="moz-txt-link-freetext" href="http://www.dusatko.org/downloads/jdusatko.asc">http://www.dusatko.org/downloads/jdusatko.asc</a></pre>
</body>
</html>