<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: FiloSottile</title><link>https://news.ycombinator.com/user?id=FiloSottile</link><description>Hacker News RSS</description><docs>https://hnrss.org/</docs><generator>hnrss v2.1.1</generator><lastBuildDate>Thu, 23 Apr 2026 13:42:14 +0000</lastBuildDate><atom:link href="https://hnrss.org/user?id=FiloSottile" rel="self" type="application/rss+xml"></atom:link><item><title><![CDATA[New comment by FiloSottile in "Jujutsu megamerges for fun and profit"]]></title><description><![CDATA[
<p>I just use the VS Code git integration with the jj colocated git repo. HEAD is @- and the changes in @ are considered working copy changes. It works for all I was using the VS Code integration for.</p>
]]></description><pubDate>Tue, 21 Apr 2026 01:30:48 +0000</pubDate><link>https://news.ycombinator.com/item?id=47843488</link><dc:creator>FiloSottile</dc:creator><comments>https://news.ycombinator.com/item?id=47843488</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47843488</guid></item><item><title><![CDATA[New comment by FiloSottile in "Quantum Computers Are Not a Threat to 128-Bit Symmetric Keys"]]></title><description><![CDATA[
<p>This will probably not help enough for asymmetric keys, and is unnecessary for symmetric keys. <a href="https://arxiv.org/abs/2603.28846" rel="nofollow">https://arxiv.org/abs/2603.28846</a> claims an attack runtime of a few minutes.<p>There are enough order-of-magnitude breakthroughs between today and scalable quantum error correction, that it makes no sense to try to to guess <i>exactly</i> the order of magnitude of the attacks that will be feasible.<p>Either you believe they won't happen, in which case you can keep using long-term ECDSA keys, or you believe they will happen, in which case they are likely to overshoot your rotation period.</p>
]]></description><pubDate>Mon, 20 Apr 2026 22:31:29 +0000</pubDate><link>https://news.ycombinator.com/item?id=47841911</link><dc:creator>FiloSottile</dc:creator><comments>https://news.ycombinator.com/item?id=47841911</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47841911</guid></item><item><title><![CDATA[New comment by FiloSottile in "Quantum Computers Are Not a Threat to 128-Bit Symmetric Keys"]]></title><description><![CDATA[
<p>The calculated DW cost of the quantum attack is 2^104 (with conservative/optimistic assumptions and ignoring the physical cost of a single logical gate), which is "much more realistic than a brute force attack" in the same sense that a 128-bit brute force attack is much more realistic than a 256-bit brute force attack.<p>None of those are remotely practical, even imagining quantum computers that become as fast (and small! and long-term coherent!) as classical computers.</p>
]]></description><pubDate>Mon, 20 Apr 2026 22:26:46 +0000</pubDate><link>https://news.ycombinator.com/item?id=47841859</link><dc:creator>FiloSottile</dc:creator><comments>https://news.ycombinator.com/item?id=47841859</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47841859</guid></item><item><title><![CDATA[New comment by FiloSottile in "Quantum Computers Are Not a Threat to 128-Bit Symmetric Keys"]]></title><description><![CDATA[
<p>Hashes are symmetric cryptography primitives, and it's even proper to talk about key sizes for e.g. HMAC and HKDF hash-based constructions, to which Grover's algorithm applies analogously to how it applies to cipher keys.</p>
]]></description><pubDate>Mon, 20 Apr 2026 18:42:41 +0000</pubDate><link>https://news.ycombinator.com/item?id=47838744</link><dc:creator>FiloSottile</dc:creator><comments>https://news.ycombinator.com/item?id=47838744</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47838744</guid></item><item><title><![CDATA[New comment by FiloSottile in "A cryptography engineer's perspective on quantum computing timelines"]]></title><description><![CDATA[
<p>The world just doesn’t work in such a binary way. Forming a mental model of an entity’s incentives, goals, capabilities, and dysfunctions will serve you much better than making two buckets for trusted parties and adversaries.</p>
]]></description><pubDate>Tue, 07 Apr 2026 01:29:04 +0000</pubDate><link>https://news.ycombinator.com/item?id=47669665</link><dc:creator>FiloSottile</dc:creator><comments>https://news.ycombinator.com/item?id=47669665</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47669665</guid></item><item><title><![CDATA[New comment by FiloSottile in "A cryptography engineer's perspective on quantum computing timelines"]]></title><description><![CDATA[
<p>> KyberSlash<p>That's a timing side-channel, irrelevant to ephemeral key exchanges, and tbh if that's the worst that went wrong in a year and a half, I am very hopeful indeed.</p>
]]></description><pubDate>Mon, 06 Apr 2026 23:13:27 +0000</pubDate><link>https://news.ycombinator.com/item?id=47668636</link><dc:creator>FiloSottile</dc:creator><comments>https://news.ycombinator.com/item?id=47668636</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47668636</guid></item><item><title><![CDATA[New comment by FiloSottile in "A cryptography engineer's perspective on quantum computing timelines"]]></title><description><![CDATA[
<p>I mean "your OS and have a CRQC" because they will need to compromise the software PQ key by compromising the OS, and derive the hardware YubiKey private key using the CRQC.</p>
]]></description><pubDate>Mon, 06 Apr 2026 22:07:29 +0000</pubDate><link>https://news.ycombinator.com/item?id=47667934</link><dc:creator>FiloSottile</dc:creator><comments>https://news.ycombinator.com/item?id=47667934</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47667934</guid></item><item><title><![CDATA[New comment by FiloSottile in "A cryptography engineer's perspective on quantum computing timelines"]]></title><description><![CDATA[
<p>Thus succeeding at making the telecommunications vendors used for Top Secret US national security data less secure, the <i>obvious</i> goal of the US National Security Agency, and the only reason they wouldn't use the better cryptography designed by Dr. Bernstein. /s<p>Truly, truly can't understand why anyone finds this line of reasoning plausible. (Before anyone yells Dual_EC_DRBG, that was a NOBUS backdoor, which is an argument <i>against</i> the NSA promoting mathematically broken cryptography, if anything.)<p>Timing side channels don't matter to ephemeral ML-KEM key exchanges, by the way. It's <i>really hard</i> to implement ML-KEM wrong. It's <i>way easier</i> to implement ECDH wrong, and remember that in this hypothetical you need to compare to P-256, not X25519, because US regulation compliance is the premise.<p>(I also think these days P-256 is fine, but that is a different argument.)</p>
]]></description><pubDate>Mon, 06 Apr 2026 21:56:29 +0000</pubDate><link>https://news.ycombinator.com/item?id=47667779</link><dc:creator>FiloSottile</dc:creator><comments>https://news.ycombinator.com/item?id=47667779</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47667779</guid></item><item><title><![CDATA[New comment by FiloSottile in "A cryptography engineer's perspective on quantum computing timelines"]]></title><description><![CDATA[
<p>TIL about the Chicago Pile! (I don't know enough about the physics to tell if it could have indeed exploded.)<p>> On 2 December 1942<p><a href="https://en.wikipedia.org/wiki/Chicago_Pile-1" rel="nofollow">https://en.wikipedia.org/wiki/Chicago_Pile-1</a><p>> on July 16, 1945<p><a href="https://en.wikipedia.org/wiki/Trinity_(nuclear_test)" rel="nofollow">https://en.wikipedia.org/wiki/Trinity_(nuclear_test)</a><p>Two years and a half. This is still a good metaphor for "once you can make a small one, the large one is not far at all."</p>
]]></description><pubDate>Mon, 06 Apr 2026 21:34:06 +0000</pubDate><link>https://news.ycombinator.com/item?id=47667475</link><dc:creator>FiloSottile</dc:creator><comments>https://news.ycombinator.com/item?id=47667475</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47667475</guid></item><item><title><![CDATA[New comment by FiloSottile in "A cryptography engineer's perspective on quantum computing timelines"]]></title><description><![CDATA[
<p>If you are doing <i>authentication</i> with those hardware keys, you will probably be fine, if we do our job fast enough. Apple's Secure Enclave already supports some PQ signatures (although annoyingly not ML-DSA-44 apparently?) and I trust Yubico is working on it.<p>If you are doing encryption, then you do have reason to worry, and there aren't great options right now. For example if you are using age you should switch to hybrid software ML-KEM-768 + hardware P-256 keys as soon as they are available (<a href="https://github.com/str4d/age-plugin-yubikey/pull/215" rel="nofollow">https://github.com/str4d/age-plugin-yubikey/pull/215</a>). This might be a scenario in which hybrids provide some protection, so that an attacker will need to compromise both your OS <i>and</i> have a CRQC. In the meantime, depending on your threat model and the longevity of your secrets (and how easily they can rotated in 1-2 years), it might make sense to switch to software PQ keys.</p>
]]></description><pubDate>Mon, 06 Apr 2026 21:19:42 +0000</pubDate><link>https://news.ycombinator.com/item?id=47667296</link><dc:creator>FiloSottile</dc:creator><comments>https://news.ycombinator.com/item?id=47667296</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47667296</guid></item><item><title><![CDATA[New comment by FiloSottile in "A cryptography engineer's perspective on quantum computing timelines"]]></title><description><![CDATA[
<p>> The industry standard and general recommendation for quantum resistant symmetric encryption is using 256 bit keys<p>It simply is not. NIST and BSI specifically recommend all of AES-128, AES-196, and AES-256 in their post-quantum guidance. All of my industry peers I have discussed this with agree that AES-128 is fine for post-quantum security. It's a LinkedIn meme at best, and a harmful one at that.<p>My opinion changed on the <i>timeline</i> of CRQC. There is no timeline in which CRQC are theorized to become a threat to symmetric encryption.</p>
]]></description><pubDate>Mon, 06 Apr 2026 21:12:59 +0000</pubDate><link>https://news.ycombinator.com/item?id=47667204</link><dc:creator>FiloSottile</dc:creator><comments>https://news.ycombinator.com/item?id=47667204</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47667204</guid></item><item><title><![CDATA[New comment by FiloSottile in "A cryptography engineer's perspective on quantum computing timelines"]]></title><description><![CDATA[
<p>DES is the algorithms that was secretly modified by the NSA to <i>protect it</i> against differential cryptanalysis. Capping a key size is hardly a "backdoor."<p>Also, that was the time of export ciphers and Suite A vs Suite B, which were very explicit about there being different algorithms for US NatSec vs. everything else. This time there's only CNSA 2.0, which is pure ML-KEM and ML-DSA.<p>So no, there is no history of the NSA pushing non-NOBUS backdoors into NatSec algorithms.</p>
]]></description><pubDate>Mon, 06 Apr 2026 19:40:09 +0000</pubDate><link>https://news.ycombinator.com/item?id=47665877</link><dc:creator>FiloSottile</dc:creator><comments>https://news.ycombinator.com/item?id=47665877</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47665877</guid></item><item><title><![CDATA[New comment by FiloSottile in "A cryptography engineer's perspective on quantum computing timelines"]]></title><description><![CDATA[
<p>> from a classical security point of view PQC cannot be trusted<p>[citation needed]<p><a href="https://words.filippo.io/crqc-timeline/#fn:lattices" rel="nofollow">https://words.filippo.io/crqc-timeline/#fn:lattices</a></p>
]]></description><pubDate>Mon, 06 Apr 2026 19:36:13 +0000</pubDate><link>https://news.ycombinator.com/item?id=47665831</link><dc:creator>FiloSottile</dc:creator><comments>https://news.ycombinator.com/item?id=47665831</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47665831</guid></item><item><title><![CDATA[New comment by FiloSottile in "A cryptography engineer's perspective on quantum computing timelines"]]></title><description><![CDATA[
<p>We can disagree on the tradeoff, but if you see no upside, you are missing the velocity cost of the specification work, the API design, and the implementation complexity. Plus the annoying but real social cost of all the bikeshedding and bickering.</p>
]]></description><pubDate>Mon, 06 Apr 2026 19:27:13 +0000</pubDate><link>https://news.ycombinator.com/item?id=47665706</link><dc:creator>FiloSottile</dc:creator><comments>https://news.ycombinator.com/item?id=47665706</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47665706</guid></item><item><title><![CDATA[New comment by FiloSottile in "A cryptography engineer's perspective on quantum computing timelines"]]></title><description><![CDATA[
<p>We are stretching the metaphor thin, but surely the progress towards an atomic bomb was not measured only in uranium production, in the same way that the progress towards a QC is not measured only in construction time of the machine.<p>At the theory level, there were only theories, then a few breakthroughs, then some linear production time, then a big boom.<p>> Something doesn't add up here.<p>Please consider it might be your (and my) lack of expertise in the specific sub-field. (I do realize I am saying this on Hacker News.)</p>
]]></description><pubDate>Mon, 06 Apr 2026 19:22:44 +0000</pubDate><link>https://news.ycombinator.com/item?id=47665639</link><dc:creator>FiloSottile</dc:creator><comments>https://news.ycombinator.com/item?id=47665639</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47665639</guid></item><item><title><![CDATA[New comment by FiloSottile in "A cryptography engineer's perspective on quantum computing timelines"]]></title><description><![CDATA[
<p>Yeah, that's an audience mismatch, this article is for "us." End users of cryptography, including website operators and passkey users (<a href="https://news.ycombinator.com/item?id=47664744">https://news.ycombinator.com/item?id=47664744</a>) can't do much right now, because "we" still need to finish our side.</p>
]]></description><pubDate>Mon, 06 Apr 2026 18:56:48 +0000</pubDate><link>https://news.ycombinator.com/item?id=47665242</link><dc:creator>FiloSottile</dc:creator><comments>https://news.ycombinator.com/item?id=47665242</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47665242</guid></item><item><title><![CDATA[New comment by FiloSottile in "A cryptography engineer's perspective on quantum computing timelines"]]></title><description><![CDATA[
<p>See <a href="https://bas.westerbaan.name/notes/2026/04/02/factoring.html" rel="nofollow">https://bas.westerbaan.name/notes/2026/04/02/factoring.html</a> and <a href="https://scottaaronson.blog/?p=9665#comment-2029013" rel="nofollow">https://scottaaronson.blog/?p=9665#comment-2029013</a> which are linked to in the first section of the article.<p>> Sure, papers about an abacus and a dog are funny and can make you look smart and contrarian on forums. But that’s not the job, and those arguments betray a lack of expertise. As Scott Aaronson said:<p>> Once you understand quantum fault-tolerance, asking “so when are you going to factor 35 with Shor’s algorithm?” becomes sort of like asking the Manhattan Project physicists in 1943, “so when are you going to produce at least a small nuclear explosion?”<p>To summarize, the hard part of scalable quantum computation is error correction. Without it, you can't factorize essentially anything. Once you get <i>any</i> practical error correction, the distance between 32-bit RSA and 2048-bit RSA is small. Similarly to how the hard part is to cause a self-sustaining fissile chain reaction, and once you do making the bomb bigger is not the hard part.<p>This is what the experts know, and why they tell us of the timelines they do. We'd do better not to dismiss them by being smug about our layperson's understanding of their progress curve.</p>
]]></description><pubDate>Mon, 06 Apr 2026 18:44:16 +0000</pubDate><link>https://news.ycombinator.com/item?id=47665092</link><dc:creator>FiloSottile</dc:creator><comments>https://news.ycombinator.com/item?id=47665092</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47665092</guid></item><item><title><![CDATA[New comment by FiloSottile in "A cryptography engineer's perspective on quantum computing timelines"]]></title><description><![CDATA[
<p>Remember that the entities most likely to heed those governments recommendations are those providing services to said government and its military.<p>I feel like the NSA pushing a (definitely misguided and obviously later exploited by adversaries) NOBUS backdoor has poorly percolated into the collective consciousness, missing the NOBUS part entirely.<p>See <a href="https://keymaterial.net/2025/11/27/ml-kem-mythbusting/" rel="nofollow">https://keymaterial.net/2025/11/27/ml-kem-mythbusting/</a> for whether the current standards can hide NOBUS backdoors. It talks about ML-KEM, but all recent standards I read look like this.</p>
]]></description><pubDate>Mon, 06 Apr 2026 18:42:11 +0000</pubDate><link>https://news.ycombinator.com/item?id=47665064</link><dc:creator>FiloSottile</dc:creator><comments>https://news.ycombinator.com/item?id=47665064</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47665064</guid></item><item><title><![CDATA[New comment by FiloSottile in "A cryptography engineer's perspective on quantum computing timelines"]]></title><description><![CDATA[
<p>Indeed, in an open system like the WebPKI it's fine in theory to only make the central authority PQ, but then you have the ecosystem adoption issue. In a closed system, you don't have the adoption issue, but the benefit to making only the central authority PQ is likely to be a lot smaller, because it might actually be the only authority. In both cases, you need to start moving now and gain little from trying to time the switchover.</p>
]]></description><pubDate>Mon, 06 Apr 2026 18:38:39 +0000</pubDate><link>https://news.ycombinator.com/item?id=47665027</link><dc:creator>FiloSottile</dc:creator><comments>https://news.ycombinator.com/item?id=47665027</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47665027</guid></item><item><title><![CDATA[New comment by FiloSottile in "A cryptography engineer's perspective on quantum computing timelines"]]></title><description><![CDATA[
<p>This article is more aimed at those specifying and implementing WebAuthN and SSH, than at those using them.<p>They/we need to migrate those protocols to PQ now, so that you all can start migrating to PQ keys in time, including the long tail of users that will not rotate their keys and hardware the moment the new algorithms are supported.<p>For example, it <i>might</i> be too late to get anything into Debian for it to be in oldstable when the CRQCs come!</p>
]]></description><pubDate>Mon, 06 Apr 2026 18:17:23 +0000</pubDate><link>https://news.ycombinator.com/item?id=47664744</link><dc:creator>FiloSottile</dc:creator><comments>https://news.ycombinator.com/item?id=47664744</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47664744</guid></item></channel></rss>