<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Mar 25, 2021 at 5:51 PM Kristian Gjøsteen <<a href="mailto:kristian.gjosteen@ntnu.no">kristian.gjosteen@ntnu.no</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;">23. mar. 2021 kl. 05:22 skrev jrzx <<a href="mailto:jrzx@protonmail.ch" target="_blank">jrzx@protonmail.ch</a>>:<div><blockquote type="cite"><div><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;float:none;display:inline">On Sunday, March 21, 2021 3:49 PM, Kristian Gjøsteen <</span><a href="mailto:kristian.gjosteen@ntnu.no" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" target="_blank">kristian.gjosteen@ntnu.no</a><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;float:none;display:inline">> wrote:</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><blockquote type="cite" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none">The block cipher design paradigm has been a roaring success.<br>We are in a position where an idiot like me can safely us<br>block cipher to design cryptosystems and prove solid><br>theorems about their security.<br></blockquote><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;float:none;display:inline">I don't think I am a complete idiot, and it is non trivial for me to implement the block cipher paradigm without screwing up.</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;float:none;display:inline">You wind up doing a lot of clever and complicated things with nonces and key scheduling.</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;float:none;display:inline">Allegedly, a great many people do screw up.</span></div></blockquote></div><div><br></div><div>Yes, we know. We all know. But you are missing the point.</div><div><br></div><div>Block ciphers do not make your implementation job harder, they make it easier, because you do not (usually!) have to implement the block cipher.</div><div><br></div><div>What makes your implementation job harder is idiots like me designing systems. And you know what: Without block ciphers, idiots like me would still design systems. And they would be harder to implement correctly. As a bonus, they would also be more likely to be insecure **as a design**, rendering secure implementation moot.</div><div><br></div><div>Block ciphers are great. (Callas mentioned <span style="color:rgb(0,0,0)">tweakable block ciphers</span> in another e-mail; they are double-plus great.)</div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">+1 </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">But the real reason I prefer block ciphers over stream ciphers is that stream ciphers have repeatedly turned out to be brittle. A spec with a block cipher is usually pretty hard to screw up. A spec with a stream cipher is difficult to write and difficult to implement.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The fundamental problem is that a stream cipher is implemented by XOR-ing the plaintext with a cipherstream. And that is fragile because if you have two ciphertexts enciphered against the same cipherstream, you can XOR them to get the XOR of the two input ciphers. Ooops.</div><br></div><div><div class="gmail_default" style="font-size:small">Another significant issue is in the design of the cipher, the cipherstream of RC4 was not as unpredictable as people imagined. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Take the design problem I am working on today.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">A host accepts UDP requests from multiple clients which MAY change their Source IP address and port at any time because of NAT deployment. The source IP is not reliable as a means of matching requests to requestors. Since we are likely stuck with 64 bit machines for the foreseeable future, a 64 bit connection identifier is a sufficient alternative. It is highly unlikely we could ever support even 2^32 connections on a single host. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">We are also going to require 16-32 bytes of sequence identifier, stream identifier, acknowledgement, etc.<br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">So in a plaintext world our packets look like this:</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">[Source-ID][T-HEAD][Plaintext]</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"></div><div class="gmail_default" style="font-size:small">If we want to use a stream cipher to encrypt, we need to do this:</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">[Source-ID][T-HEAD][Nonce][Ciphertext][Tag]<br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">So what Mallet sees is</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">[Source-ID][T-HEAD][????][???????????][???]<br></div><br></div><div><div class="gmail_default" style="font-size:small">Quite a bit of data.</div><br></div><div><br></div><div><div class="gmail_default" style="font-size:small">With a block cipher, I can play rather more interesting games. If T-HEAD is unique, I can recycle that to provide my nonce. I can do that with a block cipher because the criteria is 'almost certain'. With a stream cipher, that has to be 'absolutely guaranteed'. And that makes a huge difference in both design and implementation. If Ethernet packets were a sensible 64KB, I wouldn't mind about losing the 16 bytes. But when we are limited to 1260 bytes, I care. A LOT.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">But wait, there is more, with a block cipher I can encrypt those initial T-HEAD bytes. Why give anything away to the opposition? Let k0 be a key that is established at session start and is constant for the lifetime of the session and kn be a key that is formed using a KMAC on the sequence info in T-HEAD and the key agreement data:</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">[Source-ID][E(T-HEAD, k0)][E(Plaintext,kn)][Tag]<br></div><div class="gmail_default" style="font-size:small"><br></div></div><div><div class="gmail_default" style="font-size:small">So what Mallet sees using FRED transport and security is:</div><br></div><div><div class="gmail_default" style="font-size:small">[Source-ID][??????????????????]</div><br></div><div><div class="gmail_default" style="font-size:small">That Source-ID is irritating the heck outta me. It has to be the same every time for the demultiplex to work. Or does it.</div></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Lets make Source-id a full encryption block, for the sake of argument 128 bits. This will cost me 8 bytes.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Each time the Host sends out a response packet, it contains a series of encrypted Source-ID tags. These consist of</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">[Source-ID][Sequence][State]</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The entire tag is encrypted under a static key known only to the host. These are in effect a form of cookie or Kerberos token. When the server receives a request, it simply decrypts the first 16 bytes and it gets back the Source-ID. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">So now what Mallet sees is</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">[??????????????????]<br></div><div><div class="gmail_default" style="font-size:small">[??????????????????]</div><div class="gmail_default" style="font-size:small">[??????????????????]</div><div class="gmail_default" style="font-size:small">[??????????????????]<br></div><br></div><div><div class="gmail_default" style="font-size:small">All I am leaving Mallet at this point is packet timing data. Every packet is padded out to the same number of bytes. Mallet can guess I am using OCB-AES and thus identify the different packet components, but that is all. I probably wouldn't use this approach everywhere, but it certainly makes a lot of sense in TOR type situations.</div><br></div></div></div></div></div></div></div></div></div></div></div></div></div>