<?xml version="1.0" encoding="UTF-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
  <updated>2026-10-26T02:42:22Z</updated>
  <generator>https://nostr.now</generator>

  <title>Nostr notes by Marin Ivezic</title>
  <author>
    <name>Marin Ivezic</name>
  </author>
  <link rel="self" type="application/atom+xml" href="https://nostr.now/npub1fecedu8qj6dfzt4xr9v0w5vk43xsfct6m64u4h0f0y3ryqu39gps0mpzk2.rss" />
  <link href="https://nostr.now/npub1fecedu8qj6dfzt4xr9v0w5vk43xsfct6m64u4h0f0y3ryqu39gps0mpzk2" />
  <id>https://nostr.now/npub1fecedu8qj6dfzt4xr9v0w5vk43xsfct6m64u4h0f0y3ryqu39gps0mpzk2</id>
  <icon>https://files.defcon.social/dcsocial-s3/accounts/avatars/109/546/844/816/218/349/original/a6e531b1b89b90e6.jpg</icon>
  <logo>https://files.defcon.social/dcsocial-s3/accounts/avatars/109/546/844/816/218/349/original/a6e531b1b89b90e6.jpg</logo>




  <entry>
    <id>https://nostr.now/nevent1qqsf5pxlet7e24qyjxpm9ckjqm6ssfkjx9lu0a09pp244knxrgq36dgzyp88r9hsuztf4yfw5cv43a63j6ky6p8p0t02hjkaa9ujyvsrjy4qxr5p8jl</id>
    
      <title type="html">NIST published the final version of IR 8547, its plan for ...</title>
    
    <link rel="alternate" href="https://nostr.now/nevent1qqsf5pxlet7e24qyjxpm9ckjqm6ssfkjx9lu0a09pp244knxrgq36dgzyp88r9hsuztf4yfw5cv43a63j6ky6p8p0t02hjkaa9ujyvsrjy4qxr5p8jl" />
    <content type="html">
      NIST published the final version of IR 8547, its plan for retiring quantum-vulnerable public-key cryptography, on October 27. &lt;br/&gt;&lt;br/&gt;NIST deprecates RSA and ECDSA signatures at 112 bits or more, EdDSA at 128 bits or more, and DH, MQV and RSA key establishment at 112 bits or more, all after 2030. All of them are disallowed under NIST standards and guidelines after 2035.&lt;br/&gt;&lt;br/&gt;P-256, P-384, RSA-3072 and Ed25519 had no deprecation step in the November 2024 draft and are now deprecated on the same day as RSA-2048.&lt;br/&gt;&lt;br/&gt;A deprecated algorithm is usable, with a risk the data owner must examine before deciding to continue. A disallowed one is no longer allowed for the stated purpose. Decrypting old ciphertext and verifying old signatures fall under a third status, legacy use. NIST doesn&amp;#39;t say how long it will last for these algorithms.&lt;br/&gt;&lt;br/&gt;From 2031, anyone following NIST&amp;#39;s statuses needs a recorded risk decision for each classical-only key exchange or signature they keep.&lt;br/&gt;&lt;br/&gt;For hybrid key establishment, the SP 800-56C composite technique stays allowed even with a disallowed input, and a combination with at least one approved input can be FIPS 140-validated. Under SP 800-56C Rev. 2, a hybrid secret Z || T qualifies for approved key derivation when Z comes from an approved scheme. An ML-KEM secret counts.&lt;br/&gt;&lt;br/&gt;The IETF put ML-KEM first in X25519MLKEM768, so the ML-KEM implementation is the component that must be validated. In SecP256r1MLKEM768 and SecP384r1MLKEM1024, the ECDH secret comes first. In SP 800-227, NIST already approves combiners with the approved secret in any position, but in IR 8547 it ties the either-order rule to a promised SP 800-56C update. Vendors shipping those groups should ask their labs how they&amp;#39;ll be treated after 2035.&lt;br/&gt;&lt;br/&gt;I&amp;#39;d keep the TLS combiner inside TLS. In SP 800-227 section 4.6.3, NIST says a combiner that uses only the shared secrets doesn&amp;#39;t, in general, preserve IND-CCA security when only one component remains secure. The security analysis in RFC 10024 relies on the TLS 1.3 transcript.&lt;br/&gt;&lt;br/&gt;The X25519MLKEM768 key share adds about 1.2 KB, so the ClientHello can span two packets, and some servers reject it instead of falling back to classical key exchange. Log the negotiated group for each production connection, and check every hop separately.&lt;br/&gt;&lt;br/&gt;Hybrid key exchange protects session keys only, so the RSA or ECDSA chain needs its own migration. An ML-DSA-44 signature is 2,420 bytes, against 64 to 72 for ECDSA on P-256.&lt;br/&gt;&lt;br/&gt;NIST gives key establishment and signatures the same dates in Tables 2 and 4. In the same report, it explains that harvest now, decrypt later makes key establishment more urgent.&lt;br/&gt;&lt;br/&gt;In Section 3.1.2, NIST still says authentication may stay classical until a CRQC is available and then switch immediately. Under Table 2, the same algorithms are disallowed after 2035 either way.&lt;br/&gt;&lt;br/&gt;Dual signatures get a definition but no encoding and no post-2035 status. Contracts and archives that must stay verifiable for decades need evidence records renewed with post-quantum algorithms, but NIST doesn&amp;#39;t mention them in IR 8547.&lt;br/&gt;&lt;br/&gt;HQC is the alternative KEM, with a FIPS in development. ML-KEM-768 is the default parameter set. LMS and XMSS are named for software and firmware signing.&lt;br/&gt;&lt;br/&gt;NIST added Ascon to the symmetric tables and printed its AEAD entry as &amp;#34;AES-AEAD128&amp;#34; by mistake. It also corrected SHAKE256&amp;#39;s preimage strength from 512 to 256 bits. The statuses that module validation applies come from SP 800-131A, and its Revision 3 is still a draft.&lt;br/&gt;&lt;br/&gt;Full analysis, with a draft-to-final comparison table: &lt;a href=&#34;https://postquantum.com/security-pqc/nist-ir-8547-final/&#34;&gt;https://postquantum.com/security-pqc/nist-ir-8547-final/&lt;/a&gt;&lt;br/&gt;&lt;br/&gt;I teach the US requirements behind these dates in PQC Compliance: United States at Quantum Academy: &lt;a href=&#34;https://quantumacademy.com/courses/pqc-compliance-us/&#34;&gt;https://quantumacademy.com/courses/pqc-compliance-us/&lt;/a&gt;&lt;br/&gt;&lt;br/&gt;#infosec #cryptography #PQC #postquantum #NIST #TLS #FIPS
    </content>
    <updated>2026-10-28T05:58:22Z</updated>
  </entry>

  <entry>
    <id>https://nostr.now/nevent1qqsp6g5t969m2z8zzsh8epr37k70mhu3zglk087jq87z27ux39mpdgczyp88r9hsuztf4yfw5cv43a63j6ky6p8p0t02hjkaa9ujyvsrjy4qx4m7plt</id>
    
      <title type="html">With the new hack-back memo, the US has shot itself in the foot ...</title>
    
    <link rel="alternate" href="https://nostr.now/nevent1qqsp6g5t969m2z8zzsh8epr37k70mhu3zglk087jq87z27ux39mpdgczyp88r9hsuztf4yfw5cv43a63j6ky6p8p0t02hjkaa9ujyvsrjy4qx4m7plt" />
    <content type="html">
      With the new hack-back memo, the US has shot itself in the foot again. And most of the initial online discussions miss how far the damage reaches. For the US.&lt;br/&gt;&lt;br/&gt;Quick summary. On August 12 the President signed a memorandum letting vetted American companies break into foreign systems used by criminal groups and disrupt or destroy them. It is not vigilantism: the companies act under federal direction, and two officials approve every operation in writing.&lt;br/&gt;&lt;br/&gt;Americans lost more than $20 billion to this fraud last year, so the motivation is real. I am not against acting. I am against this approach, and I know the arguments because I spent years making them to governments that wanted the same thing.&lt;br/&gt;&lt;br/&gt;The debate so far has been about whether private firms should do this, and whether innocent foreigners get hurt. However I analyze it, the first casualty is American:&lt;br/&gt;&lt;br/&gt;- Why would anyone share threat intel with Americans, when it could now be used to attack infrastructure in their own country?&lt;br/&gt;&lt;br/&gt;- Why would a non-US CISO keep American EDR and XDR agents deep in their stack, when nobody can tell them whether that vendor also runs surveillance and offensive operations for the state?&lt;br/&gt;&lt;br/&gt;- Why would anyone outside the US let an American vendor build the map of their weakest cryptography, in the PQC discovery and inventory work their own regulator is forcing them to do?&lt;br/&gt;&lt;br/&gt;- Why would a European buyer accept &amp;#34;we cannot comment&amp;#34; as a tender answer?&lt;br/&gt;&lt;br/&gt;- Why would an American firm disclose the flaw it just found, when its other contract values that flaw unpatched?&lt;br/&gt;&lt;br/&gt;- Why would a sovereign wealth fund hold a listed US security vendor it has no way to assess?&lt;br/&gt;&lt;br/&gt;- Why would an allied service share access with a partner whose contractors may be on the same box?&lt;br/&gt;&lt;br/&gt;- How does a US prosecutor explain the next indictment of a Chinese contractor hacker?&lt;br/&gt;&lt;br/&gt;- What does Washington say when Beijing runs the same program and calls it law enforcement?&lt;br/&gt;&lt;br/&gt;Procedures are due October 11 and need not be published. Which means these questions may never get a public answer, and every one of them will get answered by assumption instead. None of those assumptions will favor the American cybersecurity industry.&lt;br/&gt;&lt;br/&gt;&lt;a href=&#34;https://postquantum.com/cyber-kinetic-security/cyber-privateers-what-breaks/&#34;&gt;https://postquantum.com/cyber-kinetic-security/cyber-privateers-what-breaks/&lt;/a&gt;&lt;br/&gt;&lt;br/&gt;#Cybersecurity #CISO #CyberPolicy #ThreatIntel #NationalSecurity #InfoSec #VendorRisk #PQC
    </content>
    <updated>2026-08-14T16:48:08Z</updated>
  </entry>

  <entry>
    <id>https://nostr.now/nevent1qqsgu3evqlmewzqmn4g2cugxgxfjdd4peqyg4skyfqg8s0t98sqxn5gzyp88r9hsuztf4yfw5cv43a63j6ky6p8p0t02hjkaa9ujyvsrjy4qxhjeds9</id>
    
      <title type="html">Fair question, and you&amp;#39;re right that Internet-facing OT and ...</title>
    
    <link rel="alternate" href="https://nostr.now/nevent1qqsgu3evqlmewzqmn4g2cugxgxfjdd4peqyg4skyfqg8s0t98sqxn5gzyp88r9hsuztf4yfw5cv43a63j6ky6p8p0t02hjkaa9ujyvsrjy4qxhjeds9" />
    <content type="html">
      In reply to &lt;a href=&#39;/nevent1qqs9cmlscnhqjqata6athwwcyent57cf4q5esrut56jry3wkf2rdl5s77890c&#39;&gt;nevent1q…890c&lt;/a&gt;&lt;br/&gt;_________________________&lt;br/&gt;&lt;br/&gt;Fair question, and you&amp;#39;re right that Internet-facing OT and medical devices have more urgent problems than PQC. Fixing basic exposure is a prerequisite to worrying about PQC. &lt;br/&gt;&lt;br/&gt;But measuring PQC readiness by device type is how you find out which vendors and device categories will be the last-mile problem when regulatory deadlines (CNSA 2.0 2030, NIST deprecation 2030, UK NCSC 2028/2031/2035) become an issue.
    </content>
    <updated>2026-07-19T15:25:13Z</updated>
  </entry>

  <entry>
    <id>https://nostr.now/nevent1qqsxgp9kcvx64mh7ed00a4zatah8j0vus0dr5sdn93puw3yd34mahaqzyp88r9hsuztf4yfw5cv43a63j6ky6p8p0t02hjkaa9ujyvsrjy4qxc5f5mz</id>
    
      <title type="html">Internet-wide PQC measurement: 160M SSH hosts scanned. IT: 12% ...</title>
    
    <link rel="alternate" href="https://nostr.now/nevent1qqsxgp9kcvx64mh7ed00a4zatah8j0vus0dr5sdn93puw3yd34mahaqzyp88r9hsuztf4yfw5cv43a63j6ky6p8p0t02hjkaa9ujyvsrjy4qxc5f5mz" />
    <content type="html">
      Internet-wide PQC measurement: 160M SSH hosts scanned.&lt;br/&gt;&lt;br/&gt;IT: 12% PQC-capable. OT: under 5%. Medical devices: under 5%. Cloud leads because providers deploy PQC by default. Everything else waits for manual upgrades nobody has scheduled.&lt;br/&gt;&lt;br/&gt;The OT gap should alarm anyone in ICS/SCADA.&lt;br/&gt;&lt;br/&gt;&lt;a href=&#34;https://postquantum.com/security-pqc/forescout-pqc-adoption-data-2026/&#34;&gt;https://postquantum.com/security-pqc/forescout-pqc-adoption-data-2026/&lt;/a&gt;&lt;br/&gt;&lt;br/&gt;#PQC #OTsecurity #ICS #infosec
    </content>
    <updated>2026-07-18T18:49:00Z</updated>
  </entry>

  <entry>
    <id>https://nostr.now/nevent1qqsquwuv4r26kwrsanhe5p3us20z8am29xkptu8wfrnufuj4xlj0nkqzyp88r9hsuztf4yfw5cv43a63j6ky6p8p0t02hjkaa9ujyvsrjy4qxhprzu7</id>
    
      <title type="html">After the White House quantum summit, I tested the claim that ...</title>
    
    <link rel="alternate" href="https://nostr.now/nevent1qqsquwuv4r26kwrsanhe5p3us20z8am29xkptu8wfrnufuj4xlj0nkqzyp88r9hsuztf4yfw5cv43a63j6ky6p8p0t02hjkaa9ujyvsrjy4qxhprzu7" />
    <content type="html">
      After the White House quantum summit, I tested the claim that America built &amp;#34;every layer of the quantum stack.&amp;#34; Eight layers. Named researchers. Primary sources.&lt;br/&gt;&lt;br/&gt;Quick scorecard:&lt;br/&gt;&lt;br/&gt;The PQC algorithms (ML-KEM, ML-DSA, SLH-DSA) that NIST standardized and that EO 14412 mandates for federal systems? Designed almost entirely by Europeans and Canadians. CWI (Netherlands), Bochum (Germany), IBM Zurich (Switzerland), ENS Lyon (France), Waterloo (Canada). NIST ran the process — that&amp;#39;s a real institutional win. But the algorithmic content is international.&lt;br/&gt;&lt;br/&gt;The enabling infrastructure is even more striking.&lt;br/&gt;&lt;br/&gt;Dilution refrigerators from Finland (Bluefors) and UK (Oxford Instruments) dominate the market that cools US superconducting quantum computers. Domestic manufacturing exists (Maybell in Denver, Bluefors&amp;#39;s Syracuse operation) but the US remains substantially dependent on European-headquartered suppliers. &lt;br/&gt;&lt;br/&gt;Control electronics from Switzerland (Zurich Instruments), Israel (Quantum Machines), Germany (Rohde &amp;amp; Schwarz). &lt;br/&gt;&lt;br/&gt;The CHIPS Act quantum investments are partly a response to these dependencies.&lt;br/&gt;&lt;br/&gt;On the science side: Josephson junction predicted at Cambridge (1962). First superconducting qubit demonstrated at NEC Japan (1999). Surface code traces to Kitaev (Russia). Steane code from Oxford. qLDPC codes from French and Russian mathematicians.&lt;br/&gt;&lt;br/&gt;The US built the strongest commercial integration and scaling layer. That is a real and hard-won capability. It is not the same as sole authorship of the entire stack.&lt;br/&gt;&lt;br/&gt;Policy implication: &amp;#34;we built everything&amp;#34; leads to different supply chain decisions than &amp;#34;we built the best integration layer, and it depends on allied supply chains.&amp;#34; The second framing is more accurate and produces better policy.&lt;br/&gt;&lt;br/&gt;Full article with every claim sourced:&lt;br/&gt;&lt;a href=&#34;https://postquantum.com/quantum-sovereignty/who-built-the-quantum-stack/&#34;&gt;https://postquantum.com/quantum-sovereignty/who-built-the-quantum-stack/&lt;/a&gt;&lt;br/&gt;&lt;br/&gt;#quantum #PQC #infosec #cryptography #postquantum #supplysecurity #quantumcomputing #cybersecurity
    </content>
    <updated>2026-07-15T17:29:05Z</updated>
  </entry>

</feed>