the part that still gets me is Tutte. Tiltman had pulled about 4000 characters of key out by hand because one operator sent the same message twice on the same settings, and from just that key Tutte worked out the machine had 12 wheels and how many pins each one had. no captured machine, no manual, nothing, took him a few months with pencil and paper

I tried to actually SHOW the xor / depth part and the diagonal thing with the 41 wheel instead of just talking over photos. simplified the chi/psi/motor stuff a bit so curious if it holds up for people who know this better than me

https://youtu.be/l4P98Xryx-U

AI-assisted reverse engineering has me wondering about executing code while keeping the program itself encrypted, say using FHE.

The problem is that a useful program has to affect the outside world. How do you let outputs escape the encrypted computation without also exposing the code or internal state?

Curious if anyone’s been thinking about this or working on something related.

I'vw been looking up for method to get highest set bit assuming x != 0. De Brujin multiplication trick seems to be the fastest but it uses a look up table. I wonder if it can be bitsliced and how would it compare to other methods?

Hi everyone, my classmates and I are planning to make a workshop for cybersecurity tools for our other classmates. I’m planning on teaching them about encryption, I’ve been looking for easy to handle/beginner friendly tools for that. I looked into AGE and GRG, and online tools like cyberchef; do you think these will do, or do you have other recommendations that are better and more practical for beginners?

PS: when i say beginners we really beginners like some of us are just starting with Linux fundamentals.

To preface: I am new to the field of cryptography. While working on a larger project, I came across a problem that I’m not sure can even be solved. Here’s an abstract explanation:

Alice wants to use a service hosted on Bob’s server, but Bob desperately wants to read Alice’s messages. For security, Alice splits her message into two secret shares. She sends the two shares to two of Bob’s servers using an onion router, so the two servers don’t know where the shares come from and can’t collude to reconstruct Alice’s original message. (Let’s say Bob gets enough requests to make timing attacks unfeasible.) But Bob’s servers use two-party computation and need to exchange intermediate results. Since Bob’s servers don’t know where their share comes from, they can’t communicate directly, so they have to communicate via Alice as a middleman.

Here’s my actual problem: If the two servers use Alice's public key or send their results in plaintext, Alice can read them and gather information about how Bob’s service works. (We don’t want that.) If the two servers encrypt their data, they either have to share a key or know each other’s public keys, meaning the servers can recognize each other in Bob’s internal company network and set up a connection to collude. (Let’s say they don’t just send their server ID in their encrypted intermediate results.)

So, is there any way to make sure Bob can’t read Alice’s message and Alice can’t read Bob’s intermediate results? Or is this unsolvable?

Thank you in advance.

I spent a month developing and testing this playing card cipher which is gunning for the title of best playing card cipher. Strength is 225 bit. It refers to cards as both 0-51 and 0-25. It's fast and easy to use and requires no notes or extra math. Simply move cards to the position indicated and use the deck like a mod 52 s-box.

If I had money to spare I'd offer some for the best attack. So far there best attack is brute force. I've subjected Heka to statistical testing and SAT solvers and it qualifies as ideal. Also, under KPA scenarios the key cannot be recovered nor more ciphertext decryption.

I'd appreciate feedback on the cipher. How was your experience using Heka with a real deck of cards?

https://github.com/utepshaadm/Heka/tree/main

Hey all,
I'm a third-year physics student from Thailand, and I'm looking to get real experience in cryptography, pentesting, and especially post-quantum crypto. Money isn't a factor for me. I just want to work on something real and learn from people who know more than I do. I can put in close to full-time hours, so I'm happy to take on anything from small tasks to a proper project.
Math background in linear algebra, number theory and probability, so I'm comfortable with the theory side
Python, Rust, C/C++ on Linux
Built a PQC benchmark with liboqs (ML-KEM, ML-DSA, SLH-DSA vs RSA/ECC), including my own timing harness
Built a mini Shor's algorithm demo in Qiskit, with QFT and period finding from scratch
Around 100-199 CTF/lab challenges (HTB Hacker rank, THM top 10%, CryptoHack, PicoCTF) plus some OSINT
Small open-source contributions, including liboqs and RustCrypto
Currently tinkering with a scanning/OSINT automation tool

If you have a project that needs an extra pair of hands, such as benchmarking, testing, tooling, docs or Advice on where to start in PQC research or pentesting is also very welcome. DM me if you want my CV.

Consult the official BC release notes for more detail: https://www.bouncycastle.org/download/bouncy-castle-java/#release-notes

Hi everyone,

I’m currently doing a Master’s degree in Cryptography and Information Security, and I’m looking for a good project/thesis idea that would be suitable for a Master’s student.

I’m particularly interested in applied cryptography, cybersecurity, cryptographic protocols, and practical implementations. I would like to work on a project that is not just a basic implementation of AES or RSA, but something that could demonstrate a deeper understanding of cryptography and have real-world applications.

What cryptography projects or research topics would you recommend for a Master’s student?

I’d also appreciate suggestions that can be implemented using a Python/Linux lab environment without requiring expensive hardware.

Thanks in advance for any ideas or advice!

Does anyone have any details on what the WinZip AES-256 Quantum-resistant encryption option actually is, which appears as an option in WinZip 77.2.

I see "WinZip now has the option to encrypt with AES-256 in Galois/Counter Mode, replacing the AES-CTR with HMAC method used previously." on their site, but it was my understanding the GCM was actually slightly less QR than CTR, at least without modifications (see https://tosc.iacr.org/index.php/ToSC/en/article/view/13011/12589).

Their website says "WinZip uses AES encryption and decryption routines written by Dr. Brian Gladman. The source code for these routines is available to any interested party under an open source BSD or GPL license from the AES project page on Dr. Gladman's website. This is the same AES code that is incorporated into WinZip" but this code does not seem to include the QR variant.

The formal specification v1.04 for WinZip AES was last updated in 2009, and covers only the AE-1 and AE-2 variants I already support, and not this new variant.

I ask because I am working on an program that supports ZIP files that use WinZip AES, and my AE-1 and AE-2 support is complete, but I would like details to support this new option.

Edit: https://github.com/johnsonjh/infozip-av/issues/1 is where I am going to keep further notes and track progress.

Edit2: Solved! See https://github.com/user-attachments/files/33212728/ae3_reference.py for a verifier in Python 3. Xtro-ZIP (https://github.com/johnsonjh/infozip-av) will soon be the first third-party ZIP program to support AE-3 archive creation and extraction.

Now, is this scheme (AES-256-GCM / PBKDF2-HMAC-SHA256 -> HKDF-SHA256 expansion) *really* Quantum Resistant? I guess that's a matter of marketing.

Edit3: I received a "final" response from WinZip Support: "As per the update from the internal team, we’re not planning on publishing anything specific regarding the AE-3 algorithm at this time.  However, we are working on an update to the encryption article available on our website. But even then, it won’t be specific."

That is their verbatim reply. Quite shocking in my opinion. However, my reverse engineered implementation is now fully interoperable, and we can declare the new scheme as well-defined (AES-256-GCM / PBKDF2-HMAC-SHA256 -> HKDF-SHA256) without their help.

Hello!

I'm reaching out because I'm currently conducting a group AP Research study on a bottleneck in Post-Quantum Cryptography migration, specifically focusing on how enterprises handle third-party vendor compliance.

1.⁠ ⁠As organizations prepare themselves to migrate to Post-Quantum Cryptography (PQC) in the advent of supercomputers, how is your company reacting to interoperability obfuscations where vendors are either struggling or unwilling to update their TPRM legacy dependency files to quantum-safe security?

2.⁠ ⁠⁠Assuming that vendors are hesitant to willingly migrate to PQC standards, does this hinder you from proceeding with your own security updates as your formerly secured data will now be susceptible to adversarial attacks once it reaches vendor servers?

3.⁠ ⁠⁠Have you experienced issues where vendor systems slowed down or crashed because the security keys were large?

4.⁠ ⁠⁠If a solution that used a Zero-Trust Framework existed, where sensitive data is decoupled from the transport layer and encrypted with easier-to-handle PQC tokens, would you prefer this wrapper approach over trying to force NIST-mandated PQC compliance onto third-party vendors?

The US government and the world want you to worry about coming quantum attacks against key exchange (e.g., HTTPS) MORE than authentication attacks. For example, the US government says entities that must follow NIST cybersecurity requirements need to mitigate key exchange quantum attacks by the end of 2030 and authentication attacks by the end of 2031.

The US government is not alone. It seems the entire world is focused on mitigating key exchange attacks first, and authentication attacks second. It’s already this way in practice. According to Cloudflare (https://radar.cloudflare.com/post-quantum), over 72% of HTTPS-enabled sites are already using quantum-resistant cryptography (aka post-quantum cryptography). Yet, I can’t find a single digital certificate attached to those same websites that have quantum-resistant keys.

72% versus 0%

As I have previously written many times, the world has it exactly backward. Quantum attacks against authentication are a much bigger problem.

The conventional wisdom as to why everyone needs to focus on key exchange attacks first is Harvest Now, Decrypt Later (HNDL) attacks. With HNDL attacks, an adversary obtains your currently quantum-susceptible encrypted network traffic, stores it, and then decrypts it when they have cryptographically-relevant quantum computers.

The world says you need to be scared now, now, now!!

I agree, but for a different reason.

HNDL attacks will be fairly rare to non-existent. Here are my many reasons:

First, you need a well-resourced, well-motivated, capable adversary who believes HNDL is their best, cheapest, and fastest method of attack. HNDL attacks are very expensive, slow, and difficult. You need an adversary that has a target (or targets), where HNDL is their only and best method of attack.

This requirement basically limits potential attackers to well-resourced, quantum-enabled governments attacking other government-related adversaries. This already eliminates most businesses and individuals.

But even for the government-versus-government scenarios, HNDL attacks are a terrible choice. Any other type of attack would be cheaper, faster, and more likely to be successful.

For an HNDL attack, the adversary needs to eavesdrop on the adversary’s network communications. This is far from impossible for well-resourced governments, but it is still needed and expensive.

HNDL eavesdropping requires that an adversary eavesdrop on and store billions and billions of network packets, without any idea of what packets contain what information.

There are different cryptographic keys involved with every session. In any given eavesdropping scenario, the victim’s network is likely to be transmitting hundreds to thousands of sessions every second to minute, each with different keys. Each quantum crack reveals one cryptographic key, which decrypts one session. Does that session have information that is useful to the adversary? Who knows? But odds are that any single broken session does not include information that is useful the adversary.

Just guessing, I think an adversary would need to crack thousands to tens of thousands of sessions to get to useful information.

Each cryptographic session crack is expensive and slow. The cheapest cryptographically-relevant quantum computer is likely to be many tens to hundreds of millions of dollars.

Cracking cryptographic keys is slow.

According to IonQ, the quantum computer vendor that appears the closest to cracking quantum-susceptible cryptographic keys (in 2028), states (https://www.ionq.com/news/ionq-publishes-worlds-first-fully-compiled-end-to-end-blueprint-for-breaking-256-bit-elliptic-curve-signatures) that it will take 25.7 days per crack.

Do the math.

You need to crack thousands to tens of thousands of sessions, each taking almost 26 days, to HOPE to get useful information.

Why hack hard when you can hack easy?

It would be far easier and cheaper to just hack your adversary the same ways you have been successfully hacking them for decades: social engineering, vulnerability exploitation, and bribes.

Why spend hundreds of millions of dollars over years to hope to get information when you can send an email saying, “Click here!” or fire off an AI frontier model to find a new zero day to exploit? It’s far cheaper and faster to do every traditional attack than it is HNDL.

It reminds me of Blue Pill attacks theorized in 2006 (https://en.wikipedia.org/wiki/Blue_Pill_%28software%29) by Joanna Rutkowska. She is brilliant. The attack she came up with was brilliant. With the Blue Pill attack, your target entire host/OS was virtualized, allowing anyone to bypass any defense that it contained. It was big news for months. Oh, my god! There is no defense that can stop it!!

And it was true, it was very hard to prevent Blue Pill attacks (although Rutkowska thought of a way to detect them, which she called Red Pill).

But I wrote at the time that Blue Pill attacks would not become a big thing. And I was right. Blue Pill attacks required taking control of a host and virtualizing the entire host or operating system, which requires a lot of memory, processing power, and time. And why do that if the same old, cheaper attacks that have always worked very well for hackers can be done?

Why hack hard when you can hack easy?

And I was right.

I was right then and I’m right now.

HNDL attacks are extraordinarily costly and slow. And even then, the adversary is not guaranteed to get to the useful information that they were seeking.

Instead, I can just send in a remote access trojan and maintain access to the entire environment for as long as I can go undiscovered (which is usually a pretty long time in most environments).

It reminds me of the famous XKCD cartoon: https://xkcd.com/538/

Trust Now Exploit Later Is Different

Authentication attacks, which the post-quantum community calls Trust Now Exploit Later, are exactly different. With TNEL attacks, all an attacker needs is the digital certificate of a target (i.e., user, computer, website, content, etc.). Digital certificates are the backbone of authentication all over the Internet, in our companies, our devices, and our lives.

If a quantum attacker can get someone’s digital certificate, which is often pretty easy, they can compute the private (and public) key attached to the digital certificate, duplicate that digital certificate, and then fraudulently do anything (i.e., sign-in, sign content, pretend to be that person or site) that digital certificate allows them to do. An adversary doing a TNEL attack might also need to break the digital certificate of the certification authority (CA) that signed the target’s digital certificate, so at most an adversary would need to do two cracks.

With HNDL key exchange attacks, each crack allows me to decode all the information encrypted inside the network packets encrypted by the same key. It’s very limited. It’s very expensive. It’s very slow. I may or may not get anything for each successful exploit.

With TNEL authentication attacks, the threat model includes dozens and dozens of potential attack scenarios. It’s one or two successful exploits needed, at most, and then the world is your oyster.

If someone compromises your digital certificate, they essentially become you. Your only possible response is to block/revoke the compromised digital certificate and re-issue a new, hopefully quantum-resistant digital certificate.

The problem is that the replacing and/or revocation of digital certificates has always been slow and sloppy. There are at least three existing methods for digital certificate revocation (e.g., CRL, OCSP, and manual methods), and none have really worked well at scale. Quantum-resistant Merkle Tree Certificates (MTC), are likely to create a new revocation method. Never has adding anything in the cybersecurity world made things easier or more accurate.  Adding a new something (without doing away with the old something) just means we have to support more things (badly) now.

Every time I see someone mentioning HNDL attacks and telling me to worry about them, I see another modern-day Blue Pill attack scare. It’s great in theory, but there are far easier and cheaper ways to attack someone.

I would not be surprised if history shows that HNDL attacks were so rare that we never hear about them. Nobody brings up Blue Pill attacks anymore. HNDL attacks will either be near zero or zero when history is finished.

It doesn’t mean you shouldn’t mitigate key exchange attacks. I just know that authentication attacks are the far bigger worry.

Hey, anyway, we can get people to get post-quantum; we need to do. But for my money…for my cybersecurity risk calculations, authentication attacks are a far, far bigger worry.

I wish the world stopped pushing key exchange mitigations as the biggest worry, because it’s not.

My best advice is to focus on mitigating both authentication and key exchange attacks at the same time, if you can, and if you are forced to concentrate on one versus the other (and don't have to follow NIST's requirements), focus on stopping authentication attacks first and best.

Hello, I've been interested in cryptography for several months, especially the part about breaking codes (I don't remember if that's what they call cryptanalysis), and I would appreciate it if someone could recommend some texts for me to read and study.

I have some experience; I already know quite a few types of ciphers, although I learned them all by hand with pen and paper, so I don't use anything digital. But if there's something good that requires computer skills, I'd appreciate it.

thanks!

Hi, I am sorry from my last time (I had some problems with me) but here I am again. I want to ask you why exponent e is not picked based on n and phi?

This is my small code in Python:

import sympy

p = sympy.randprime(1000, 10000)

q = sympy.randprime(1000, 10000)

from math import gcd

n = p * q

phi = (p - 1) * (q - 1)

e = pow(n, -1, phi)

assert gcd(e, phi) == 1

d = pow(e, -1, phi)

m = 1199

c = pow(m, e, n)

r = pow(c, d, n)

Edit: I really like experimenting with RSA now, what about this?:

import sympy

p = sympy.randprime(100, 1000)

q = sympy.randprime(100, 1000)

from math import gcd

n = p * q

phi = (p - 1) * (q - 1)

e = pow(phi-n, -1, phi)

assert gcd(e, phi) == 1

d = pow(e, -1, phi)

m = 998

c = pow(m, e, n)

r = pow(c, d, n)

What do you think about what AI does to the way we encrypt our data. Should we withdraw the money from our banks?

Hi, I am an engineering student and i am pursuing civil engineering but, i am also interested in learning about machines, computers, etc. I recently heard about cryptography and I got curious about it... but, internet being a plethora of information, it's difficult to know, where to start, what sources to use and how to know more about it. I also have one prerequisite, the sources should be free to use.

Please let me know if you can help me with this, I would be very grateful.

Edit: I am also working to build a prototype for a hackathon (my first hackathon) and i wanna use AI tools for it, but, claude runs out of limit very quickly, and claude code is expensive. I have been using Arena AI to build a prototype, but, I think it would be a whole lot better to use claude code, and i found out about a github repo called,"OmniRoute" but, i am really an amateur in this field and i have zero clue on how to use that repo in my system and actually have those "billion tokens" that everyone talks about.

Noticed it on the map as I was driving through the area, very glad I stopped in because I was enthralled! Had to snake around the huge NSA complex to get there and the sight itself was interesting. The amount of hardware they had was just as impressive as the tour guide who had personally used much of it when he himself worked for the NSA. It’s relatively small but the quality of the exhibits make up for lack of volume. I dabbled a bit with simple ciphers in highschool but fell off as with many things when life catches up but this visit has reignited my interest in the subject and led me to this informative subreddit. If you’re every in the DC area definitely visit!

I was re-watching The Imitation Game recently and was thinking about how it would be fun to have a browser based activity for creating codes with an enigma machine and then breaking them using the Bombe machine. I imagined this as a fun classroom activity for a History class or maybe computer science as an introduction to crypto. I tried to make it as historically accurate as possible and make it as educational as I could. Happy to take any suggestions for improvements if anyone ever uses this in a classroom. Anyways, hope someone else finds this as interesting to play with as I did!

https://enigmamachine.app

Here is the work in progress: https://enigma.design

I watched the excellent Veritasium video on the Enigma machine, and also watched the animation by Jared Owen, but was still a bit confused on how the inner mechanics of an Enigma machine actually work (e.g. how do the rotors move, what is the double step, and how did the plugboard get wired to the rest of the mechanism).

I used Codex+Astra to build out the inner components through a combination of reference images, writing out many extremely detailed prompts, and building my own inspection tools to ensure that every part is sized and positioned in a historically accurate way.

Would love any feedback on the experience so far!

Da più di un anno sto sviluppando un sistema di messaggistica end-to-end con crittografia (Olm/Megolm).

La scelta iniziale è stata piuttosto radicale: niente numero di telefono, niente email e nessuna identità personale richiesta per creare un account.

L'utente inizia con un nome utente e una password. Le conversazioni sono avviate tramite inviti.

Tuttavia, questa scelta non si è limitata al livello del prodotto. Ha finito per influenzare gran parte dell'architettura.

Il sistema utilizza Olm/Megolm per il livello crittografico, React sul lato client e un backend basato su FastAPI, PostgreSQL e WebSocket.

Ma la parte che mi ha coinvolto di più non è stata la scelta delle tecnologie.

È stata la comprensione di come farle funzionare insieme quando entrano in gioco identità, dispositivi, sessioni crittografiche, stato, sincronizzazione, persistenza, riconnessioni e recupero.

Un account può cambiare dispositivo.

Un browser può perdere completamente il suo stato locale.

Una sessione potrebbe non essere più disponibile quando serve.

La connessione può essere interrotta in mezzo a una transizione.

Il sistema deve continuare a sincronizzare ciò che deve essere sincronizzato senza che il backend diventi un'autorità sui contenuti delle conversazioni.

Ed è proprio qui che il modello di fiducia smette di essere una proprietà dichiarata e diventa una serie di decisioni di implementazione.

Il backup delle chiavi segue la stessa logica.

L'utente può creare una frase segreta personale che protegge il materiale crittografico necessario per recuperare le sue conversazioni.

Se accede da un nuovo dispositivo o perde i dati locali del browser, la frase segreta permette di recuperare quel materiale.

Tuttavia, la frase segreta non può essere recuperata dal servizio.

Se viene persa e non esiste un altro meccanismo di recupero valido, il sistema non può semplicemente fornire le vecchie chiavi dal backend.

Questa è una conseguenza intenzionale del modello, non una limitazione che voglio nascondere.

Durante lo sviluppo, ho dovuto modificare diverse parti dell'architettura più volte.

Non perché il sistema non funzionasse, ma perché una soluzione che sembrava corretta a un livello ha introdotto conseguenze indesiderate a un altro.

Probabilmente questa è la parte più interessante dell'intero progetto: le difficoltà sono emerse dalle interazioni tra i componenti, non dai componenti stessi.

Il sistema include anche un'architettura progettata per l'uso aziendale.

Non si tratta semplicemente di aggiungere un pannello di amministrazione alla versione per utenti finali. Il modello di business introduce requisiti e vincoli diversi e ha richiesto un'architettura dedicata.

Il codice che ho scritto finora include il backend, il client, il layer crittografico, gestione delle sessioni e dei dispositivi, persistenza, sincronizzazione e tutto ciò che serve per far funzionare il sistema come un'applicazione reale.

Ci sono già test sia per il backend che per il frontend, compresi i test del flusso crittografico che utilizzano Olm/WASM reale, verificando effettivamente la crittografia e la decrittografia tra sessioni.

Sto ora completando il frontend.

La rilascio è prevista per metà ottobre 2026.

A quel punto pubblicherò un nuovo post con un link alla versione utilizzabile e al repository GitHub, in modo che il sistema possa essere testato e l'implementazione analizzata direttamente.

Nel frattempo, sto già cercando persone che abbiano lavorato direttamente con E2EE, sistemi Ratchet, gestione delle chiavi, messaggistica multi-dispositivo, sincronizzazione e sistemi distribuiti.

Sono soprattutto interessato a capire dove le mie assunzioni potrebbero essere sbagliate.

Se hai esperienza con questi sistemi, sarei interessato a ricevere feedback sulla gestione dei dispositivi, il ciclo di vita delle chiavi e delle sessioni, recupero, sincronizzazione, metadati e modalità di fallimento.

Qualsiasi feedback, incluso il feedback critico, sarebbe utile.

Grazie in anticipo a chiunque sia disposto a prendersi il tempo per leggere questo e condividere la propria esperienza. La prospettiva di persone che hanno già affrontato problemi simili può essere estremamente utile per identificare casi che potrei non aver considerato.