On Fri, Aug 5, 2022 at 8:16 PM Sofía Celi <cheren...@riseup.net> 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
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
