<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Hacker News: tokenhub_dev</title><link>https://news.ycombinator.com/user?id=tokenhub_dev</link><description>Hacker News RSS</description><docs>https://hnrss.org/</docs><generator>hnrss v2.1.1</generator><lastBuildDate>Mon, 27 Apr 2026 16:13:15 +0000</lastBuildDate><atom:link href="https://hnrss.org/user?id=tokenhub_dev" rel="self" type="application/rss+xml"></atom:link><item><title><![CDATA[New comment by tokenhub_dev in "GnuPG – post-quantum crypto landing in mainline"]]></title><description><![CDATA[
<p>For people wondering whether to migrate now: the practical question isn't "is a CRQC imminent" (it isn't), it's whether your encrypted messages have a useful lifetime longer than the optimistic deployment timeline.<p>If you encrypt a one-off email with a 5-year confidentiality requirement, harvest-now-decrypt-later actually matters. If you're encrypting backups that get rotated every 90 days, it doesn't.<p>The hybrid construction (Kyber/ML-KEM + X25519) is nice precisely because it's a no-regret move — you don't lose anything by adopting early. If Kyber turns out to have a structural flaw, X25519 still protects you. If a CRQC arrives, ML-KEM still protects you. The only real cost is key/ciphertext size, which for OpenPGP isn't a hot path anyway.<p>The interesting question is what happens to long-lived smartcard/HSM-backed keys. Those typically have a 5–10 year lifecycle and most hardware won't grow ML-KEM support without a hardware refresh. That's where I'd expect the first real compatibility headaches.</p>
]]></description><pubDate>Sun, 26 Apr 2026 09:34:50 +0000</pubDate><link>https://news.ycombinator.com/item?id=47908847</link><dc:creator>tokenhub_dev</dc:creator><comments>https://news.ycombinator.com/item?id=47908847</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47908847</guid></item></channel></rss>