Le whitepaper technique de Nymchat

Accord de clé post-quantique à Nymchat

Distribuer les clés publiques ML-KEM-768 sur Nostr sans un répertoire ou un registre, et les semer d’un secret qu’aucune valeur publique n’expose.

L'ajout d'un échange de clés post-quantum à un messager n'est généralement pas un problème de cryptographie. Les primitifs sont standardisés et les bibliothèques existent. Deuxième Ce document décrit comment Nymchat répond à cela – d’où vient la deuxième clé, comment elle atteint les personnes qui en ont besoin, et ce que l’interface est autorisée à revendiquer au sujet du résultat – et, dans la dernière section, ce que ce résultat ne protège pas.

Cette page est traduite automatiquement pour plus de commodité. La version originale anglaise est la version qui s’applique.

1Le problème

Nos messages privés sont cryptés avec PIN-44, qui a deux moitiés séparables. La moitié qui déchire le texte simple — ChaCha20 avec une étiquette HMAC-SHA256, Le HKDF (Le RFC 5869- n'est pas significativement menacé par un ordinateur quantique ; l'algorithme de Grover coûte une accélération de racine carré contre une clé symétrique, et 256 bits absorbent cela. Accepter La courbe elliptique de Diffie-Hellman Général256k1Récupérer une clé privée de son homologue public expose rétroactivement chaque secret partagé que la clé a jamais produit.

La menace que cela crée n'est pas reportée jusqu'à ce qu'une telle machine existe. Un adversaire avec le stockage peut enregistrer le texte de chiffrement aujourd'hui et le déchiffrer chaque fois que la capacité arrive. Tout ce qui est envoyé maintenant qui importe alors est déjà compromis. C'est l'attaque spécifique qu'un échange de clés post-quantum vainc, et c'est la raison pour laquelle le travail ne peut pas attendre que la machine soit construite.

1.1 La question à laquelle cet ouvrage répond

L'atténuation est bien comprise: exécuter un mécanisme d'encapsulation de clé post-quantum aux côtés de l'échange classique, de sorte qu'un attaquant doit rompre les deux pour lire n'importe quoi.Les FIPS 203Cela soulève immédiatement un problème de distribution :

Vous pouvez l'écrire sur papier, le lire à haute voix, ou le scanner à partir d'un écran, et c'est tout ce que tout le monde a besoin de chiffrer pour vous. Une clé publique ML-KEM-768 est de 1,184 bytes. Il ne peut pas être lu à haute voix, il ne s'intègre pas dans un nom d'utilisateur, et il n'appartient pas à un code QR en plus d'une identité qui n'est que de 32 bytes.

La partie la plus difficile est qu'une deuxième clé apporte trois problèmes distincts, et le reste de ce document est en grande partie une réponse à eux:

• Il peut être remplacé. Une clé que personne ne peut lire d’un coup d’œil est exactement le genre de chose qu’un attaquant échange pour lui-même.
• Il doit être compatible sur tous les appareils d’un utilisateur. Le même compte sur un téléphone et un ordinateur portable doivent présenter la même clé, ou les messages scellés à l'un ne peuvent pas être ouverts sur l'autre.
• Il peut être perdu. La clé publique est republiée à partir d'un secret, donc ce qui doit réellement survivre est ce secret - et par la construction rien d'autre ne le reconstruit.

2Les contraintes du design

Quatre contraintes ont façonné la réponse, et elles excluent la plupart des conceptions évidentes avant que n'importe quel code ne soit écrit.

1. Le moins de secrets possible. Nos utilisateurs portent déjà exactement un secret, le nsec. Chaque secret supplémentaire est un autre moyen de perdre votre histoire, et quelqu'un qui sait sauvegarder un nsec ne saura pas sauvegarder quoi que ce soit d'autre. Section 3.1 montre que celui-ci ne peut pas être rencontré directement - une clé post-quantum dérivée du nsec ne fournit pas de protection post-quantum du tout - de sorte que le design dépense exactement un secret et pas plus: une seule pièce de matériau clé, généré une fois par identité, présenté dans la même forme que le nsec et au même endroit, de sorte que quiconque sait comment garder l'un sait comment garder l'autre. Section 10.1 est honnête sur ce que cela coûte encore.
2. Pas d’autorité Il n'y a pas de serveur qui puisse être confié pour dire quelle clé appartient à qui.
3. Plusieurs appareils, une seule identité. Une identité Nostr est couramment utilisée par plusieurs clients à la fois. Quel que soit le matériau clé qui existe doit finir par être identique sur tous, et les chemins qui la portent ne doivent pas eux-mêmes être lisibles par l'adversaire contre lequel la fonctionnalité se défend.
4. Pas de négociation. Tout échange en bande de “quels chiffres soutenez-vous?” est une surface que l'attaquant peut enlever pour forcer l'option plus faible.

3Un secret de racine indépendant

La décision porteuse de la charge est que la clé de décapsulation ML-KEM est semée à partir de matériaux clés qu’aucune valeur publique n’expose.

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 racine est présentée à l'utilisateur de la manière dont un nsec est : Bébé32 Avec le préfixe humain lisible nympqAinsi, il se lit comme nympq1…, affiché à côté du nsec dans l'écran d'identité derrière la même interaction de révélation, copié avec le même contrôle, jamais connecté et jamais envoyé nulle part dans le clair.

Le sel est séparé par le domaine, de sorte qu'aucun autre secret ne peut jamais dériver de la même paire de clés. epoch Résistance à la rotation (section 9).

3.1 Pourquoi la clé ne peut pas être dérivée de la clé d'identité

Le design évident est de semer la paire de clés du secret que l'utilisateur a déjà:

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

Il est attrayant pour quatre raisons, toutes réelles: rien de nouveau à sauvegarder, parce que le nsec est déjà la sauvegarde; chaque appareil acceptant par construction, sans protocole de synchronisation pour aller mal; une annonce remplaçable par identité étant évidemment correct, parce que les appareils ne peuvent pas être en désaccord sur la clé; et la clé existante avant qu'elle ne soit jamais publiée, afin qu'un client puisse sceller quelque chose pour lui-même en premier.

Tous les quatre avantages sont inutiles, pour une raison. L'algorithme de Shor s'exécute contre un npub publié donne le nsec. La dérivation des graines est un algorithme public sur le nsec. Ainsi, l'adversaire qui brise la moitié classique reconstruit la moitié post-quantum en exécutant le même HKDF que tout le monde exécute. Contre la récolte-maintenant-déchiffrer-plus tard - la seule menace que la fonction existe pour s'arrêter - une clé dérivée de cette façon n'ajoute rien.

Un secret indépendamment généré qui est ensuite synchronisé entre les appareils d'un utilisateur à l'intérieur d'un message NIP-44 ordinaire est le même échec avec des étapes supplémentaires: un adversaire enregistre ce message aujourd'hui et récupère sa clé classique plus tard, et la racine tombe.

3.2 Obtenir la racine sur les autres appareils de l'utilisateur

Constraint 3 de la Section 2 – une identité, plusieurs dispositifs – ne peut pas être satisfait par l’arithmétique ici, parce que le tout est que la clé n’est pas une fonction de quelque chose que les dispositifs partagent déjà. nympq1… Le code lui-même

La racine est présentée comme nympq1… à côté du nsec, et un deuxième appareil l'accepte collé dans le même panneau. C'est le mécanisme entier. Un appareil qui n'a pas reçu le code ne peut pas participer, ce qui est décrit dans la Section 4.2.

Le transfert manuel est un plan délibéré plutôt qu’une première étape.La règle de la Section 3.1 dit que la racine ne peut jamais voyager sous le cryptage classique uniquement, et tout mécanisme qui rendrait cela automatique – la synchronisation à travers un relais, l’emballage avec la clé d’identité – viole exactement cela.

Le format laisse de la place à un chemin enveloppé : un enregistrement peut contenir une liste d’enveloppes, chacune d’entre elles un blob AEAD sous une clé que l’utilisateur peut reproduire sur un autre appareil – une sortie PRF passkey, par exemple. nympq1… Le code est le seul moyen de traverser.La section 10.1 indique combien cela coûte.

L'enregistrement lui-même vit dans sa propre catégorie de paramètres, nymchat-pq-rootMême sans emballage, il fait le travail nécessaire : sa présence est la façon dont un second appareil apprend que cette identité a déjà une racine, ce qui l'empêche d'avoir une identité rivale (section 3.3).

3.3 Génération et adoption

Sur le boot, en détenant une identité durable, un client fonctionne dans cet ordre :

1. Rechercher un existant nymchat-pq-root Le record !
2. Enregistrement trouvé, et cet appareil peut le déverrouiller - l'adopter et proclamer cette identité comme post-quantum capable.
3. Enregistrement trouvé, et cet appareil ne peut pas le déverrouiller - ne générez pas de nouvelle racine, et ne publiez pas d'annonce du tout. nympq1… d’un appareil qui le possède déjà.
4. Pas de record - générer une racine, publier l'enregistrement, annoncer et montrer le nympq1… l'utilisateur une fois pour qu'il puisse le sauvegarder.

Étape 3 est l'étape qui est facile à se tromper, et c'est la raison pour laquelle l'ordre est écrit plutôt que laissé à chaque mise en œuvre. Deux appareils que chacun décide de générer une racine produisent deux racines indépendantes sous une identité, et c'est l'échec que cet ordre existe pour empêcher.

4L’annonce des capacités

La moitié publique de la paire de clés dérivée est publiée comme une adresse Général 01 événement — type 30078, marqué 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 signifie que le relais conserve un événement par (kind, pubkey, d-tag), de sorte qu'une république remplace l'annonce précédente en place. Chaque identité a donc exactement un enregistrement actuel, ce qui rend la clé d'Alice ” un seul retrait sans ambiguïté plutôt qu'une liste à concilier.

La signature est obligatoire. L'événement est signé par la clé d'identité, de sorte que la revendication “cette clé ML-KEM appartient à ce npub” est exactement aussi forte que le npub lui-même. Remplacer une clé d'encapsulation différente nécessite de forger une signature secp256k1. Un attaquant qui peut le faire n'a pas besoin de se soucier du KEM.

Les annonces expirent. Un 7ème jour PIN-40 expiration, republié toutes les 24 heures, garde le registre une déclaration sur un client qui est toujours en cours d'exécution plutôt que celle qui était auparavant.

Une annonce manquante est lue exactement comme celle qui n'a jamais porté une clé: les pairs envoient un NIP-44 ordinaire, que chaque connexion peut lire, et le client reprend l'échange post-quantum sur sa prochaine connexion, lorsqu'il republique. Donc rester silencieux pendant plus d'une semaine coûte la protection des messages envoyés pendant l'écart - ils sont classiquement cryptés plutôt que résistants aux quantiques - et ne coûte rien d'autre.

Sans une, un enregistrement survit au-delà de la clé qu’il nomme : un appareil qui est effacé, réinitialisé ou qui a sa racine remplacée laisse une instruction debout pour encapsuler une clé que personne ne détient plus, et les messages envoyés sous elle sont perdus sans erreur des deux côtés.

Le champ clé nomme son format. Le champ est pk2, et le chiffre fait partie du contrat plutôt que de la décoration: il nomme le format de charge utile avec lequel la clé peut être utilisée. Un lecteur qui ne reconnaît pas le champ conclut “Nymchat client, pas de clé post-quantum” et envoie le NIP-44 ordinaire, que chaque connexion peut lire. C'est la direction correcte de l'échec, et il vaut la peine d'affirmer comme une règle le numérotage du format existe pour faire valoir: une revendication de capacité non reconnue doit coûter la protection, jamais la livraison. Une clé qu'un paie ne peut pas utiliser est pire que aucune clé du tout, parce que le message qu'il produit est perdu sans erreur de part et d'autre.

4.1 L’absence est significative et triple

Un détail subtil mais important: l'annonce est publiée par chaque client Nymchat, pas seulement ceux capables de post-quantum, et le champ clé est facultatif.

Une annonce sans clé est une déclaration signée que l'expéditeur exécute Nymchat, ce qui permet au chemin d'envoi de sauter un emballage spéculatif de protocole croisé qu'il aurait autrement à inclure pour quiconque qu'il ne peut pas identifier.

4.2 Un appareil qui ne peut pas ouvrir la racine reste silencieux

L’annonce est remplaçable : un événement par identité, la dernière écriture gagne.C’est ce qui fait que la conception de l’enregistrement unique fonctionne, et c’est aussi ce qui rend un appareil non lié dangereux s’il publie.Un appareil qui a annoncé une clé qu’il s’était fixée pour lui-même va casser le vrai enregistrement et envoyer tous les pairs à l’encryption sous une clé que les autres appareils ne peuvent pas ouvrir.

Ainsi un appareil qui connaît une racine existe mais ne peut pas l'ouvrir ne publie aucune annonce du tout.Il n'est pas cassé et il n'est pas verrouillé de l'application: il lit toujours chaque message pour lequel il a les clés et envoie toujours de manière classique, tout en invitant l'utilisateur à le relier.

5Découverte et décision d'envoi

Les clients apprennent les clés des pairs de deux façons.Un abonnement permanent couvre les personnes avec lesquelles un utilisateur correspond réellement – conversations ouvertes et membres du groupe – de sorte que leurs annonces arrivent comme des événements ordinaires.Pour une rencontre entre pairs pour la première fois, une requête unique s’exécute à l’heure d’envoi, limitée à 2,5 secondes; si elle ne résout pas, le message devient classique, qui est le comportement qui existait avant l’ajout de post-quantum plutôt qu’un nouveau mode d’échec.

Un utilisateur qui relie un nouvel appareil, ou qui passe d'un login d'extension de navigateur à une clé locale, devient post-quantique capable de la conversation au milieu, et un permanent caché “no” les garderaient sur le cryptage classique pour la vie de l'annonce.

5.1 Pourquoi il n'y a pas d'attaque de dégradation

La décision de routage se réduit à une seule question :

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

Il n'y a pas de négociation de capacité, pas de liste d'algorithmes pris en charge, et aucun champ qu'un attaquant peut nettoyer pour forcer un chemin plus faible. est Le mode d'échec d'une annonce retirée ou retenue est que le message devient classique - le statu quo avant cette fonctionnalité - plutôt qu'un message hybride est abaissé à quelque chose de falsifiable.

L’inverse tient aussi et compte plus : un client envoie un hybride uniquement Lorsqu’il détient une clé, et qu’il détient la clé est la preuve que le destinataire peut décapsuler. Il n’y a pas d’état dans lequel un message est envoyé post-quantum à quelqu’un qui ne peut pas le lire.

6La construction hybride

Un texte de chiffrement NIP-44 non modifié est la couche intérieure, et ML-KEM clé une AEAD extérieure autour de celle-ci:

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)

Les deux secrets doivent encore être récupérés pour lire le message: la couche extérieure ne produit qu'un texte de chiffrement NIP-44, et l'ouverture qui a besoin du classique ECDH. Un adversaire quantique qui brise secp256k1 obtient la clé intérieure et fait encore face à ML-KEM; une rupture de ML-KEM arrache la couche extérieure et laisse NIP-44 debout.

• kem_ss Rien dans cette dérivation ne touche à la sortie ECDH brute, ce qui se traduit par la Section 6.1.
• kem_ct, recip_kem_pk et les deux clés d'identité sont liées en tant que données associées, de sorte que la couche externe est engagée à la transcription exacte qui l'a produite.

La clé ML-KEM du destinataire est longue, mais chaque message porte un texte de chiffrement indépendant et par conséquent un texte indépendant. kem_ssC'est ce qui fait que dériver la nonce au lieu de la randomiser sonne: ChaCha20-Poly1305 est rompu en réutilisant une paire (clé, nonce), et ici la clé elle-même est nouvelle pour chaque message, de sorte qu'aucune paire ne peut se répéter.

6.1 Pourquoi les couches restent séparées

L’alternative est de mélanger les deux secrets en une seule clé de conversation et de transmettre cela à NIP-44 :

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

Cette construction sonne comme la cryptographie. Elle a un problème structurel : elle a besoin de ecdh_x, la coordonnée brute x de la sortie ECDH, en tant que matériau clé - et une extension de navigateur (PIN-07) ou un signataire à distance (PIN-46Il exécute NIP-44 au nom de l'appelant et renvoie un texte de chiffrement, ce qui est tout le point de tenir la clé quelque part où l'application ne peut pas atteindre.

Mélanger les secrets exclut donc chaque connexion qui conserve la clé d'identité dans un signataire, c'est-à-dire les utilisateurs les plus prudents, et aucune quantité de travail sur la dérivation de la clé ne peut le changer. La couche supprime la dépendance: NIP-44 reste entier et est produit par tout ce qui détient la clé d'identité, signataire inclus, tandis que la moitié KEM est calculée à partir du code de récupération détenu directement par le client.

Le texte de chiffrement ML-KEM est de 1 088 octets et roule sur chaque message, base64url-encodé à 1 451 caractères; l'AEAD externe ajoute une balise Poly1305 de 16 octets et élargit la charge utile NIP-44 qu'il enveloppe d'un tiers. Un message de 50 caractères augmente de 176 octets à 1 712, et un message de 2 000 caractères de 2 820 à 5 238. Le sol est d'environ 1,5 KB par message indépendamment de la courteur du message, ce qui est le prix d'encapsuler à nouveau chaque fois plutôt que de réutiliser un secret partagé.

6.2 Caractéristiques des payloads

Le pq2. Le préfixe rend le déploiement incrémental : il est auto-descriptif, de sorte qu’un client choisit le chemin de déchiffrement en inspectant la charge utile plutôt que de faire confiance à une étiquette ou de se souvenir de ce qu’un peer soutient.Un lecteur qui ne reconnaît pas un préfixe ne parvient pas à ouvrir cette charge utile plutôt que de la mal lire, et les messages scellés avant l’une ou l’autre partie pourraient faire que le post-quantum reste lisible comme le NIP-44 ordinaire sans migration.

6.3 Les deux couches de l'emballage cadeau

A PIN-17 Le message privé est un PIN-59 Enveloppe cadeau: une rumeur non signée, scellée sous la clé d'identité de l'expéditeur (type 13), puis enveloppée sous une clé jetable générée par message (type 1059). Sur un login qui détient la clé d'identité directement, Nymchat hybride les deux couches, chacune avec sa propre encapsulation.

Le sceau est produit par le signataire comme NIP-44 ordinaire — l'application ne voit jamais la clé qui le fait — de sorte qu'il ne peut pas être hybridé en place. Cela ne coûte rien contre l'attaque en question: le sceau n'est accessible que par l'enveloppe, et le sceau est ce qu'un enregistreur stocke. Un adversaire qui détient le trafic enregistré doit briser le ML-KEM avant qu'un sceau ne soit même visible pour attaquer.

7Messages de groupe et couverture partielle

Un message de groupe n'est pas un texte de chiffrement. Il s'agit du même texte simple distribué à chaque membre, chaque copie encapsulée à la clé ML-KEM de ce membre. Un membre qui a publié une clé reçoit un emballage hybride; celui qui n'a pas reçu un emballage classique.

Cela crée un problème de comptabilité qu'une mise en œuvre naïve se trompe. Si huit membres sur dix reçoivent une copie hybride, le message est pas Un adversaire a besoin d'une copie classique d'un texte clair qui est identique dans tous les dix, de sorte que le message est protégé uniquement si chaque C’est une copie.

Nymchat suit donc la couverture par message pendant le fan-out – le nombre n’est connu que pendant que les enveloppes sont construites – et le badge rapporte « résistant au quantique » à 8 membres sur 10, plutôt que de prétendre que le message est protégé. reçu message de groupe (seul l'expéditeur compte le fan-out), l'interface rapporte une protection partielle plutôt que complète.

7.1 Ce que rapporte le bouclier

Le bouclier dit la vérité sur la MessageMais pas sur le logiciel qui l'a envoyé :

• Protection complète : chaque copie de ce texte simple est sortie hybride.
• Partiel : certaines copies d’un message de groupe sont sortis de manière classique.Dégradé plutôt que complet, parce qu’une copie classique d’un texte simple identique dans tous est un besoin de l’adversaire.
• Classique est déclaré directement plutôt que montré comme aucun badge, parce qu'un indicateur absent est ambigu entre “non protégé”, “brisé”, et “cette construction manque de la fonctionnalité”.

Le verdict est enregistré lorsque le message est scellé plutôt que recalculé à partir de ce qu'un peer annonce plus tard.Le texte de chiffrement qui existe déjà ne peut pas être mieux protégé qu'il ne l'était, et une interface qui redresse les anciens messages sur la force d'une nouvelle annonce affirmerait quelque chose de faux sur les bytes sur un relais.

Les règles de groupe ci-dessus s'ajoutent à cela plutôt que de le remplacer: un message de groupe n'est entièrement protégé que lorsque la copie de chaque membre a été enregistrée, et un message de groupe reçu sans comptage de couverture est partiel.

8Des copies adressées à vous-même

Plusieurs choses d’un client sont enregistrées cryptées pour l’identité de l’utilisateur : les paramètres synchronisés, la liste de conversation, les clés de groupe et l’archive des messages. Ceux-ci portent plus sur un utilisateur que la plupart des messages simples, de sorte que les laisser classiques les rendrait l’objet le plus faible stocké indépendamment de la façon dont les messages eux-mêmes ont été scellés. nymchat-pq-root catégorie elle-même, qui ne peut pas être scellée sous une clé qu'elle seule peut produire.

Un bloc de paramètres ou une rangée d'archives est assis en un seul endroit pendant des années, ce qui est exactement la forme d'une chose qu'un adversaire récolte-maintenant-déchiffré collecte - beaucoup plus que n'importe quel message unique, qui est au moins éphémère dans l'esprit de l'utilisateur.

Une contrainte régit le format ici plutôt que la clé. Une copie auto-adressée doit être lisible par chaque l'appareil sur le compte, de sorte que chaque appareil annonce ce qu'il peut ouvrir dans la liste de son annonce porte, et le compte écrit seulement ce qu'ils peuvent tous lire. écrire quoi que ce soit d'autre bloquerait un appareil hors de ses propres paramètres - le même échec silencieux Section 3.2 évite par d'autres moyens, venant d'une direction différente.

9La rotation

Le epoch Le compteur dans la dérivation est ce qui rend la rotation possible sans le nouveau matériau de clé. L'increment lui donne une nouvelle paire de clés de la même racine et une annonce republiée; les pairs prennent la nouvelle clé de l'enregistrement remplaçable. la rotation ne demande donc pas à l'utilisateur d'écrire quelque chose une seconde fois: la racine est générée une fois par identité et l'époque fait le tour.

9.1 Les anciennes époques sont conservées, et rien n’est réencrypté

Un client construit des candidats de décryptage de l'époque actuelle jusqu'à l'époque − 3, de sorte qu'un message scellé peu de temps avant une rotation s'ouvre toujours contre la paire de clés qui était actuelle lorsqu'elle a été envoyée.

Cette fenêtre est ce qui rend la rotation sûre à faire du tout: sans elle, chaque rotation pourrait gâcher tout ce qui était en vol. Tout ce qui est déjà scellé reste lisible pour la vie de l'identité, car un message que l'utilisateur ne peut plus ouvrir est strictement pire pour eux que celui dont la protection ne peut pas être améliorée rétroactivement (Section 10.5).

10Ce qui ne protège pas

Un document qui ne liste que ce qu’un design obtient ne décrit pas un système, et surestimer une propriété de sécurité dans une interface est pire que de l’omettre.

10.1 La racine est un second secret, et la perdre est irrécupérable

C'est le prix réel de la conception.La contrainte de la Section 2 selon laquelle un utilisateur devrait avoir exactement une chose à garder ne peut pas être remplie: le nsec seul ne reconstruit pas la clé post-quantum, car le point est qu'aucune valeur publique et aucun autre secret ne l'expose.Si aucun dispositif ne tient la racine et aucun des enveloppes de la Section 3.2 ne peut être ouvert, le matériau scellé à la clé dérivée de la racine n'est pas récupérable.Il n'y a pas d'escrow et il n'y a délibérément aucune autorité qui pourrait en tenir une.

Avec le transfert manuel le seul chemin, ceci est plus tranchant qu'il ne peut le lire en premier. nympq1… code n'importe où a exactement une copie de celui-ci, sur un appareil, et la perte de cet appareil perd chaque message post-quantum, les paramètres blob et la ligne d'archivage scellés à elle. nsec Cela ne sert à rien ; c’est la propriété sur laquelle repose tout le design.

Un attaquant attaque le chemin le moins cher disponible, de sorte qu'un schéma vaut ce que vaut son chemin de récupération le plus faible - une phrase mémorable, par exemple, mettrait toute la chose à ce que vaut la phrase, et la ligne enveloppée est exactement l'artefact qu'un adversaire récolte maintenant déchiffré plus tard et moule hors ligne au loisir.

10.2 Authentication, distincte de la confidentialité

Chaque signature dans Nostr est Schnorr sur secp256k1, et cela n'a pas changé ici. Un adversaire avec un ordinateur quantique pourrait forger des signatures et faire semblant d'utilisateur en temps réel. Ce que l'échange de clés hybride défait, c'est la récolte-maintenant-déchiffrement-plus tard: un attaquant enregistrant le trafic aujourd'hui ne peut pas le lire plus tard. Il ne rend pas un message impardonnable contre un adversaire qui a déjà la machine. Cette distinction est apportée dans les applications délibérément - l'indicateur padlock rapporte l'authentification, le bouclier rapporte la confidentialité, et ils sont des glyphs séparés parce qu'un message peut avoir l'un sans l'

La liaison entre un npub et une clé ML-KEM est une signature secp256k1, de sorte qu'un adversaire qui peut les forger peut remplacer une clé propre.

10.3 Les métadonnées

L’enveloppe-cadeau cache l’expéditeur, le destinataire au-delà d’un seul p Le tag, le type et le timestamp du message interne. Il ne cache pas qu'un événement existe, sa taille, ou quand un relais l'a reçu.

10.4 Le réseau hors ligne

Le transfert de réseau Bluetooth de Nymchat est un protocole distinct avec sa propre poignée de main, et il n'est pas couvert par ce travail.

10.5 Messages déjà envoyés

Le texte de chiffrement enregistré alors que les deux côtés étaient toujours classiques reste classique en permanence. Il existe déjà et ne peut pas être ré-séché. La protection commence au message où les deux côtés ont gardé les clés post-quantum, pas au moment où la fonctionnalité a été activée.

11Les alternatives envisagées

12Parité de mise en œuvre

Nymchat fournit deux implémentations indépendantes de cette construction - une en JavaScript pour l'application Web, une en Dart pour les applications mobiles, y compris un port ML-KEM-768 à partir de zéro.

La mise en œuvre de Dart ML-KEM est validée contre l'officiel Résultat ACVP Test de réponse connue pour ML-KEM-768 (ML-KEM-*-FIPS203) — 25 clés-génération, 25 encapsulations et 10 cas de décapsulations, exécutés comme leur propre suite. Ce sont les vecteurs que NIST publie pour valider une mise en œuvre, de sorte que leur transmission est la preuve que le port est correct, pas seulement la preuve que les deux clients sont d'accord l'un avec l'autre. En outre, une fixation partagée de vecteurs de test — dérivation de graines, encapsulation, les deux formats de charge utile et emballages de cadeaux complets — est générée à partir de la référence JavaScript et vérifiée par les deux suites de test. Le secret racine étend cette fixation plutôt que de la remplacer: racine à graine, racine à clé, empreinte digitale publique de la racine, et les clés dé nympq1… Une divergence dans l'une ou l'autre de la mise en œuvre échoue la construction plutôt que de produire un message que l'autre client ne peut pas ouvrir.

C’est ce qui indique à un appareil que c’est la racine que je tiens, à partir de “c’est une autre, et un client qui ne pouvait pas reproduire l’empreinte digitale d’un autre client liserait un enregistrement parfaitement bon comme aucun enregistrement du tout – et ensuite, en suivant la Section 3.3, jette une seconde racine et divise l’identité.