r/cryptography

Hi everyone,

I’m a Master’s student with a background in both math and computer science, and I'm deeply passionate about cryptography. I’ve already taken a dedicated crypto track at my university, and now I’m facing the choice of what to do next.

I’ve always been a bit torn because my goal is to do research at the intersection of mathematics and computer science. To give you an idea: I wouldn't want to spend my time purely formalizing protocol security proofs, but I also don't want to just write code for already existing protocols. I'm looking for that sweet spot right in the middle.

My next step is definitely a PhD. Even though I'm close to graduating, I haven't applied anywhere yet. Do you have any recommendations on which universities or research groups in Europe I should look into for a solid PhD in cryptography?

Thanks in advance for any advice!

Hi, I am currently a junior in Applied Mathematics and Statistics with a double major in Pure mathematics at Stony Brook University.
I am very interested in cryptography and I am looking forward to go into a PhD program.

Here is a little about me, I am interested to hear if there are any other ways I can improve myself.

Schools I am interested in: Stanford, CMU, Brown, Stony Brook, UCLA, UC Berkeley, University of Maryland, UIUC, and more.

Experience and qualifications:

• An REU, I am working on mathematical modeling for cyberbullying/digital safety. I might be able to publish depending on how everything goes
• I am applying for another REU, I probably would have 2 before my applications (hopefully the other one in cryptography/number theory) before the time of my applications (or possibly an internship at NSA instead of a second REU if I can get accepted)
• I have 2 letters from my PIs so far.
• 3.85 GPA
• TA experience for a Probability and Statistics course
• A mathematics YouTube channel where I post regularly, although it is not very professional
• Part-time experience working as a mathematics instructor at Mathnasium
• I am reaching out to my professors in cryptography to do research in PQC in my senior year

Relevant coursework:

• Calculus I-IV
• Linear Algebra
• Advanced Linear Algebra
• Abstract Algebra
• Two semesters of Graduate Algebra
• Number Theory
• Cryptography (graduate class)
• Introduction to Analysis
• Applied Complex Analysis
• Applied Real Analysis
• Analysis of Algorithms
• Honors Theory of Computation
• Probability and Statistics
• Probability Theory
• Finite Mathematical Structures
• Graph Theory
• Numerical Analysis
• Introduction to Advanced Mathematics
• Communicating with data
• Physics I-II
• Two programming courses in Java and Python

My grades are mostly A, A- or B+, the ones most relevant to Cryptography are almost all As.

Are there any other ways I could improve my profile and prepare for PhD applications in cryptography? Are the colleges I listed too ambitious for me?

So came across a great video by IBM a few weeks ago https://www.youtube.com/watch?v=ZrHKwxasXS4 and now even Microsoft is talking about it in the linked article provided.

They all have the same vibe. Projects need to start building "crypto-agility" into their apps and services to make the inevitable shift to post-quantum algorithms far less painful in the future.

There are only a few projects that seem to have this super power already. I wonder if this will be the next biggest thing that will enable many other projects to fall short of being future proof? Algorand has also started making post about Crypto Agility.

I heard the Ethereum is making big changes, perhaps Vitalik is also heading in this direction?

Edit: I think I should have titled this "alternative generic key container formats" or something. I didn't mean to have this be about web certs. Is there a better word for this?

Hello! I'm working on some software that needs certificates for signatures/verification... and probably certificate chains/subkeys, maybe revocation lists, a format that can be easily updated for new future key formats, ideally with standard tools/compatibility, etc...

x509 would be the obvious choice here, but I was wondering if there was anything else (or new formats) that would work instead. There's a lot of historical cruft with x509, it's complex so the libraries for working with it are complex, and some stuff like needing to tie a name to the cert is an extra burden not relevant to my use... and it's hard to know what features can be dropped without reducing security overall.

I dug around the list of alternatives I came up with are:

• GPG
• CVC
• SSH (I don't think this supports chains...)

I thought there'd be more. I was wondering if there were any others I missed before I start digging in deeper.

The last resort is to just wrap my own container around per-key formats, which wouldn't be hard, but I felt like there must be a better way...

Edit:

• From @harrison_314 - JWT

There are certain rumours in certain corners of the internet that NSA/GCHQ have an L[1/4] factoring algorithm, i.e. they may be able to beat the number field sieve, at least in theory.

Assume for one second this is true, or if not, at least that L[1/4] exists.

Many people say that AI is just a next-word guesser etc, but there is no doubt about its usefulness in presenting relevant material before the eyes of a human.

No-one has publicly discovered L[1/4] factoring despite half a century of intense research. Publicly, humans thus far have failed on their own.

Can AI-assisted research conceivably push the boundaries just a bit beyond the collective genius of human mathematicians, through e.g. time saving in experimentation/scripting, connection of ideas, judicious human postulation with dead ends abandoned and promising avenues explored more quickly than ever before, and find that L[1/4]?

​

I've been working on the architecture for a privacy-first encrypted storage app, and I'm intentionally keeping it as simple as possible.

The core idea is that every additional feature increases the attack surface, so the application only does two things:

Upload (encrypt locally before upload)

Download (decrypt locally after download)

Some design decisions:

Users receive a 24-word recovery phrase during registration.

The recovery phrase derives the Master Key.

The Master Key is never used directly. It only derives purpose-specific keys using HKDF.

Every file has its own derived encryption key.

File metadata is encrypted with a separate key hierarchy.

The server never sees plaintext, encryption keys, or the recovery phrase.

The local password is only used to unlock an encrypted Master Key vault stored on the device.

A maximum of two authorized devices can be linked to an account.

Users can export an encrypted Vault containing all ciphertext and encrypted indexes at any time.

The long-term goal is that even if the company shuts down, users can still recover all their files using only their 24-word recovery phrase and the exported Vault.

The philosophy is simple:

The server stores data. The client owns trust.

I'm not trying to build another cloud drive with collaboration, document editing, AI features, or social functionality. The goal is to build a storage system that does one job extremely well: protecting user data.

I'm interested in feedback from people with experience in cryptography, secure storage, or zero-knowledge systems.

What potential weaknesses or design mistakes do you see in this approach?

I'm currently experimenting with a blockchain that uses ML-DSA-87 as its default signature scheme instead of ECDSA.

One of the biggest trade-offs is transaction size.

A single transaction includes an ML-DSA-87 public key and signature, making each transaction several KiB larger than a traditional ECDSA-based blockchain.

I don't want to weaken security, and I'd prefer to avoid protocol changes that add significant complexity (such as maintaining a public key registry in the blockchain state).

So I'm curious:

- Are there any safe ways to reduce the effective size of ML-DSA-87 public keys or signatures?

- Are there any compression techniques that preserve security?

- Is transport-level compression (e.g. P2P message compression) generally preferred over compressing the cryptographic objects themselves?

- If you were designing a post-quantum blockchain today, how would you handle this trade-off?

From what I've read, ML-DSA signatures are already highly structured, so I suspect there isn't much room for lossless compression without changing the scheme itself.

I'd love to hear how others would approach this problem.

I’m currently taking the CompTIA A+ course, and after I pass, I’ll be jumping straight into my next course starting October 1. I plan on earning all three certifications (A+, Network+, and Security+), but I was wondering which one I should prioritize after A+. Should I go for Network+ or Security+ first, or does the order not really matter?

I built a web‑based PGP key generator that runs entirely client‑side in your browser – no server calls, no telemetry, and no logging.

The generator uses OpenPGP.js and creates OpenPGP key pairs (RSA 4096/8192 as well as ECC/Curve25519/brainpoolP384r1) directly in the browser. All cryptographic operations (key generation, fingerprint calculation, export) happen locally – there are no requests to third‑party servers and no external script dependencies.

What the tool does:

• Generates a PGP key pair based on name/pseudonym, email address and a password (passphrase for the private key).
• Displays the public key, private key, fingerprint and long key ID.
• Exports the public/private key or the complete key pair as a ZIP file (filenames include the email address and key ID).
• Provides a “Secure wipe” button that overwrites and clears input fields and generated keys in the DOM with random data before you leave the page.

How it’s built – short technical overview:

• Pure HTML/CSS/JS, no external fonts/CDNs, only locally bundled JS libraries (OpenPGP.js and JSZip).
• Strict security headers (Content‑Security‑Policy, X‑Frame‑Options, Referrer‑Policy, etc.) to harden the page against common browser‑based attack vectors.
• All input is only used in the browser’s memory. There is no persistence, no tracking and no transmission of passwords or keys to any server.

Important notes:

• The private key is still sensitive, of course – you should always store it offline/encrypted and never share it with third parties.
• The tool is intentionally minimalistic: no database, no web of trust, just key generation & export.

If you want to try it out or review it (code, security concept, UX, threat model, etc.), here’s the article with all details and the tool itself:

PGP-Keygenerator: https://secunis.de/pgp-keygenerator.html

The article with all details: https://www.secunis.de/clientseitiger-pgp-keygenerator/

I’m really concerned that soon the internet won’t have any privacy and to even access the internet later or any form of social media , you will have to verify with an id . Why doesn’t someone make alternatives that’s full encrypted and can’t be controlled by the government.

AES is the default and has hardware acceleration on most modern CPUs. But VeraCrypt also offers algorithms like Serpent, Twofish, and cascades (AES-Twofish-Serpent).

Is any of them actually stronger than AES in a practical sense, or is there no real-world security benefit?

I still don’t understand how it’s possible to make such horrible quality documentation. The introduction is ok but could be better, it doesn’t even tell you where to start, where to go, the functions, classes, interfaces everything is just stuck together like bunch a magnets. I’m not even exaggerating just take a look at the docs, everything is scrambled, tightly spaced, barely explained, just laying my eyes upon the text gives me a severe headache.

They really need to make better documentation. because if you make good api’s, but unfortunately the documentation sucks then developers will not want to use it.

SHA-256 produces as 32-byte Digest and SHA-224 gives a 28 byte one. At first, I thought SHA-224 was accomplished by taking a SHA-256 digest and chopping off a few bytes. So I was wondering, does the bytes matter? You can lop off bytes 1 to 4. You can truncate bytes 29 to 32. A third way is to get rid of bytes 4 to 7. You can get rid of bytes 4, 9, 13, and 14. All of these would get you down to 28 bytes.

Then I read that this isn't how you create SHA-224 digests. Apparently the initializing part is different? So by the time you get to the truncation step, you don't have a SHA-256 digest.

That still leaves a question of, does it matter which bytes are dropped as long as all parties can agree on which ones to drop? I'm guessing the last 4 bytes are truncated.