Re: [Cfrg] New UMAC Draft

Hal Finney writes:
> For reasons which are not completely clear to me, implementations of
> this idea like UMAC and Dan Bernstein's Poly1305-AES substitute a
> random permutation p(nonce) for the random function f(nonce).

The reason is simple: We're taking advantage of the community's (perhaps
misplaced) trust in the security of a block cipher, namely AES.

I suspect that future cryptographers will regard the notion of a block
cipher as a historical accident, not something to actually be deployed
in any sort of cryptographic protocol. Using Poly1305 with a stream
cipher is easy: insert 128 blank bits at the beginning of the message
being encrypted, and steal those 128 bits of ciphertext for Poly1305.

Ted Krovetz writes:
> What Bernstein's theorem says  is that it does not matter HOW the
> function f is used, but instead  HOW MANY times it is used.

It's certainly true that the main parameters in the theorem are the
maximum number of f applications and the size of f's domain. However, to
apply the theorem, you also need a bound on Pr[A(f) = 1]; and producing
that bound requires knowing how f can be used by the algorithm A.

I agree that splitting isn't inherently a problem. The real question is
how UMAC chooses oracle inputs.

---D. J. Bernstein, Professor, Mathematics, Statistics,
and Computer Science, University of Illinois at Chicago

_______________________________________________
Cfrg mailing list
Cfrg@ietf.org
https://www1.ietf.org/mailman/listinfo/cfrg