Nymchat whitepaper tecnico

Accordo chiave post-quantum a Nymchat

Distribuire le chiavi pubbliche ML-KEM-768 su Nostr senza un directory o un registro, e sementarle da un segreto che nessun valore pubblico rivela.

Aggiungere uno scambio di chiavi post-quantum a un messaggero non è per lo più un problema di crittografia. I primiti sono standardizzati e le biblioteche esistono. Secondo Questo documento descrive come Nymchat risponde a questo – da dove proviene la seconda chiave, come raggiunge le persone che ne hanno bisogno, e cosa l’interfaccia può rivendicare sul risultato – e, nell’ultima sezione, cosa quel risultato non protegge.

Questa pagina è tradotta automaticamente per comodità. Si applica l'originale inglese.

1Il problema

I nostri messaggi privati sono crittografati con NIP-44, che ha due metà separabili. la metà che scatena il testo semplice - ChaCha20 con un tag HMAC-SHA256, Il HKDF (Il RFC 5869- non è significativamente minacciato da un computer quantistico; l'algoritmo di Grover costa un accelerazione a radice quadrata contro una chiave simmetrica, e 256 bit assorbe quella metà. Accetta La curva ellittica di Diffie-Hellman Scuola256K1Recuperare una chiave privata dalla sua controparte pubblica rivelerà retroattivamente ogni segreto condiviso che la chiave abbia mai prodotto.

La minaccia che questo crea non viene rimandata fino a quando non esiste una macchina del genere. Un avversario con archiviazione può registrare il testo di cifratura oggi e decifrarlo ogni volta che arriva la capacità. Qualsiasi cosa inviata ora che ancora conta allora è già compromessa. Questo è l'attacco specifico che un exchange di chiavi post-quantum sconfigge, ed è per questo che il lavoro non può aspettare che la macchina venga costruita.

1.1 La domanda a cui questo articolo risponde

La mitigazione è ben compresa: eseguire un meccanismo di incapsulazione della chiave post-quantum accanto allo scambio classico, quindi un attaccante deve interrompere entrambi per leggere qualsiasi cosa.Fifi 203Ciò solleva subito un problema di distribuzione:

Un npub è auto-contenuto. Puoi scriverlo su carta, leggerlo ad alta voce, o scannerlo da uno schermo, ed è tutto ciò che chiunque ha bisogno di criptare per te. Una chiave pubblica ML-KEM-768 è di 1,184 byte. Non può essere letta ad alta voce, non si adatta a un nome utente, e non appartiene a un codice QR oltre a un'identità che è solo 32 byte.

La parte più difficile è che una seconda chiave porta tre problemi distinti, e il resto di questo documento è in gran parte una risposta a loro:

• Può essere sostituito. Una chiave che nessuno può leggere ad un'occhiata è esattamente il tipo di cosa che un attaccante scambia per il proprio.
• Deve essere concordato su tutti i dispositivi di un utente. Lo stesso account su un telefono e un laptop devono presentare la stessa chiave, o i messaggi sigillati a uno non possono essere aperti sull'altro.
• Può essere perso. La chiave pubblica viene ripubblicata da un segreto, quindi ciò che effettivamente deve sopravvivere è quel segreto - e con la costruzione nulla altro lo ricostruisce.

2Restrizioni progettuali

Quattro restrizioni hanno modellato la risposta, e escludono la maggior parte dei disegni evidenti prima di scrivere qualsiasi codice.

1. Il minimo possibile di segreti. Ogni segreto aggiuntivo è un altro modo per perdere la tua storia, e qualcuno che sa eseguire il backup di un nsec non saprà eseguire il backup di qualcos'altro.La sezione 3.1 mostra che questo non può essere soddisfatto direttamente - una chiave post-quantum derivata dal nsec non fornisce alcuna protezione post-quantum - quindi il design spende esattamente un segreto e nessun altro: un singolo pezzo di materiale chiave, generato una volta per identità, presentato nella stessa forma del nsec e nello stesso luogo, in modo che chi sa come mantenere uno sa come mantenere l'altro.La sezione 10.1 è onesta su quanto costerà ancora.
2. Nessuna autorità Non esiste un server che possa essere affidato per dire quale chiave appartiene a chi. Qualsiasi tale server diventa il punto in cui i messaggi possono essere reindirizzati.
3. Molti dispositivi, una sola identità. Qualunque materiale chiave esista deve finire identico su tutti loro, e i percorsi che lo portano lì non devono essere leggibili dall'avversario contro il quale la funzione sta difendendo.
4. Nessuna negoziazione Qualsiasi scambio in banda di “quali cifre supportate?” è una superficie che un attaccante può strappare per forzare l'opzione più debole.

3Un segreto indipendente

La decisione di carico è che la chiave di decapsulazione ML-KEM è seminata da materiale chiave che nessun valore pubblico espone.

pqRoot   = 32 bytes from a CSPRNG, generated ONCE per identity

seed     = HKDF-Expand(
               HKDF-Extract(salt = "nym-pq-root-v2", IKM = pqRoot),
               info = "mlkem768/epoch/" || epoch,
               64 bytes)

(ek, dk) = ML-KEM-768.KeyGen(seed)

La radice viene presentata all'utente come un nsec è: di Bech32 Con il prefisso umano legibile nympqQuindi si legge come nympq1…, mostrato accanto al nsec nella schermata di identità dietro la stessa interazione di rivelazione, copiato con lo stesso controllo, mai registrato e mai inviato da nessuna parte nel chiaro. non è una password e non è un login.

Il sale è separato dal dominio allo scopo, quindi nessun altro segreto può mai derivare la stessa coppia di chiavi. epoch La rottura dei motori (sezione 9).

3.1 Perché la chiave non può essere derivata dalla chiave di identità

Il design ovvio è quello di seminare il keypair dal segreto che l'utente ha già:

seed = HKDF(salt = "…", IKM = nsec)          // do not do this

È attraente per quattro motivi, tutti reali: nulla di nuovo da backup, perché il nsec è già il backup; ogni dispositivo che accetta per costruzione, senza alcun protocollo di sincronizzazione per andare storto; un annuncio sostituibile per identità essendo ovviamente corretto, perché i dispositivi non possono essere in disaccordo sulla chiave; e la chiave esistente prima che sia mai pubblicata, in modo che un cliente possa sigillare qualcosa per se stesso in un primo momento.

Tutti e quattro i vantaggi sono inutili, per una ragione. L'algoritmo di Shor corre contro un npub pubblicato rende il nsec. La derivazione dei semi è un algoritmo pubblico sul nsec. Così l'avversario che rompe la metà classica ricostruisce la metà post-quantum eseguendo lo stesso HKDF che tutti gli altri eseguono. Contro la raccolta-ora-decript-più tardi - l'unica minaccia che la funzione esiste per fermare - una chiave derivata in questo modo non aggiunge nulla.

Una segretezza generata indipendentemente che viene quindi sincronizzata tra i dispositivi di un utente all'interno di un normale messaggio NIP-44 è lo stesso fallimento con ulteriori passaggi: un avversario registra quel messaggio oggi e recupera la sua chiave classica più tardi, e la radice cade fuori.

3.2 Ottenere la radice per gli altri dispositivi dell'utente

Contenuto 3 della Sezione 2 - una identità, più dispositivi - non può essere soddisfatto da aritmetica qui, perché l'intero punto è che la chiave non è una funzione di qualcosa che i dispositivi già condividono. nympq1… Il codice stesso.

La radice viene visualizzata come nympq1… accanto al nsec, e un secondo dispositivo lo accetta incollato nello stesso pannello. Questo è l'intero meccanismo. Un dispositivo che non ha ricevuto il codice non può partecipare, che la Sezione 4.2 descrive.

La regola della sezione 3.1 dice che la radice non può mai viaggiare sotto la crittografia classica-solo, e ogni meccanismo che renderebbe questo automatico - sincronizzarlo attraverso un relè, avvolgerlo con la chiave di identità - viola esattamente questo.

Il formato lascia spazio per un percorso avvolto: un record può portare un elenco di avvolgimenti, ognuno un blob AEAD sotto una chiave che l'utente può riprodurre su un altro dispositivo - una uscita PRF passkey, per esempio. nympq1… Il codice è l'unico modo di attraversare.La sezione 10.1 specifica quanto costerà.

La registrazione stessa vive nella propria categoria di impostazioni, nymchat-pq-rootAnche portando nessun avvolgimento fa il lavoro necessario: la sua presenza è come un secondo dispositivo impara che questa identità ha già una radice, che è ciò che lo impedisce di mentire una rivale (Sezione 3.3).

3.3 Generazione e adozione

Su boot, tenendo un'identità duratura, un client funziona in questo ordine:

1. Cercare un esistente nymchat-pq-root Il record.
2. Registrazione trovata, e questo dispositivo può sbloccare - adotterlo e annunciare questa identità come post-quantum capace.
3. Record trovato, e questo dispositivo non può sbloccarlo - non generare una nuova radice, e non pubblicare alcun annuncio. Invitare l'utente a collegare questo dispositivo nympq1… codice da un dispositivo che lo ha già.
4. Nessun record - generare una radice, pubblicare il record, annunciare e mostrare il nympq1… un codice all'utente una volta per poterlo salvare.

Passo 3 è il passaggio che è facile sbagliare, ed è la ragione per cui l'ordine è scritto piuttosto che lasciato a ogni implementazione. Due dispositivi che ciascuno decide di generare una radice producono due radici indipendenti sotto una identità, e questo è il fallimento che questo ordine esiste per prevenire.

4L’annuncio della capacità

La metà pubblica della coppia di tasti derivati viene pubblicata come un Il Nip-01 evento — tipo 30078, taggato nym-pq:

{
  "kind": 30078,
  "tags": [
    ["d", "nym-pq"],
    ["t", "nym-pq"],
    ["expiration", "<unix seconds>"]
  ],
  "content": {
    "v":     2,
    "alg":   "mlkem768",
    "nym":   1,
    "epoch": 0,
    "pk2":   "<base64url ML-KEM-768 encapsulation key>",
    "exp":   <unix seconds>,
    "devices": [ ... ]
  }
}

Addressable significa che il relay mantiene un evento per (kind, pubkey, d-tag), quindi una repubblica sostituisce l'annuncio precedente in posto. Ogni identità quindi ha esattamente un record corrente, che è ciò che rende “guardare la chiave di Alice” un singolo acquisto inequivocabile piuttosto che un elenco da conciliare.

La firma è vincolante. L'evento è firmato dalla chiave di identità, quindi la dichiarazione “questa chiave ML-KEM appartiene a questo npub” è esattamente così forte come il npub stesso. Sostituire una chiave di incapsulazione diversa richiede la forgiatura di una firma secp256k1. Un attaccante che può farlo non ha bisogno di preoccuparsi del KEM.

Gli annunci scadono. Il settimo giorno NIP-40 La scadenza, ripubblicata ogni 24 ore, conserva nella registrazione una dichiarazione su un client che è ancora in esecuzione piuttosto che quella che era.

Un annuncio mancato viene letto esattamente come uno che non ha mai portato una chiave: i colleghi inviano un NIP-44 ordinario, che ogni login può leggere, e il cliente riprende lo scambio post-quantum sulla sua prossima connessione, quando ripubblica. Così stare in silenzio per più di una settimana costa la protezione per i messaggi inviati durante il gap - sono classiciamente crittografati piuttosto che resistenti al quantum - e non costa altro.

Senza uno, un record supera la chiave che chiama: un dispositivo che viene cancellato, reimpostato o ha la sua radice sostituita lascia un'istruzione in piedi per incapsulare a una chiave che nessuno detiene più, e i messaggi inviati sotto di esso vengono persi senza errore su entrambi i lati.

Il campo chiave nomina il suo formato. Il campo è pk2, e la cifra fa parte del contratto piuttosto che della decorazione: chiama il formato di carico utile con cui la chiave può essere utilizzata. Un lettore che non riconosce il campo conclude il client “Nymchat, nessuna chiave post-quantum” e invia il normale NIP-44, che ogni login può leggere. Che è la direzione corretta del fallimento, e vale la pena dire come regola la numerazione del formato esiste per far valere: una richiesta di capacità non riconosciuta deve costare la protezione, mai la consegna. Una chiave che un collega non può usare è peggiore di nessuna chiave affatto, perché il messaggio che produce è perso senza errore su entrambi i lati.

4.1 L’assenza è significativa e triplicata

Un dettaglio sottile ma importante: l'annuncio è pubblicato da ogni client Nymchat, non solo quelli capaci di post-quantum, e il campo chiave è facoltativo.

Un annuncio senza chiave è una dichiarazione firmata che l'emittente esegue Nymchat, che consente al percorso di invio di saltare una speculativa confezione cross-protocol che altrimenti avrebbe bisogno di includere per chiunque non possa identificare.

4.2 Un dispositivo che non può aprire la radice rimane silenzioso

L'annuncio è sostituibile: un evento per identità, l'ultima scrittura vince. Questo è ciò che fa funzionare il design di singolo record, ed è anche ciò che rende un dispositivo non collegato pericoloso se pubblica. Un dispositivo che ha annunciato una chiave che aveva intitolato per se stesso avrebbe bloccato il registro reale e inviato ogni peer alla crittografia sotto una chiave che gli altri dispositivi non possono aprire.

Quindi un dispositivo che conosce una radice esiste ma non può aprirla pubblica nessun annuncio affatto.Non è rotto e non è bloccato dall'applicazione: continua a leggere ogni messaggio per il quale ha le chiavi e ancora invia in modo classico, spingendo l'utente a collegarlo.

5La scoperta e la decisione di invio

I clienti imparano le chiavi dei coetanei in due modi. Un abbonamento permanente copre le persone con cui un utente corrisponde effettivamente - conversazioni aperte e membri del gruppo - quindi i loro annunci arrivano come eventi ordinarie. Per un coetaneo incontrato per la prima volta, una query a un colpo viene eseguita al momento dell'invio, limitata a 2,5 secondi; se non si risolve, il messaggio diventa classico, che è il comportamento che esisteva prima che il post-quantum venisse aggiunto piuttosto che una nuova modalità di fallimento.

Un utente che collega un nuovo dispositivo, o che si sposta da un login di estensione del browser a una chiave locale, diventa post-quantum capace di mezzo-conversazione, e una permanentemente cache “no” li manterrebbe sulla crittografia classica per la vita dell'annuncio.

5.1 Perché non c'è un attacco di downgrade

La decisione di routing si riduce a una sola domanda:

pq = (we hold a signed, unexpired ML-KEM key for this recipient)

Non vi è alcuna negoziazione di capacità, nessun elenco di algoritmi supportati, e nessun campo un attaccante può chiarire per forzare un percorso più debole. È La modalità di fallimento di un annuncio spogliato o ritenuto è che il messaggio va classico - lo status quo prima di questa caratteristica - piuttosto che che un messaggio ibrido sia ridotto a qualcosa di falsificabile.

Anche l’inverso conta e conta di più: un cliente invia ibridi solo quando detiene una chiave, e tenere la chiave è la prova che il destinatario può decapsulare. Non c'è stato in cui un messaggio viene inviato post-quantum a qualcuno che non può leggerlo.

6La costruzione ibrida

Un testo di cifratura NIP-44 non modificato è lo strato interno, e ML-KEM tastiera un AEAD esterno intorno a esso:

inner = nip44_encrypt(plaintext, conversation_key(sender, recipient))

info  = "nymchat-pq2" || sender_secp_pk || recip_secp_pk || kem_ct || recip_kem_pk
prk   = HKDF-Extract(salt = "nymchat-pq2-v1", IKM = kem_ss)
key   = HKDF-Expand(prk, info || "key",   32)
nonce = HKDF-Expand(prk, info || "nonce", 12)

outer = ChaCha20-Poly1305(key, nonce, plaintext = inner, aad = info)

payload = "pq2." || base64url(kem_ct) || "." || base64url(outer)

Entrambi i segreti devono ancora essere recuperati per leggere il messaggio: lo strato esterno produce solo un testo di cifratura NIP-44, e l'apertura che ha bisogno del classico ECDH. Un avversario quantistico che rompe secp256k1 ottiene la chiave interna e ancora affronta ML-KEM; una rottura di ML-KEM strappa lo strato esterno e lascia NIP-44 in piedi.

• kem_ss Niente in questa derivazione tocca l'uscita ECDH cruda, che è ciò che si traduce in Sezione 6.1.
• kem_ct, recip_kem_pk e entrambe le chiavi di identità sono legate come dati associati, quindi il livello esterno è impegnato alla trascrizione esatta che lo ha prodotto.

La chiave ML-KEM del destinatario è duratura, ma ogni messaggio porta un testo di cifratura indipendente e quindi un testo indipendente. kem_ssQuesto è ciò che rende derivare la nonce piuttosto che randomizzare suona: ChaCha20-Poly1305 di è rotto reutilizzando una coppia (chiave, nonce), e qui la chiave stessa è nuova per ogni messaggio, quindi nessuna coppia può ripetere.

6.1 Perché gli strati rimangono separati

L'alternativa è quella di mescolare entrambi i segreti in una singola chiave di conversazione e di consegnare quella a NIP-44:

ck = HKDF-Extract(salt = "…",
                  IKM  = ecdh_x || kem_ss || …)          // do not do this

Quella costruzione suona come la crittografia. ha un problema strutturale: ha bisogno di ecdh_x, il coordinato x crudo dell'uscita ECDH, come materiale chiave - e un'estensione del browser (NIP-07) o una firma a distanza (NIP-46Esegue NIP-44 per conto del chiamante e restituisce un testo di cifratura, che è l'intero punto di tenere la chiave da qualche parte dove l'applicazione non può raggiungere.

Mescolare i segreti, quindi, esclude ogni login che mantiene la chiave di identità in un signatario, cioè gli utenti più attenti, e nessuna quantità di lavoro sulla derivazione della chiave può cambiarla. Lo strato rimuove la dipendenza: NIP-44 rimane intero ed è prodotto da ciò che detiene la chiave di identità, signatario incluso, mentre la metà KEM è calcolata dal codice di recupero detenuto dal client direttamente.

Il costo è la larghezza di banda, e non è piccolo. Il testo di cifratura ML-KEM è di 1,088 byte e corre su ogni messaggio, base64url-codificato a 1,451 caratteri; l'AEAD esterno aggiunge un tag Poly1305 da 16 byte e espande il carico utile NIP-44 che avvolge di un terzo. Un messaggio da 50 caratteri cresce da 176 byte a 1,712, e un messaggio da 2000 caratteri da 2,820 a 5,238. Il pavimento è di circa 1,5 KB per messaggio indipendentemente da quanto sia breve il messaggio, che è il prezzo di incapsulare fresco ogni volta piuttosto che riutilizzare un segreto condiviso.

6.2 Caratteristiche auto-descrittive

Il pq2. Il prefisso rende la distribuzione incrementale: è auto-descrittiva, quindi un client sceglie il percorso di decrittografia ispezionando il carico utile piuttosto che fidandosi di un tag o ricordando ciò che un peer supporta. Un lettore che non riconosce un prefisso non riesce ad aprire quel carico utile piuttosto che leggerlo male, e i messaggi sigillati prima di entrambi i lati potrebbero rendere il post-quantum leggibile come il normale NIP-44 senza migrazione.

6.3 Entrambi gli strati dell'involucro regalo

A NIP-17 Il messaggio privato è un NIP-59 Involgimento regalo: un rumore non firmato, sigillato sotto la chiave di identità del mittente (tipo 13), poi avvolto sotto una chiave gettata generata per messaggio (tipo 1059). su un login che detiene la chiave di identità direttamente, Nymchat ibrida entrambi i livelli, ciascuno con la sua propria incapsulazione.

Il sigillo viene prodotto dal signatario come NIP-44 ordinario – l’applicazione non vede mai la chiave che lo fa – quindi non può essere ibridizzato in luogo. Questo non costa nulla contro l’attacco in questione: il sigillo è raggiungibile solo attraverso l’involucro, e l’involucro è ciò che un registratore memorizza. Un avversario che detiene il traffico registrato deve rompere ML-KEM prima che un sigillo sia anche visibile per attaccare.

7Messaggi di gruppo e copertura parziale

Un messaggio di gruppo non è un solo testo di cifratura. È lo stesso testo semplice fornito a ogni membro, ogni copia incapsulata alla propria chiave ML-KEM di quel membro. Un membro che ha pubblicato una chiave riceve una confezione ibrida; uno che non ha una confezione classica.

Questo crea un problema contabile che un'implementazione ingenua si sbaglia. Se otto dei dieci membri ricevono una copia ibrida, il messaggio è non Un avversario ha bisogno di una copia classica di un testo semplice che sia identico in tutti i dieci, quindi il messaggio è protetto solo se ogni La copia è

Nymchat quindi traccia la copertura per messaggio durante il fan-out - il conteggio è conoscibile solo mentre i pacchetti sono in costruzione - e il badge riferisce “quantum-resistente a 8 di 10 membri” piuttosto che affermare che il messaggio è protetto. ricevuto Il messaggio di gruppo (solo il mittente conta il fan-out), l'interfaccia segnala una protezione parziale piuttosto che completa.

7.1 Cosa segnala lo scudo

Lo scudo dice la verità MessaggioNon si tratta del software che lo ha inviato:

• Protezione completa: ogni copia di questo testo semplice è uscito ibrido.
• Parziale: alcune copie di un messaggio di gruppo sono uscite in modo classico. disegnato degradato piuttosto che completo, perché una copia classica di un testo semplice identico in tutti loro è un bisogno dell'avversario.
• Il classico è dichiarato direttamente piuttosto che mostrato come nessun badge, perché un indicatore assente è ambiguo tra “non protetto”, “spezzato”, e “questa costruzione manca la funzione”.

Il verdetto viene registrato quando il messaggio è sigillato piuttosto che ricomputato da ciò che un peer annuncia più tardi. Ciphertext che esiste già non può diventare meglio protetto di quello che era, e un'interfaccia che ricostruisce i vecchi messaggi sulla forza di un nuovo annuncio affermerebbe qualcosa di falso sui byte su un relay.

Le regole di gruppo sopra stack in cima a questo piuttosto che sostituirlo: un messaggio di gruppo è completamente protetto solo quando la copia di ogni membro è stato, e un messaggio di gruppo ricevuto con nessun conteggio di copertura mostra parziale.

8Copie indirizzate a te stesso

Diverse cose che un client memorizza sono crittografate per l'identità dell'utente: impostazioni sincronizzate, l'elenco delle conversazioni, le chiavi di gruppo e l'archivio dei messaggi. Queste trasportano più informazioni su un utente rispetto alla maggior parte dei singoli messaggi, quindi lasciarli classici li renderebbe l'artefatto memorizzato più debole indipendentemente da quanto accuratamente i messaggi stessi siano stati sigillati. nymchat-pq-root categoria stessa, che non può essere sigillata sotto una chiave che solo essa può produrre.

Un blob di impostazioni o una riga di archivi si trova in un posto per anni, che è esattamente la forma di cosa che un avversario raccoglie - ora decriptato - più tardi - molto più di qualsiasi singolo messaggio, che è almeno effimero nella mente dell'utente stesso.

Una restrizione regola il formato qui piuttosto che la chiave. Una copia auto-indirizzo deve essere leggibile da ogni Ogni dispositivo pubblicizza ciò che può aprire nella scheda che il suo annuncio porta, e l'account scrive solo ciò che tutti possono leggere.

9Rotazione

Il epoch Il conteggio nella derivazione è ciò che rende possibile la rotazione senza nuovo materiale chiave. Incrementandolo si ottiene una nuova coppia di chiavi dalla stessa radice e un annuncio ripubblicato; i coetanei raccolgono la nuova chiave dal record sostituibile.

9.1 Le antiche epoche sono conservate, e nulla è re-encryptato

Un client costruisce candidati di decrittografia dall'epoca corrente fino all'epoca − 3, quindi un messaggio sigillato poco prima di una rotazione si apre ancora contro la coppia di chiavi che era corrente quando è stato inviato.

Quella finestra è ciò che rende la rotazione sicura da fare: senza di essa, ogni rotazione distruggerebbe ciò che era in volo. Qualsiasi cosa già sigillata rimane leggibile per la vita dell'identità, perché un messaggio che l'utente non può più aprire è strettamente peggio per loro di quello la cui protezione non può essere migliorata retroattivamente (Sezione 10.5).

10Cosa non protegge

Un documento che elenca solo ciò che un progetto raggiunge non descrive un sistema, e sopravvalutare una proprietà di sicurezza in un'interfaccia è peggio che ometterla.

10.1 La radice è un secondo segreto, e perderlo è irrimediabile

Questo è il prezzo reale del design. Il vincolo in Sezione 2 che un utente dovrebbe avere esattamente una cosa da mantenere non può essere soddisfatto: il nsec da solo non ricostruisce la chiave post-quantum, perché il punto è che nessun valore pubblico e nessun altro segreto lo espone. Se nessun dispositivo detiene la radice e nessun avvolgimento della Sezione 3.2 può essere aperto, il materiale sigillato alla chiave derivata dalla radice non è recuperabile.

Con il trasferimento manuale l'unico percorso, questo è più nitido di quanto possa essere letto per la prima volta. nympq1… Il codice ovunque ha esattamente una copia di esso, su un dispositivo, e la perdita di quel dispositivo perde ogni messaggio post-quantum, le impostazioni blob e la riga di archivio sigillata su di esso. nsec non aiuta; questa è la proprietà su cui si basa l'intero design.

Un attaccante attacca il percorso più economico disponibile, quindi uno schema vale quello che vale il suo percorso di recupero più debole - una frase memorabile, per esempio, metterebbe l'intera cosa a quello che vale la frase, e la riga avvolta è esattamente l'artefatto che un avversario raccoglie e macina offline in tempo libero.

10.2 Autenticazione, diversa dalla riservatezza

Ogni firma in Nostr è Schnorr su secp256k1, e questo è invariato qui. Un avversario con un computer quantistico potrebbe falsificare firme e impersonare un utente in tempo reale. Quello che gli scambi di chiavi ibridi sconfiggono è la raccolta-ora-decript-più tardi: un attaccante che registra il traffico oggi non può leggerlo più tardi. Non rende un messaggio imperdonabile contro un avversario che ha già la macchina. Questa distinzione viene portata nelle applicazioni deliberatamente - l'indicatore padlock segnala l'autenticazione, lo scudo segnala la riservatezza, e sono gli glifi separati perché un messaggio può avere uno senza l'altro.

Il legame tra un npub e una chiave ML-KEM è una firma secp256k1, quindi un avversario che può falsificare queste può sostituire una chiave propria.

3.3 Metadati

L'involucro del dono nasconde l'emittente, il destinatario oltre un unico p Il tag, il tipo e il timestamp del messaggio interno. Non nasconde che un evento esiste, la sua dimensione, o quando un relay lo ha ricevuto.

10.4 La mesh offline

Il trasporto di mesh Bluetooth di Nymchat è un protocollo separato con il proprio tocco di mano, e non è coperto da questo lavoro.

10.5 Messaggi già inviati

Ciphertext registrato mentre entrambi i lati erano ancora classici rimane classico in modo permanente. Esso esiste già e non può essere nuovamente sigillato. La protezione inizia al messaggio in cui entrambi i lati hanno tenuto le chiavi post-quantum, non nel momento in cui la funzione è stata attivata.

11Le alternative considerate

12Parità di attuazione

Nymchat fornisce due implementazioni indipendenti di questa costruzione - una in JavaScript per l'applicazione web, una in Dart per le applicazioni mobili, tra cui una porta da zero ML-KEM-768.

L'implementazione Dart ML-KEM è validata contro l'ufficiale di NIST ACVP Test di risposta conosciuta per ML-KEM-768 (ML-KEM-*-FIPS203) – 25 casi di generazione chiave, 25 casi di incapsulazione e 10 casi di decapsulazione, eseguiti come propria suite. Questi sono i vettori che NIST pubblica per convalidare un'implementazione, quindi passare è la prova che il porto è corretto, non solo la prova che i due clienti sono d'accordo l'uno con l'altro. Oltre a questo, una fissura condivisa di vettori di test - derivazione di semi, incapsulazione, entrambi i formati di carico utile e completamento del regalo - è generata dal riferimento JavaScript e controllata da entrambe le suite di test. Il segreto radicale estende quella fissura piuttosto che sostituirla: radice a seme, radice a chiave, impronta pubblica della radice e i dati derivati, nonce e associati del livello est nympq1… Una divergenza in entrambe le implementazioni fallisce la build piuttosto che produrre un messaggio che l'altro client non può aprire.

E 'quello che dice un dispositivo “questo è la radice che ho” da “questo è un diverso uno”, e un cliente che non poteva riprodurre l'impronta digitale di un altro cliente avrebbe letto un record perfettamente buono come nessun record - e poi, seguendo la Sezione 3.3, minare una seconda radice e dividere l'identità.