IETF Logo Mail Archive

Re: [Cfrg] RG Last Call on draft-irtf-cfrg-gcmsiv-06

Andy Polyakov <appro@openssl.org> Tue, 19 September 2017 09:52 UTC

Return-Path: <appro@openssl.org>
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 2EF1B132EDA for <cfrg@ietfa.amsl.com>; Tue, 19 Sep 2017 02:52:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level:
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 WJoPUnAQwCUW for <cfrg@ietfa.amsl.com>; Tue, 19 Sep 2017 02:52:46 -0700 (PDT)
Received: from mta.openssl.org (mta.openssl.org [194.97.150.230]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED11D126BF0 for <cfrg@irtf.org>; Tue, 19 Sep 2017 02:52:45 -0700 (PDT)
Received: from [127.0.0.1] (localhost [IPv6:::1]) by mta.openssl.org (Postfix) with ESMTP id 8D5C8E03E4; Tue, 19 Sep 2017 09:52:43 +0000 (UTC)
To: Shay Gueron <shay.gueron@gmail.com>, "cfrg@irtf.org" <cfrg@irtf.org>
References: <EA4347BF-D26F-4303-9A8D-E7B28986DE56@isode.com> <71d10985-4c46-4a7c-e634-76a822102a61@openssl.org> <CACsn0cnSq9nJpdjpDQ-HpHX7i6W-0=JkCOB-WenBRoMSKO9ypA@mail.gmail.com> <b751593d-20bb-8914-de96-e9040080e15d@openssl.org> <CAHP81y_CUTvA9Ftqz0Q_qzs94iPddW+4g5ObhzruNKR5zaEPvw@mail.gmail.com>
From: Andy Polyakov <appro@openssl.org>
Message-ID: <46eaa04f-09ef-3f11-4729-dfeec1b1cf60@openssl.org>
Date: Tue, 19 Sep 2017 11:53:03 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <CAHP81y_CUTvA9Ftqz0Q_qzs94iPddW+4g5ObhzruNKR5zaEPvw@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/yHVZ1EIGJ0qDkf3xE-QeqUpIIgE>
Subject: Re: [Cfrg] RG Last Call on draft-irtf-cfrg-gcmsiv-06
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.22
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: Tue, 19 Sep 2017 09:52:48 -0000

Hi,

> I would like to re-emphase a few points (although they have been already
> nicely stated). 
> 
> The purpose of using POLYVAL is not performance. It is "consistency".
> The performance gains are a marginal bonus (and if they are ephemeral it
> does not matter). 

So we agree that performance *gains* are marginal. Should we consider
performance *losses* elsewhere? For example for those who choose "easy
way out". Or have to do so, for example because they have dedicated
GHASH hardware. But even if we take performance out of equation, do we
all agree that "consistency" is sufficient by its own? To justify
additional implementation/diversity costs that is. Do note that we are
not exactly still struggling with GCM. Effectively thanks to

> I proposed a way to solve this
> (https://crypto.stanford.edu/RealWorldCrypto/slides/gueron.pdf) ,

And once again, if we agree that "consistency" is sufficient by its own,
does it have to be interwoven with specific mode specification? Isn't it
like starting building house from *roof*? If we consider that we would
be better off if primitives were little-endian-centric, then let's say
that and start building *foundation*...

v2.23.0 | Report a Bug | By Email