Subject: Re: [Cfrg] Encrypt in place guidance

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Wed, 1 Apr 2020 14:06:44 +0000

Robert,

You're in luck, because Speck offers 96-bit block-size (with key size 96 or 144 bits). ;-)

This (variable block size) was one of the advantages of Speck over, e.g., AES. So the ISO first trimmed it down to the AES capabilities, and then decided "oh well, we already have AES".

On 4/1/20, 09:38, "Cfrg on behalf of Leo Perrin" <[email-masked] on behalf of [email-masked]> wrote:

    > 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.
    
    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
    
    _______________________________________________
    Cfrg mailing list
    [email-masked]
    https://www.irtf.org/mailman/listinfo/cfrg

---

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

> You're in luck, because Speck offers 96-bit block-size (with key size 96 or 144 bits). ;-)

I did see that and felt it was a strong point for Speck.

> This (variable block size) was one of the advantages of Speck over, e.g., AES. So the ISO first trimmed it down to the AES capabilities, and then decided "oh well, we already have AES".

I saw that in the IACR slides:

Gee look at all these great advantages it has.

But the other guys don't, so let's strip them out.

Oh, gee, no advantage here, so let's just drop it.

Got to love that logic.  Of course if it is really a broken cipher, then 
it is broken.

There is really crypto justification for AEAD.  But this comes at a 
serious cost that sometimes cannot be met.

Having options like what Speck provides has value.  Not great, but a 
real value.

Yes, there are all sorts of replay attacks.  There are some use-case 
related mitigations.  In this case, so the operator is lieing about 
where they are.  So what, they can do that anyway and have all the 
crypto right.

This is why, on a system level, we are proposing how an authorized 
entity can directly and securely message the operator's control system 
with such things as:  "Land now or be shot out of the air and THEN we 
will come to get you." Much more timely than trying to send an officer 
to the supposed Geo position of the operator first.

:)

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 1 Apr 2020 15:05:42 +0000

I tried to find some overview discussion of the ISO, and apparently the slides I chose were not good.

ISO rejected Simon/Speck because they didn’t trust the ciphers; one of the reasons for that was that there was no security analysis.

---

From: Jeffrey Walton <[email-masked]>
Date: Wed, 1 Apr 2020 11:49:25 -0400

> ISO rejected Simon/Speck because they didn’t trust the ciphers; one of the reasons for that was that there was no security analysis.

The ISO eventually adopted Simon and Speck in other standards,
however. ISO/29167-21 (for Simon) and ISO/29167-22 (for Speck). The
29167 ISO has something to do with RFID.

Jeff

---

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

> 29167 ISO has something to do with RFID.

In that standard (29167), SIMON and SPECK are in good company with... the "XOR encryption" (29167-15), i.e. the XOR of a fixed string. Being included in that standard is then obviously *not* a sign of trustworthiness. 

To be fair, it is not a sign of untrustworthiness either. In fact, 29167 seems to be intended to contain everything as good algorithms can also be found in it: PRESENT is 29167-11, Grain is 29167-13, and the AES is 29167-14. Why did they standardize "XOR encryption"? Why do so after standardizing the AES? I don't have the slightest clue.

/Léo

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Wed, 1 Apr 2020 16:14:44 +0000

The clue may lie in the specifics of their use case(s) and the corresponding threat models. 

Regards,
Uri

Sent from my iPhone

> On Apr 1, 2020, at 12:11, Leo Perrin <[email-masked]> wrote:
> 
>

---

From: Michael StJohns <[email-masked]>
Date: Wed, 1 Apr 2020 12:15:35 -0400

Pretty much every IOT chip these days has support for at least AES 128 
(and usually for ECB and  CTR and/or CCM).   Unless there is a good 
reason to use something else, assuming you have a good IV source, use 
AES-CTR - it can be used for any number of bytes without expansion.  If 
you don't have a great IV source, use something like AES-CFB8.   Avoid 
domain specific algorithms that may or may not have had security 
analyses done that are appropriate to your domain.

You should have some some sort of message authentication/integrity 
protection and that's a physics problem that needs to be solved by 
allocating some additional bytes.  Generally at least 4 for an integrity 
tag.   If you have that space, move to AES-CCM as your mode.

IMO, Speck may be a better choice later on as it gains more public 
experience and more implementations but you may want to think twice 
about including it in a specification at this time.

Later, Mike

On 4/1/2020 10:58 AM, Robert Moskowitz wrote:
> Got to love that logic.  Of course if it is really a broken cipher, 
> then it is broken.
>
>> On 4/1/20, 09:38, "Cfrg on behalf of Leo Perrin"<[email-masked] on behalf of [email-masked]>  wrote:
>>
>>

---

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

On 4/1/20 12:15 PM, Michael StJohns wrote:
> AES-CTR - it can be used for any number of bytes without expansion.  
> If you don't have a great IV source, use something like AES-CFB8.

Michael,

I went looking for CFB8 and was only getting CFB.  Can you please 
provide a pointer to it?

Thanks.

Bob

>    Avoid domain specific algorithms that may or may not have had 
> security analyses done that are appropriate to your domain.
>
> allocating some additional bytes.  Generally at least 4 for an 
> integrity tag.   If you have that space, move to AES-CCM as your mode.
>
>> entity can directly and securely message the operator's control 
>> system with such things as:  "Land now or be shot out of the air and 
>> THEN we will come to get you." Much more timely than trying to send 
>> an officer to the supposed Geo position of the operator first.
>>
>> :)
>>

---

From: Michael StJohns <[email-masked]>
Date: Wed, 1 Apr 2020 12:33:09 -0400

NIST SP800-38A -  Section 6.3.   CFB can work on any number of bits up 
to the block size.  CFB8 does a byte at a time and uses a block cipher 
operation for each byte.

Mike

On 4/1/2020 12:25 PM, Robert Moskowitz wrote:
>> Pretty much every IOT chip these days has support for at least AES 
>> 128 (and usually for ECB and  CTR and/or CCM).   Unless there is a 
>> good reason to use something else, assuming you have a good IV 
>> source, use AES-CTR - it can be used for any number of bytes without 
>> expansion.  If you don't have a great IV source, use something like 
>> AES-CFB8.
>
> Michael,
>

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Wed, 1 Apr 2020 16:36:20 +0000

Performance of CFB8 leaves something to be desired. Some chips have hardware AES, others don’t. 

I for one am happy with what I’ve seen of the security analysis and the algorithm design itself. YMMV. 

Sizes of IV and auth tag depend on the use case and it’s threat model (did I say that already?). Though I concede that if the use case can tolerate full-size for them, there’s no reason to do otherwise (in my area there’s no such thing as “excessive force” :).

Regards,
Uri

Sent from my iPhone

> On Apr 1, 2020, at 12:16, Michael StJohns <[email-masked]> wrote:
> 
> 
> Pretty much every IOT chip these days has support for at least AES 128 (and usually for ECB and  CTR and/or CCM).   Unless there is a good reason to use something else, assuming you have a good IV source, use AES-CTR - it can be used for any number of bytes without expansion.  If you don't have a great IV source, use something like AES-CFB8.   Avoid domain specific algorithms that may or may not have had security analyses done that are appropriate to your domain.
> 
> You should have some some sort of message authentication/integrity protection and that's a physics problem that needs to be solved by allocating some additional bytes.  Generally at least 4 for an integrity tag.   If you have that space, move to AES-CCM as your mode.
> 
> IMO, Speck may be a better choice later on as it gains more public experience and more implementations but you may want to think twice about including it in a specification at this time. 
> Later, Mike
> 
> 
> 
>> Got to love that logic.  Of course if it is really a broken cipher, then it is broken.
>> 
>> There is really crypto justification for AEAD.  But this comes at a serious cost that sometimes cannot be met.
>> 
>> Having options like what Speck provides has value.  Not great, but a real value.
>> 
>> Yes, there are all sorts of replay attacks.  There are some use-case related mitigations.  In this case, so the operator is lieing about where they are.  So what, they can do that anyway and have all the crypto right.
>> 
>> This is why, on a system level, we are proposing how an authorized entity can directly and securely message the operator's control system with such things as:  "Land now or be shot out of the air and THEN we will come to get you." Much more timely than trying to send an officer to the supposed Geo position of the operator first.
>> 
>> :)
>>

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 1 Apr 2020 13:13:42 -0400

> to the block size.  CFB8 does a byte at a time and uses a block cipher 

Got.  My copy of 38A is from '02; I will have to see if there is an 
updated version, but sec 6.3 is there in my copy and I see how CFB8 works.

Two questions:

Operator and USS have 1 IV for the mission.  Because of potential of 
lost messages, cannot make a chain as mentioned previously.

1) Can the same IV be used for multiple 8 byte location blocks using 
CFB8?  Since the first 4 bytes are a signed integer:

Int signed deg*10^7 (LE)    e.g. –11989298

It is likely that if the latitude is changing, it will only be in byte 
3.  It is possible that latitude is fix (the operator is walking 
straight east or west) and only the last byte is changing in longitude.

2) What about CFB16 for efficiency?  Changes will tend to be in bytes 4 
and 8.  Attackers will know this.

I feel more comfortable with some 64 bit cipher if I can't get that 2 
byte IV counter....

thanks

>>>> Yes, there are all sorts of replay attacks.  There are some 
>>>> use-case related mitigations.  In this case, so the operator is 
>>>> lieing about where they are.  So what, they can do that anyway and 
>>>> have all the crypto right.
>>>>
>>>> system with such things as:  "Land now or be shot out of the air 
>>>> and THEN we will come to get you." Much more timely than trying to 
>>>> send an officer to the supposed Geo position of the operator first.
>>>>
>>>> :)
>>>>

---

From: Sergey Agievich <[email-masked]>
Date: Thu, 2 Apr 2020 15:38:12 +0000

Q1. How to encrypt an m-bit plaintext X using an n-bit block cipher E = {E_K} for n > m?

If the encryption speed doesn't matter, we can use the following approach based on the Feistel scheme. This approach is already being used in format-preserving encryption.

    Enc(X, K):
      1. Y <- X.
      2. Split Y into 2 equal parts: Y = Y1 || Y2
      (let us assume for simplicity that m is even).
      3. For i = 1, 2, ..., d do:
        Y <- Y2 || (Y1 ^ first_m/2_bits(E_K(Y2 || Ci)),
      where Ci is a (n - m/2)-bit round constant.
      4. Y <- Y2 || Y1.
      5. Return Y.

    Dec(Y, K):
      1. X <- Y.
      2. Split X into 2 equal parts: X = X1 || X2.
      3. For i = d, ..., 2, 1 do:
        X <- X2 || (X1 ^ first_m/2_bits(E_K(X2 || Ci)).
      4. X <- X2 || X1.
      5. Return X.

According to the theory, to provide CCA security guarantees (CCA = Chosen Ciphertext Attacks) for m-bit encryption X |-> Y, we should choose d >= 6. It seems very ineffective that when shortening the block length, we have to use 6 times more block encryptions. On the other hand, we preserve both the block cipher interface and security guarantees in a simple way.

Q2. How to encrypt an (3n/2)-bit plaintext X using an n-bit block cipher E = {E_K}?

I recommend the following scheme.

    Enc(X, K):
      1. Y <- X.
      2. Split Y into 3 equal parts: Y = Y1 || Y2 || Y3.
      3. For i = 1, 2, 3 do:
        3.1. Y2 || Y3 <- E_K(Y2 || Y3) ^ Ci;
        3.2. Y <- Y2 || Y3 || (Y1 ^ Y2).
      4. Return Y.

This scheme guarantees at least 2 differential and linear activations per 3 rounds (the more activations, the higher strength against differential and linear attacks).

For comparison, the alternative scheme

        3.1. Y1 || Y2 <- E_K(Y1 || Y2);
        3.2. Y <- Y2 || Y3 || Y1.

that has been discussed in this thread guarantees only 1 activation.

Best,
Sergey

________________________________
От: Cfrg <[email-masked]> от имени Robert Moskowitz <[email-masked]>
Отправлено: 1 апреля 2020 г. 20:13
Кому: Michael StJohns; [email-masked]
Тема: Re: [Cfrg] Encrypt in place guidance

On 4/1/20 12:33 PM, Michael StJohns wrote:
NIST SP800-38A -  Section 6.3.   CFB can work on any number of bits up to the block size.  CFB8 does a byte at a time and uses a block cipher operation for each byte.

Got.  My copy of 38A is from '02; I will have to see if there is an updated version, but sec 6.3 is there in my copy and I see how CFB8 works.

Two questions:

Operator and USS have 1 IV for the mission.  Because of potential of lost messages, cannot make a chain as mentioned previously.

1) Can the same IV be used for multiple 8 byte location blocks using CFB8?  Since the first 4 bytes are a signed integer:

It is likely that if the latitude is changing, it will only be in byte 3.  It is possible that latitude is fix (the operator is walking straight east or west) and only the last byte is changing in longitude.

2) What about CFB16 for efficiency?  Changes will tend to be in bytes 4 and 8.  Attackers will know this.

I feel more comfortable with some 64 bit cipher if I can't get that 2 byte IV counter....

thanks

Mike

On 4/1/20 12:15 PM, Michael StJohns wrote:
Pretty much every IOT chip these days has support for at least AES 128 (and usually for ECB and  CTR and/or CCM).   Unless there is a good reason to use something else, assuming you have a good IV source, use AES-CTR - it can be used for any number of bytes without expansion.  If you don't have a great IV source, use something like AES-CFB8.

Michael,

I went looking for CFB8 and was only getting CFB.  Can you please provide a pointer to it?

Thanks.

Bob

   Avoid domain specific algorithms that may or may not have had security analyses done that are appropriate to your domain.

Later, Mike

Robert,

:)

    Cheers,

    /Léo

    _______________________________________________
    Cfrg mailing list
    [email-masked]<mailto:[email-masked]>
    https://www.irtf.org/mailman/listinfo/cfrg

_______________________________________________
Cfrg mailing list
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/cfrg

_______________________________________________
Cfrg mailing list
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/cfrg

_______________________________________________
Cfrg mailing list
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/cfrg

_______________________________________________
Cfrg mailing list
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/cfrg

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 2 Apr 2020 12:01:33 -0400

Sergey,

Thank you.  This is very worthwhile.  It will take me a bit to process 
this, then incorporate it in my draft.

Bob

On 4/2/20 11:38 AM, Sergey Agievich wrote:
> If the encryption speed doesn't matter, we can use the following 
> approach based on the Feistel scheme. This approach is already being 
> used in format-preserving encryption.
>
>     Enc(X, K):
>       1. Y <- X.
> According to the theory, to provide CCA security guarantees (CCA = 
> Chosen Ciphertext Attacks) for m-bit encryption X |-> Y, we should 
> choose d >= 6. It seems very ineffective that when shortening the 
> block length, we have to use 6 times more block encryptions. On the 
> other hand, we preserve both the block cipher interface and security 
> guarantees in a simple way.
>
> This scheme guarantees at least 2 differential and linear activations 
> per 3 rounds (the more activations, the higher strength against 
> differential and linear attacks).
>
> ------------------------------------------------------------------------
> *От:* Cfrg <[email-masked]> от имени Robert Moskowitz 
> <[email-masked]>
> *Отправлено:* 1 апреля 2020 г. 20:13
> *Кому:* Michael StJohns; [email-masked]
> *Тема:* Re: [Cfrg] Encrypt in place guidance
>
>
>> NIST SP800-38A -  Section 6.3.   CFB can work on any number of bits 
>> up to the block size.  CFB8 does a byte at a time and uses a block 
>> cipher operation for each byte.
>
>>>> source, use AES-CTR - it can be used for any number of bytes 
>>>> without expansion.  If you don't have a great IV source, use 
>>>> something like AES-CFB8.
>>>
>>> Michael,
>>>
>>>>> There is really crypto justification for AEAD.  But this comes at 
>>>>> a serious cost that sometimes cannot be met.
>>>>>