Re: [Cfrg] Attacker changing tag length in OCB

[Dan Brown <[e-mail]>]

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Peter Gutmann
> 
> Rene Struik <[e-mail]> writes:
> 
> >History suggests that lots of security vulnerabilities arise precisely

[DB] Temporarily taking generality (and frivolity) to the limit:

a) History has taught us: better safe than sorry.
b) History has taught us: if ain't broke, don't fix it.
c) History has taught us: keep it simple.

My interpretation is that under the generic cliché-pastiche criteria above,
the two proposed OCB fixes on this list pass (a), but fail on (b) and (c).  

***

More specifically, can (or has) somebody formalize(d) the problem here, and
proved that some method actually fixes solve the problem.  

I liken the AEAD-security here to be the symmetric-key equivalent to IND-CCA
for PKE.  I'm not aware of any IND-CCA-type definitions or proofs that
soften the integrity-protection compared to the confidentiality-protection.


Intuitively, I agree that this softened-authentication (e.g. tag shorter
than key) mode has merit: confidentiality has to withstand future
cryptanalysis, whereas cryptanalysts cannot go back in time to impersonate.

***

Speaking of history, fixing, PKE, MACs, and authentication: I recall the
incident of ECIES proposed in IEEEP1363 (and include in SEC1-v1).  It was
based on provably secure construction, but various tweaks were introduced to
add some bonus features (i.e. additional unencrypted input to the MAC, sound
familiar?), which proved to be flawed fixes (which had to be fixed in turn,
in IEEE 1363, SEC1-v2 and ISO 18033-2).  In other words, let's not tweak OCB
until we're certain of why and how.  Of course, that's a single data point.
I defer to the wisdom of the learned historians to make an inference based
on a broader data set.