> On 28 Sep 2025, at 19:07, Phillip Hallam-Baker <[email protected]> wrote:
>
> I am busy writing the drafts for proposing the JSContact exchange scheme to
> this group.
>
> One of the concerns that comes up is that AES-GCM remains a technique that
> turns a nice robust block cipher into a stream cipher and that makes it
> rather fragile when considering all the possible ways the botched and the
> bungles could mis-implement things.
I’m not sure OCB is significantly better in this regard.
>
> Yes, I know formal methods are all the rage, been there, done that, might
> even collect the bit of paper with the ribbon some day. The problem with
> formal methods is that they only reveal the security of the system you
> analyze and only with respect to the concerns your tools are able to address.
> And the problem I have as a protocol designer is that you can end up with a
> scheme that is formally verifiable but brittle in operation. Case in point
> here being VENONA which led to the execution of the Rosenbergs despite one
> time pads being a provably perfect cipher.
>
> GCM-SIV is one possible option but it requires two pass processing which is
> OK for encrypting IP packets but severely limits application of the result.
> The DARE Envelope construct I am using as a basis was originally designed to
> support exchange of encrypted ZIP-like archives containing TBs of files.
> Single pass processing really is a must.
You should really be using something like Rogaway’s STREAM to encrypt large
files, regardless of underlying mode. And in that case the drawbacks of SIV are
lessened. (But personally I’d choose something based on the original SIV, as
AES-GCM-SIV has various drawbacks).
See my earlier draft (which fell between the IETF cracks when the JOSE WG was
disbanded): https://datatracker.ietf.org/doc/html/draft-madden-jose-siv-mode-02
>
> AES-OCB is much better, it is robust even with IV reuse
No it is not - as per https://web.cs.ucdavis.edu/~rogaway/ocb/ocb-faq.htm#nonce
“ What happens if you repeat the nonce? You’re going to mess up authenticity
for all future messages, and you’re going to mess up privacy for the messages
that use the repeated nonce. So don’t do this. It is the user’s obligation to
ensure that nonces don’t repeat within a session. In settings where this is
infeasible, OCB should not be used.”
That is the same as GCM.
> and we would likely have used it in place of GCM if there hadn't been three
> sets of conflicting patent claims. I know one version has issues but the
> scheme described in RFC7253 is generally believed to be sound. Phil Rogaway
> invented much of the apparatus used for formal analysis of symmetric
> algorithms.
>
> What I propose is adding A128OCB, A192OCB, and A256OCB to the registry of
> algorithms following the same approach as AES-GCM. They are just a drop in
> replacement.
I’m not against adding OCB, but IMO it provides little practical benefit over
GCM, especially for the typical use-cases of JOSE.
I think one of the AEGIS variants is more interesting -
https://www.ietf.org/archive/id/draft-irtf-cfrg-aegis-aead-17.html
Best,
— Neil
_______________________________________________
jose mailing list -- [email protected]
To unsubscribe send an email to [email protected]
