Hi r/cryptography,

I’m Barbaros, an independent developer from Türkiye.

I’m working on an open-source research project called Komite, and I’d like technical criticism before choosing an anonymity protocol or writing the reference implementation.

The core problem is:

Can a system verify that a person is eligible to participate exactly once, while preventing the participant’s individual choice from being linked back to their real identity?

The intended use is small and medium-sized decision-support groups inside teams, companies, institutions and similar contexts.

This is NOT an election system, referendum system, or binding voting system.

The result is only an input to a decision.

Current requirements / research targets:

1. Contextual eligibility must be verifiable.

2. A participation right must not be reusable.

3. Identity and individual choice should be unlinkable.

4. An operator should not be able to reconstruct that link.

5. A later database compromise should not reveal historical identity-choice mappings.

6. IP, timing, device and behavioral metadata should not silently recreate the link.

7. Aggregate results should eventually be tamper-evident / verifiable.

8. Small cohorts must fail closed when disclosure risk is too high.

None of those anonymity properties are currently claimed as proven.

No cryptographic architecture has been selected yet.

The directions I’m comparing include:

- blind signatures

- anonymous credentials

- mixnet / tally separation

- a practical privacy baseline based on data minimization and trust separation

The difficult part for me is the small-group case.

For example, even if a blind signature breaks the direct issuer-token link, a single operator may still correlate issuance and submission timing when only 10–50 people participate.

Anonymous credentials introduce attribute and lifecycle complexity, while granular attributes may themselves shrink the anonymity set.

A mixnet can mitigate traffic correlation, but its anonymity benefit is limited when the underlying group is small.

So the questions I’d especially value criticism on are:

1. Is “verified eligibility + single participation + unlinkable choice” the right decomposition of the problem?

2. For small cohorts, is blind issuance plus delayed/batched submission a defensible research direction, or am I underestimating correlation attacks?

3. Is there a better primitive or protocol family I should study before narrowing the architecture?

4. What security property would you insist on formalizing first?

5. What part of this threat model looks naive or impossible?

The project currently contains research/design documents only. There is no production implementation and no claim of audited anonymity.

Repository:

https://github.com/barbarosbal/Komite

Threat model:

https://github.com/barbarosbal/Komite/blob/main/docs/THREAT-MODEL.md

Architecture directions:

https://github.com/barbarosbal/Komite/blob/main/docs/ARCHITECTURE-DIRECTIONS.md

I’m not looking for validation. I’d rather find the assumptions that break before committing to a protocol.

Hello,

I am in the process of designing my digital estate, i.e. preparing for the case when I am dead or incapacitated, and close friends will have to take over my affairs. I'd like to make this as easy as possible for them.

With this post, I would like to sketch my current idea (the result of a couple of weeks of research), and ideally get your input from a cryptographic perspective.

Note that this is a lot more conceptual than it is technical. I hope this is okay for this sub, if not — I am sorry, maybe you can recommend a better place?

No AI is being used in the composition of this post.

Up front, here is what I am trying to protect: passwords and the like, from loss, and also from unauthorized use by a third party. My approach does involve a handful of family members and close friends, and I generally trust them, though my solution also does protect against one or two of them going rogue.

It's actually not rocket science:

1. on an isolated, secure system, create a PQC-enabled GnuPG key pair (GPG 5, ky1024_cv448), secured with a 256bit passphrase;

2. use SLIP39 to encode this passphrase into a m-of-n multi-share, i.e. 4 of a total of 7 shares together can yield the passphrase;

3. copy each SLIP39 mnemonic share to individual paper, along with instructions;

4. put the key onto n USB sticks or microSD cards each, and wipe any other copy. Do keep the public key, obviously.

5. slip the USB keys/microSD cards and the paper menmonics into n envelopes each, and seal them. I won't go into details here, let's just assume the information therein is now no longer accessible without permanent tamper of the seal;

6. distribute the envelopes among your n trusted peers, along with instructions such as "keep this secret until my will executor contacts you, or you find out about my death, in which case please inform those that survive me that you hold a piece of my digital estate".

7. create (and regularly update) a collection of files, i.e. a tarball with the secrets and documents that make up the digital estate;

8. encrypt this tarball with the public key of the aforementioned GnuPG key pair to create a so-called vault;

9. mail the resulting vault to the trusted parties at regular intervals, asking them to confirm receipt, posession of the envelopes, and possibly randomly to prove that the envelopes are still untampered.

That's it. I've thought long and hard about alternative, redundant storages for the vault. Keeping them on USB sticks in bank safes just means that they'll go stale with time, so they have to be updateable.

And even though I've thought long and hard about possibilities to keep them redundantly around in a way that it's extremely unlikely that copies will have been made by the time post-post-quantum breaks Kyber, this remains I think an insoluble problem. Risk reduction here comes with a lot of extra complexity.¹

The solution with mailing the updated vaults out at regular intervals to trusted parties seems appropriate, as it creates redundancy, and no single one of those trusted people is in the threat model.

If post-quantum happens, and PQC turns out to be inadequate, then either I am still around (and we will have a whole slew of other problems) and could change the important passwords, or my digital estate needs to be accessed and handled anyway — not that I'd care, having tried to do my best to make it easy for those who survive me.

What do you think? Am I grossly overlooking attack vectors, or misunderstanding certain aspects of the cryptography?

Thanks for your time, m

Footnote:

¹) one could, for instance, include in the envelopes links to redundant storage of a "proxy archive", containing the GPG key, as well as two additional links to (1) the vault, and (2) a one-time-pad for XOR encryption. Each of those two files by themselves would be useless, and the likelihood of both of them being found together and the proxy archive also saved for a later point in time in a post-PQC world, is infinitesimally small, but the complexity is multi-fold.

RSA-260 = 4397328654844826923795068102505872571721883526553349659561256924505973939597
          593482272505698004801207988043088656411102133523080581
        × 5028695206842569864686141618253083416610081090075366674776775706538324961364
          412200138116378509733307971876652984898985905923678379

https://x.com/penlume/status/2095372672356212876

everything is in the title, though I need having the embedding degree between 3 and 300 million.

Please don't go too harsh, as I haven't managed to harvest enough info and find a decent elaboration on all of it with AI, articles, etc, so I'm jonesing for one. This is my third time asking this question on different subreddits.

I've been studying the source code of Bitsliced AEGIS on GitHub and I checked the multilane barrel-shift implementations of AEGIS256x2 for both 32 and 64 bits. I stumbled upon the context mask which prevents collisions between lanes and I noticed immediate differences: instead of the common mask described in the AEGIS document of LaneIdx byte + Total lanes byte + zero byte padding up to 16 lane bytes, now I see the following:

1. It's 256 bytes for X2 lane variant instead of 32

2. The indexes are weirdly placed rather at the end of the supposed blocks

3. The indexes themselves are uncommon, being 0x14, they also differ in their values and positions between 32 and 64 bit versions of the mask

In the libaegis library the context mask coefficients are placed in the right order, which matches the documentation, so I don't understand what makes this so different and how we construct one

This is the article about AEGIS I'm referring to: https://cfrg.github.io/draft-irtf-cfrg-aegis-aead/draft-irtf-cfrg-aegis-aead.html#name-the-init-function-4

The GitHub implementation: https://github.com/aegis-aead/aegis-bitsliced

Given the context, how can I construct a mask for e.g. X4, X8 lanes and so on for both 32 and 64 bit barrel shifts?

This is what allowed the Internet to be secure and to actually scale and be functional, it’s what allowed governments to be secure so basically the entire Internet and every single government and military runs on this. Also it created cryptography as an actual science and defined all of its actual principles so everything from bitcoin to post quantum security completely relies solely on this award.

Also literally all post quantum cryptography, meaning all security for the next few decades completely relies on it. especially as different-hellman and RSA become completely irrelevant

It’s not just important for security it pretty much is security

OmniMesh is a UK deep-tech cybersecurity company building a secure transport system for Defence, CNI and high-assurance environments.

We’re looking for an experienced applied cryptographer / cryptographic engineer to advise approximately one day per month.

The role is focused on independently challenging our cryptographic architecture, protocol composition, key-management decisions, hybrid post-quantum approach and implementation assumptions as we move towards MVP.

This is an active technical advisory position.

Particularly interested in people with experience in secure protocol design, applied cryptography, PQC, formal analysis or high-assurance communications.

UK-based preferred, although exceptional remote candidates are welcome.

DM if interested.

I was noticing something: unlike on semiprimes, it s quite easy to generate a point of known small order on a curve defined on a semiprime without knowing it s factorization. The idea is to transfer this small order to the underlying semiprime using a pairing method derived from the Weil pairing. Knowing if a given specific small order exists can be derived using congruences modulo N.

As you know, the problem is then to avoid a degenerate output from the Miller s algorithm. The problem is the only method I know to avoid this without using the factorization is to use a distortion map that works only with supersingular elliptic curves. But using a supersingular curve caps the order to gcd(p+1,q+1) which is unknown most of the time or just equal to 2. Taking order 2 result in generating outputs equal to 1 or -1. Useless for gcd factoring.

So, any idea of a pairing mechanism that would works over ordinary elliptic curves using embedding degree 1? Possibly using a distortion map that works over ordinary elliptic curves in such a case? Or a pairing that works with simple final exponentiation such as cubing or squaring?

I really like age-encryption, and I wanted an easy way for people to send me messages or files encrypted, without them having to install anything or manage keys. So I wrote age-web-gateway. Like some services in the past, it lets anyone send an anonymous message with the content encrypted in the browser. The recipient side only needs to publish an age public key at a location they control, either a DNS TXT record or an HTTPS .well-known file on their domain.

Maybe someone in this sub finds it interesting.

Go backend, MIT licensed, container image on GHCR, so you can run your own instance and point it at your own SMTP or Cloudflare Email API. Feedback and criticism welcome, especially on the key discovery and trust-level part.

Project: https://github.com/dhcgn/age-web-gateway

Demo: https://age.hdev.io/

Firstly I have read the wiki for the sub and I have a few of those recommendations open to look through later. Apologies if I missed any recommendations there that cover exactly what I'm asking for, I've tried to give as much detail as I can below to try and show why I'm having difficulty finding books. The TLDR is I can't trust that the cheap ones are not complete slop and I can't trust that the expensive ones aren't full of graduate level software-side information, way too advanced for what little maths I remember or not modern enough to cover the areas I'm interested in. I realise I may need a few different books to cover everything, all recommendations are welcome.

My experience / knowledge -

I have 15+ years in software development in various high value fields and the past few years of my career have been spent implementing authentication and authorisation. I have a pretty good handle on things as a consumer of libraries and from the concrete implementation side. I understand the basics of key exchange, symmetric vs asymmetric, diffie-hellman, RSA, elliptical curve encryption (very basic!), public/private keys, trapdoor functions, hashing, salts etc.

Why I'm asking instead of doing my own research -

I find myself wanting to understand more on the theoretical side and especially of the frontier techniques like ZKP, quantum-resistant algorithms and the like. In the current world of AI I find it very difficult to trust any book written in the last 4-5 years, however I need a recent publication to cover these subjects comprehensively hence asking for advice on here.

Target / goal -

If it helps with recommendations my main motivation is trying to develop open source zero knowledge alternatives to the current push for mass surveillance. I need to know that what I build is secure, well-grounded and that I can say with confidence that nothing leaks from the user's device, even accidentally. For that I think I need a very good grounding in cryptography and a working knowledge of using kali or similar to check traffic and the like. I do realise the kali side is probably beyond the scope of this sub but throwing it out there in case people might wear both hats and have recommendations for courses or books

Hello, I noticed that whenever I download a Linux distro, to verify that it has not been modified, it is required that I download 3 files:

"SHA512SUMS.sign" to verify the checksum's authenticity,

"SHA512SUMS" to verify the ISO's integrity,

"the ISO" to install the OS.

Why would they add the checksum in the middle, verifying the signature already verifies both authenticity and integrity. Why don't they just sign the ISO? I don't understand the purpose of the "SHA512SUMS" file.

Hi everyone, I recently graduated with an undergrad in CS, with a focus in cybersecurity. My final year project was about the Kyber algorithm used in PQC. I did an implementation of the enc + dec and then did a brute force attack to (in a way) "prove" the security.

I’m currently trying to work on a new project, but I’m having trouble finding something that feels really relevant or interesting. I’m good at mathematics and algebra, so I was able to learn the LWE concepts myself. However, my background/major is not mathematics, so I’m a little worried that anything significantly more complex might be beyond what I can realistically grasp. So far, some ideas that i have is

• machine learning for recovering information from PQC side channel attacks (slightly related to PQC, but the main
• PQC migration roadmap (mainly for corporate organisations. I’m unsure about this since it would likely be quite generic, and every company has different systems and requirements. It feels more suitable as an article or framework rather than a project)
• PQC blockchain (not sure how to go about this)
• anything old but replace with PQC (eg: Vpn with PQC, email with PQC. This feels quite generic to me, since anyone can essentially use an external library or OpenSSL and add PQC to an existing system)

I’m looking for something where I can actually experiment with or analyse the algorithm itself, rather than simply integrating an existing implementation. If anyone else has any idea to suggest, or to collaborate, do let me know!

Hello,

I wanted to get feedback on an idea I had and have been working on. Just to start, I am not a professional cryptographer at all, but have always had an interest in this field etc. I wrote a small post to explain what I thought was kind of an interesting idea.

Basically, to remove herd behavior from markets and reduce bot activity, participants would hash their predictions under a specific format, with an event identifier and a nonce before the event occurs in real life, proving prior knowledge. Once the event happens, they can reveal they have a matching hash and can verify it was produced before the event happened. I know that this may only work for binary (yes/no) type events, and a nonce system should prevent like a frequency analysis type attack. Here's a link to the post:

https://jc377.substack.com/p/blind-forecast-commitment-market?utm_source=share&utm_medium=android&r=47kqzt

I really appreciate any feedback, be gentle lol I really am not a professional cryptographer by any means at all! Just wanted to get some feedback from people way more knowledgeable than me here

Hello, Im not sure if this is the best place to start but, I'm an independent developer/researcher who has been working on a controlled reconstruction of a historical OpenSSL RNG vulnerability and its effect on cryptographic key generation.

The project is focused on reproducibility and provenance rather than exploitation of third-party systems. The experimental environment uses controlled inputs and owner-generated/synthetic targets, with the goal of determining whether historically vulnerable key-generation conditions can be reconstructed in a defensible and independently reproducible way...

So far, I've built a preserved experimental package containing reproducible artifacts, documented controls, integrity hashes, provenance records, and controlled reconstruction results. I've also filed a U.S. provisional patent application covering aspects of the work.

I'm now looking for technically qualified people who might be interested in independently reviewing the methodology and evidence.

In particular, I'd value feedback on:

- whether the experimental controls are sufficient to support the claimed causal conclusions;

- what evidence an independent cryptographic evaluator would expect before considering the reconstruction methodology validated;

- what additional provenance/reproducibility tests would strengthen the work; and

- whether this type of historical cryptographic reconstruction has useful applications in security research, legacy cryptographic-risk analysis, or forensic validation.

I'm deliberately not posting any implementation details or anything that could facilitate unauthorized recovery.

I'm also not claiming that the work has been independently validated yet—that's one of the reasons I'm posting.

If anyone here works or knows people professionally in cryptography, implementation security, OpenSSL, or security evaluation and would be willing to point out weaknesses in the methodology or discuss independent validation, I'd genuinely appreciate the feedback.

CSPRNG algorithms like Blum Blum Shub make use of one way functions to transform one PRNG state into the next. For example, modular squaring of the state (modular square root requires factoring) or modular exponentiation (discrete logarithms are computationally hard).

It seems that the reasoning is, if the random state is compromised (state compromise extension attack), then the attacker would be able to know what the future random numbers will be but not what the previously generated random numbers were. I am not finding any information on why this particular requirement is important. How is it useful to be able to keep past generated random numbers secret when future ones are compromised?

I'm working on a Python cryptography project and I'm deliberately trying to go beyond the usual feature checklist.

The common stuff is already covered by existing libraries: standard symmetric/asymmetric cryptography, hashes, KDFs, signatures, etc.

What I'm interested in is the opposite end of the spectrum:

What is the most obscure, niche, weird, legacy, specialised or "I can't believe I actually needed this" cryptographic feature you've ever needed?

For example:

• an obscure/legacy encryption format
• an old disk/container format
• a particular version of a standard
• a weird key derivation scheme
• compatibility with some ancient software
• parsing/decrypting a format that almost nobody uses anymore
• a specific binary crypto-related structure
• unusual padding/encoding conventions
• cryptographic file-format detection
• historical ciphers or machines
• interoperability with a non-Python implementation
• some operation that exists in another language/library but is missing from Python
• something you implemented yourself once and never want to implement again

The more ridiculously niche, the better.

I'm not asking for "what crypto algorithm should every library support?" I specifically want things where the answer might be:

Please describe the actual use case if possible, not just the algorithm/format name.

Also interested in features that aren't necessarily cryptographically modern or recommended for new systems — compatibility and forensic/research use cases count too.

What obscure crypto functionality would make you say: "Wait, this actually exists?"

Hi everyone. Could someone explain mTLS to me? How does mTLS work? How are the public and private keys used here? How does authentication and verification work, and so on?

I'm supposed to do a project for college. In this I am trying to stimulate a smart home environment. I'm using some sensors and motors(light, IR, stepper up motor etc) to gather up the data. The main part of the project is to encrypt that data at the point of conception of data. I'm using a ESP32 for the micro controller and I'm supposed to encrypt it there itself.
At first i chose homomorphic encryption, as it sounded complicated but had a python library. So, seemed enough to satisfy the proff. As i soon learned, I can't do that in a ESP32. Right now I'm considering Elliptical Curve Cryptography for the encryption. I saw all the videos on it i could find. I'm still going Python ECDSA library documentation. I asked chatgpt what math concepts I'm supposed to learn, and it seems like i know all those concept. I'm overwhelmed and I don't know if i'm going in right direction at all. Can anyone help?

To be clear, I’m not proposing Quantum Key Distribution.

I know QKD uses quantum states/entanglement to establish shared secret key material. What I’m wondering is whether pre-shared entangled states themselves could act as a possession-based authentication factor.

Imagine a future with cheap, long-lived quantum memory. A server stores one half of many entangled pairs, while a physical token in the user’s home stores the other halves.

During login, the server sends a random challenge specifying which unused qubits to measure and in which bases. The token returns the results, and the server measures its corresponding qubits and checks the correlations. Those pairs are then discarded.
So the security property would be:

-“Prove that you physically possess this specific quantum resource.”
rather than:

- “Use quantum mechanics to generate a shared encryption key.”

My questions are:

- Is this genuinely different from QKD cryptographically?

- Do existing quantum-authentication protocols already work like this?

- Would random measurement bases or Bell/CHSH-style tests make the credential meaningfully unclonable?

- Would this offer any real advantage over a classical hardware token such as a YubiKey?

- What attacks would break it, especially relay attacks?

I’m not claiming this is a new idea - I’m mainly curious whether long-lived entanglement could theoretically function as a physical authentication credential.

I made VC Port — a phone app that opens the same VeraCrypt file containers (.hc, .tc, .vera, or any disguise name) you already use on a computer.

This is not VeraCrypt. I am not allowed to use that name. It is a derived work with the VeraCrypt volume core, so TrueCrypt License 3.0 is inherited (not a random TrueCrypt revival). Phone UI is Apache-2.0.

What it does

• Pick a locked file (on the phone, or a file on a USB stick — not the whole USB disk).
• Type password / PIM / keyfiles. Master build does not remember passwords.
• Browse folders on a Mounted tab inside the app. This is not a system drive — Files / Files.app cannot browse the unlocked folder. That is intentional (seizure / forensic leftovers).
• Copy or move several files between the phone and an open volume, or between two open volumes.
• Create new volumes on the phone (with the same finger-scribble entropy step as the desktop wizard, mixed with the OS CSPRNG).
• Share encrypted — send the locked file as-is, no password on the send.
• Panic wipe / Dismount clears secrets on the phone. The ciphertext file is not deleted.

Platforms: Android + iPhone. Offline by default — FOSS build has no INTERNET permission. No ads, no analytics, no crash reporters.

Honest limits

• Not unbreakable. A compelled password still wins.
• 0.3.7 is a stable alpha, not 1.0, not a Play/App Store build.
• GitHub APK is a debug-signed preview. Production = build FOSS yourself and sign with your keystore.
• iPhone: unsigned IPA — you sign with your Apple ID (AltStore / SideStore or Xcode). I do not ship a store-signed app.

Not included: whole-disk USB unlock like OTG Master. If your stick is one big VeraCrypt partition, use OTG Master or a PC. If the volume is a file on the stick, pick that file in VC Port.

Links

• Source + APK/IPA: https://github.com/ShivamPingaleDev/Veracrypt_port
• Release: https://github.com/ShivamPingaleDev/Veracrypt_port/releases/tag/v0.3.7
• Screenshots in the README (Volume, Create, Mounted, Tools)

I am Shivam Mangesh Pingale — still doing a five-year IT engineering degree, built this because I wanted something I could actually use on a phone. Open to suggestions, teaching, internships, or work ([shivampingaledev@proton.me](mailto:shivampingaledev@proton.me) · [shivampingaledev@gmail.com](mailto:shivampingaledev@gmail.com)). No pressure.

Security issues: please use the repo’s SECURITY.md, not a public exploit thread.

Hey so I wanted to learn cryptography as I am into crypto and wanted to make some advance projects and as crypto runs on cryptography so I thought to learn it, but when I saw some resources all they did was telling what these terms do (like XOR, caeser) so I am confused as how will we be able to make projects , ps I can't learn somany things...