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

Andy Polyakov <appro@openssl.org> Tue, 19 September 2017 07:46 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 AF1EB13306A for <cfrg@ietfa.amsl.com>; Tue, 19 Sep 2017 00:46:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] 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 iU1-znx_mHtD for <cfrg@ietfa.amsl.com>; Tue, 19 Sep 2017 00:46:16 -0700 (PDT)
Received: from mta.openssl.org (mta.openssl.org [IPv6:2001:608:c00:180::1:e6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58C92126DFE for <cfrg@irtf.org>; Tue, 19 Sep 2017 00:46:16 -0700 (PDT)
Received: from [127.0.0.1] (localhost [IPv6:::1]) by mta.openssl.org (Postfix) with ESMTP id AB0FDE03D1; Tue, 19 Sep 2017 07:46:14 +0000 (UTC)
From: Andy Polyakov <appro@openssl.org>
To: Adam Langley <agl@imperialviolet.org>
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
References: <EA4347BF-D26F-4303-9A8D-E7B28986DE56@isode.com> <71d10985-4c46-4a7c-e634-76a822102a61@openssl.org> <CAMfhd9XLGowg+VtKMxt2owQjmXjedY7V0GLh_cKVu+6WfyquVQ@mail.gmail.com> <d12cad69-411d-132a-ffe6-91850a1e03b1@openssl.org>
Message-ID: <2af2bbcb-aa98-bafe-ac7e-0f2fc646d117@openssl.org>
Date: Tue, 19 Sep 2017 09:46:14 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <d12cad69-411d-132a-ffe6-91850a1e03b1@openssl.org>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/jKw8CbDwSvDUfBV9Z7K-W70JWwM>
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 07:46:18 -0000

>> But it's also the case that little-endian machines now dominate. It's
>> nice that some big cores can largely hide the cost of doing the byte
>> swap, but hiding work is not the same as avoiding it (as your Skylake
>> numbers show) and smaller cores may not be able to do the
>> out-of-order, superscalar magic needed.
> 
> The assertion that 20% improvement is rather anomaly than rule has
> lesser to do with cores being "little" or "big". And I feel that logic
> is getting twisted here. "Big" cores are considered to be more likely to
> amortize additional cost of byte swap, right? Skylake is "big" core and
> it does have computational resources to do so. And fails miserably.

I think I've misinterpreted the original remark in my head, as reply
appears orthogonal now, in the morning. Yes, some processors will fail
to amortize costs of byte swap, but point is that even if they won't,
*customarily* unamortized cost won't be anywhere near 20%. Yes, avoiding
byte swap will lift the question altogether, but question still is if
gain (and we are be talking about non-anomalous cases) justifies
introduction of new primitives. Yes, they might appear more elegant to
little-endian eye, but these two, performance and elegance, are not the
only parts of equation. Not to mention that every term has weight
coefficient. Performance's weight is improvement coefficient (6% on
Skylake, none to effectively negligible on others, negative for those
who choose easy way out(*)), and elegance's weight is...

(*) As mentioned earlier, "easy way out" refers to performing byte
swapping of GHASH input and output, and building modified CTR with
signle-block cipher subroutine. As opposite to investing into
high-performance code that would have to be dedicated. Even unstitched.