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

Andy Polyakov <> Wed, 27 September 2017 21:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4BF1713306A for <>; Wed, 27 Sep 2017 14:50:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.001
X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Vo6ckIcZlUbq for <>; Wed, 27 Sep 2017 14:50:29 -0700 (PDT)
Received: from ( [IPv6:2001:608:c00:180::1:e6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5824A13445E for <>; Wed, 27 Sep 2017 14:50:29 -0700 (PDT)
Received: from [] (localhost [IPv6:::1]) by (Postfix) with ESMTP id C703BE1124; Wed, 27 Sep 2017 21:50:25 +0000 (UTC)
From: Andy Polyakov <>
To: "" <>
References: <> <> <> <> <> <> <> <>
Message-ID: <>
Date: Wed, 27 Sep 2017 23:50:25 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [Cfrg] RG Last Call on draft-irtf-cfrg-gcmsiv-06
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 27 Sep 2017 21:50:31 -0000

>>>>> do we all agree that "consistency" is sufficient by its own?
>> To me, a clean and consistent specification has value.
> I don't deny its value, question was it is sufficient [to justify
> additional implementation/diversity costs].

It's obvious that more natural bit order in POLYVAL was not the goal by
itself. Performance on par with GCM also was. And not just any GCM
performance, but one assisted by AES-NI and PCLMULQDQ instructions or
their equivalents. Next thing to understand is that referred GCM
performance is achieved by optimizing for specific cases, CTR and GHASH,
and in x86_64 case even stitched CTR-GHASH. And keyword is "specific
cases". Draft in question asserts that suggested mode decrypt
performance is virtually equivalent to GCM, but fails to emphasize that
this holds true only provided that one has devoted equivalent effort
into optimizing code for specific cases of modified CTR and POLYVAL.
Because if one doesn't do that and takes "easy way out" by exploiting
byte order equivalence with GHASH and modified CTR relying on
single-block encrypt, performance impact would be devastating, up to
several *times*. On the other hand if mode was specified using GHASH and
standard CTR, as already discussed, difference would be none to
negligible [in non-anomalous cases].

>>>>> those who choose "easy way out". 
>>>>> because they have dedicated GHASH hardware. 
>> As Adam had mentioned, adding AES-GCM-SIV (to gain misuse resistance)
>> has its cost anyway,
> Yes, and assertion is that it could have been *lower* if it was
> formulated with GHASH and standard CTR.

Because it would be limited to ordering calls to existing GHASH and CTR.