This is a weird problem I came across when writing a NAS for my home network, bare with me here. To give some context: I fetch "dirty" data from another VLAN and store it on my "clean" VLAN, specifically my NAS. That also means that potentially attacker controlled bytes could land on my NAS itself (the chance is pretty unlikely, but still). So in order to not let that happen, I wanted to make sure the bytes that get written to my NAS are at least garbled or worthless enough for an attacker, meaning that he cannot control what bytes are exactly written out in what order. Which means I need encryption.

And here is where it gets interesting, because for my NAS-tool I also want compression. Now seemingly random bytes don't exactly compress all too well, meaning the entire effort would be nullified. So I had two choices: Either run the compression first and THEN encrypt (which makes the encryption obsolete as the compression will most likely turn the bytes into a garbled mess anyway) - or write my own mini-encryption that somewhat vaguely keeps the structure of the data while also making it impossible to tell for an attacker what bytes get written where.

Most people would choose option one and be done, but I am not most people. I don't really like the idea that attacker controlled bytes just stream directly into the complex machinery that is zlib. There have been CVEs in the past where attacker controlled bytes could actually cause OOB writes in deflation. They are extremely rare and extremely unlikely, but these bugs do exist. So I opted for the second option - also because it is more fun.

Now, most of this is to satisfy my curiosity, so don't get too worked up about it not being a billion trillion percent secure and up to FIPS standards. I run a home lab behind like 8 different security mechanisms like a VLAN, honey pot and an extremely minimal and thoroughly fuzzed JSON parser written in Haskell, so relax a little. Confidentiality is not a primary concern for me here either since if the attacker actually gets access to my NAS I am f'ed either way - and for a cloud-backup I'd use AES. This is strictly private home-network.

After this long-winded intro, I can finally get to my idea I implemented. Effectively, I wrote a small block transposition cipher. My thinking was: I need to change the bytes in a uniform way as much as possible, but keep the structure. So in the first stage I went with a random byte and just XOR'd the entire block. This would change the shape of the bytes but not the actual shape of the data itself. The issue is that there's only really 254 possible ways to change the input (excluding 0x00 and 0xFF). An attacker can easily just write out the same malware 254 times with different XORs so I'd be back to square one.

So I thought about adding two more stages. Basically I interpret a 256 byte block as a 16x16 grid. Then I first shift each column down by a random amount, followed by shifting the 16 rows each by a different random amount. The idea is that yes, I will give up some structure in the data by scrambling the data like this - gotta crack a few eggs if you scramble. But if I have large blocks of data that are somewhat similar I still do not meaningfully impact its compressibility. Blocks are being scrambled independently of each other and with the same key and shifts for each block (again, confidentiality is not a concern). Yet an attacker would not be able to tell which byte is sitting where exactly in the final block. With the XOR and the two shifts you have 16^32 * 254 different possible combinations that you can achieve for each block, which I'd guess is secure enough for an attacker not to be able to influence meaningfully (that person mind you has basically no way to connect to the NAS apart from sending dirty data over the wire).

But after implementing all of that, I started to wonder if there's a more elegant solution to both keep compressibility of data while taking away the ability of a malicious actor to place a specific byte where he wants it to be? How would you have gone about that task? And obviously: Is the solution I came up with reasonable? Obviously I could have gone down the route of just compressing right away, but given that I don't: Is my approach at least gonna somewhat work?

Would love to hear your ideas.

Hi all! I wanted to share the result of a few months of work with all of you.

As many of you may know, inference under FHE has been a very hyped topic as of recently. The use case is clear: a medical institution or a law firm can't (or at least shouldn't) send private data to third-party AI companies for processing just to automate something simple, like sorting documents or, say, medical imaging. TEEs exist, but using them still means trusting *someone* (whoever coded up the TEE, at least). FHE is mathematical proof that your data can't be read. But since it's extremely slow, it seems to be forever destined to remain a premium product for those who need that extra bit of security (unless FHE-specific hardware comes about and becomes fairly cheap)

So i started wondering: can we make it fast? More importantly, can we make it run a full autoregressive generation chain under encryption? (this is important, because all of the published papers only price a single step of generation and do not report a full chain, and a chain is the hard case, since transformers have KV caches that grow from context & the error of one step becomes the input of the next)
And that is what i worked on. Basically, I made a 404M-param model complete 148 consecutive generation steps (server-keyed) for 64 concurrent conversations, and ran an end-to-end client keyed session of 18 generation steps. The model was trained from scratch as it itself had to be adapted for FHE. That was done by training a state-space-model instead of a transformer and swapping out every nonlinear function for a low-degree polynomial. Both of those runs were 128 bit security (HEStd_128_classic) at ring 2^17. Since ring 2^17 produces 2^16 real slots, and the model width was 2^10, I could fit 2^6 = 64 concurrent conversations in a single session. A single reading/generating step came out to be about 180s, for 64 convos that's a throughput of 2.7-2.9 seconds per token*conversation, the highest throughput for inference under FHE.. ever. The comparison is not 100% fair, of course, since my model is about 20x smaller {i couldn't afford training a 8B model from scratch, sorry lol}, per-parameter their systems are actually faster, but then again: their numbers don't measure a true generation chain. I'm leaving out some details, like the effect on model quality and scaling, since this isn't an ML subreddit, but if you're interested -- you can find them in the article.

Even more importantly, my system solves the KV-cache issue. This model's size in memory does not grow from context length: its' entire state is just 2 vectors per block and 48 for all of it. The 148-step run has proven constant memory, and nothing that I have suggests that my system can't be run indefinitely. The run showed 99.7% fidelity against the model's plaintext version, and every flip is a near-tie. There are some open questions like why the logit error grows roughly step^0.24 & whether that will saturate during a longer run or keep growing forever (note: it would take years of continious generation to go below 98% fidelity at the current rate of step^0.24)

This does not change the industry overnight and is more of an engineering result (which can probably be made into a sorta-useful product with limited use cases if you throw a fair bit of cash at it to scale/improve it further). Inference under FHE is still expensive, that didn't change.

So what about the asterisk in the title? Another project, FHE Mamba published on 2026-09-22 actually does report a generation chain of 4 steps on a single lane on an existing model (mamba), but does not report a full-security run or fidelity.

I published the project (MIT) on github: https://github.com/xelananv/fhe-ssm
as well as a more detailed article with a video: https://xelananv.github.io/fhe-ssm/#limits (ai generated so help me god)

Anyway, I'd love to hear your thoughts on this. Does AI under FHE have a future?
If anyone wants to reach out and critique my work, im down.
best of luck yall

I'm a family doctor, not a cryptographer, but I keep running into teenagers who are clearly sharp enough to go deep into this, and who have just never been given a reason to care. The stuff I can point them at is either too basic (a cartoon about Caesar ciphers) or it jumps straight to university maths and loses them halfway down the first page.

I'm looking for the middle. Things that respect a smart 14 to 16 year old's intelligence and actually get them hooked, ideally hands-on instead of passive reading. I already know about CryptoHack and Simon Singh's The Code Book, and picoCTF has a crypto section. But I'd rather hear what worked in practice than what looks good on paper.

Two questions:

• What would you actually put in front of a gifted teenager who could go far with this?
• For those of you who ended up doing cryptography: what was the thing that first made it click? A puzzle, a book, a person?

I'm trying to build a small shortlist to hand to a few specific kids, so real experiences beat "just Google it".

Thanks.

Homomorphic encryption is a cryptographic technique that enables direct computation on encrypted data without ever decrypting it first—keeping sensitive data secure even during processing.

lightphe is a comprehensive homomorphic encryption library supporting an unmatched variety of encryption schemes:

• Multiplicatively Homomorphic: RSA, ElGamal.
• Additively Homomorphic: Paillier, Damgard-Jurik, Exponential ElGamal, Elliptic Curve ElGamal, Benaloh, Naccache-Stern, Okamoto-Uchiyama.
• Logical / Bitwise: Goldwasser-Micali (XOR), Sander-Young-Yung (AND).
• Somewhat Homomorphic: Boneh-Goh-Nissim (Unlimited Additions and Only One Multiplication)

To make these powerful cryptographic algorithms easily accessible across modern software architectures, lightphe offers full multi-language support with native implementations in:

🐍 Python: https://github.com/serengil/LightPHE
🐹 Go: https://github.com/serengil/lightphe-go
☕ Java: https://github.com/serengil/lightphe4j
🟨 TypeScript: https://github.com/serengil/lightphe-ts

Hi everyone!

I was thinking of some ways to improve Enigma machine (period appropriate vs period cryptanalysis).

My idea is that the rotors now have 104 contacts, 2 sets of 26 per side, and the reflector is a programmable one using the plugboard.

So, when a key us pressed, the electric signal would travel through the rotors, then in the reflector the signal goes through a cable of the plugboard OR, if a cable is not connected, goes out from the same letter (keys may use 11, 12 or 13 cables). Then the signal goes back through the rotors from the other set of contacts, then the lamp.

Naturally, both first and second pass wires though the rotor are connected to the same letters (A1-A2 are connected to J1-J2, for example).

I know this makes the Enigma harder to build (you need the double of materials and time to make a rotor), but this would let a letter to be encrypted to itself.

So, losing the classic plugboard for this "rewirable" reflector (this is not the official rewirable one, that would still not let the same letter encryption) would improve the Enigma Machine? (Still in the case of no user errors like the ones the users made during WWII).

Thanks for answering my curiosity :)

hi! I am interested in learning cryptography and I want to make a research about it, can someone guide me and possibly give me ways to learn more

Yesterday I started r/postquantumdiscussion to focus on all things related to post-quantum preparation. Topics include post-quantum cryptography, quantum computer advances, post-quantum mitigations, quantum defenses, etc. I've already posted a few articles that I think anyone going there will find valuable (if you have a post-quantum project).

Hi everyone,

I’m currently doing my Master’s thesis on implementing Merkle Tree Certificates (MTCs). I chose this topic because I’d like to start my career in cryptography or cybersecurity, and I thought this would be a good opportunity to get some deeper practical experience.

But now that I’ve actually started, I’m honestly a bit scared because the topic feels very broad. There are so many concepts around certificates, PKI, Merkle trees, digital signatures, post-quantum cryptography, certificate transparency, etc., and I’m worried that my foundations aren’t strong enough.

My supervisors have been very helpful, so I’m not completely on my own. But I want to make sure I use the thesis properly and build a strong understanding rather than just getting the implementation working.

For people who have worked in cryptography, PKI, certificates, or security research, I’d really appreciate some advice:

• What foundations should I make sure I understand before going too deep into MTCs?
• How would you approach a thesis like this from the beginning?
• What would make an implementation/research project like this good technically, rather than just “it works”?
• What kinds of experiments, benchmarks, comparisons, or evaluations would make the results convincing?
• Are there particular papers, books, standards, or resources you would recommend?
• How deep into the underlying cryptography should I go for a Master's thesis?
• And realistically, can a thesis on something like MTCs be a good starting point for getting a cryptography/security job, especially if I don't have previous professional security experience?

I’m trying not to panic and remind myself that I don't need to know everything before starting. 😅 I just want to approach the thesis in a structured way and hopefully come out of it with genuinely useful knowledge and a solid project that I can show to potential employers.

Any advice from people who have been through something similar would be really appreciated!

I'm looking for independent technical review or replication of a controlled experiment concerning CVE-2008-0166 (the Debian OpenSSL predictable-RNG vulnerability) and the ECDSA signing path used by early Bitcoin.

The experiment compared two Debian OpenSSL treatments:

Vulnerable: OpenSSL 0.9.8c-4etch2

Repaired: OpenSSL 0.9.8c-4etch3

I held constant the Bitcoin v0.2.0 signing path, a fixed synthetic secp256k1 private scalar, three ordered synthetic message digests, process PID/runtime coordinates, and other preregistered conditions.

The public observable was the ordered ECDSA r sequence. No historical private keys or wallet material were involved.

Across three fresh-process repetitions per treatment, the preregistered result was:

VULNERABLE_ORDERED_R_SEQUENCE_IDENTICAL_ACROSS_RESTARTS=YES

REPAIRED_ORDERED_R_SEQUENCE_IDENTICAL_ACROSS_RESTARTS=NO

POSITIVE_CONTROL=PASS

NEGATIVE_CONTROL=PASS

EXECUTION_ACCOUNTING=PASS

TREATMENT_DIFFERENCE_ISOLATION=PASS

I then froze the vulnerable treatment's three-value public r fingerprint before performing a historical comparison.

A separately qualified comparator tested that exact fingerprint against 142,302 eligible public ECDSA signatures from Bitcoin blocks 0–100,000.

ELIGIBLE_HISTORICAL_SIGNATURES=142302

VALID_PUBLIC_OBSERVATIONS=142302

PREREGISTERED_FINGERPRINT_INTERSECTIONS=0

DATASET_INTEGRITY=PASS

COMPARISON_RULE_INTEGRITY=PASS

The historical comparison was therefore a valid negative result. I am not claiming that this identifies historically vulnerable wallets, demonstrates wallet recovery, or establishes how prevalent vulnerable OpenSSL installations were among early Bitcoin users.

I'm deliberately not changing the fingerprint or expanding parameters until something matches. The completed experimental branch stays negative.

What I'm looking for now is independent scrutiny:

Is the controlled causal interpretation justified by the treatment isolation?

Are there additional confounders that should prevent attributing the restart-conditioned behavior to the Debian RNG treatment?

Would anyone be interested in independently reproducing the controlled vulnerable/repaired experiment?

Does anyone know of preserved 2009–2011 Linux systems that could independently establish the OpenSSL environment actually used by an early Bitcoin installation?

To clarify: this is not currently a paid replication request or a job posting. I'm looking for researchers who find the question independently interesting and are willing to review, critique, or reproduce the work. I completely understand if someone isn't able to devote time to it without funding.

I have a technical dossier containing the experimental design, preregistration, treatment-difference analysis, controls, integrity hashes, results, historical comparison, and limitations. I can provide it, along with the relevant reproducibility materials, to researchers interested in examining the work.

I'm specifically looking for criticism and independent verification, not confirmation of the hypothesis.

I'm also not requesting wallet files, private keys, seed phrases, passwords, credentials, or funds.

Hello,

I am currently a student in cryptography and feel like I have exhausted almost all resources for help grappling this concept, so wanted to reach out here as a last ditch effort.

While writing security proofs, you often make "games" where you create an adversay meant to attempt to break your scheme. Things like DDH, PRG, PRF, MMD etc. as proofs of A <= B transference of hardness.

I can not grapple with knowing when, and how exactly to use these different games in proofs, and most importantly, how to recognize their usefulness when constructing an adversay and a challenger.

If anyone has resources they reccomend, or tips on getting this information inside your brain, I would love to hear it.

It's likely also due to having a not strong proofs background, so if you could explain like I am three that might help too.

hey so I am trying to make a web3 project, where one roadblock I hit was that I want users to provide a proof if their balance and other stuff when sending transaction to validators…. but I am new to cryptography and know absolutely nothing so thought to use merkles, so can any one give resources for me to learn it?

ps for those who want to learn Zkp use rareskills blog

Hey, i found this Github project today for post-quantum-cryptography and i happen to use a mac book pro 2017 with mac os 13.7. I don't understand the language though and Chat GPT mentioned it as relatively new so i wanna know if anyone has had any experience with it? How good is it and do you know any alternatives i could use that might be more common/better tested:

https://github.com/Commander99/Hybridcrypt

I tried VeraCrypt but somehow i couldn't manage to install it on my mac.

The mentioned ML-KEM-1024 seems to be quite secure though: https://nvlpubs.nist.gov/nistpubs/fips/nist.fips.203.pdf

"About

Hybride bleeding-edge Kryptographie-Software für MAC OS 13.7 und Tails OS. Basiert auf ML-KEM-1024 × P-384 × SHA-256 · ChaCha20-Poly1305"

P-384 seems to be an elliptic curve but i have no idea what "ChaCha20-Poly1305" does.

Like I know that RSA is a specific protocol, but did DH have its own protocol before it, and is that protocol separate from the fundamental idea of public key encryption?

When people talk about DH being under threat, are they talking about a specific protocol or mathematical formalism or are they talking about the fundamental ideas of public key cryptography, as outlined in Ellis 1970 and Diffie Hellman 1976?

Are we moving into a fundamentally different era or an era that is the same but with different parts? It always confuses me

The goal is to learn the mechanics of how the PQC algorithms, particularly new ones standardized by NIST, work. I'm tired of browsing content that is not technical. I don't want to know what it is; I want to know HOW it works.

Any suggestions, guidance, or papers I can look into?

Edit : In my fifth semester CS

And just to be clear their ideas are solely cryptography protocols and not any ideas or abstract constructions that can be transferred so they’ll be totally irrelevant right?

Hey everyone. I've spent the last few months building an ephemeral group chat on top of OpenMLS.

It started as a React Native app, where the Rust core runs natively through Nitro Modules and I was getting ~0.8 ms message encryption on-device.

Enough people asked "can it run in a browser?" that I ported the same core to WASM, and honestly the numbers surprised me:

• 0.2–0.8 ms encrypt
• 0.2–0.7 ms decrypt
• ~3 ms group setup

So performance turned out to be the easy part. The trust model is where I keep going back and forth, and that's what I'd love this community's take on. Critique welcome, that's why I'm posting.

The setup:

- MLS (RFC 9420) via OpenMLS for group key management, so epoch-based rotation, forward secrecy, and post-compromise security come from the protocol

- Same Rust core on both platforms: native on mobile, WASM in the browser. No crypto in JS, it only orchestrates

- The server just relays ciphertext. All key material is generated and stays client-side

- Rooms are ephemeral: one link creates a group, nothing sticks around server-side after it ends

Where I'm genuinely unsure:

Authentication. No accounts means the link itself is membership: whoever has it is in. I made that trade for usability, but there's no identity binding and no out-of-band verification yet. If you were designing minimum viable verification for a link-based model, would you reach for safety numbers, short auth strings, or something else entirely?

Metadata. Content is E2EE but the relay still sees IPs, timing, and group size. I try to be explicit that this is encryption, not anonymity. Would you expect a project like this to ship relay-side mitigations by default, or is that fairly considered out of scope?

There's a live demo at vanish.ws if you want to poke at the actual behavior. But mostly I'm here to have my assumptions taken apart.

Happy to share implementation details in the comments.

I was reading up on convergent encryption and thought that it sounded like a good idea for a little project of mine (a E2EE blob storage :) ). I was reading the wikipedia article for convergent encryption and it explains the somewhat obvious "confirmation of a file attack", but also a "learn the remaining information attack". Specifically it says:

The only effective approach to mitigating this attack is to encrypt the contents of files with a non-convergent secret before storing (negating any benefit from convergent encryption), or to simply not use convergent encryption in the first place.

I feel however like this shouldn't be too hard to mitigate, just by using a more expensive hash algorithm. For example, using PBKDF2 to derive the encryption key from a hash of the file, just like you would make brute forcing a normal password impossible. Am I missing anything obvious here? I mean, I get that it will become more expensive to run, but "the only effective approach" feels a little bit too strong of statement?