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

Tony Arcieri <> Sun, 10 March 2019 22:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9AB52130DEA for <>; Sun, 10 Mar 2019 15:31:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id f-7tgUzIB3vt for <>; Sun, 10 Mar 2019 15:31:25 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 31F9C12F1A2 for <>; Sun, 10 Mar 2019 15:31:25 -0700 (PDT)
Received: by with SMTP id u128so2178843oie.2 for <>; Sun, 10 Mar 2019 15:31:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XMICp+NbPh2S4La/ri43Q8T3NLbQXZHSdF7ISVBTgQ0=; b=PMP+C+RSLd1zMyzbbxmVM5NaCx4QRfJxllQ2smHqXSSgeCGPTUvcci4O7muCE+KumG e6lxrn8udE+ZKwfx4pCgGQj/SjRyYyno0Wm9a14HA3YMKQ2HGL0KADEE84nc6pRe8f41 d/KuoCZZjFI+sgC5SM8BkjcAkoocQjrPThIXpa16onOW4FaRSuBWl5tmoRUHHUmZ+QUm 3qFUXw40jy+DCOLkMYwcXmsq+GKIXa5kubuZVpZHO/KwGbMS3eP3xhT6rG8W39NT5sS9 +xuxMIox+GDLD7/b9a4oG93PegU9IYwZTBTpfdXWZPm5TxX8vT1rk/NioJ/YPg6E8hrk cWRQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XMICp+NbPh2S4La/ri43Q8T3NLbQXZHSdF7ISVBTgQ0=; b=EtsNgZ7+6px7ETT+dY6O2bg9jckHMCxdV68omSiAwhZiPET/pWsi2L/X2/7zCaJUow GnFmYQRaJjNJEblLRFfFsVXYHPCV7mbRD/NBT+dYq9f24BCeroc6H1VrNJKYxT51onlk HkXwv+5DsvCfmHZHSOlzEVNyCCNLM6h5dRivLEEksVpo9fQzLdUt/JyK+KX0Tk/5BI4a fSLv7z63u6HplyhFAlVAUNKpcHPGgwfObpLUJ0ckBFlPo5VWCyktQK9rMLH+yILPXd8a yI+e+LLJupRIBJk355cLl/PehxMlNC9lbI/GSuiFGvDeBH01nKVapBbHq316nBxdVHbt xfnQ==
X-Gm-Message-State: APjAAAXUGXJ+f8R09kq7GNo6yMzc7vJ+L+M1dSL3AMzAtnJrD+9n6wYP 5IXtGDf+FVO3jr8OS5AxMFKbyzfm1G5nh8t+tRA=
X-Google-Smtp-Source: APXvYqyIAk/mVXiM7WBxckV690df8cP3d8o9aoA/hPhe/FZzF1ZaMzFCMk3TItA4P0ObANrToHjHjtzRhFWtpxRqpeo=
X-Received: by 2002:aca:f546:: with SMTP id t67mr14464643oih.152.1552257084378; Sun, 10 Mar 2019 15:31:24 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Tony Arcieri <>
Date: Sun, 10 Mar 2019 15:31:12 -0700
Message-ID: <>
To: Stephen Farrell <>
Cc: Benjamin Kaduk <>, CFRG <>, "RFC ISE (Adrian Farrel)" <>, secdir <>
Content-Type: multipart/alternative; boundary="0000000000001d55a60583c50402"
Archived-At: <>
Subject: Re: [Cfrg] [secdir] ISE seeks help with some crypto drafts
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 10 Mar 2019 22:31:34 -0000

On Sun, Mar 10, 2019 at 2:47 PM Stephen Farrell <>

> One interesting question might be: is OCB so much better
> that it could we displace uses of some existing mode with
> OCB. That seems unlikely to me for the widely used modes.
> Another interesting question might be: is OCB so much
> better that we want to deploy it alongside current modes.
> I don't see the overall benefit of that myself.
> So even though I'm happy to accept that OCB has better
> properties than e.g. GCM, I don't think it's so much
> better that RFCs for it are that useful.

Let me provide some context here with a survey of existing modes and
explain why OCB is interesting:

- AES-GCM: exceedingly common on desktop/laptop/server-class computers and
high-end mobile phones. Provides performance roughly equivalent to the
underlying AES function on these devices, provided they have a superscalar
architecture and have (P)CLMUL(QDQ) units which can be used in parallel
with the units that perform AES
- AES-CCM: exceedingly common in the embedded space. This is due in part to
two things: FIPS regulations and the number of embedded devices they apply
to (smartcards and other security tokens, as well as things like HSMs), but
also because embedded CPUs/uCs generally will perform quite poorly at
- ChaCha20+Poly1305: extremely simple authenticated encryption based in a
tiny core ARX primitive for encryption and universal hashing for
authentication. Extremely fast in software, but slower than hardware
accelerated primitives

These modes have a sort of triangle of tradeoffs:

- AES-GCM is fast if and only if you have a superscalar CPU with both
hardware AES and CLMUL
- AES-CCM is fast (faster than ChaCha20Poly1305) if you have hardware
accelerated AES, but runs the AES encryption twice as many times as
AES-GCM, and has a non-parallelizable encryption function
- ChaCha20Poly1305 is faster than AES-GCM on devices that do not have CLMUL
support, but slower than AES-CCM on devices which have hardware AES support

Hardware AES support has been steadfastly improving over many years and is
available in all but the cheapest microcontrollers (i.e. even where there
are cheap uCs without it, there is often a "crypto accelerator" model of
the same uC which does).

When hardware AES is available, OCB "squares the triangle" so to speak, and
provides a sort of force multiplier where the other modes have tradeoffs.

For new protocols which are shooting for "ubiquitous deployment", i.e.
targeting servers/laptops/desktops, mobile phones, *and* the embedded
space, and want one mode that "works well everywhere", this makes OCB an
ideal candidate.

It'd be good to handle the cases that hardware AES isn't available, and
also have a "fallback cipher" on the outside chance some horrible
cryptanalysis disaster befalls OCB, so you'd still want to pair it with
ChaCha20+Poly1305 as a backup cipher. That said, for those protocols who
would rather simplify cipher selection rather than having a backup card in
their pocket, OCB is a particularly attractive mode for "One True
Ciphersuite" (a.k.a. 1TCS) protocols.