IETF Logo Mail Archive

Re: [Cfrg] [secdir] ISE seeks help with some crypto drafts

Uri Blumenthal <uri@mit.edu> Sun, 10 March 2019 18:33 UTC

Return-Path: <uri@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 15292127873; Sun, 10 Mar 2019 11:33:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 7ED0BN97_NhK; Sun, 10 Mar 2019 11:33:47 -0700 (PDT)
Received: from outgoing-exchange-3.mit.edu (outgoing-exchange-3.mit.edu [18.9.28.13]) (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 3A3911200ED; Sun, 10 Mar 2019 11:33:46 -0700 (PDT)
Received: from oc11exedge2.exchange.mit.edu (OC11EXEDGE2.EXCHANGE.MIT.EDU [18.9.3.18]) by outgoing-exchange-3.mit.edu (8.14.7/8.12.4) with ESMTP id x2AIXnsa005317; Sun, 10 Mar 2019 14:33:49 -0400
Received: from OC11EXHUB12.exchange.mit.edu (18.9.3.26) by oc11exedge2.exchange.mit.edu (18.9.3.18) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Sun, 10 Mar 2019 14:32:43 -0400
Received: from OC11EXPO28.exchange.mit.edu ([169.254.1.251]) by OC11EXHUB12.exchange.mit.edu ([18.9.3.26]) with mapi id 14.03.0439.000; Sun, 10 Mar 2019 14:33:08 -0400
From: Uri Blumenthal <uri@mit.edu>
To: Benjamin J Kaduk <kaduk@mit.edu>
CC: Stephen Farrell <stephen.farrell@cs.tcd.ie>, CFRG <cfrg@irtf.org>, "RFC ISE (Adrian Farrel)" <rfc-ise@rfc-editor.org>, secdir <secdir@ietf.org>
Thread-Topic: [secdir] [Cfrg] ISE seeks help with some crypto drafts
Thread-Index: AQHU1d8we5ehKkr/YUmHIR9Gehv2BKYCboEAgAMHO4CAAAD7AA==
Date: Sun, 10 Mar 2019 18:33:07 +0000
Message-ID: <2DBD5391-B8A5-4BDE-AAAB-2ABD89F11DA5@mit.edu>
References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> <alpine.LRH.2.21.1903081227200.30421@bofh.nohats.ca> <CAHOTMVLtjVxZNy3bFRn09xH+cOw+tPi2CL3BkaQuJEqxAzGOJg@mail.gmail.com> <edca701b-21f3-c80c-d754-fc333f1e2e04@cs.tcd.ie> <20190310182935.GE8182@kduck.mit.edu>
In-Reply-To: <20190310182935.GE8182@kduck.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
Content-Type: multipart/signed; boundary="Apple-Mail-CECB6C4B-3165-4F4A-8270-EC06A0B860B8"; protocol="application/pkcs7-signature"; micalg="sha-256"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/xA5WK8XiC8P1B4QeyrbzydpOPeU>
Subject: Re: [Cfrg] [secdir] ISE seeks help with some crypto drafts
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: Sun, 10 Mar 2019 18:33:49 -0000

For practical use blocks wider than 128 (and probably wider than 256) bits are necessary. For analytical work, narrow blocks are needed.

Sent from my test iPhone

> On Mar 10, 2019, at 14:29, Benjamin Kaduk <kaduk@mit.edu> wrote:
> 
>> On Fri, Mar 08, 2019 at 07:14:56PM +0000, Stephen Farrell wrote:
>> 
>> FWIW, I'd prefer have fewer and not more modes of operation
>> documented. I'm not aware of a need for what this draft
>> appears to specify (based on reading just the abstract). I
>> also agree the OCB IPR situation isn't clear (IIRC more than
>> just Rogaway's IPR was involved).
>> 
> 
> My reading also failed to find a great deal of motivation for needing the
> new modes.
> 
> I also found it interesting that the "wideblock" draft also specifies
> narrow blocks, and that we've had some contentious discussions in the I*TF
> in the past about narrow-block ciphers.
> 
> We always need to balance the flexibility of having specifications for new
> modes against the risk to interoperability of having too many modes.  Given
> what's in these documents at present, my personal sense is that the
> tradeoff weighs slightly against publishing, but there are many things that
> could shift that balance.
> 
> -Ben
> 
> _______________________________________________
> secdir mailing list
> secdir@ietf.org
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview

v2.23.0 | Report a Bug | By Email