I hope that this is not considered low effort, as I really would like the opinion of this community. I know that you people deal more with the guts of this stuff, but hopefully you'll hear out a layperson.

I use Crystal's OpenSSL library in a couple of symmetric encryption front ends, and there's a variety of choices I have in which ciphers are available, although less now since v3.xx where many have gone to legacy.

I know that most of these use a 128 bit s-box, but, aren't they all rather similar, and if so, why so many? Some seem to be the "official" government endorsed cipher of this or that country, one is a "streaming" cipher, and the rest can seemingly mimic a streaming cipher with certain modes.

My hunch is that some combinations are better for certain situations, while other combinations are better for others. (?)

My manager knows I fiddle with this stuff and has tasked me to make a one click encryption option for CC authorization forms before they get stored. Unlike personal use, I can't just change things whenever I feel like it, and need to get it right the first time, so I guess my question is, does it really matter? When I read cryptanalysis, it seems that they're all pretty much the same with regard to security, but on the other hand, those pages are Greek to me.

Note: I do know that the keystream generation is very important, and will be using the Argon2 shard for that operation.

With AI evolving exponentially and solving increasingly difficult problems, how realistic is the threat that quantum computing advances faster than expected? Would Bitcoin realistically be able to adapt in time?

I'm not sure if it's the right subreddit to post in, but I was wondering why AES256 is slower on my CPU (Snapdragon 888 which does have AES acceleration) than ChaCha20 and maybe anybody knows the reason. Usually AES is >1.5x faster on average if hardware support is present but there it's completely opposite:

AES256 openssl benchmark: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes AES-256-CCM 59140.73k 194164.12k 452524.12k 676609.02k 790874.79k 805153.45k

ChaCha20 openssl benchmark: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes ChaCha20 265859.33k 435673.17k 838061.74k 1332601.17k 1371340.80k 1375125.50k

TLDR; I had some fun playing around with combining columnar transposition with substitution, which turns out to be surprisingly strong. Almost certainly not "properly strong", but not trivial to break with computers either. I was really surprised by this and would love to heart your ideas how this might be attacked more properly.

I'm a physicist with background in stats & ML and an interest in cryptography and I got nerdsniped pretty hard a while ago by this quote on wikipedia

> For example, a simple substitution cipher combined with a columnar transposition avoids the weakness of both.

I've always found doulbe columnar transposition pretty interesting because Lasry's 2014 paper came out while I was learning about crypto in school. As far as I can tell, outside of special cases, the methods from that paper and their 2016 follow up paper are still reasonably representative of the state of the art. Though scoring functions and key generation have improved.

After seeing that quote on wikipedia I decided to play around with the problem of adding a substitution step such that:

1. the 2016 methods fail using a PC and one day attack time
2. the method can be carried out by hand using no aids that can't be created on the fly
3. the cipher text passes the NIST STS
4. residues under perturbation of plain text or keys pass NIST STS

And I think I succeeded! Though just to be clear, I'm not claiming the resulting method has any practical meaning, it's likely breakable using HPC or if experts ever decided to invest lots of work into it. It was purely a toy project.

To make the substitution nicely compatible with the classical "Doppelwuerfel" it needed to use a q-ary alphabet instead of binary, so I also needed to adapt the NIST STS to F_q with a null hypothesis of x_i ~ U[q] instead of F_2 and U[{0,1}].

A lot of the properties checked by the STS are only going to be provided by the substitution, in particular frequency and cascade behavior. So it was fairly obvious that the method needed to be stateful, keyed and non-linear. The simplest possible thing I could come up with was

[ y_i = (k[y_{i-1}] + x_i + y_{i-1})^n ]

where gcd(n, q-1) = 1, and k[j] means the j-th letter of the substitution keyword and F_q* is used for the alphabet. This turned out to be fairly doable by hand using a power table created on the fly. In order for perturbations to propagate forward and backward this pre-whitening was applied to the text twice, once in forward once in backward direction.

This pre-whitening for q = 58, n = 3 was actually sufficient to fullfil my goals! 58 was chosen because it was the smallest prime q with gcd(q-1, 3)=1 with q-1 > 2*26 (I wanted upper and lower plus some special characters).

After running the STS tests I implemented the methods as described in the papers mentioned above and ran them against pure double columnar transposition, which gave a sufficient partial solve within an hour using 2 keys of length ~20 and ~1000 characters of text. So I could be reasonably sure that my implementation was not completely terrible.

I then adapted the attack to the whitened text by assuming the attacker knows the whitening key and margninalising the information over the q^2 hidden systes for each n-gram that is scored. I also tested straight decryption of the candidate permutation. Both of which failed to produce a partial solve in one day time. It's pretty clear that the hidden states obscure one character worth of information each, but just to be sure I computed the table of all 2-grams and a sample of all 3-grams with all q^2 hidden states to check that 0 or 1 character worth of information get leaked, which was the case. So the loss landscape for the hill climb because much less informative. As an alternative to marginalizing over the states one can guess and n+2-gram in order to score the central n-gram. But that turned out to not be tractable for 4-grams on my hardware. I also tested NN based scoring for language fragments, but out of lazyness used llama 3.2 1B which worked for straight Doppelwuerfel, but was slower than the classical method and failed the same for the whitened one.

I was honestly surprised that it was that easy to beat those methods, I expected the raw power of modern GPUs (RTX 4080 in my case) to be sufficient, but I suspect this whitening is actually sufficient to make the loss landscape awkwardly noisy. I'm not sure how I could prove that though. I'm also almost certain that with better methods it's breakable. If you have ideas I'd love to try them out!

I’m applying to a position related to ZKP and MPC cryptography, it’s one of my first positions and I freshly graduated from a school where I learned a lot about cryptography broadly (DDH, CDH, RSA, Shor, elliptic curves, etc are familiar to me).

What main topics should I rehearse to be specifically prepared for a ZKP and MPC subject?
Thanks for replies!!

Im losing my mind looking at some of these github repos lately where people are letting standard llms write their cryptographic primitives

Large language models just guess the most likely next token. they don't do actual rigor. a probabilistic model cannot guarantee a secure state transition. it is kinda refreshing seeing the broader tech world finally admit this - like how the latest ai reasoning benchmarks are suddenly prioritizing strict formal verification and machine-readable proofs over standard chat outputs

unless an automated system can mathematically prove its logic step-by-step, keep it far away from anything requiring high-assurance security. stop trusting autocomplete with math.

Hi there - appreciate some explanation from people who understand these things - thank you

If im doing full disk encryption and i use a password which is made up of real words in order to actually remember it, does this make it a trivial task for an offline brute force attack using a dictionary? Or am i mistaken in this?

i understand that its better to have more randomness but it needs to be something i can remember and easily type every day

Hi cryptography nerds!

I am a full-stack / end-to-end developer "specializing" in SaaS.
I have previously work with E2EE systems but sadly it has been about 10+ years.
So I am a little rusty / outdated on the matter.

Recently I started a new project / platform where I wanna try playing around with making a modern E2EE / zero knowledge platform.
I have done quite a bit of research trying to figure out how to best follow modern standards. (Not including post-quantum encryption).
So I was hoping to lay out my findings in here and hopefully some of you guys would be willing to audit it.

Thanks a lot in advance!
(Let me know if I left out some important information)

------------------------------------------------------------------------------------------------------

Trust model

• Server sees: UUIDs, timestamps, operational enums, public keys, signatures, opaque HPKE ciphertext blobs.
• Server never sees: user private keys, password/recovery KEKs, tenant private keys, plaintext content of anything user-typed.
• Browser compromise = game over. Explicitly out of scope. The user's password is their cryptographic root.
• TLS assumed for transport.

------------------------------------------------------------------------------------------------------

Primitives

Purpose	What	Params
Password hardening	Argon2id	t=3, m=65536, p=4, dkLen=32 minimum
KDF	HKDF-SHA256	inside HPKE + standalone for on-disk priv-key wrap
Symmetric AEAD	AES-256-GCM	12-byte nonce, 16-byte tag
Hybrid PKE	HPKE Base (RFC 9180)	DHKEM(X25519, HKDF-SHA256) / HKDF-SHA256 / AES-256-GCM
Signatures	Ed25519	identity, manifest, inter-service auth, grant signatures

Forbidden: RSA, AES-CBC, AES without an authenticated mode, scrypt, hand-rolled ECIES, P-256, separate encrypt+MAC. HPKE specifically (rather than rolling our own X25519+HKDF+AES-GCM, which is structurally what HPKE is) for the "audit against RFC 9180 test vectors" property.

------------------------------------------------------------------------------------------------------

Key hierarchy

How a user gets from a password to being able to open anything:

            password                 recovery code
                │                          │
                ▼ Argon2id                 ▼ Argon2id
            KEK_password             KEK_recovery
                │                          │
                ▼ AES-GCM (one of two wraps, same plaintext)
        ┌──────────────────────────────────────┐
        │     member priv (X25519)             │
        │     member signing priv (Ed25519)    │
        └──────────────────────────────────────┘
                │
                ▼ HPKE.Open (unwraps for each tenant the member belongs to)
        ┌──────────────────────────────────────┐
        │     tenant priv (X25519)             │
        └──────────────────────────────────────┘
                │
                ├──▶ HPKE.Open on tenant-recipient ciphertext
                │    (names, descriptions, payloads, audit log, etc.)
                │
                └──▶ HPKE.Open on the tenant's vault entries,
                     then HPKE.Seal under service pubkey for one call
                     (the structural plaintext exception)

------------------------------------------------------------------------------------------------------

Three recipient classes

Every HPKE envelope is sealed under exactly one of three recipient classes. The access boundaries are structural — they fall out of who holds which private key, not from RBAC:

                      │ Browser (signed-in │ Backend
                      │  member of tenant) │  service
──────────────────────┼────────────────────┼─────────────
Tenant-recipient      │  decrypt           │  no access
Service-recipient     │  encrypt only      │  decrypt
Member-recipient      │  decrypt (only the │  no access,
                      │   target member;   │   ever, by
                      │   others encrypt)  │   construction

The service holds exactly one private key — its own. It has no path to decrypt tenant-recipient or member-recipient envelopes, and that's not policy, it's that the bytes don't exist on that machine. Member-personal data lives in a separate table with no column shape that could ever hold a service-recipient envelope, so a future bug can't accidentally add that path.

------------------------------------------------------------------------------------------------------

Wire format

All HPKE envelopes are self-describing:

versioned_envelope =
   'v' '1'  ||  key_id (16-byte UUID)  ||  enc (32 bytes)  ||  ciphertext_with_tag

• key_id resolves into the right keys table based on the recipient class implied by the call site.
• enc is the RFC 9180 encapsulated key (X25519 ephemeral public).
• AAD is not on the wire — reconstructed from authenticated context at decrypt time.
• No nonce on the wire — HPKE derives the AEAD nonce from its KeySchedule + sequence; we use sequence 0 (one Seal per ciphertext).

I picked envelope-embedded key_id over a row column to keep ciphertext self-describing. Both are RFC 9180-compliant; the trade is "rotation queries scan a blob prefix" vs "indexed column lookup." Reason this is the wrong trade?

------------------------------------------------------------------------------------------------------

AAD discipline (this is where I most want eyes)

Every Seal/Open passes AAD that binds the ciphertext to its specific row / field / tenant / purpose. AAD is reconstructed from authenticated context at Open time — never read from storage. Example recipes:

• Generic tenant-readable data: tenant_data:v1:{tenant_id}:{resource_type}:{resource_id}:{field_name}
• Wrapped tenant priv for member X: tenant_priv_wrap:v1:{tenant_id}:{tenant_key_id}:{member_id}
• Service-recipient envelope: service_envelope:v1:{service_key_id}:{tenant_id}:{secret_id}:{binding_id}:{purpose_id}:{grant_id}:{expires_at}

Every HPKE info label is namespaced and domain-separated. HKDF inside HPKE mixes info into key derivation, so even with the same recipient pubkey, ciphertext sealed for one context cannot be Open'd against another's label.

The rule I'm enforcing: every AAD must include enough authenticated context that any cross-row / cross-tenant / cross-purpose substitution is detectable on Open. Nervous I've missed a substitution attack on a specific recipe.

Authorization scopes are plaintext canonical JSON, Ed25519-signed by the issuing user's identity key, byte-preserved end-to-end. Not encrypted, because the server has to enforce them at access time. The signed bytes bind a tenant-pubkey-hash, allowlists, and expiry. Is the signed-but-readable shape right here, or is there a cleaner primitive?

------------------------------------------------------------------------------------------------------

The one structural plaintext exception

Exactly one spot where plaintext briefly touches a server: a backend service must occasionally decrypt user-supplied secrets to forward them to a third party on the user's behalf. No architectural shape where "service makes the call on your behalf" and "service never sees the secret" are simultaneously true.

1. Browser opens secret under tenant priv (browser has tenant priv).
2. Browser HPKE-Seals secret under the SERVICE pubkey. AAD binds it
   to (service_key_id, tenant_id, secret_id, binding_id, purpose,
   one-of[execution_id, grant_id + expires_at]).
3. Ciphertext travels through intermediate hops — none of which can
   decrypt (they hold no service private key).
4. Service verifies its inter-service JWT, reconstructs AAD from
   JWT-authenticated values + its own service_key_id, HPKE.OpenBase.
   Plaintext lives on ONE stack frame for ONE call. Goes out of
   scope on return.

If that service private key leaks AND an attacker has DB access, AAD reconstruction is trivial — every field is a plaintext column or a JWT claim derivable from one. Defense-in-depth at the protocol layer I'm missing?

------------------------------------------------------------------------------------------------------

Rotation (full-re-encryption model)

Tenant-key rotation is eager full re-encryption, browser-driven:

1. Admin browser unwraps current tenant priv.
2. Generates new X25519 keypair.
3. HPKE-Seals new tenant priv under every current member's pubkey (one wrap row per member).
4. Atomic txn: insert new key as current, mark old as superseded, insert all new wrap rows.
5. Browser walks every encrypted row, decrypts under old key, re-encrypts under new key. Resumable across sessions.
6. When zero rows reference the old key: delete every wrap row for the old key, retire the old key, browser zeroes its copy.

------------------------------------------------------------------------------------------------------

What I'd love eyes on, in priority order

1. AAD recipes — substitution / replay attack I'm missing? Especially the service-recipient envelope.
2. Service-key-leak threat — defense-in-depth at the protocol layer?
3. key_id in envelope vs row column — reason one is materially worse?
4. Rotation correctness — race in steps 5/6 leaving a ciphertext referencing a retired key?
5. PQ migration plan — is the suite_id swap actually as clean as I think?
6. Signed-but-readable authorization scopes — cleaner primitive available?

Here is the technical write up and source code of the cipher. Written in assembly for ARM64 chips.

This cipher can encode and compress at the same time. Typically a 50% savings from plaintext to cipher text but depends on the plaintext data being encoded.

I am having a 1% decode failure and am unsure how to proceed. I am thinking it's from leading zeros that are not being interpreted correctly.

If that is the case, what would be wrong with rejecting this sort of bug and forcing a re encoding?

I am an undergraduate student in Mathematics from India and preparing for entrance examinations to master in Mathematics. I was looking for some careers in industry that are math heavy and are intresting to work in. That's when I found out about cryptography. For people working in private and government firms, what exactly do you do and what kind of mathematics do you use? The main thing is that I wanted a career where I can utilise Mathematics for actual stuff. Academia is good but boring and a permanent position takes too much time (PhD + multiple postdocs). Also, what is the scene of this field in the next few decades? What do you need besides mathematics to work in this field?

I've been working on a Rust implementation of Shamir's Secret Sharing for the past few days. Take a 32-byte encryption key, split it into N shards using polynomial math over a prime field, and require any T of those shards to reconstruct it.

The repo has the full flow: encrypt a file, split the key into shards, then reconstruct and decrypt using only a threshold of them. Uses num-bigint for the field arithmetic and aes-gcm for AEAD encryption.

repo: https://github.com/owlpharoah/shamirsecret

I built this mostly to understand the math properly. The polynomial evaluation and reconstruction logic was trickier than I expected, especially getting the modular inverses right.

Theres still some edge cases and error handling for me to fix and some bugs (with the random coeff sampling) i need to squash.

I bought an external ssd to store and use some of my softwares and games but don't know if its better to install softwares and games first then encrypt with veracrypt full disk encryption or encrypt it first then install softwares to it. Which way is the better way?

Hi everyone, I’m currently working on an academic FPGA project involving ECC-256, ECC-384, and ECC-528 signing and verification algorithms, mainly focusing on modular arithmetic architectures for low-latency and resource optimized designs.

My target operating frequency is around 400–500 MHz, and I’m looking for any relevant research papers, publications, GitHub repositories, or references related to efficient modular arithmetic techniques for ECC on FPGA platforms. Any guidance or pointers would be greatly appreciated. This is purely for academic and research purposes.

Thanks in advance!

Thinking about a problem that came up in a hobby project and the cryptographic side of it is genuinely interesting. Wondering what the prior art actually is, because the literature I find on long term key and identity custody tends to optimise for institutional lifetime horizons (decades) and assumes a more or less continuous institutional structure throughout.

The thought experiment:

A classified document needs to be reliably held by a single named custodian at any given time. When that custodian dies or retires, the document and its associated authority transfer to the next named custodian. The chain has to survive 750+ years.

Constraints:

No central authority across the full horizon. The originating institution might exist for 60 years, then merge into a successor, then that successor collapses, then a new institution forms claiming continuity, and so on. Across 750 years that happens maybe 6 or 7 times.

The current custodian must be cryptographically verifiable as the legitimate holder of the chain, not by appeal to an institution that may not exist any more, but by appeal to the chain itself.

About 30 to 40 custodians total across the 750 years. So roughly one handoff every 20 years on average, though uneven (some custodians serve 5 years, some serve 40).

Each custodian must be able to verify, when they receive the document, that the chain back to the origin is intact. They must also be able to verify it years into their custody, in case the institution that maintains the public verification side of the chain has collapsed in the meantime.

The document itself is mostly stable. Some custodians annotate it. Annotations need to be attributable to specific custodians, in order, with no possible repudiation by later custodians.

Where I keep getting stuck:

1. Key rotation across centuries. Modern crypto primitives have known shelf lives. RSA-2048 will be broken eventually. Whatever signature scheme the originating custodian uses will not be the one in use 750 years later. The chain has to accommodate scheduled migration to newer primitives, with each migration itself a signed event from the then-current custodian, but the migration has to be verifiable later from primitives that may not exist any more either.
2. Identity continuity vs custodian identity. The custodianship is the identity, not the person. When custodian Alice dies and Bob takes over, Bob is now the custodian. Bob's signatures are valid from then on. Alice's signatures from before remain valid for things signed during her tenure but become invalid for new things. How do you cleanly encode that on the chain when in 200 years nobody knows who Alice or Bob were as people?
3. Threshold succession. Sometimes a custodian dies unexpectedly without a clean handoff. Practical answer: a small set of witnesses (maybe 3 to 5 people) hold threshold key material so that a 2 of 3 or 3 of 5 can certify the next custodian after an unexpected death. But across 750 years the witnesses also turn over. You end up with a chain of threshold sets, each one certified by the previous one. Has anyone actually modelled this?
4. The anchor problem. The chain has to be checkable, which means somewhere outside the chain there has to be a trust anchor. Periodic public hash anchoring works while there is a public chain (Bitcoin or successor), but assuming a public chain still works in 750 years is an aggressive assumption. What is the lightest weight independent anchor that does not require a particular external infrastructure to persist? I keep thinking about geographically distributed printed proofs in neutral archives but that feels like cheating.
5. Forced succession. If a custodian is captured or coerced and made to sign over to an illegitimate next custodian, the chain has to be able to register that event as a forced succession and continue forward with that fact visible, not silently swallow it. How do you encode "this handoff happened under duress" verifiably without giving the coercer the ability to forge the duress flag the other way?

What I would reach for instinctively:

Append only signed log per custodianship. Each entry signed by the then current custodian's key, with the key itself certified by the prior custodian's key. Threshold witness signatures on every succession event. Periodic public anchoring via whatever the contemporary equivalent of OpenTimestamps is. Migration to new primitives encoded as explicit migration events, where the migrating custodian signs a statement in both the old and new primitives, allowing later verification by either while the old one still works.

But I keep getting stuck on the part where, in year 2473 or so, a custodian receives the document and wants to verify the chain back to year 2123. By that point primitives have migrated maybe 4 times. Each migration was signed in both old and new, but the old primitives may now be either broken (and therefore forgeable retroactively) or simply unverifiable through obsolescence (no implementation exists any more). Is there literature on this specific shape of multi generation primitive migration where the earliest links in the chain are signed in primitives that are no longer trustworthy at verification time?

Curious about prior art I might not know. The closest analogues I can think of:

PKI root CA succession (centuries scale possible, but assumes continuous institutional structure)

Religious manuscript tradition (centuries scale, but the verification is mostly textual and social, not cryptographic)

Government classified document custody (decades scale, classified processes, hard to learn from)

Crypto-anarchy succession schemes (Tim May era stuff, mostly theoretical, never deployed at horizon)

Threshold cryptography succession (small scale, short horizon)

If anyone has seen this kind of problem treated seriously in the literature, I would love a pointer. It feels like the kind of thing a cryptographer would have written about, but I keep missing it.

Hi everyone,

​I’ve recently fallen down the rabbit hole of cryptography and cryptanalysis, and I’m absolutely fascinated. I’ve always had a huge passion for mathematics, logic, and pattern-finding (things like number theory, prime numbers, and modular arithmetic really excite me).

​Seeing how these mathematical concepts are used to either build unbreakable ciphers or tear them apart via cryptanalysis feels like the ultimate puzzle.

​Since I love the math behind it so much, I’m seriously considering this as a future career path. I wanted to ask the experts here:

​What does the job market look like for a Cryptanalyst / Cryptographer? Are there good opportunities in the private sector (tech companies, blockchain, cybersecurity firms) besides government agencies?

​What should I focus on learning next? (Should I dive deeper into specific branches of math, or start learning standard programming/implementation?)

​Is it as fun and intellectually challenging in real life as it looks on paper?

​Would love to hear from anyone working in the field or studying it. Any guidance, book recommendations, or advice on what to look into would be amazing!

​Thanks in advance!

Note: I'm not an English speaker so I used AI

Hi,

I am building a key import mechanism for a hardware token (smartcard).

The tokens each hold exactly one P-256 key pair and can either import a new key pair replacing the old one, or sign a SHA-256 digest.

Instead of generating additional RSA keys in order to allow importing using a standard RSAES_OAEP_SHA_1 algorithm I am trying to use the existing key pair as the wrapping key for importing a new key pair, as using RSA would make it more complex and bug-prone (if the commands sent to the token are larger than 255 bytes you need to implement mechanisms such as chaining or extended length).

What I'm doing currently is:

1. Collect the current public key of the token that will import a new key pair

2. Generate an ephemeral key pair

3. Perform ECDH with the ephemeral private key and the token's public key

4. Hash the result with SHA-512 to get enough common secret data Use the NIST SP800-108 KDF on the common secret to derive the key and the nonce

5. Encrypt the new key pair with AES-CCM, outputting a 16 byte tag

6. Concatenate the ephemeral public key, the tag and the ciphertext

7. Send this to the token that will import it all

And then something similar happens on the token: get the common secret with ECDH, decrypt the data, verify the tag

Now my main question is, should the ephemeral public key be part of the authenticated data protected by the AES-CCM tag? And in general, is the design sound?

And is it enough to compute a SHA-512 digest to get enough key material instead of a proper KDF?

As indeed a KDF is not used because it's potentially not available as the new key generation and wrapping is also happening on a different smartcard where resources are limited, and it's the same reason why it's AES-CCM and not AES-GCM, and why the whole key pair is transmitted encrypted and not just the private key (as again point multiplication is potentially not available).

I say potentially because with enough money and connections I could get access to some private APIs for extra crypto algorithms including KDFs and ECC point multiplication.

Si puedes descifrarlo solo hazlo, te espero.