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

[Tony Arcieri <[e-mail]>]

On Sun, Mar 10, 2019 at 2:47 PM Stephen Farrell <[e-mail]>
wrote:

> 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
AES-GCM
- 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.