Dev Breakfast · 2026-09-26

You can forge 1024-bit RSA signatures without factoring the modulus: 1380 CPU core-years, five calendar months, 2³² oracle queries, with about 1200 core-years in precomputation. If you think keeping the RSA signature oracle as a black box is secure, this 'lunchtime attack' is aimed right at you.

Forging 1024-bit RSA Signatures: 1380 CPU Core-Years, No Modulus Factorization

RSA's security is based on the assumption that factoring large integers is hard, but a new paper argues that this assumption might be misapplied. Researchers from the University of California, San Diego, and Inria implemented a 2007 algorithm proposed by Joux, Naccache, and Thomé, forging 1024-bit RSA signatures without factoring the modulus. The total cost is 1380 CPU core-years over five calendar months, plus 2³² oracle queries. Most of this is precomputation (about 1200 core-years), after which the attacker can forge any signature offline with just 180 core-years. For comparison, factoring a 1024-bit RSA modulus currently requires 500,000 to 1,000,000 CPU core-years—meaning this path is three orders of magnitude faster.

What's truly worth stopping to look at for those who write code is its threat model: the so-called 'lunchtime attack' requires the attacker to have temporary access to a raw RSA signing/decryption oracle. After losing access, they can still permanently forge any signature for that key. The paper used an HSM as the oracle to complete the entire attack, performing only black-box API interactions without stealing the key. RSA blind signature schemes naturally provide the same oracle. According to the paper's extrapolation, 2048-bit RSA would only require 2⁹⁰ computations and 2⁴³ queries on this path, whereas it's typically considered to offer 112-bit security; even 4096-bit RSA fails to meet the 128-bit security level. The conclusion is: in scenarios with a signing oracle, RSA's actual security strength is 15 to 30 bits lower than estimates based on factoring.

Don't rush to check your TLS configuration. The paper itself states that this does not pose a direct operational threat to most modern RSA deployments—you first need to let the attacker access that oracle. Moreover, 1024-bit signatures have been prohibited by NIST for generation since 2013, and the mainstream is now 2048-bit. This research is more like adding a piece of classic cryptography evidence to the idea that 'RSA's bill must be paid early': NIST plans to deprecate RSA by 2030 and prohibit it by 2035, shifting to post-quantum algorithms, and this paper means that even if quantum computers don't arrive, RSA should go.

💡 Chef's take: Pay attention to the 'temporary' in the threat model—it's not about obtaining the key, but about gaining access to the signing interface for a period of time, then using it offline infinitely. So what you should really audit is not the key length, but which parts of your system expose raw RSA signing or decryption capabilities.

Sources:

• Forging 1024-bit RSA signatures in nearly SNFS time (IACR ePrint 2026/2131)

Go 1.27 Experimental SIMD: Vectorized Code Across Platforms Without Writing Assembly

Go 1.26 added SIMD APIs for amd64, and 1.27 extends this to arm64's NEON and wasm, taking a step further: a fully portable simd package that ignores platform and vector width. Previously, using SIMD required writing Go assembly, and only truly performance-sensitive kernels were worth the hassle—resulting in a lot of code that could have benefited from vectorization, with half of the CPU's width idle.

The package's design philosophy is 'only take the intersection.' SIMD differences across platforms are huge: wasm, PowerPC, and s390x have fixed 128-bit vectors, amd64 has 128/256/512-bit options, riscv64's vector length varies from 128 to 65536 bits and must be a power of two, while arm64 has fixed 128-bit NEON and variable 128-2048-bit SVE. Masks also vary: wasm, AVX, AVX2, and NEON lack mask registers entirely, relying on bitwise vector operations; AVX512 and RVV have dedicated mask registers; SVE allocates one bit per byte, but only the lowest bit of each element mask is effective. simd hides all these differences, taking the common operation set across platforms, simulating missing operations in the intersection with other SIMD instructions efficiently, and falling back to pure simulation on platforms without SIMD to ensure code always runs.

In usage, vector types are capitalized complex base types, like simd.Uint8s, simd.Float32s, reading from slices via LoadFloat32s and writing back via Store. Build with GOEXPERIMENT=simd. Currently supported are amd64's AVX/AVX2/AVX512, arm64's NEON, and wasm's SIMD instructions. There are two pitfalls to know first: one is that 1.27 still lacks a public operation for cross-element summation, so the official example can only store the vector back to a slice and use a handwritten loop to add, with ReduceSum waiting for the next version; the other is that comparison operations produce mask types tied to element width, so Int8s comparison yields Mask8s, and you must sort out this correspondence in the type system yourself.

For Go developers, there's no rush to change dependencies in the short term—this is an experimental API, and the GOEXPERIMENT switch might change anytime. But it's worth noting the direction: for computation-intensive tasks like encryption, data processing, and AI inference, which previously required assembly or resignation, there's now a path of 'write once, near-assembly performance.' To try it, start with structured loops like innerProduct, first profiling to confirm the hotspot is indeed in computation, and don't spend time on places that weren't slow to begin with.

Sources:

• hackernews · yurivish

ansi2html One XSS, SourceHut Account Takeover

SourceHut's build log pages can be compromised with a sequence of ANSI escape codes. Security researcher arusekk, while tinkering with sr.ht's packaging workflow, glanced at the HTML source of build logs and found that the ansi2html library, which converts ANSI color codes to HTML, essentially mishandles OSC 8 hyperlinks. The crafted input looks like this: \33]8;;https://example.com/"/autofocus/tabindex="1"/onfocus="alert\xss`\7Nothing to see here\33]8;;\7, and it gets output verbatim as —the double quotes close the href, and the subsequent attributes become part of the DOM. Another even simpler one: hrefs starting with javascript:` are passed through. The vulnerability is numbered CVE-2026-92973.

To trigger it, you don't even need an account. By sending a patch with CI to a public mailing list or controlling any remote resource that gets printed to logs, you can generate a build job at https://builds.sr.ht/~someone-else/job/1234567. Whoever opens this log page runs the payload in their browser. The log page itself contains CSRF tokens, which can be obtained with document.querySelector('[name=_csrf_token]').value. Combined with the 'Resubmit build' form, once an administrator views it, permissions are compromised. Even more valuable are the deploy keys on builds.sr.ht, including sr.ht's own. The author is restrained: how to write the payload is left for you to practice, but don't try it in production, even your own.

The fix has three layers. The upstream ansi2html under pycontribs had been dormant for over a year, so the author filed an issue and a PR. SourceHut's Drew directly added output sanitization to builds.sr.ht, at the cost of losing colors in logs now—protected, but also stripped functionality. The author's suggested proper fix is to tighten CSP, first removing unsafe-inline (though the log page's own scrolling script is inline, making this step difficult), then rewriting ansi2html into a stateful conversion automaton. For coders, this has two implications: first, if your CI renders external input as HTML, whether in logs, diffs, or reports, it's the same pitfall; second, a dependency that hasn't been maintained for over a year won't automatically be secure just because 'it's basic.' Checking those small libraries in the lockfile that 'just convert a format' is more cost-effective than waiting for the next CVE.

Sources:

• SourceHut account takeover via build logs (XSS in ansi2html.py) | CVE-2026-92973

Avast Kernel Driver Double Read Vulnerability: Privilege Escalation to Kernel on Windows 11

A security team has published full exploitation details for CVE-2025-13032: the Avast kernel driver reads the Length field of _UNICODE_STRING twice, first allocating kernel pool with a low value, then memcpy with a high value. In the window between, another thread flips Length to 0x1000, causing an overflow into a kernel pool out-of-bounds write, ultimately achieving arbitrary kernel read/write and local privilege escalation. The exploit worked on the then-current Windows 11, and the author says the race window is narrow but can be hit stably with few iterations. The good news is that newer Windows kernels use user-mode accessors to verify each access, closing this exploit path. Users of antivirus software can check their versions, and developers writing drivers should remember: read user-provided lengths only once; reading twice creates a vulnerability.

Sources:

• hackernews · safateam

Topcoat 0.9 Release: Rust Full-Stack Framework Adds Client-Side Reactivity

Topcoat, the Rust full-stack framework announced by the Tokio team two months ago, today releases version 0.9. Author Carl Lerche, once part of the Ruby on Rails core team, wants to bring that 'out-of-the-box' experience to Rust: views, components, mailer, ORM (Toasty) are all included, aiming to make Rust's productivity for web applications match other languages. The focus of 0.9 is client-side reactivity, with APIs and components like shards, live!/emit!, suspense, and error_boundary now available, essentially moving towards the browser side on top of server-side rendering. The original text mentions that applications can use only about 20MB of memory, a number attractive to those accustomed to Node.js. But whether a framework is good ultimately depends on whether writing business code requires fighting with lifetimes and generics—the author himself admits Rust isn't as elegant as some modern languages. Rust for upper-layer applications is worth watching, but don't rush to migrate production projects.

Sources:

• Topcoat is pushing the boundary of server applications with Rust | Tokio

---

Do you have an interface that exposes raw RSA signing or decryption? Do you dare treat it as a temporary lunchtime contact, or must you assume it's already leaked? See you tomorrow at 8 AM.

This issue selects 5 out of 58 pieces of information from the past 24 hours on X / Hacker News / GitHub Trending (sampled hourly throughout the day, fact-checked, and compiled in the morning). Content is generated with LLM assistance, each item includes original source links, and important decisions should be cross-verified.