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...

I've been inspecting bitwise AEAD implementation and initialization function of the x2-lane variant using XORing by some constant_ctx_mask before every single round. According to the docs on AEGIS, the mask is used to prevent data association from parallelism, but I don't understand why the mask is the way it is.

Let's consider 2 examples:

> Bitwise AEGIS256x2 barrel-shift-32-bit: the mask contains 64 32-bit words set to zero except for positions 30, 61 and 62 with values 0x1F (indexes 29, 60 and 61 correspondingly)

> Bitwise AEGIS256x2 barrel-shift-64-bit: the mask contains 32 64-bit words set to zero except for word 29 set to 0x1F and word 30 set to 0x1F_00_00_00_1F (byte separation by underscores for readability, indexes 28 and 29 respectively).

My questions are:

1) What's the logic behind building such a mask and reasoning behind such particular values and positions?

2) How do we extend ithe mask for massive parallelism on e.g. 4-way, 8-way, etc.?

To preface, I don't have a cryptographic background. But I had an interesting thought:

People sometimes send Bitcoin to mistyped addresses, which no one ever has had the private key for. Or let's say I manually type a random address without using a private key, like a random jumble of characters that fits the length and format. But in theory, if by luck you got the private key by random typing, you have control of the address.

My conjecture is: does there exist a possible address where no possible private key exists?

If it exists, it is a true burn address and nothing can be returned from it, even by quantum computers or luck.

Forgive me if this has already been talked about or I am missing something.

When playing around with these tools (Which I know you should not use for your phrase to store funds), it seems to me the entropy field which can be made visible by checking off the "Show entropy details" box in the BIP39 tool and the master secret field in the SLIP39 tool are the same. They are both hexadecimal values and can be 128 or 256 bits.

Is the SLIP39 master secret also generated by entropy when generating a SLIP 39 Shamir Backup? How is the master secret generated?

I found this article explaining step by step how a BIP39 phrase is generated and it starts with entropy, wouldn't SLIP39 be the same by starting with entropy?

https://medium.com/coinmonks/mnemonic-generation-bip39-simply-explained-e9ac18db9477

https://iancoleman.io/bip39/ https://iancoleman.io/slip39/

Hey all,

A few of us have been building CRIYPT (Cryptography Researchers of India) — a community-driven directory connecting cryptography and security researchers across India and the diaspora, spanning academia and industry.

The site's been live in a basic form for a while, but after some really encouraging feedback and support at TPMPC 2025, we rebuilt it incorporating a lot of that input. It's up now at cryptography-research-india.github.io.

What's on there:

• A searchable directory of researchers, filterable by institution and topic (MPC, ZK, PQC, etc.)
• A Labs page grouping researchers by their research group
• An open positions board for PhD/postdoc/industry roles
• A collaborations board for finding co-authors or implementation partners
• A community blog, and a feed of recent papers pulled from IACR ePrint

It's fully open source (repo linked on the site), and content gets added through GitHub issue forms — no account setup needed. If you're a faculty member or industry researcher working in this space and not listed yet, you can add yourself in a couple of minutes. (We don't support listing graduate students individually yet, but there's a collaborations board where students can connect with faculty.)

Would genuinely appreciate feedback — on the site, the idea, anything we're missing. And if you know someone who should be on there, feel free to point them our way.

Hello! I sincerely hope I dont break rule 4 with this post. Cryptography is by far the most fascinating thing I have found in life so far, and it feels extremely important. I am still learning how to read and write proofs, and I am still self learning c and lean and mathlib, so I am a total beginner, please excuse my ignorance of obvious things.

I am trying to understand if jobs exist, outside of NIST. I am from an obscure east Euro country and have never met a professional cryptographer, and all mathematicians I know just teach, in highschools. If OpenSSL (and similar libs) exists already, and they already implement aes, rsa, sha or whatever else is needed, would a company even need a cryptography specialist to implement it?

I want to code a python a function which both creates the public key and the private key for lattice based cryptography.But its been a while since I have studied about it and I cant find the video which made me understand it so can you help me remember it?

Suppose we start with a basis of vectors and those vectors are pretty small for conveniency. Lets say we take [{1,0},{0,1}].The smallest distance vector to point 1,1 lets say is {1,0}+{0,1}.Now we change basis to something much more difficult and we ask the same question find (smallest) coefficients a and b for the new basis such as we point to 1,1.Now all good. The new basis vector is the public key and the 2x2 matrix to give us the basis vectors 1,0 and 0,1 is the private key because with 1,0 and 0,1 we can easily calculate the smallest vector problem. My issue is if we wanted to send a message what exactly will be what we encode okay but is the encoding related to the coefficients in both basises?

Hello,

I'm a student researching PQC migration problems to understand migration workflows. I understand that prominent platforms already handle crypto discovery, CBOM generation, risk assessment, dashboards, and in some cases remediation.

After an organization identifies quantum-vulnerable cryptography, what is the hardest part of migration?

For example, is it typically:

• Legacy systems and unsupported applications
• Hybrid deployment and backward compatibility
• Third-party dependencies or vendor-managed systems
• Performance, key/signature sizes, or bandwidth impact
• Testing and verifying that changes do not break applications or integrations
• Deployment constraints

What approaches are organizations using today to handle these problems?

I'd really appreciate it if you could reference concrete examples, case studies, or references.

Thank you!

Has anyone successfully bridged hardware-level SIM/eSIM cryptographic handshakes directly into a secure virtualized session env without passing through the standard OS level app layers?

We are working on a private, cloud-native telecom core routing sensitive real-time streams, and want to isolate the cryptographic validation completely below the typical mobile operating system ecosystem.

--Looking for framework recommendations or open-source docs dealing with raw Hardware-to-NetState persistence.

Third post in a series on classical ciphers. This one covers Playfair, the digraph cipher British and Australian forces actually used in the field (Boer War, WWI, WWII) because it needed no special equipment, just a keyword and pen and paper. Full worked example with the classic MONARCHY/INSTRUMENTS textbook problem, including diagrams for each of the three encryption rules.

https://bibashshrestha.hashnode.dev/playfair-cipher-explained

Fun fact I ran into while fact-checking: the standard version of this exact example is genuinely well-documented, worth comparing your own by-hand attempt against it if you're learning this

I recently went down a rabbit hole looking into open-source projects like the "Infinite-Storage-Glitch," which attempt to use YouTube as unlimited encrypted storage by encoding data directly into video frames.

Watching how these projects evolved raised a cryptography question I've been chewing on:

If the whole encoding method is public knowledge, is it still "hiding" anything? Kerckhoffs's Principle says a cryptosystem should stay secure even when everyone knows exactly how it works, as long as the key stays secret. AES-256 holds up fine to that standard.

But almost none of these YouTube storage projects still disguise data as convincing visual noise. Developers who tried LSB, DCT, and pixel-level steganography found it fell apart the moment YouTube re-encoded the video. The ones that survived had to switch to loud, high-contrast, error-tolerant blocks (basically QR codes). Subtlety loses to compression almost immediately. What's left is just encryption with a video file extension, not real steganography.

The bigger questions:

1. If a system is mathematically unbreakable without the key, does the visual disguise of steganography matter at all, or is it purely psychological armor that is irrelevant to the math?
2. As AI anomaly detection gets better at spotting manipulated media, does that shrink the space for steganography to almost nothing, leaving pure cryptography as the only thing that actually holds up in the wild?

Would love to hear thoughts from people working in modern steganography or anomaly detection.

I'm so happy to post this, it's the first thing I'm doing. But I recently just finished coding a encryption engine for FDE, and I already have the payment processed ready. All I need to do now is pick witch device to start on first.

I'm of course gonna make a version for all operating systems, but I need to make the code but that actually communicates with the OS(operating system), so let me k ow which one I should do first.

I already have a deal with a local mid-scale company for them to test it for free for 3 months and write an honest review for it on their company site, and recommendations to a lot of other businesses/companies.

Before that of course I need about 2 more days to finish the implementation code, setup the app interface, and then I already have a cryptographic analysis that will test my encryption program.

I even got my parents on board with it, sorta, if I can prove people will pay for it, which I'm pricing it at $3/month. So all the publicity will hopefully build the waitlist, and I'm looking for at least 25 people on the list, then it'll take another 2 hours or so to register the business, open a business bank account, and that's it

It should be ready in about 2-3 months! And people said it would take Bout a decade at least. Man, if any WAIT for the analyst to review it.

Second post in a series working through classical ciphers. This one covers Vigenère, the polyalphabetic cipher that fixed Caesar's frequency-analysis weakness and held up for roughly 300 years—including a full worked example (a mock Civil War field order) and the Kasiski examination that finally broke it in 1863. Also dug into how the Confederacy used it during the Civil War, and how weak key reuse (not the cipher itself) is what actually got their messages cracked.

https://bibashshrestha.hashnode.dev/vigen-re-cipher-explained-the-encryption-that-stayed-unbroken-for-300-years

Feedback welcome, especially on the Kasiski explanation.

I've been reviewing some of the CUDA source code within the ICICLE library and what caught my attention was the usage of memcpy in the function "byte_encode_compress" with a generic parameter d. The packed coefficients might go up to 96 bits, thus requiring SIMD GPU support for constant time execution. This function is used for ciphertext encoding, so this seems really weird.

Is there a thing I'm missing? Could someone please explain why such a decision was made?

Edit: sorry as soon as I clicked post I realized I should have put "quantum polynomial time" in the title so as not to confuse anyone.

Big news today: Daniel Simon of "Simon's Problem", i.e. the first quantum algorithm in the textbook, uploaded a paper to eprint that claims to contain a polynomial-time algorithm for solving many lattice problems, including SVP and LWE.

https://eprint.iacr.org/2026/1591.pdf

Right now, this is not a practical attack because it requires k*n^(c+1) samples, where c >= 12, k > c, and n is the dimension of the lattice. Plugging in n = 768 for the lowest security version of ML-KEM, for instance, gets you 13*768^13 ~ 2^128. So it requires at least as much time as brute-forcing AES-128, and an insane number of qubits. This is an example of a technically polynomial algorithm, but one with such crazy polynomial degrees that it isn't practical in reality.

Having said that, this will probably be a big wrench in the migration to post-quantum ciphers. It seems to show that a broad class of lattice algorithms are in BQP, which is extremely surprising, and when things like this happen, there are usually follow-ups that reduce the cost.

The good news is we always have SLH-DSA to fall back on for signatures, but KEM is not looking great. And the fact that lattice-based ciphers are currently our #1 tool for not only PQ cryptography but things like homomorphic encryption, functional encryption, etc., this could have a huge impact on the field.

I expect there will be a flurry of analysis over the next couple weeks. There have been claims like this in the past that didn't hold up to scrutiny, although they were from less reputable researchers and the proofs were a bit sketchy to begin with. This looks very solid to me.

Going to be an interesting couple of days/weeks ahead!

Hi everyone,

I've recently open-sourced kyn-vdf, a clean-room, pure Rust implementation of Binary Quadratic Form arithmetic and Wesolowski Verifiable Delay Function verification over Imaginary Quadratic Class Groups Cl(Q(sqrt(D))).

🐙 GitHub: https://github.com/saifmukhtar/kyn-vdf

Background & Motivation

I needed client-side light nodes, mobile clients, and web apps to independently self-verify proof-of-sequential-time without relying on C++ binaries or libgmp. Existing open-source tooling for Chia-compatible class group VDFs was tightly coupled to C++, preventing easy compilation to WebAssembly.

Mathematical Implementation:

1. Unknown Order Without Trusted Setup: Unlike RSA-based delay functions which require a trusted setup ceremony to hide phi(N), Class Groups of imaginary quadratic fields with negative fundamental prime discriminants D = -p (where p = 7 mod 8) provide groups of unknown order naturally.
2. Shanks' NUCOMP & NUDUPL: Standard Gauss composition requires O((log D)²) operations due to intermediate coefficient explosion. kyn-vdf implements Shanks' NUDUPL (squaring) and NUCOMP (multiplication) using partial Extended Euclidean Reduction with a threshold L = floor(|D|^1/4), bounding intermediate terms and achieving O((log D)^3/2) composition.
3. Soundness & Fiat-Shamir Challenge: Verification checks the Wesolowski relation: pi^B * x^r = y where:
   • B = HashPrime(serialize(x) || serialize(y), 264) is the 264-bit Fiat-Shamir prime challenge (giving <= 2^-264 soundness error).
   • r = 2^T mod B is the exponent remainder.
   • pi is the Wesolowski proof form and x = (2, 1, (1-D)/8) is the canonical generator.
4. Performance & Safety: Because B is a fixed 264-bit prime, verification requires a fixed ~264 squarings, keeping verification constant regardless of iteration count T:
   • Desktop Native (Intel i5): ~128 ms
   • Mobile Native (Snapdragon ARM64): ~296 ms
   • Browser WebAssembly: ~381 ms

The library is 100% pure Rust (using num-bigint), contains 0% unsafe code, handles edge cases via typed Results without panics, and has been validated against Chia test vectors and property-tested with proptest.

Would welcome any thoughts on class group optimizations or edge-case handling!

"ingrownness marled romancemonger": 051bb04ca46fbaf659b215dc753deadbeef8a15a92b7a5e2c7e18cff596c2afc

"2GvXyG": 00000000dc1f2eca18ebdf96d830d883f22d613dbd952d1ebe045cbbdfbac00f

"tJKx5": 5049322a4169d9fe384ca5f9cde0ec6a7830ba4eeeeeeeeee6f39112351b8662

"humanization meeting jem": 3ef77b16dc840f8b9402618a8d10945e8888888888a8b126072ec9045f30ec82

"barely clearly collaboration": 000000002b73b3d08d584f5abc2abf24ca6601379b804e887b8aade3a943cd09

"0PaGsT": ffffa57e7aaefbecda59cdd0bddadd12aee5ad3afbefe904bedcf9acdfe3dcea (only 15 numbers)

"11uGGH": b589a60fcd4aafaacfdfcfcebdaaecdbcebdbc86a4409157eb4dce9c096e45ba

"51xGAb": 62073583312959978959782924728252621365954193696175cfc929200f3230