Re: [Cfrg] Encrypt in place guidance

Dan Brown <danibrown@blackberry.com> Wed, 01 April 2020 15:04 UTC

Return-Path: <danibrown@blackberry.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 3B48D3A1111 for <cfrg@ietfa.amsl.com>; Wed, 1 Apr 2020 08:04:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=blackberry.com
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 leHC_g3dCiYJ for <cfrg@ietfa.amsl.com>; Wed, 1 Apr 2020 08:04:48 -0700 (PDT)
Received: from smtp-pg11.blackberry.com (smtp-pg11.blackberry.com [68.171.242.227]) (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 7E6913A110F for <cfrg@ietf.org>; Wed, 1 Apr 2020 08:04:47 -0700 (PDT)
Received: from pps.filterd (mhs401ykf.rim.net [127.0.0.1]) by mhs401ykf.rim.net (8.16.0.27/8.16.0.27) with SMTP id 031F0f8x083351; Wed, 1 Apr 2020 11:04:43 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=blackberry.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-transfer-encoding : mime-version : content-type; s=corp19; bh=WF0sx0fBujVln9eA0+DzJBN8/WO1euk2SLXKDVLnhHw=; b=HkNFgcmWz4MqawPYRFFXdXO/KROz4sefh8sNCQQakpS5PfXgk3ORUJgGEB3efnmvvRxd qBbHTYarl/YsVYlWPnTwA/cBg5ujGmL6LGFbsAlEWXs19r0fdYU0LWXwdJto/dD4AM5d hWG2xlEO7kjSpZNieUSvQV1OkOrwdS+aPoqi2BJJQ81gMP9XF+8VdjaSzCmyV5spVj5O SwESpV3FvDpatr516ZVfwbmcdR0mzmciGFRikjaDv8L34zBTXpO7ani+YdbRxUC1334X QN51i6slSTsTUbs8x9PTAjEITZcVyO03sYB+2qklp4/NeVISYh+THaN+DWSBxPo7f7Lk 5A==
Received: from xch211cnc.rim.net (xch211cnc.rim.net [10.3.27.116]) by mhs401ykf.rim.net with ESMTP id 3049twtdmp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Wed, 01 Apr 2020 11:04:43 -0400
Received: from XCH210YKF.rim.net (10.2.27.110) by XCH211CNC.rim.net (10.3.27.116) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 1 Apr 2020 11:04:43 -0400
Received: from XCH210YKF.rim.net ([fe80::81ca:ad34:fc3:5ce8]) by XCH210YKF.rim.net ([fe80::81ca:ad34:fc3:5ce8%5]) with mapi id 15.01.1913.007; Wed, 1 Apr 2020 11:04:43 -0400
From: Dan Brown <danibrown@blackberry.com>
To: Leo Perrin <leo.perrin@inria.fr>, Robert Moskowitz <rgm-sec@htt-consult.com>
CC: cfrg <cfrg@ietf.org>
Thread-Topic: Encrypt in place guidance
Thread-Index: AQHWCCrHq5iYxH/07kezv9P4mh6NgqhkWiDQ
Date: Wed, 1 Apr 2020 15:04:43 +0000
Message-ID: <13bdf0609efe41c3818fd4338d92c364@blackberry.com>
References: <83571efb-a32f-6a59-a496-de56716f07da@htt-consult.com> <a16dcbe63aa745e482a3f435aa8e0470@blackberry.com> <f5e4c7a3-e039-ec7d-59b7-0c581d9022e6@htt-consult.com> <9ACD4ECA-CFBF-40DC-8CB8-BB7DAEFBB42D@ll.mit.edu> <d4383234-d452-dad8-52dc-dd35dbecbb8a@htt-consult.com> <4d64bcce-7f9e-9ec4-e73b-45e2c57d5de6@cs.tcd.ie> <1938299699.23565911.1585728427697.JavaMail.zimbra@inria.fr> <96a4b21c-2ba2-ac2f-e84d-9a13a5c24d69@htt-consult.com> <2035303591.24133736.1585748191997.JavaMail.zimbra@inria.fr>
In-Reply-To: <2035303591.24133736.1585748191997.JavaMail.zimbra@inria.fr>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [100.64.97.128]
Content-Transfer-Encoding: quoted-printable
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
Content-Type: text/plain; charset="iso-8859-1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/tevT1Ne4VDCc74xpEodSPLEseSw>
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 15:04:50 -0000

> -----Original Message-----
> From: Cfrg <cfrg-bounces@irtf.org> On Behalf Of Leo Perrin
> 
> > 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!
> 
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:
> 
> (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.

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.