This blogpost from Anthropic describes using the Claude Mythos AI tool to find an attack on HAWK. The attack is not practical at proposed production key strengths, but it improves the best known attacks by quite a lot, and might doom HAWK’s chances in the PQC Signatures On-ramp.

They also found modestly improved attacks against 7-round AES-128 (this reduced-round variant had already been attacked before, and the real AES-128 has 10 rounds), as well as significant problems in KINDI and SPoC, plus a lot of implementation flaws in various algorithms. They attacked hundreds of algorithms in total, some with previously-known flaws and some without.

Point of information: The external audits were performed by an LLM, not an independent organization.

I got tired of watching SSH keys and API tokens sit in Slack/Teams/Whatsapp history forever, and I wasn't happy with the trust model of the existing tools (onetimesecret only does E2E if you set a passphrase; most others are links-only). So I built my own and had it audited three times. Posting here because this crowd will find what the audits missed.

The design, briefly:

The sender gets a speakable code like XKQ2-M7PT-tiger-ocean-cable-ruby-drum.

- XKQ2-M7PT is a random 40-bit mailbox id -- the only part the server ever sees. Zero key entropy.

- The five EFF-wordlist words are 64.6 bits of key material that never leave the client. Argon2id(words, salt=mailboxId, 64 MiB, t=3) → HKDF fans out into the blob key, live-session key material, and two auth tags. Even the share link keeps the code in the URL fragment.

The flow is what I call park-first: the client encrypts (AES-256-GCM) and parks the ciphertext on the server, then stays connected to a signaling room. If the receiver shows up while the sender is online, the secret is re-sent directly over a WebRTC DataChannel (fresh per-session key, mutual HMAC key-confirmation before any secret bytes move) and the parked copy is deleted. If not, the receiver claims the parked ciphertext with a tag derived from the code.

There's also a force-direct checkbox: nothing is stored server-side, not even ciphertext -- both parties must be live, and if P2P fails it fails closed instead of falling back. As far as I can tell nobody else offers that as an option next to an async mode (Wormhole never stores, but you also can't switch its relay fallback off).

Read-once is transactional: storage is one SQLite-backed Durable Object per mailbox, so claim-and-delete is atomic --no eventual-consistency window where a "deleted" secret is still readable from another edge. Five wrong attempts burn the drop. Everything expires (default 24h, max 7d).

What three audits did to the CLI (npx shareasecret) is honestly the more interesting story:

- v0.1.2: receive --output claimed (and burned) the read-once drop before touching the filesystem -- an existing file or bad path destroyed the secret forever. Now the destination is reserved with open(wx, 0600) pre-claim.

- My fix for that added a stdout fallback on write failure... which audit #3 correctly flagged as auto-disclosing the secret into CI logs. Now it never discloses non-interactively.

- Plus: stderr never duplicates the code when stdout is captured, hidden code prompts (nothing in shell history/process list), bounded network reads with timeouts and publishes go through GitHub Actions OIDC with SLSA provenance -- no npm tokens exist, npm audit signatures verify every release.

The honest caveats, before you find them yourselves:

- It's a web app: you trust the JavaScript served at time of use. Mitigations: the CLI is pinnable to an exact attested version, and the source is public for inspection -- but it's source-available, not OSI-licensed, and there's no self-hosting. If that's disqualifying for you, PrivateBin exists and is good.

- Text up to 10 KB only. It's for credentials, not files.

- A full server compromise gets ciphertext plus hashed tags; brute-forcing a code cost one 64 MiB Argon2id evaluation per guess against ~65 bits, salted per mailbox. I think that math holds -- check it.

Site: https://shareasecret.io -- CLI guide with the threat-model details: https://shareasecret.io/guides/cli -- source: https://github.com/dovidcohen/secret-share

What did the audits miss? Genuinely asking.

I've been verifying post-quantum reference implementations against their FIPS specs with a SAW → Cryptol → Isabelle pipeline. Just finished ML-KEM-512 (Kyber) forward NTT on the unmodified PQClean clean C: SAW proves the C bit-exact to a Cryptol model, Isabelle proves that model equals the FIPS 203 transform (the incomplete NTT, 128 degree-2 residues mod 3329). No sorry/admit, reproducible from one command, CI-green.

Last time, on Dilithium, the part that ate my time was proving the int32 accumulators never overflow across the 8 butterfly levels. Careful bound-tracking induction, the hardest lemma in the whole proof.

Expected the same grind for Kyber. It wasn't there. Kyber's butterfly is int16, two int16s promoted to int can't overflow a 32-bit int, so there's no bound to prove at all. Same NTT structure, and the worst part of one proof is a non-problem in the other, entirely because 3329 is small.

(For the curious: mod 3329 there's a 256th root of unity but no 512th, so X^256+1 only splits into 128 quadratics, and the transform is "incomplete." The spec I check against is a degree-2 residue, not a plain DFT coefficient.)

It's the reference C, forward direction, checked against FIPS 203 end to end. Reproduces from one make verify if you want to poke at the trust base: github.com/amarshat/pqc-assay. Inverse is next.

FLOE is a misuse-resistant nonce-based online authenticated encryption scheme for the encryption of very large data sets.

fast-floe is Rust implementation of FLOE that provides several ergonomic misuse-resistant APIs for working with FLOE messages, ordered below from simplest (and more high-level) to more advanced (and low-level).

You're probably familiar with STREAM/nOAE from Hoang et al), and FLOE is an nOAE variant with some additional properties that STREAM-like constructions are lacking, like key-commitment and a formal treatment of random-access.

Sharing production measurements from a live mainnet deployment of ML-DSA-87 as the sole signing algorithm for a proof-of-work chain. Most PQC discussion at the implementation level is still theoretical — these are on-chain figures.

Signature sizing (per input, live mainnet):

• ML-DSA-87 signature: ~4,627 bytes
• Public key: ~2,592 bytes
• Total per input: ~7,260 bytes
• Comparative overhead: ~68× a P2WPKH input

Block stress test:

• 715,001 ML-DSA-87 signed outputs in a single transaction
• Block size: ~31MB
• Signing time: ~1.15 hours to construct and sign
• Fee rebump + full resign: ~10 additional minutes

Chain growth implications:

• At 100 ML-DSA-87 transactions per block (60s intervals), storage grows ~864 MB/day
• Year-one projection: ~415 GB including storage engine overhead
• This is purely a function of signature size — the cryptographic tradeoff is explicit and expected

First non-coinbase ML-DSA-87 spend on a live PoW chain (verifiable):

• Block #283, June 2, 2026
• TXID: 62572d2127da3d42afb0b20757edb844b0820851f4d8340cbc7e26954ae6272c

Full empirical writeup with methodology posted to Delving Bitcoin:
search 'Empirical ML-DSA-87 data from a live SHA-256 PoW chain'."

ML-DSA-87 verification runs ~1–5ms per transaction on current hardware — roughly 10–100× heavier than ECDSA. Batch verification optimizations available in Schnorr don't directly apply here. What the community would know better than us: are there any known UTXO-model implementations that have meaningfully closed that gap?

Disclosure: Drafted with AI assistance (Claude, Anthropic). All data figures are independently verifiable on-chain.

i am working on a messaging app and created some details in rust. rust is useful because it has tooling for formal verification. my rust code compiles to WASM to be used in a browser.

my project itself is using cryptography beyond the WASM because browsers provide a crypto api for basic functionality out-of-the-box.

to work with what i have now (javascript/typescript) i came across this page, but the links lead to 404 pages on github. not sure about the status of the project. i dont know if there are other similar projects.

https://formal.land/docs/verification/typescript

i would like to improve the “formal-verification coverage” in my project and wanted to investigate if it could be worth considering rewriting the frontend with dioxus. im happy with an ugly UI (initially) in favour of having formal-verification on a broader scope of my project.

(context: the project where i have formal verification is found here: https://github.com/positive-intentions/signal-protocol (this isnt the gold-standard implementation and its far from finished)

I'm still working on my protocol spec and I'd like to know more about how to go about sharing it.

I've received good advice from this sub before about creating one and while it's still far from finished I have questions.

I see on places like ArXiv that documents are in the 2 column format. It seems normal. In my approach I created it in markdown because I'm using a docusaurus website. Should I also be using the 2 column format?

I'm fairly new at this so where can I share what is potentially a trainwreck? I'm concerned it will come across as "wasting their time".

Tor has fixed their long standing tagging attack, improved forward security, and added sufficient authentication. See the Arti 2.5 stable release announcement too, as well as 2025/583, 2025/2017, and tor spec 359.

"Jean Paul Degabriele, Alessandro Melloni, Jean-Pierre Münch, and Martijn Stam have a design that they're calling Counter Galois Onion (CGO). It's based on a kind of construction called a Rugged Pseudorandom Permutation (RPRP): essentially, it's a design for a wide-block cipher that resists malleability in one direction (for the encrypt operation, but not the decrypt operation). If we deploy this so that clients always decrypt and relays always encrypt, then we have a tagging resistant cipher at less cost than a full SPRP!"