bwesterb

Landmarks are generated every hour, but I expect clients to pull them perhaps once or twice per day. Servers will keep two signatureless MTCs around a few days apart, so even if your client didn't update in a few days you can still use the small signatureless cert. The biggest reason for needing the big MTCs is for when you need a new certificate quickly. Our intern Lena had a look how common that would be, and she estimates it'd be required for 0.1% at any given time. https://www.youtube.com/watch?si=72ClhykaYDHf0sND&v=f8unMB2Q...

The biggest blocker for DANE at the moment is that it doesn't have a transparency story. There is no good visibility into whether your TLD advertises a second pair of zone signing keys to few you don't control. We can add some transparency logs as with CT, but then we have a rate-limiting problem. You could have a mix of heavily rate-limited free DNSSEC logs and some paid DNSSEC logs. This is starting to look a lot like the current WebPKI then. I must say that this is an under explored area.

You only need to send one treehead per MTCA. From that one treehead the server can infer it must also have the previous few. If that's still too much, we can compress it even further by only sending "I trust the standard CAs of Mozilla plus/minus some CAs and the stalest treehead I have has this timestamp". That'll be just a few bytes.

I agree that there is a big gap between what browsers offer today, and a non-browser client. This is a good moment to improve things. There is no reason that we can't have system service populating /etc/ssl/treeheads, which openssl can read. Or fall back to $USER/.config/treeheads, or per application.

If your browser is online on an unrestricted network, then the tree heads will be kept up to date, and this will leak nothing. If you had your laptop closer for a weekend, open it up immediately and visit a website before your browser had a chance to update, well, you leak for maybe a minute or two you had your laptop closed for a weekend. So it's not that much. But we'll want to see how we can reduce this as much as possible.

It's also trusted as an EU Trust Service Provider. https://eidas.ec.europa.eu/efda/trust-services/browse/eidas/... That's basically QWACS. <ins>Ah, of course you mentioned it in the other thread!</ins>

We definitely should have, and that is on us. We'll fix it. https://blog.cloudflare.com/unauthorized-issuance-of-certifi...

If you don't mind a one terabyte public key. https://eprint.iacr.org/2017/351.pdf

About 8x just for key agreement and 40x for signatures. It's a lot. For key agreement it's worth it, and now about 1/3 of browsers in the wild use it. http://radar.cloudflare.com/adoption-and-u…

One third of all human traffic with Cloudflare is using a post-quantum KEM. I'd say that counts as enabled. We want that to be 100% of course. Chrome (and derivates) enabled PQ by default. https://radar.cloudflare.com/adoption-and-usage

About one third of traffic with Cloudflare is already using post-quantum encryption. https://x.com/bwesterb/status/1866459174697050145

Signatures still have to be upgraded, but that's more difficult. We're working on it. http://blog.cloudflare.com/pq-2024/#migrating-the-internet-t...

Go patches are out. (1.21.3, 1.20.10)

Cool!

Caddy support incoming. https://github.com/caddyserver/caddy/pull/5852

I'll take the compliment, thank you :).

If there is an n^(100^100) algorithm that solves an NP-complete problem, then P=NP, but public-key cryptography is still safe because for any practical n it's still too hard to break. There are also public-key systems that are based on NP-complete problems that are easily broken, because n is chosen too small.

Kyber is lead by Crypto Jedi: https://cryptojedi.org/peter/ :)

It's hard to say. Here is a great paper that tries to answer this question.

https://arxiv.org/pdf/2009.05045v1.pdf

See Figure 11. Optimistically 15 years. Pessimistically 35 years. But anything can happen.

And a Go implementation I wrote for Cloudflare. https://github.com/cloudflare/circl/tree/main/kem/kyber

NTRU-Prime, NTRU, Kyber and SABER are all great KEMs. NIST could've chosen any one of them. NIST never standardised Ed25519 and OpenSSH still uses it, which is perfectly fine.

I am writing one. You should use the C one, if you can.

https://github.com/bwesterb/argon2pure