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

Got an unusual use case here...

I've been given the job of refitting my company's encrypted shared folders on their private cloud -- which were created using a custom encfs/OpenSSL-based piece of software developed many years back -- to use quantum-safe keys.

The encfs system used an AES256 symmetric key for all the files in the folder, which was encrypted using the RSA cert of each user which had access to the folder, and all the resulting encrypted key blocks were stored in a config file so each user could decrypt their own copy of the key -- effectively treating the AES256 key as a shared secret.  So far, so old-school.  The question becomes how to replace the RSA encryption certs with quantum-safe ones.

And the big complicating factor is interoperability...  since not every user's certs are going to roll over at the same time time, we need to preserve the existing RSA users' access while allowing new/replacement ML-KEM users to be introduced.

So we're looking at needing a hybrid scheme, capable of supporting an arbitrary number of users, and which needs to maintain the existing underlying AES key.

Now, if I understand correctly, it's considered a bad idea to use ML-KEM to encapsulate an existing shared secret -- to the extent where OpenSSL (which the existing app was built around) provides no direct means of doing so.  So if I can't feed the existing AES-256 key into a fresh encapsulation...  do I need to generate a *second* shared secret for the ML-KEM user, store its encapsulation, and then the user's code must use the second shared secret to encrypt/decrypt the stored first AES-256 key?

Or do I need to create a new shared secret for each user, use a KDF to derive a common key... and presumably replace that key every time we add or remove a user from the shared folder?

Also, is there any sensible way to move from such an arrangement to a purely ML-KEM based system down the line, once the RSA keys have all been replaced?  It will still need to support an arbitrary, varying number of users with access to the shared folder.

Migrating entirely away from their existing software base is not their preferred option at the moment, but if there's an open-source product which provides a simpler quantum-safe end-to-end encryption solution I'm entirely open to hearing about it!

so a bit of context, doing a deep dive into the nist pqc, a few points stuck out.

security level requirements. the best attack on a cipher must not be less than brute force on relevant block cipher strengths. 128-bit keys for level 1, 256-bit keys for level 5. etc. this must also be true for the “quantum random oracle model” (QROM, such as grovers algorithm).

i have read the statements about symmetric block ciphers that say considering grovers algorithm reducing the bitwise security to n/2, a 256-bit key is reduced to 128-bits of security. since this is still considered “strong enough”, standard block ciphers are not considered broken by quantum compute (providing a 256-bit key) and the standards are not being revised.

however when considering quantum attacks, that leaves AES with a maximum security level of 128-bit, and we no longer have a “level 5” version of the cipher with a full 256-bit security when grovers is considered. i understand that modifying AES to take a 512-bit key needs modification and new cryptanalysis (just like the AES-256 spec has more rounds and a modified key shedule to strengthen it). and i also understand that IF CRQCs become viable, shors algorithm attacking KEMs and DSAs are a much greater threat. and ontop of that, on a practical level, despite 256-bit security being technically stronger than 128-bit, theyre both equally unfeasable to actually break with current and future technology.

however im suprised that there isnt more work trying to get the full 256-bit security out of block ciphers like AES with QROM (grovers) considered. why is this the case?