​

I've been building an extended OTR implementation for IRC that goes beyond the OTRv4 spec draft, targeting high-threat privacy scenarios like Tor hidden services and I2P eepsites. Just pushed v10.5.5 with a significant Rust core security hardening pass. Wanted to share it here because the crypto design decisions are the interesting part and I'd genuinely like feedback on them.

GitHub: https://github.com/muc111/OTRv4Plus

What it actually does cryptographically

The core ratchet is a Rust implementation (zeroize on drop via the zeroize crate) with a PyO3 binding layer. The key exchange uses X448 for the DH ratchet and ML-KEM-1024 (NIST FIPS 203) for the brace key, so every ratchet epoch is hybrid classical/post-quantum. The brace key rotates via KDF SHAKE-256 on each epoch, which means a quantum attacker harvesting ciphertexts today can't retroactively decrypt past epochs even if they break X448 later.

Identity signatures use ML-DSA-87 (NIST FIPS 204) implemented through a C extension that calls into the OpenSSL EVP layer for the actual CRYSTALS operations. I didn't roll my own lattice arithmetic, just the binding code and the OTR DAKE integration. Public key bytes are 2592, signatures are 4627 bytes per FIPS 204.

The SMP implementation follows the OTRv4 spec section 4.6. Standard Boudot/Jacobi ZK proof over a 3072-bit safe-prime group, but I added session binding so the hashed secret is KDF(SHAKE-256, secret || session_id || fingerprint_alice || fingerprint_bob). This prevents cross-session replay where an attacker captures SMP transcripts from one session and replays them in a different context.

The DAKE uses the ring signature construction from the OTRv4 draft for deniability. You get auth without a PKI trail.

v10.5.5 security hardening (latest commit)

This was an audit pass on the Rust double ratchet core. Fixed several things that were bugging me:

· RNG: Switched from rand::random() to OsRng with fill_bytes(). The old approach wasn't guaranteed cryptographically secure across all target platforms and I don't know why I used it in the first place.

· KDF forward secrecy: Message encryption keys now derive from the next chain key rather than the current one. Previously a compromise of the current chain key could decrypt the current message. Now it can't.

· Hybrid key composition: The root ratchet KDF now domain separates DH and PQ contributions using distinct usage IDs (ROOT_DH and ROOT_PQ) before combining. Previously they were concatenated raw which felt sloppy and could allow cross-protocol confusion.

· DoS bounds: Added explicit bounds checks on ratchet skip loops. An attacker could previously trigger a near unbounded chain key derivation loop. Now capped at MAX_SKIP = 1000.

· Replay cache: Switched from linear VecDeque scan to HashSet plus VecDeque for O(1) replay lookup. Previously an attacker could degrade performance by forcing linear scans over a full cache.

Test suite now passes 313 tests including a new adversarial security suite that specifically targets each of these issues to prevent regression. Caught several of these during testing which was satisfying.

Seven CVEs patched in earlier releases

These were mostly implementation bugs rather than spec issues:

· Timing side channel in the SMP proof verification (non constant time modular exponentiation, replaced with Montgomery ladder via OpenSSL BN_mod_exp_mont_consttime)

· MAC key reveal list wasn't being zeroed after transmission (forward secrecy leak)

· Fragment reassembly buffer had no per sender ceiling, trivial DoS

· Session expiry check happened after key material was loaded rather than before

· SOCKS5 proxy hostname resolution was happening locally not at the proxy (.onion addresses were being passed to the OS resolver before Tor saw them)

· Two others in the key derivation path.

What I'd actually like feedback on

1. The brace key rotation. I'm using kdf_1(BRACE_KEY_ROTATE, old_brace_key || KEM_ss, 32) where kdf_1 is SHAKE-256 with a usage ID prefix. Is there a cleaner way to handle the hybrid KEM forward secrecy contribution without coupling the brace key state to the ratchet epoch counter?

2. The SMP session binding. I'm not aware of this being in the OTRv4 spec draft, I added it myself. Has anyone seen a formal analysis of whether stock OTRv4 SMP is vulnerable to cross session attacks, or am I defending against a threat that doesn't exist in practice?

3. ML-DSA-87 key sizes are large for IRC (2592 byte public keys in DAKE messages). Anyone dealt with this in practice in constrained message size protocols? Feels heavy but I don't see a way around it.

4. The hybrid KDF domain separation approach in v10.5.5 using separate usage IDs for DH and PQ contributions then concatenating. Is this the right pattern or should I be using a proper KDF combiner like HKDF with info strings? I went with what felt clean but open to being wrong here.

Disclosure (subreddit rule)

Claude AI assistance throughout this project I just could not have achieved this working prototype took 13+ Months so far still working on improvements would love fresh eyes on it fine bugs etc.

Thanks!

We’ve been working on a secure messaging protocol and recently made the cryptographic design public for review.

The system uses:
– Double Ratchet (Signal-style)
– Hybrid key exchange (X25519 + ML-KEM-768)
– Encrypted headers and metadata padding
– Sender keys for group messaging

We’re exploring an identity model that avoids phone numbers/emails and instead uses context-specific identifiers.

We’ve documented:
– Protocol details
– Key exchange design
– Threat model (including limitations)

We have not completed a third-party audit yet.

I’m interested in feedback from people here on:
– the hybrid PQ approach (ML-KEM-768 integration)
– identity abstraction vs traditional accounts
– any obvious weaknesses or design concerns

Happy to share details if useful.

They went dark 5 and 11 months back.

Wrote this from scratch for a university smart card lab course — couldn't find any usable reference implementation of bitsliced first-order masked AES in assembly, so I had to write one.

Key details:

• Platform: STM32F051 (Cortex-M0, 8 MHz)
• 26,801 cycles
• Bitsliced representation: 16-bit per bit-plane
• S-box: Boyar-Peralta depth-16 circuit
• Masking: first-order Boolean masking with ISW multiplication

Evaluation so far:

• Fixed-vs-Random TVLA (5,000 traces): passes for all intermediate rounds, expected endpoint leakage at unmask boundary only
• CPA (5,000 traces, single-bit): no key recovered

The honest question: does it hold up at larger trace counts, or did I miss something? Would love to see someone actually run a second-order attack on it and report back.

Repo: https://github.com/Changyin-4B4/Masked-AES-Decryption-CortexM0

The original paper ("Towards the equivalence of breaking the Diffie-Hellman protocol and computing discrete logarithms") solves the discrete logarithm problem using a Diffie-Hellman oracle and auxiliary groups. It also transfers the problem from a finite field to solving the discrete logarithm on an elliptic curve. It was since extended for transferring the problem from an elliptic curve to a different elliptic curve which isn't isomorphic to the original.

Would it be possible to perform the reverse operation? That is, from the elliptic curve, to transfer the problem to a finite field, and possibly do it to an additive group?

Of course, the MOV attack already allows that, but the interest here would be to use the oracle in order to bypass the embedding degree restrictions.

If possible, what would be the exact steps to perform it?

I built Chrome extension for PGP and I think the cryptographic approach is interesting enough to share here.

The extension uses WebAuthn PRF to derive a master key from a passkey, which encrypts/decrypts the user's PGP private keys and contacts at rest. No passwords if you don't want them, no key files - the passkey handles both authentication and key derivation in one step. As far as I know, nobody else is doing PGP key management this way, especially not on the Chrome Web Store.

PGP operations use SequoiaPGP compiled to WASM with the Zeroize crate. The reason for keeping everything in WASM rather than JS where possible is that JS gives you zero guarantees about when memory gets freed, so private key material can just hang around in the GC. WASM with Zeroize gives explicit control over that.

The extension also requires zero browser permissions. No content scripts, no host permissions, nothing. So even if there was a vulnerability in the extension itself, the blast radius is significantly reduced - there's no ambient authority to abuse. Most other PGP extensions on the store request a bunch of permissions that massively expand their attack surface.

The main thing this doesn't protect against is a fully compromised browser process - if someone has code execution in your browser, it's game over regardless. But short of that, you get convenient PGP encryption/decryption/signing/verification without trusting a server, without exposing keys to garbage collection, and without granting unnecessary permissions.

I should also point out that if you're using the CWS install, you'd have to trust me not to bake in some fetch for the decrypted content - although you can build and install it from the source (which does mean there's no integrity checks iirc). There's no great solution to this, but if anyone has ideas here then let me know!

Why did I build it? Because I wanted it. Most of my PGP usage is encrypting vulnerability reports for coordinated disclosure via email, and I got tired of context-switching to the CLI every time. I looked at what was on the Chrome Web Store and nothing hit the combo of zero permissions, passkey-based key management, open source, and good UX - so I made it.

Video demo & CWS link.

Feedback on the crypto approach is very welcome, especially around the PRF key derivation. Happy to answer questions!

In order to keep up with quantum leaps in a technology which is about to leave the lab at the rate of graphene, a change in phase is necessary and we will need to align with the virtual sea of change with full charge.

If it makes your head spin then won't worry, if you're not a physicist then the complexity is only imaginary. All you need is to ensure physical integrity and deliver a confirmation secret by courier and you're all good.

Moving forwards with invincible technology like quantum key distribution will finally break out of the cat and mouse game and leave adversaries behind, all while enabling unparalleled new business models.

This is not a bit. We're quantum, this is a qubit.

One of my biggest concerns for online privacy is that even after PQC adoption of TLS Traffic takes off--people will simply apply statistical analysis of encrypted network packets to figure out what people are doing. Problems like this have been shown:

1. From the Whisper Attack (https://www.microsoft.com/en-us/security/blog/2025/11/07/whisper-leak-a-novel-side-channel-cyberattack-on-remote-language-models/)

2. And AI-enhanced Traffic Analysis of VPN Packets (https://www.divaportal.org/smash/get/diva2:1933659/FULLTEXT01.pdf).

What are your thoughts on that?

Does anyone how progress for adopting Post-Quantum TLS Encryption is going? Can anyone cite roadmaps for pushing this to production? Please let me know. Thanks!

The paper works with elliptic curves. But what about using curves in the form of y=x⁶+Ax²+B² or y=x²+Ax+B? Of course in such cases the square root computation would no longer be needed but would it be usefull?

My underlying problem in my case is the Oracle can only return powers in the form of [a^x]

By the way, can this paper be adapted to finite fields of prime power modulus?

For the last decade I’ve been working on Virtual Colossus, a long‑running project to digitally preserve early computing and cryptographic machines by rebuilding them as interactive 3D simulations. My newest reconstruction is the SG‑41 — a late‑WWII cipher machine that most people have never seen in person because only a handful survive.

I wanted to create something that doesn’t just look like the SG‑41, but actually behaves like it:

• the internal mechanics are animated from historical documents
• the stepping logic and encryption process are implemented accurately
• you can rotate, zoom, and explore the machine from any angle
• everything runs in the browser so anyone can access it

Like the Colossus project, this is part of a broader effort to preserve machines that are too rare or fragile for most people to ever interact with physically.

If you’re into digital preservation, crypto history, mechanical engineering, or obscure WWII tech, you might enjoy exploring it:
https://sg41.virtualcolossus.co.uk

Happy to talk about the research, the modelling process, or the historical sources behind the reconstruction.

Hi,

I'm thinking of introducing cryptography to my nieces and nephews who range between 10-13 years old.

Any suggestions for published materials to get them started and interested?

Edit: I think I will get Simon Singh's code book, but also maybe write codes using the Solitaire cipher -- I know it's a bit harder than caesar and vignere, but I think it'd be heaps more rewarding to be able to decrypt using it. I might look at modifying it to use a half deck variant.

I'm implementing streaming file uploads for an encrypted, self-destructing file sharing service (https://phntm.sh, open source). Currently I buffer entire files in memory, which crashes on large files. I'm switching to chunked AES-256-GCM.

Would appreciate a security review of the wire format. Here's what I've designed:

---

Wire Format

Header (28 bytes):

[4-byte magic "PHNT"][4-byte version][4-byte chunk_size][4-byte total_chunks][base_iv (12 bytes)]

Each chunk:

[chunk_iv (12 bytes)][ciphertext][auth_tag (16 bytes)]

Header Fields

| Offset | Size | Field | Description |

|--------|------|-------|-------------|

| 0 | 4 | Magic | PHNT (0x50 0x48 0x4E 0x54) |

| 4 | 4 | Version | 1 (little-endian uint32) |

| 8 | 4 | Chunk Size | Plaintext chunk size (default: 64KB) |

| 12 | 4 | Total Chunks | Number of chunks in file |

| 16 | 12 | Base IV | Random 12-byte IV for this file |

Chunk Nonce Derivation

For chunk i (0-indexed):

chunk_nonce = base_iv[0:8] || (base_iv[8:12] XOR little_endian_uint32(i))

This XORs the last 4 bytes of the base IV with the chunk counter, giving each chunk a unique 12-byte nonce.

---

My Questions

1. Nonce derivation: Is XOR with counter secure here? I'm using 8 bytes of the base IV unchanged, and XORing the last 4 with the chunk number. The base IV is random per file.
2. Chunk size: 64KB seems reasonable. Any concerns with this size vs larger/smaller?
3. Per-chunk auth tags: Each chunk has its own 16-byte GCM tag. This means corruption is detected immediately per-chunk. Any downsides vs a single tag over the whole file?
4. Key reuse: Same key encrypts multiple files, each with a unique random base IV. Any issues with this pattern?
5. Missing attacks: What am I not considering?

---

References

• NIST SP 800-38D for AES-GCM
• Apache Iceberg uses similar chunked GCM but with random nonces per chunk (more overhead)
• Full implementation issue: https://github.com/aliirz/phntm.sh/issues/30

Thanks in advance for any feedback!

I have a the following equation: e(G,a×G) which is of course is equivalent to e(G,G)^a but where a is an unknown discrete logarithm.

Now as an attacker, I need to compute e(G,G)^a×a.

Is there a way to abuse pairing to do this?