Quanta has a good article about a new foundational method for constructing non-interactive zk proofs. Current methods rest on (provably) shaky foundations. This approach reimagines a new definition for zk proofs (*effectively* zero knowledge proof), which as the name suggests, is effectively the same.
https://www.quantamagazine.org/how-unknowable-math-can-help-hide-secrets-20260511/
I am currently designing a system where KDF may be useful.
Suppose I use Argon2id and I keep the password private but share the key_store.json file publicly.
How secure would the private key be if an attacker only had access to the encrypted key_store.json file?
Hey folks!
So, I’ve been living in the cybersecurity trenches for a while (mostly security products development stuffs), but I’m honestly getting bored of just clicking around. I wanna go deep, like, actual cryptographic research deep, all that elite, brain-bending stuff. I'm looking to pivot into serious research, maybe a masters or a integrated phD or some research fellow role in India. I know the scene is a bit niche here, so I need some help finding these places which I can aim for. Anyone any suggestions ?
Vídeo do meu canal sobre como criptografia mensagens usando produto de matrizes. Se tiverem interesse assistam lá e comentem o que acharam.
Hey, I'm a noob in cryptography, and I can't understand the difference between cryptanalysis and formal verification, regardless of the techniques employed. My question is more about what is the purpose of each one? What do we achieve after performing only one of them and not the other? Thank you in advance!
Hello everyone!
In the last few weeks, I was trying to find a good ECDSA explanation to share with a colleague and I was surprised to find no post with an actual visual explanation for the algorithm.
So that's why I decided to make this post!
Obs: I really did try to find any resources close to the idea of my post and didn't find any. If you know about any link that actually explains the ECDSA visually, please share it, I'll be pretty happy to see it.
Anyway, I hope you enjoy the post.
I’ve been thinking about a concept that mixes LLMs with public-key style communication, and I’m trying to understand whether it has any real cryptographic value or if it’s fundamentally flawed.
Idea:
To send a message:
To decode:
The intention is not classical ciphertext, but semantically transformed text that looks harmless or unrelated.
Curious whether this is nonsense, already explored, or potentially an interesting direction.
Is there existing research close to this idea?
Hello everyone,i want to start learning Fully Homomorphic Encryption (fhe) from scratch. Please tell me how to do that and what resources are available to get started.
these days i try to find applied cryptography(especially, software engineering for PQC, PKI, public key cryptography etc.) but it is really hard to get a job...
am i always watching Linkedin? or i should become a phd course student haha
Question from someone who barely understands cryptography: could a malicious, authoritarian-leaning government compromise or alter a Zero-Knowledge Proof app to collect users' web browsing data in some way?
Wrote a basic/intuitive explanation of RSA encryption, why prime factorisation creates asymmetric encryption.
Tried keeping it simple without killing the actual math behind it. Would love feedback on whether the explanations hold up technically.
Hello fellow cryptographers.
This has been a personal research project of mine. As a physics student I thought of using non-linear dynamics of chaotic systems (in this case Lorenz + Chebyshev) for pseudo-random bit generation.
The generator has passed NIST SP 800-22 test suite as well as some other statistical tests such as Poker, LZC, Serial Correlation, Chi-Square and Shannon Entropy. Further red teaming (next bit prediction) was done using machine learning modes such as Linear/Logistic Regression, Decision Trees (ExtraTrees, HistGradientBoosting) and a Feedforward Neural Network. All ML models failed to predict over baseline.
So in short, the generator uses Argon2id as a seeding mechanism. It derives a 1024 bit key from a user password. Then those bits are spliced and used as seeds for chaotic systems (in which the bits are used to prime the initial parameters of the chaotic systems). Then an XOR operation is done on both outputs of the chaotic systems which gives the final bitstream.
So as I mentioned earlier this is a personal research project of mine. I am a physics student hence the option of using chaotic systems. Now I know, that, previously people had discouraged me from working on this deeming chaos based PRNG's as 'Snake-Oil' but I felt that this niche application of chaos based systems in cryptography was something worth researching on!!. (So here we are).
Now, I would love to hear your feedback on this project. Any tips to better it is also welcome.
I know further testing is required (like TestU01 and Dieharder). I will try to do it in future. It would be wonderful if some of you could red team the PRNG further using ML based models such as LSTM, Transformers or CNN/RNN. Anyhow, pasting link to the repository, do check out and tell your thoughts on this.
You already know this is happening to you right now.
Every website you visit builds a profile on you. Your login is not just a login — it's a data point. Your email, your device fingerprint, your location, your behavior patterns, your biometric if you use Face ID — all of it collected, stored, sold, and eventually leaked.
This is not a conspiracy. It is the business model. The entire identity industry is built on the premise that to verify you are you, someone has to store something about you.
I built a protocol that makes that premise architecturally impossible.
Not harder. Not better encrypted. Impossible.
What TAP actually is — plain English first:
TAP stands for Temporal Authentication Protocol.
Your heartbeat is not a steady tick. The gaps between beats vary in a pattern unique to you — this is called HRV (heart rate variability). Think of it like a fingerprint, except it lives inside your chest, changes slightly with every session, and cannot be lifted off anything.
TAP takes those gaps, runs them through a mathematical function with the current time and two random numbers that only live on your device, and produces a cryptographic private key. That key is used to sign a challenge. The answer — yes or no — goes on the blockchain. Then the key is thrown away.
Next session, your heartbeat re-creates it. Nothing is stored. Nothing can be stolen because there is nothing to steal.
But here is the part everyone misses when they ask about heartbeat stability — heartbeat is just one biometric. It is the strongest one, but TAP works with any consistent physical biometric. Voice. Fingerprint. Iris. Whatever your body produces consistently. The protocol is biometric-agnostic. What is novel is not what biometric you use — it is what is done to it.
What is actually new here — because this question will come up:
Every existing system does one of these things:
Nobody has combined all three: biometric + time variable + local-only storage = ephemeral private key that re-derives from your body each session and is never stored anywhere.
The time variable is the thing that makes this categorically different from every biometric system that exists. Your fingerprint on your phone is a static check against a stored template. TAP uses your fingerprint — or heartbeat, or voice — as the seed to a key that is mathematically unique to this exact moment. The same biometric at a different time produces a completely different key. Yesterday's session is cryptographically dead. Always.
The nine patent claims — what is actually being protected:
Claim 1 — Biometric KDF Identity Primitive Any consistent biometric signal combined with a time-variable floor and locally stored salts fed into Argon2id to produce an ephemeral Ed25519 keypair. The private key is never stored. This is the core primitive. Nothing like it exists.
Claim 2 — Biological Continuity Verification Without Biometric Storage Range-band indicators derived from but never storing raw biometric data. The system verifies you are still you without keeping any representation of you. Bands update via exponential moving average — 90% existing model, 10% new reading — so the identity ages with you without storing who you were.
Claim 3 — Probabilistic Morphology Signature from R-R Sequences A statistical model of your heart's waveform shape built from timing data alone. Gets more accurate every session. After 50 sessions it is a near-unique probabilistic fingerprint. Never stores raw morphology. Gets harder to fake the longer you use it.
Claim 4 — Encrypted Cardiac Deltas On-Chain Each session produces a tiny encrypted mathematical update — not raw biometric data, just a delta — stored on the blockchain encrypted with your private key. Meaningless to anyone without your key. Allows cross-device identity reconstruction after device loss without ever putting biometric data on chain.
Claim 5 — Session-Bound Liveness Verification Rate-of-change continuity check. A living heart drifts. A recording does not. Any frozen signal — replay attack, synthetic generator, pre-recorded audio — fails this check automatically because it has zero biological drift.
Claim 6 — Cryptographic Device Continuity Location plausibility cross-referencing as clone detection. Not tracking where you are — checking whether it was physically possible for your device to move between sessions. Two simultaneous authentications from the same public key at impossible locations flags a clone attack.
Claim 7 — Magnetocardiographic Proximity Verification The heart generates a magnetic field. MCG sensing captures that field. The field drops off with the inverse square of distance — meaning the sensor must be within centimeters of your chest to capture anything usable. Physical proximity is enforced by physics, not software. Cannot be defeated remotely. Cannot be replayed. The cardiac magnetic field is generated by ionic current in your specific heart muscle tissue and cannot be reproduced synthetically.
Claim 8 — Existing Smartphone Hardware as MCG Sensor Three implementations using hardware already in your phone: (a) the compass magnetometer chip at direct chest contact, (b) a phone case with a dedicated magnetometer communicating via NFC, (c) the wireless charging coil repurposed as a cardiac field detector. Zero new hardware required for the most accessible implementation.
Claim 9 — Biometric-Agnostic Temporal KDF Framework The entire protocol generalized. Any consistent biometric as the seed input. All security properties — temporal uniqueness, replay resistance, liveness verification, temporally increasing attack cost — are inherited automatically by any biometric that satisfies the framework's four conditions.
Hardware claims — separate patent track:
Hardware Claim A — NV-Center Diamond Magnetometer Device A wearable device using nitrogen-vacancy center diamond quantum sensing for cardiac magnetic field capture at room temperature. Achieves ~1 picotesla sensitivity. Transmits only extracted feature vectors via NFC during active sessions. Raw signal never leaves the device.
Hardware Claim B — MCG Phone Case Peripheral A smartphone case with an integrated magnetometer array. Session-gated NFC communication — data only transmits during active TAP authentication. Powers itself from the phone's NFC field. On-case preprocessing — raw signal stays in the case hardware.
Hardware Claim C — Wireless Charging Coil MCG Tap Method of accessing the wireless charging coil's magnetic field sensing for cardiac signal extraction. Novel application — first described use of charging coil for biometric authentication. Requires manufacturer integration at chipset level as the long-term path.
The blockchain layer — this is where it gets interesting for this community:
Your public key gets written to the blockchain at enrollment. That is the only thing on chain about you. No name. No biometric. No email. Just a math address pointing to a math key with a timestamp.
Every session, your device re-derives the private key from your fresh biometric capture, signs a challenge, and the smart contract confirms three things: public key is enrolled, signature matches, challenge is fresh and unexpired. Returns yes or no. That is the entire integration surface.
The encrypted cardiac deltas accumulate on chain over time — session by session, each one a tiny mathematical update encrypted with your private key. Anyone looking at the chain sees meaningless encrypted numbers. You pull them down to a new device, decrypt locally, reconstruct your identity model. Device loss solved without a recovery database.
The smart contract is two functions. 50 lines of Solidity. Anyone can read it. Anyone can verify it does exactly what it claims. The transparency is the trust.
The open source network effect — why more implementations make it stronger:
This is open source by design and the security model depends on it.
Every company or developer that implements TAP as an authenticator adds signal to the network. The protocol convergence works like this: as implementations proliferate, the noise introduced by slightly different implementations forces convergence to the mathematically correct version — the one with the strongest properties — because any deviation is detectable and rejectable by the network.
A proprietary version of this with a backdoor cannot survive in an open ecosystem because the open implementations provide a reference that exposes any deviation. The more people build on it the harder it becomes to corrupt it.
If you run a website, a forum, a DAO, a marketplace — you can add TAP as an authenticator with two API calls. Your users get a yes or no. You never see their biometric. You never store anything about them. Your compliance surface is zero because you are architecturally incapable of holding personal data.
What this disrupts:
Identity providers — Auth0, Okta, Ping — their entire value proposition is managing the database of who your users are. TAP eliminates the database. There is nothing left to manage.
Data brokers — their supply chain starts at identity. No stored identity means no data exhaust to harvest, aggregate, and sell. The profiling industry requires a record to build a profile on. TAP produces no record.
Biometric authentication companies — every system that stores a biometric template (FaceID templates, fingerprint databases, iris scans) is a breach waiting to happen. You cannot change your face. You cannot change your fingerprint. TAP never stores the template so there is nothing to breach and nothing permanently compromised if a device is lost.
KYC infrastructure — banks and financial institutions spend billions annually verifying identity and storing the results. TAP provides proof of humanity — same person, living, present — without the institution ever holding the underlying biometric. GDPR, CCPA, HIPAA, BIPA compliance becomes architectural rather than procedural.
CAPTCHA and bot detection — the entire industry exists because there is no reliable way to prove a human is on the other side. TAP is that proof. A bot cannot press a phone to its chest and produce a living heartbeat. The physics of liveness detection is the filter.
New industries this creates:
Human-only networks — social platforms, forums, marketplaces where every participant is provably a living human. Not verified by a company. Not checked against a list. Proven locally by math and biology.
Temporal identity markets — because TAP identity strengthens over time, early enrollment has value. The first million enrolled identities have a longer track record of biological continuity than anyone who enrolls later. This creates a new kind of digital seniority that cannot be faked or purchased.
Biometric hardware manufacturing — the NFC case, the MCG wearable, the NV-center sensor device. None of these exist as consumer products today. TAP gives them a protocol to build to.
Proof-of-humanity as infrastructure — DAOs, voting systems, content platforms, financial systems that need human verification without identity disclosure. TAP is the missing primitive that makes human-only digital spaces possible at scale.
What is built right now:
Working prototype — enrollment and verification operational. Voice biometric pipeline alongside heartbeat. Ed25519 keypairs generating from real captures. TAP server running with public API endpoints that any relying party can call.
Formal paper — 17 pages, full proofs of temporal uniqueness, replay resistance, biological continuity, temporally increasing attack cost, MCG spoofing impossibility. Nine patent claims, two hardware claims. Pre-print published.
Research landing page is in my bio
The open research question I am actively solving: getting the acoustic signal consistent enough to hit 80% same-person key match rate across captures. Two-pass peak detection fix built, consistency trial pending.
What I need from this community:
If you are working on cryptography, HRV biometrics, signal processing, or blockchain identity — I want your critique. The formal proofs are in the paper. Break them if you can.
If you implement wallets, dApps, or authentication systems — the TAP API is two endpoints. I want early implementers.
Karan Bedi · Dallas TX · May 2026 · Patent Pending · Pre-print Full paper:
Hello, I am developing an E2EE messenger with a custom protocol. I am trying to design the protocol in a way that provides a low barrier to entry for regular users. It annoys me that in strict E2EE protocols, the UX is severely compromised.
So, I've been thinking: is adding a master key, which the user can write down on a piece of paper or memorize, a huge mistake? Because if this master key is compromised, all the chats will be decrypted, right? But on the other hand, I believe this is quite a convenient solution if you want to provide people with seamless key synchronization.
I want to ask, what do you think about this? Should I add a master key? Should I make it optional? Or should I abandon the master key altogether?
I have implemented a very basic AES 128 where each round takes 1 clock cycle, ie for Sub bytes, shift rows, mix columns, add round key in a single cycle. Total 10 clock cycles for 10 rounds. My Sbox is precomputed, i.e like an LUT for all 256 entries. For each round Sub bytes takes 16 instances of Sbox, one instance for each bytes replacement, total 16 bytes and 4 for add round key step.
I want to optimise my AES, came to know that it can be optimised by using some GF((2^4)^2) instead of GF(2^8).
Can any one give a good source for understanding this approach please. Also any other suggestions for better implementations for S box optimisation or for entire AES
Thank you
For all of my life I have struggled with Mathematics. In fact, in school they told me I had a "math disability". Turns out that "math disability" was actually just autism that they failed to diagnose. I went undiagnosed until I was 26 years old and already in my first full time professional job. I've decided now that I am nearly 38 years old, it's time to finally try my hand at mathematics with a new understanding of how my brain works and to work with myself. I'm starting from almost nothing. I would have posted this in the mathematics but the reason I am posting here is because I would very much like to know more about the mathematics that go into some of the algorithms surrounding cryptography. Can anyone point me in the right direction? I'm doing a hacking course and we are covering RSA and Diffie-Hellman. I am reading through some of the explanations for how they work and I'm absolutely lost. I've seen the explanation for how everything works with color mixing but I'm still so curious as to how the math actually works. I can't understand how if two random numbers are chosen in a range (0 < g < p) why I couldn't also arrive at the result by selecting a random number for a and arrive at the same private key. Help!
I just need a good explanation of the forking lemma. I have seen that it is used to prove the security of digital signatures but I don't really understand it that much. Any good explanations?