Re: [Cfrg] request for comments on "Generation of Deterministic Initialization Vectors (IVs) and Nonces"

[Peter Gutmann <[e-mail]>]

David McGrew <[e-mail]> writes:

>Like you suggest, it would be valuable to define a user-oriented API for
>encryption, which hides all of the crypto details from the user and thus
>minimizes the demands that it places on their knowledge.  

Hmm, I can't see how trying to address things at the API level could work
because there's already a large variety of very different APIs, many dating
back 10-15 years, that would need to be changed.  I can't imagine how you'd
convince Microsoft, OpenSSL, BSAFE, whoever owns Java this week, and a bunch
of others, all to switch to, or introduce, a new unified AEAD encryption API.

All you'd really need to do is define is a single, standard way of applying
AES-GCM (or whatever), and then various vendors could then adapt it for
whatever their API looks like.

>What do you think?  Any chance that I can talk you into contributing, or at
>least reviewing, a draft defining an API like this?

See above, even if you/I/we come up with an API, I can't imagine what it'd
take for vendors to adopt it.  Look at things like the MD4 and MD5 RFCs (to
take something that's been around since the dark ages of Internet cryto),
apart from a very very low-level part of the OpenSSL API I've never seen
anything that uses it, and that was introduced at more or less the year zero
of hashing APIs (it predates SSLeay, CryptoAPI, Java, and others), but still
didn't get adopted.

So I think the way forward is to define a single unambiguous way of applying
GCM, and leave it to individual API developers to provide the interface to it.
Even then, unfortunately, for most of the major protocols (IKE, ESP, TLS, etc)
it's already too late, they've already defined their own incompatible
mechanisms.

Peter.