Removed ML-KEM note from TLDR area per feedback; keep TLDR unchanged

This commit is contained in:
Laan Tungir
2026-07-29 09:18:28 -04:00
parent 270cddc433
commit 668fb65efb
3 changed files with 4 additions and 6 deletions
-2
View File
@@ -23,8 +23,6 @@ I have currently used the following post quantum algorithms:
This app will generate public-private keypairs for each of these, publish on nostr your public key for each, and sign it with your current Nostr identity via your favorite signer (the nsec never leaves the signer).
> **Note on ML-KEM-768.** ML-KEM-768 (Kyber, FIPS 203) is a **Key Encapsulation Mechanism (KEM)**, not a signature scheme — it cannot sign events. The first four algorithms (ML-DSA-44, ML-DSA-65, SLH-DSA-128s, Falcon-512) are the post-quantum **signature** schemes that sign the attestation and provide post-quantum authenticity. ML-KEM-768 is included only to pre-commit a post-quantum **encryption** public key, so that a future post-quantum Nostr messaging protocol (e.g., PQ-encrypted DMs or session-key exchange) can use it without re-anchoring a new key to your identity. Its ownership is authorized by your existing secp256k1 signature over the kind 1 event, not by a PQ signature. See [ML-KEM cannot sign](#ml-kem-cannot-sign) for the full rationale.
You are making a statement to the world: "Here are post quantum pubkeys. If quantum computers hit, you know that the person signing using these can only be me."
This entire kind 1 event is then hashed and stamped into a block on Bitcoin using OpenTimestamps.
+1 -1
View File
@@ -1,6 +1,6 @@
{
"name": "nostr_quantum_preparation",
"version": "0.1.2",
"version": "0.1.3",
"description": "A migration strategy for bringing post-quantum security to Nostr without breaking the social graph, without requiring consensus on a single post-quantum algorithm, and without forcing existing users to abandon their identities.",
"main": "index.js",
"scripts": {
+3 -3
View File
@@ -1,5 +1,5 @@
{
"VERSION": "v0.1.2",
"VERSION_NUMBER": "0.1.2",
"BUILD_DATE": "2026-07-29T13:17:12.249Z"
"VERSION": "v0.1.3",
"VERSION_NUMBER": "0.1.3",
"BUILD_DATE": "2026-07-29T13:18:27.972Z"
}