Re: [quicwg/base-drafts] Add retry integrity tag (#3120)

Christian Huitema <notifications@github.com> Sun, 01 December 2019 02:39 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26762120048 for <quic-issues@ietfa.amsl.com>; Sat, 30 Nov 2019 18:39:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8
X-Spam-Level:
X-Spam-Status: No, score=-8 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, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.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 3_YQlRNwdANc for <quic-issues@ietfa.amsl.com>; Sat, 30 Nov 2019 18:39:37 -0800 (PST)
Received: from out-6.smtp.github.com (out-6.smtp.github.com [192.30.252.197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 543AF120024 for <quic-issues@ietf.org>; Sat, 30 Nov 2019 18:39:37 -0800 (PST)
Date: Sat, 30 Nov 2019 18:39:35 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1575167975; bh=sYNfTW51UwWuotakSg3beJdEv8j6Lc3U2W8QEB3Y2b4=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=KK85lbqXmEet93ByoXYQp69ShuljuNu0xeQ6QjGwBKab03WB4/ZyqPAgY+xiroGbm 1ywdYShiIQY5fKtUAQ/1aYqVltuXWcw5L5gwvC7XB+GCiH/sR/a0UcQ2B/yMvtkG3s YI4hXJyIo12tTuhGwu1OEHPELdNwtbgdrsyirdu0=
From: Christian Huitema <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJKYQVLOR6GNMU7FDZ3F36BNGPEVBNHHB4UZE54@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/3120/c560043120@github.com>
In-Reply-To: <quicwg/base-drafts/pull/3120@github.com>
References: <quicwg/base-drafts/pull/3120@github.com>
Subject: Re: [quicwg/base-drafts] Add retry integrity tag (#3120)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5de327e7aec9f_79b33fe92eecd964189392"; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: huitema
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/MHiXDjjAuuqWJpKhm5teWxTkBNA>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 01 Dec 2019 02:39:40 -0000

In Singapore, we were debating whether to just do checksum, versus encrypt and use an initial vector based on the CID. I wanted to compare the two variants using a benchmark designed for Picotls, but I ran into a little bit of trouble because of the structure of the picotls encryption API, which looks like:

1) Initialize an encryption context with the key context, the IV, and the authenticated data
2) Encrypt the message
3) Compute the AEAD checksum

With that API, there is no option to not use an IV,. Using a constant IV would have exactly the same cost as using a variable IV. I went on to compare the time to encrypt 64 bytes versus the time to just authenticate 64 bytes. Results are below for two implementations of AES128 GCM, one from OpenSSL crypto library and another from Windows Bcrypt library -- both measured using 64 bit code on my Windows laptop:


   | encrypt | decrypt | authenticate | verify
--  | -- | -- | -- | --
bcrypt  | 0.35751 | 0.22602 | 0.24687 | 0.20189
openssl 1.1.1c | 0.30211 | 0.23956 | 0.24296 | 0.23926

The times are measured here in microseconds -- these are the average on 100,000 operations. We see that the times are fractions of microseconds in both cases. The encryption operation is more expensive than a simple authentication, 45% more with brcrypt, 24% more with openssl. The decrypt operation is 12% more expensive than the simple authenticate with brcypt, almost the same with openssl.




-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3120#issuecomment-560043120