Let me emphasize the reasons Douglas brought up. Note that I need to use NIST Sec Level 5 algorithms. So, Kyber-1024 and Dilithium5 (other algorithms show even worse ratio between KEM and signature!).
Communications costs:
- Difference in public key sizes: 1568 bytes of Kyber vs. 2592 bytes of
Dilithium => 1024 extra bytes to carry over channel each way;
- Signature: extra 4595 bytes each way, because in addition to exchanging certs
(aka "signed public keys", which is inevitable) you need to sign the exchange
and communicate that signature across;
- Total: 5619 extra bytes each way. For peer-to-peer broadband connections, you
can say "so what?". But my links are *very* austere.
Computation costs (ballpark, on a powerful CPU):
- KEM: keygen 15us, encap 18us, decap 14us (say, double encap and decap for
PFS-providing exchange);
- Signature: sign 113us, verify 55us;
- Comparison: 134us for signature-less KEM vs. 215us for TLS-like exchange =>
almost twice as long;
- Difference may be negligible for Intel Xeon, but for my much weaker hardware
it matters.
So, for constrained environments with austere comm links, signature-less
"authkem" is God-sent.
Big servers that need to support many clients (so they care how much CPU cycles
and comm bytes they spend on every connection) would appreciate these savings
too.
@ekr,I hope this provides convincing explanation why "authkem" is needed.
P.S. I know that Falcon has much more favorable sizes - but (a) it takes three
times as long to sign, and (b) it uses FP calculations, which isn't great to
implement in my environment.
--
Regards,
Uri
There are two ways to design a system. One is to make is so simple there are
obviously no deficiencies.
The other is to make it so complex there are no obvious deficiencies.
- C. A. R. Hoare
On 7/12/21, 20:59, "TLS on behalf of Douglas Stebila" <tls-boun...@ietf.org on
behalf of dsteb...@gmail.com> wrote:
Hi Eric,
The main motivation is that, in some cases, post-quantum signatures are
larger in terms of communication size compared to a post-quantum KEM, under the
same cryptographic assumption.
For example, the KEM Kyber (based on module LWE) at the 128-bit security
level has 800-byte public keys and 768-byte ciphertexts. The matching
signature scheme Dilithium (also based on module LWE) has 1312-byte public keys
and 2420-byte signatures. Doing KEM-based server authentication rather than
signature-based server authentication would thus save 2164 bytes per handshake.
We would still need digital signatures for a PKI (i.e., the root and
intermediate CAs would sign certificates using PQ digital signature schemes),
but the public key of the endpoint server can be a KEM public key, not a
digital signature public key.
Douglas
> On Jul 12, 2021, at 20:30, Eric Rescorla <e...@rtfm.com> wrote:
>
> Hi folks,
>
> I have just given draft-celi-wiggers-tls-authkem-00.txt a quick
> read. I'm struggling a bit with the rationale, which I take to be
> these paragraphs:
>
> In this proposal we use the DH-based KEMs from [I-D.irtf-cfrg-hpke].
> We believe KEMs are especially worth discussing in the context of the
> TLS protocol because NIST is in the process of standardizing post-
> quantum KEM algorithms to replace "classic" key exchange (based on
> elliptic curve or finite-field Diffie-Hellman [NISTPQC]).
>
> This proposal draws inspiration from [I-D.ietf-tls-semistatic-dh],
> which is in turn based on the OPTLS proposal for TLS 1.3 [KW16].
> However, these proposals require a non-interactive key exchange: they
> combine the client's public key with the server's long-term key.
> This imposes a requirement that the ephemeral and static keys use the
> same algorithm, which this proposal does not require. Additionally,
> there are no post-quantum proposals for a non-interactive key
> exchange currently considered for standardization, while several KEMs
> are on the way.
>
> I see why this motivates using a KEM for key establishment, but I'm
> not sure it motivates this design, which seems like a fairly radical
> change to TLS. As I understand the situation, in the post-quantum
> world we're going to have:
>
> - non-interactive KEMs (as you indicate above)
> - some sort of signature system (otherwise we won't have certificates).
>
> This certainly argues that we need a KEM for key establishment, but
> not for authentication. Instead, why can't we use signatures for
> authentication, as TLS does today? I.e., the certificates would have a
> (potentially post-quantum) signing key in them and you then use the
> KEM for key establishment and the signing key for authentication.
> That would give us a design much closer to the present TLS 1.3
> (effectively just defining a new group for the KEM).
>
> What am I missing?
>
> -Ekr
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
