Subject: Re: [Cfrg] Encrypt in place guidance

From: Leo Perrin <[email-masked]>
Date: Wed, 1 Apr 2020 10:07:07 +0200 (CEST)

Hi,

>> Speck
> 
> Hmm. Were the design criteria for that algorithm
> ever published in the end? (I've not followed it,
> so they may have been.)

The authors of SPECK put something on eprint [1] but it merely lists public results and claims they already knew about the corresponding attacks. I personally don't find this document convincing at all since it came *after* a public analysis. In my opinion (and it is not a controversial one in the academic symmetric crypto community), if the designers of a cipher did not publish their security analysis along with its specification then you should not even consider using the corresponding cipher. Of course, there is also the elephant in the room: SPECK was designed by the same entity as the backdoored DUAL_EC.

By the way, there are many (many!) 64-bit block ciphers in the literature---see Table 6 of [2]. Full disclosure: I am a co-author of this survey. If you have questions about it, feel free to ask!

[1] https://eprint.iacr.org/2017/560
[2] https://eprint.iacr.org/2017/511

Cheers,

/Léo

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 1 Apr 2020 06:57:41 -0400

There is no way the basic messages are changing and expanding as long as 
BT4 is used.

There is an auth message that can carry multiple basic messages.  We 
have a draft in DRIP:

draft-wiethuechter-drip-auth

That provides message protection.  This is up to 10 chained BT4 
broadcasts.  Or 1 BT5 broadcast.

Yes, replay attacks are pretty much built into this architecture. The 
major vendors don't get it or don't care (many are chinese companies).  
The regulators just think this is ATM a little bigger.

We do what we can with what we have.  Build each message the best way 
and make sure they all work better inside the Auth wrapper.

And this does not obviate the need for privacy of the operator 
information.  That would still need to be encrypted.

All a work in progress.  Too many SDOs and regulators involved.

On 4/1/20 2:49 AM, Björn Haase wrote:
>
> I fear that you might actually need at least some more bytes of 
> payload in order to get any sound scheme realized.
>
> For preventing replay attacks a 32 bit nonce and a 32 bit 
> authentication tag might have to be considered to form the bare 
> minimum requirement ☹.
>
> We have had a similar problem with the severely size-limited 
> BluetoothLE advertising (broadcast) packets.
>
> One option that we use is segmenting the information by splitting it 
> into several packets. This way reception of two or more separate
>
> packets is needed in order to get the full information.
>
> Mit freundlichen Grüßen I Best Regards
>
> Dr. Björn Haase
>
> ------------------------------------------------------------------------
> Senior Expert Electronics | TGREH Electronics Hardware
>
> *Endress+Hauser Liquid Analysis*
>
> Endress+Hauser Conducta GmbH+Co.KG | Dieselstrasse 24 | 70839 
> Gerlingen | Germany
> Phone: +49 7156 209 377 | Fax: +49 7156 209 221
> [email-masked] | www.conducta.endress.com
>
> ------------------------------------------------------------------------
>
> Endress+Hauser Conducta GmbH+Co.KG
> Amtsgericht Stuttgart HRA 201908
> Sitz der Gesellschaft: Gerlingen
> Persönlich haftende Gesellschafterin:
> Endress+Hauser Conducta
> Verwaltungsgesellschaft mbH
> Sitz der Gesellschaft: Gerlingen
> Amtsgericht Stuttgart HRA 201929
> Geschäftsführer: Dr. Manfred Jagiella
>
> ------------------------------------------------------------------------
>
> Gemäss Datenschutzgrundverordnung sind wir verpflichtet, Sie zu 
> informieren, wenn wir personenbezogene Daten von Ihnen erheben.
>
> Dieser Informationspflicht kommen wir mit folgendem Datenschutzhinweis 
> <https://www.de.endress.com/de/cookies-endress+hauser-website> nach.
>
> ------------------------------------------------------------------------
>
> Disclaimer:
>
> The information transmitted is intended only for the person or entity 
> to which it is addressed and may contain confidential, proprietary, 
> and/or privileged
> material. Any review, retransmission, dissemination or other use of, 
> or taking of any action in reliance upon, this information by persons 
> or entities
> other than the intended recipient is prohibited. If you receive this 
> in error, please contact the sender and delete the material from any 
> computer.
> This e-mail does not constitute a contract offer, a contract 
> amendment, or an acceptance of a contract offer unless explicitly and 
> conspicuously designated or stated as such.
>
>
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/cfrg

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 1 Apr 2020 08:15:56 -0400

Leo,

Thank for this paper. I will investigate the various ciphers in it.

I suspect that after Apr 9 (next ASTM meeting), I will need to encrypt 
96 bits as they address the lack of Operator altitude in the message.  I 
cannot attend the meeting, as it schedule during Passover.  Oh well, my 
colleagues will be there to put forth my position.

So I am looking for both a 64 bit and 96 bit block cipher.  I figured 
out that if there is no 96 bit, I can do this by first encrypting the 
1st 64 bits and then the last 64 bits.  The middle 32bits are double 
encrypted, but I not seeing that as a problem. But then I am not a 
cryptographer, only a crypto-plumber.

Again thank you for your assistance.

Bob

---

From: Leo Perrin <[email-masked]>
Date: Wed, 1 Apr 2020 15:36:32 +0200 (CEST)

> cryptographer, only a crypto-plumber.

I would advise you *not* to do this: this effectively creates a 96-bit block cipher with at least one significant flaw.

Suppose that your plaintext is (A,B,C), where each word is 32-bit long, and that you use a block cipher E_k operating on 64 bits. Then you would first obtain (W,X) = E_k(A,B), and then (Y,Z) = E_k(X,C), so that the encryption of (A,B,C) is (W,Y,Z). The problem with this approach is that W does not depend on C. A similar behaviour exists for decryption (C does not depend on W). As a consequence, this 96-bit block cipher does not provide full diffusion!

It is better to use a dedicated 96-bit block cipher. There are not many of them but they exist:
- BKSQ, from the AES designers (essentially a 96-bit AES);
- SEA,
- EPCBC.
The references for these are in our survey.

If you really need to turn a 64-bit block cipher into a 96-bit one, then you would need to do at least 3 iterations of the 64-bit cipher instead of 2 as you suggested:

(A, B, C) ---(E_k, Id)---> (W, X, C)
(W, X, C) ---(Id, E_k)---> (W, Y, Z)
(W, Y, Z) ---(E_k, Id)---> (T, U, Z)

Still: from a security stand-point, I would much prefer a dedicated 96-bit cipher if I were in your position.

Cheers,

/Léo

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 1 Apr 2020 10:48:12 -0400

> I would advise you *not* to do this: this effectively creates a 96-bit block cipher with at least one significant flaw.

This is why I know to ask on this list.

> Suppose that your plaintext is (A,B,C), where each word is 32-bit long, and that you use a block cipher E_k operating on 64 bits. Then you would first obtain (W,X) = E_k(A,B), and then (Y,Z) = E_k(…

Ah.

> The references for these are in our survey.

Good.  Thanks for the pointers.

> Still: from a security stand-point, I would much prefer a dedicated 96-bit cipher if I were in your position.

I would also prefer a real 96 bit cipher than tricking a 64 bit to do 
the job, but it is good to know the proper construct.

Thanks

Bob

---

From: Dan Brown <[email-masked]>
Date: Wed, 1 Apr 2020 15:04:43 +0000

> -----Original Message-----
> From: Cfrg <[email-masked]> On Behalf Of Leo Perrin
> 
> I would advise you *not* to do this: this effectively creates a 96-bit block
> cipher with at least one significant flaw.
> 
> Suppose that your plaintext is (A,B,C), where each word is 32-bit long, and that
> you use a block cipher E_k operating on 64 bits. Then you would first obtain
> (W,X) = E_k(A,B), and then (Y,Z) = E_k(X,C), so that the encryption of (A,B,C) is
> (W,Y,Z). The problem with this approach is that W does not depend on C. A
> similar behaviour exists for decryption (C does not depend on W). As a
> consequence, this 96-bit block cipher does not provide full diffusion!
> 
This is a good catch!  

Another way to say this is that information leaks.  If A,B ever repeats, then W repeats, so information about A,B leaks.

(Hmm, also in a previous message Robert said that K is re-used, so if (A,B,C) repeats, then (W,Y,Z) repeats.  What is the threat model here?)

Also, Leo's observation implies a weakening of implicit message authentication.  An adversary who sees (W,Y,Z) replaces it by (W',Y,Z), which decrypts to (A',B',C) where A' and B' are junk, but C is real.  If the decrypted messages are explicit authenticated based on message redundancy, and most of the redundancy is C, then a kind of forgery is obtained. 

> 
> If you really need to turn a 64-bit block cipher into a 96-bit one, then you
> would need to do at least 3 iterations of the 64-bit cipher instead of 2 as you
> suggested:
> 

Surely somebody has studied such constructions?  I remember hearing about how many rounds of Feistel ladder were necessary, etc.

Intuitively, there ought to some kind of limitation to the security of such constructions, or else one could build up a large block size from a very small size, which sounds implausible.  That said, I never studied block cipher design ...

----------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.