Re: [TLS] Before we PQC... Re: PQC key exchange sizes

[Phillip Hallam-Baker <[e-mail]>]

On Fri, Aug 5, 2022 at 8:16 PM Sofía Celi <[e-mail]> wrote:

Thanks for looking at this.

...
> Completely agree. This is also the case for DNSSEC, for example. We
> don't have a proper mapping of those operational issues. We have started
> research on the matter so if you are interested in contributing, let us
> know.
>

Unless we get a scheme that allows for signatures of 200 bytes or less, we
are really, really going to have to redesign the DNS protocol and DNSSEC
architecture because trying to do DNSSEC with signatures that don't fit in
an ethernet frame is a non-starter.

The way I would do it is to use structured cryptography, that is a single
signature per zone over a Merkle tree of the individual records.

Pruning the digests to 256 bits presents an acceptable work factor and only
costs 32.log2(n) bytes where n is the number of records in the zone.


> > I am now thinking in terms of 'Post Quantum Hardened" and "Post Quantum
> > Qualified". Hardening a system so it doesn't completely break under QCC
> > is a practical near term goal. Getting to a fully qualified system is
> > going to be a root-and-canal job.
>
> There is a notion of being 'quantum annoyant' to a quantum computer:
> perhaps that might be an starting point for other schemes that do no
> have a post-quantum counterpart as of right now. For others, a hybrid
> approach should definitly be taken such that classical cryptography
> still protects data.
>

I am using PQC to protect the data and Threshold-ECC to protect the data
with separation of roles.

> The term 'interactive' is used very differently in protocol design and
> > cryptography. DH and ECDH are mutual key exchanges. Alice and Bob both
> > receive a shared secret that both contribute to equally. Kyber is a
> > unilateral key exchange, Alice encrypts to Bob's public key without
> > using her key. If we want to have a mutually authenticated key exchange,
> > Bob is going to have to encrypt something to Alice's public key.
>
> That is correct. Such is the way KEMs work. We don't have that
> counterpart in post-quantum that we can attest to a high level of
> security. This is not so evidently needed in TLS but it is on Signal,
> OTR, and other protocols. I recently sent an email to the pqc mailing
> list around the matter:
> https://mailarchive.ietf.org/arch/msg/pqc/mW1r-57_OX7kAMGPef3noC4ZF_E/


While DH does in theory allow Alice and Bob to establish a shared secret
directly using a mutual key agreement, that is not an approach I have ever
wanted to use. It means we end up using the same primary key for our key
agreement. That just feels dirty to me. I prefer to do two unilateral
exchanges and concatenate the results to get the input to the KDF which is
how Noise/Signal is doing things for the two party interaction case.

Given the use case is human-human interaction and given all the other
latency in the call setup, I have a really really hard time seeing multiple
round trips for a forward secrecy rekey. Furthermore, Signal is a closed
infrastructure, you can only use the Signal servers and the Signal client.
So I am also having a hard time seeing how their problem is our problem or
how backwards compatibility is a concern. One of my pet peeves in Signal is
in fact their nanny knows best insistence on me constantly updating their
client.


When you said 'interactive protocol', what I thought you were saying is
that Kyber requires the multiple round trips some of the early Zero
Knowledge protocols required.


PHB