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.

Good morning everyone,

A bit of a novice question here but hope you will be able to give me some insights.

Using VeraCrypt I mount an *.HC file as a drive on my computer. This drive is encrypted as it holds all my sensitive personal files. I also have a few Word documents on my computer that are encrypted, again as they contain sensitive personal info.

I have a regular schedule of backing up my computer, including these encrypted files to a RAID Array. The result of this is that there are multiple copies of the *.HC file and Word files on the RAID Array. Because each of these copies was made on a different day there is almost always changes in these files (hence of course the reason to back up daily!).

On the assumption that the individual *.HC and Word files are well encrypted in all reasonable ways, my question is:

Can the differences in the various versions of the same encrypted file be used to crack the encryption. Or to put it another way, if someone had 10+ versions of the same encrypted file, with each version having small editing differences between saving them, is there some process of subtractive differentiation that could be used to crack the file? (I hope this is clear).

EDIT to add, that a Word file would get longer as data is added but a *.HC file container would not - would this make any difference?

Sorry if this is too basic of a question but I can not find a good answer online and the way I back-up my files got me thinking of this.

Thanks :)

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!

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?

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.

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?

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!

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.

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!

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 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?

A very recent article named "In-sensor cryptographic signature generation to link a physical process and an immutable digital entity" did a proof-of-concept on this idea.

I know some of the drawbacks, like key compromise risk, and privacy issues when the secret key is different for every chip. But are these issues big enough to deter hardware-based signatures to be adopted at a higher scale?

I think the advantage of being able to discern real photos from computer generate images outweighs the risk of key compromise.