# A symmetric-key approach to post-quantum Web PKI

DevFeed: [A symmetric-key approach to post-quantum Web PKI](<https://devfeed.tech/articles/let-s-kerberos-36612.md>)

Original publisher: [Read original article](<http://www.imperialviolet.org/2024/04/07/letskerberos.html>)

Author: Adam Langley

Published: 2024-04-07T00:00:00Z

Content type: opinion

Language: en

Sources: [ImperialViolet](<https://devfeed.tech/sources/imperialviolet.md>)

Topics: [Cryptography](<https://devfeed.tech/topics/cryptography.md>), [Post-Quantum](<https://devfeed.tech/topics/post-quantum.md>), [Encryption](<https://devfeed.tech/topics/encryption.md>), [TLS (Transport Layer Security)](<https://devfeed.tech/topics/tls.md>), [public key](<https://devfeed.tech/topics/public-key.md>), [Security, Privacy and Abuse Prevention](<https://devfeed.tech/topics/security-privacy-and-abuse-prevention.md>), [kerberos](<https://devfeed.tech/topics/kerberos.md>)

Tags: [cryptography](<https://devfeed.tech/tags/cryptography.md>), [dns](<https://devfeed.tech/tags/dns.md>), [don-t](<https://devfeed.tech/tags/don-t.md>), [kerberos](<https://devfeed.tech/tags/kerberos.md>), [post-quantum](<https://devfeed.tech/tags/post-quantum.md>), [public](<https://devfeed.tech/tags/public.md>), [public-key](<https://devfeed.tech/tags/public-key.md>), [tls](<https://devfeed.tech/tags/tls.md>)

## AI overview

The article proposes using DNS records and shared symmetric keys with multiple certificate authorities to help authenticate a Kyber key agreement between a client and server. It notes that initial public-key connections to the authorities would still require large post-quantum signatures and raises privacy and policy concerns because authorities could observe which servers clients contact.

## Source excerpt

(I think this is worth pondering, but I don't mean it too seriously--don't panic.) Are the sizes of post-quantum signatures getting you down? Are you despairing of deploying a post-quantum Web PKI? Don't fret! Symmetric cryptography is post-quantum too! When you connect to a site, also fetch a record from DNS that contains a handful of "CA" records. Each contains: a UUID that identifies a CA ECA-key(server-CA-key, AAD=server-hostname) A key ID so that the CA can find "CA-key" from the previous field. "CA-key" is a symmetric key known only to the CA, and "server-CA-key" is a symmetric key known to the server and the CA. The client finds three of these CA records where the UUID matches a CA that the client trusts. It then sends a message to each CA containing: ECA-key'(client-CA-key) -- i.e. a key that the client and CA share, encrypted to a key that only the CA knows. We'll get to how the client has such a value later. A key ID for CA-key'. Eclient-CA-key(client-server-key) -- the client randomly generates a client-server key for each CA. The CA record from the server's DNS. The hostname that the client is connecting to. The CA can decrypt "client-CA-key" and then it can decrypt "server-CA-key" (from the DNS information that the client sent) using an AAD that's either the client's specified hostname, or else that hostname with the first label replaced with *, for wildcard records. The CA replies with Eserver-CA-key(client-server-key), i.e. the client's chosen key, encrypted to the server. The client can then start a TLS connection with the server, send it the three encrypted client-server keys, and the client and server can authenticate a Kyber key-agreement using the three shared keys concatenated. Both the client and server need symmetric keys established with each CA for this to work. To do this, they'll need to establish a public-key authenticated connection to the CA. So these connections will need large post-quantum signatures, but that cost can be amortised over