Re: [Cfrg] Encrypt in place guidance

"Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu> Wed, 01 April 2020 14:06 UTC

Return-Path: <prvs=136048fdfc=uri@ll.mit.edu>
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 756E33A0FD7 for <cfrg@ietfa.amsl.com>; Wed, 1 Apr 2020 07:06:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.195
X-Spam-Level:
X-Spam-Status: No, score=-4.195 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=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 y0FlzXTC6hg2 for <cfrg@ietfa.amsl.com>; Wed, 1 Apr 2020 07:06:51 -0700 (PDT)
Received: from llmx3.ll.mit.edu (LLMX3.LL.MIT.EDU [129.55.12.49]) (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 8743A3A0FD6 for <cfrg@ietf.org>; Wed, 1 Apr 2020 07:06:51 -0700 (PDT)
Received: from LLE2K16-MBX04.mitll.ad.local (LLE2K16-MBX04.mitll.ad.local) by llmx3.ll.mit.edu (unknown) with ESMTPS id 031E6j60023418; Wed, 1 Apr 2020 10:06:45 -0400
From: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>
To: Leo Perrin <leo.perrin@inria.fr>, Robert Moskowitz <rgm-sec@htt-consult.com>
CC: cfrg <cfrg@ietf.org>
Thread-Topic: [Cfrg] Encrypt in place guidance
Thread-Index: AQHWCC7G69TVJWSFL0ue+QmPsR+m6A==
Date: Wed, 1 Apr 2020 14:06:44 +0000
Message-ID: <B3BE1040-E53E-4F4B-B221-6FCF8CA26C60@ll.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.22.0.200209
x-originating-ip: [172.25.1.90]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3668580404_1177736604"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-04-01_01:2020-03-31, 2020-03-31 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2002250000 definitions=main-2004010127
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/2lHjSJB5_9cHDY21Kjz44_Qix6A>
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:06:54 -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" <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