I was noticing something: unlike on semiprimes, it s quite easy to generate a point of known small order on a curve defined on a semiprime without knowing it s factorization. The idea is to transfer this small order to the underlying semiprime using a pairing method derived from the Weil pairing. Knowing if a given specific small order exists can be derived using congruences modulo N.

As you know, the problem is then to avoid a degenerate output from the Miller s algorithm. The problem is the only method I know to avoid this without using the factorization is to use a distortion map that works only with supersingular elliptic curves. But using a supersingular curve caps the order to gcd(p+1,q+1) which is unknown most of the time or just equal to 2. Taking order 2 result in generating outputs equal to 1 or -1. Useless for gcd factoring.

So, any idea of a pairing mechanism that would works over ordinary elliptic curves using embedding degree 1? Possibly using a distortion map that works over ordinary elliptic curves in such a case? Or a pairing that works with simple final exponentiation such as cubing or squaring?

Hey folks,

So I now know how to do Symmetric Key Exchange, over a public channel (all data exchanged is public) using just symmetric keys ciphers (which need to be as strong as a KPRF, for example like SKREMAlpha).

So basically starting with nothing, Alice and Bob agree on a key of arbitrary length, WITHOUT using public key cryptography at all.

How is this called in literature? Is this a new result?

So it's basically based on Meet in the Middle Key Exchange plus key length amplification.

Best,

Mircea Digulescu

This blog post goes over the N-Able passportal vault leak, where the access and refresh tokens for users passportal instances were leaked to any site or iframe a user visited/was presented with.

The key management here is insane for a password manager in 2026, this leaks the entire vault, giving attackers persisted access because of the architecture of this password manager, where the passwords are decrypted on the server and the vault key material is encoded in the accessToken, which is sent to the server upon every request.

From my testing, I think there's a server side secret alongside the decryption key in the accessToken as I was unable to decrypt the "?decrypt=false" returned content.

edit: title was meant to say "Vault Key Material"

Did I wrote pure garbage? I d like a first check before waiting for peer review.

After reading about cases where weak entropy led to unsafe keys and people losing funds (recent bitcoin COLDCARD attack) , I decided to learn more about entropy and how it is generated.

There are different ways to generate entropy, like TRNGs, PRNGs, rolling dice, or flipping coins. But for me, it was hard to make these concepts click and understand how we go from a random source of entropy to something like a private key.

So I made a tool that explains this visually.

Live Demo: https://hashexplained.com/entropy
Source (MIT): https://github.com/bitcoin-dev-project/hashes-visualizer

This is seems noteworthy. It's from Simon.

Correct me if I'm wrong but the approximation factor of sqrt(n)polylog(n) means that current lattice cryptosystems would be in danger and not PQ-algorithms anymore.

Coinspect recently disclosed Ill Bloom, a vulnerability affecting recovery phrases generated using the historical CryptoJS.lib.WordArray.random() implementation.

The affected CryptoJS 3.x code used a Multiply-With-Carry construction seeded with values derived from Math.random()

The technical disclosure, including the PRNG reconstruction and affected-version analysis, is here:

https://illbloom.org/

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.

Hi, I'd like to share a personal research project with the community: PQC-Labs, a set of reproducible engineering experiments evaluating how the NIST post-quantum standards (ML-KEM / FIPS 203, ML-DSA / FIPS 204) are being adopted in real-world software — OpenSSH and OpenSSL so far.

Each experiment is documented (objective, methodology, results, conclusions) and reproducible via Docker. It's not a product or commercial project — just documented lab work I'm sharing openly.

Project: https://pqc-labs.github.io/pqc-lab

Code: https://github.com/PQC-labs C

Thanks!

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.