Re: [Cfrg] Encrypt in place guidance

Robert Moskowitz <rgm-sec@htt-consult.com> Wed, 01 April 2020 14:59 UTC

Return-Path: <rgm-sec@htt-consult.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41C253A1097 for <cfrg@ietfa.amsl.com>; Wed, 1 Apr 2020 07:59:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T8s3dIS5daFE for <cfrg@ietfa.amsl.com>; Wed, 1 Apr 2020 07:59:02 -0700 (PDT)
Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7CC33A1094 for <cfrg@ietf.org>; Wed, 1 Apr 2020 07:59:02 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 7769F6213F; Wed, 1 Apr 2020 10:59:01 -0400 (EDT)
X-Virus-Scanned: amavisd-new at htt-consult.com
Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Fzl8CsOXhNg0; Wed, 1 Apr 2020 10:58:54 -0400 (EDT)
Received: from lx140e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id CA71362136; Wed, 1 Apr 2020 10:58:52 -0400 (EDT)
To: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>, Leo Perrin <leo.perrin@inria.fr>
Cc: cfrg <cfrg@ietf.org>
References: <B3BE1040-E53E-4F4B-B221-6FCF8CA26C60@ll.mit.edu>
From: Robert Moskowitz <rgm-sec@htt-consult.com>
Message-ID: <39806a9f-206b-797d-e2b8-0a55bea2b1cb@htt-consult.com>
Date: Wed, 1 Apr 2020 10:58:49 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0
MIME-Version: 1.0
In-Reply-To: <B3BE1040-E53E-4F4B-B221-6FCF8CA26C60@ll.mit.edu>
Content-Type: multipart/alternative; boundary="------------F76488B680370BB44BB75ACD"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/e7eQyfpfP_8bAboyn3EiT8DUBNg>
Subject: Re: [Cfrg] Encrypt in place guidance
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Apr 2020 14:59:05 -0000


On 4/1/20 10:06 AM, Blumenthal, Uri - 0553 - MITLL wrote:
> Robert,
>
> 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.

:)

> On 4/1/20, 09:38, "Cfrg on behalf of Leo Perrin" <cfrg-bounces@irtf.org on behalf of leo.perrin@inria.fr> 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
>      Cfrg@irtf.org
>      https://www.irtf.org/mailman/listinfo/cfrg
>      
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg