[CFRG] Re: KEM combiners design team output

["D. J. Bernstein" <[e-mail]>]

Neil Madden writes:
> Many protocols IMO would be immeasurably improved by
> de-Fiat-Shamir-ing them back into identification protocols (looking at
> you, FIDO).

In this interactive scenario, why not just use a KEM?

The server's long-term identity key is a KEM key instead of a key for a
signature system. The client encapsulates to that key (also sending some
encrypted data under the session key if desired). The server sends back
a MAC under the session key (or uses AEAD to encrypt data if desired).
The client checks the MAC and knows it's talking to the server.

Of course, an easy way for academics to publish papers is to analyze the
consequences of the client having a busted RNG and to propose endless
protocol-level modifications as partial bandages rather than fixing the
RNG. "The surprising insight flowing from this paper's novel definition
of CLI-BADRNG-IDFLOW is that an attacker knowing the client's randomness
for this KEM encapsulation can pose as the server, breaking guarantees
of authentication, whereas signatures are secure in this scenario", etc.

---D. J. Bernstein