Re: [openpgp] First remarks on the last I-D

["brian m. carlson" <[e-mail]>]

On 2022-06-10 at 21:28:52, Jon Callas wrote:
> 
> 
> > On Jun 10, 2022, at 06:54, Paul Wouters <[e-mail]> wrote:
> > 
> > On Wed, 8 Jun 2022, Jon Callas wrote:
> > 
> >> However, GCM mode is not required for FIPS. It is neither necessary
> >> nor sufficient. PGP was the very first software-only FIPS 140
> >> module, over twenty years ago. If someone is claiming that they
> >> need GCM mode for FIPS, they're mistaken.
> > 
> > Well, if that FIPS compliance was achieved with 3DES, at this point that would be
> > a problem as 3DES has been sunset. What non-GCM encryption algorithm is
> > FIPS approved and supported by OpenPGP ?
> 
> AES is a FIPS algorithm and has been for some time. NIST is in favor
> of it. Forgive me for being pedantic, but GCM is a mode -- and there
> are documents which I just found by typing "fips 140 modes of
> encryption" into a search engine, where it tells me that for AES:
> 
> AES-CCM is approved (SP800-38C), as is CMAC  (SP800-38B), and HMAC via
> FIPS 198-1 via SP800-107.

CCM is essentially CTR with CBC-MAC.  GCM is essentially CTR with a
polynomial Carter-Wegman-style MAC.  They both suffer from the exact
same problem of nonce reuse because in both cases the CTR part leaks the
plaintext.

If we decide we like CCM better, that's fine.  I'm not picky here.  GCM
is typically faster on modern hardware and it's online, so it's easier
to encrypt data in large chunks, but CCM can be made to work here.

We should not try to synthesize other modes out of the approved modes,
though.  For example, OCB has separate security proofs, and folks
who need FIPS compliance are almost certainly not going to get an
approval from the extremely bureaucratic agency doing the FIPS
validation if it's not pretty clearly an approved mode.

> >> And for what it's worth, I'm also against using GCM mode for
> >> storage encryption in particular, and thus in OpenPGP.
> > 
> > Noted. This is good to know.
> 
> In general, I think one should not be doing stream modes for storage,
> and the reason is nonce reuse. In the case of GHASH and thus GCM, the
> issue is that reusing a nonce breaks all MACs in the future and in the
> past. When one is doing streaming, breaking a past nonce isn't a big
> deal. However in storage, this is different. If someone accidentally
> reuses a nonce, the past break means that things already written can
> be undetectably modified. This is why the lot of us really, really get
> cranky about GCM. It would be much better to use CCM (because it was
> explicitly created to be a non-IP mode) or OCB (which is what we all
> want to use anyway, and it's faster than GCM). And yes, yes, there are
> also things like SIV.

Here's the problem with that argument: in every case where OpenPGP
generates a nonce, it also generates a session key.  If the
implementation has broken nonce behaviour, they probably also have
broken secret key generation behaviour, and the security is already
compromised.  As long as the user has provided a unique salt for the
SEIDP with the given key (and the key is securely generated), then the
use of HKDF guarantees that the key and nonce are effectively
independent and the construction is secure.  That makes the risk of
nonce-related problems lower as long as the session key is secure.

I do want to be clear that I think OCB is fine and preferred here. I
don't think that anybody is saying that GCM is the desired mode for
everyday use.  (Similarly, I think EdDSA is typically preferred over
ECDSA with NIST curves.)  I clearly don't think FIPS-compliant
cryptography is the desired configuration for everyday use.  However,
it's there for people who have certain, specific needs that please
government agencies, and for the rest of us, we don't ever have to use
it.  We can even say that implementations SHOULD use a mode other than
GCM if we like.

> I think that for storage of things like keys, it's better to do an
> HMAC or CMAC on top of CFB (since OpenPGP is full of that) or use
> CBC+CTS (which resolves padding issues).

CFB is not very commonly implemented in cryptographic libraries these
days, while GCM and CCM are.  Ciphertext stealing can be done in three
different ways, and many cryptographic libraries don't support that with
CBC, so implementing it correctly is a giant hassle.  I personally hate
CBC with a passion because verifying padding is terrible and CTS is hard
to implement.

While I am personally a fan of the CTR+HMAC constructions because they
are trivial to implement and constant time with a constant time block
cipher, the benefit to using an actual AEAD construction is that if one
uses a suitable cryptographic library, the implementation may prevent
the release of plaintext if the tag is incorrect.

I think there's substantial value to using an existing AEAD
implementation which is probably implemented correctly than requiring
people to construct one themselves, where security-relevant
implementation errors are more likely, and that the benefits to that
outweigh the downsides of GCM or CCM.
-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA