Cette traduction a été générée par apprentissage automatique et peut ne pas être exacte à 100%. Voir la version anglaise

NTCP 2

Proposal 111
Fermé
Author EinMByte, orignal, psi, str4d, zzz
Created 2014-02-13
Last Updated 2019-08-13
Target Version 0.9.36
Implemented In 0.9.36
Supercedes: 106

Note

La phase de proposition est close. Voir SPEC pour la spécification officielle. Cette proposition peut encore être référencée pour des informations de contexte.

Vue d’ensemble

Cette proposition décrit un protocole d’accord de clé authentifié pour améliorer la résistance de NTCP à diverses formes d’identification automatisée et d’attaques.

La proposition est organisée comme suit : les objectifs de sécurité sont présentés, suivis d’une discussion sur le protocole de base. Ensuite, une spécification complète de tous les messages de protocole est donnée. Enfin, les adresses de routeur et l’identification de version sont discutées. Un appendice discutant une attaque générique sur les schémas de remplissage courants est également inclus, ainsi qu’un appendice contenant un certain nombre de candidats pour le chiffrement authentifié.

Comme pour les autres transports I2P, NTCP2 est défini uniquement pour le transport point-à-point (routeur à routeur) des messages I2NP. Il ne s’agit pas d’un tuyau de données général.

Motivation

Les données NTCP sont chiffrées après le premier message (et le premier message apparaît comme des données aléatoires), empêchant ainsi l’identification du protocole par analyse de charge utile. Il est toujours vulnérable à l’identification du protocole par analyse de flux. C’est parce que les quatre premiers messages (c’est-à-dire la poignée de main) ont une longueur fixe (288, 304, 448 et 48 octets).

En ajoutant des quantités aléatoires de données aléatoires à chacun des messages, nous pouvons rendre cela beaucoup plus difficile.

Les auteurs reconnaissent que les pratiques de sécurité standard suggereraient d’utiliser un protocole existant tel que TLS, mais il s’agit de Prop104 et il a ses propres problèmes. Lorsqu’il est approprié, des paragraphes « travail futur » ont été ajoutés pour indiquer les fonctionnalités manquantes ou les sujets de discussion.

Objectifs de conception

  • Prendre en charge NTCP 1 et 2 sur un seul port, détection automatique et publication en tant que seul « transport » (c’est-à-dire RouterAddress) dans le NetDB .

  • Publier la prise en charge de la version 1 uniquement, 2 uniquement ou 1 + 2 dans le NetDB dans un champ séparé et par défaut la version 1 uniquement (ne pas lier la prise en charge de la version à une version de routeur particulière)

  • Assurer que toutes les implémentations (Java/i2pd/Kovri/go) puissent ajouter une prise en charge de la version 2 (ou non) selon leur propre calendrier

  • Ajouter un remplissage aléatoire à tous les messages NTCP, y compris la poignée de main et les messages de données (c’est-à-dire l’obfuscation de la longueur afin que tous les messages ne soient pas un multiple de 16 octets) Fournir un mécanisme d’options pour que les deux parties puissent demander un minimum et un maximum de remplissage et/ou une distribution de remplissage. Les détails de la distribution de remplissage sont dépendants de l’implémentation et peuvent ou non être spécifiés dans le protocole lui-même.

  • Obfusquer le contenu des messages qui ne sont pas chiffrés (1 et 2), suffisamment pour que les boîtes DPI et les signatures AV ne puissent pas facilement les classer. Assurez-vous également que les messages envoyés à un seul pair ou ensemble de pairs n’ont pas un motif de bits similaire.

  • Corrigez la perte de bits dans DH en raison du format Java Ticket1112 , éventuellement (probablement ?) en passant à X25519.

  • Passer à une fonction de dérivation de clé réelle (KDF) plutôt que d’utiliser le résultat DH tel quel ?

  • Ajouter une « résistance aux sondages » (comme Tor l’appelle) ; cela inclut la résistance aux répétitions.

  • Maintenir un échange de clé authentifié à deux voies (2W-AKE). 1W-AKE n’est pas suffisant pour notre application.

  • Continuer à utiliser les signatures de type variable, de longueur variable (à partir de la clé de signature de RouterIdentity publiée) comme partie de l’authentification. Comptez sur une clé publique statique publiée dans le RouterInfo comme autre partie de l’authentification.

  • Ajouter des options/version dans la poignée de main pour une extensibilité future.

  • Ajouter une résistance aux segmentations TCP malveillantes si possible.

  • N’ajoutez pas significativement au CPU requis pour la configuration de la connexion ; si possible, réduisez-le considérablement.

  • Ajouter une authentification de message (MAC), éventuellement HMAC-SHA256 et Poly1305, et supprimer le checksum Adler.

  • Raccourcir et simplifier l’en-tête I2NP : Raccourcir l’expiration à 4 octets, comme dans SSU. Supprimer le checksum SHA256 tronqué d’un octet.

  • Si possible, réduisez la poignée de main à 4 messages, deux allers-retours, à une poignée de main à 3 messages, un aller-retour, comme dans SSU . Cela nécessiterait de déplacer la signature de Bob dans le message 4 au message 2. Recherchez la raison des 4 messages dans les archives de courriels, de statut et de réunions de dix ans.

  • Minimiser la surcharge du protocole avant le remplissage. Même si un remplissage est ajouté, et éventuellement beaucoup, la surcharge avant le remplissage est toujours une surcharge. Les nœuds à faible bande passante doivent pouvoir utiliser NTCP2.

  • Maintenir les horodatages pour la détection de répétition et de décalage.

  • Éviter tout problème d’année 2038 dans les horodatages, cela doit fonctionner jusqu’à au moins 2106.

  • Augmenter la taille maximale du message de 16 K à 32 K ou 64 K.

  • Toute nouvelle primitive cryptographique doit être facilement disponible dans les bibliothèques pour une utilisation dans les implémentations de routeur Java (1.7), C++ et Go.

  • Inclure des représentants des développeurs de routeurs Java, C++ et Go dans la conception.

  • Minimiser les changements (mais il y en aura encore beaucoup).

  • Prendre en charge les deux versions dans un ensemble de code commun (ce qui peut ne pas être possible et est dépendant de l’implémentation dans tous les cas).

Non-Objectifs

  • Résistance à la DPI à l’épreuve des balles… ce serait des transports pluggables, Prop109 .

  • Un transport basé sur TLS (ou similaire à HTTPS)… ce serait Prop104 .

  • Il est OK de changer le cryptage symétrique du flux.

  • Résistance à la DPI basée sur le temps (le temps d’inter-message/délais peut être dépendant de l’implémentation ; les délais intra-message peuvent être introduits à tout moment, y compris avant l’envoi du remplissage aléatoire, par exemple). Les délais artificiels (ce que obfs4 appelle IAT ou temps d’arrivée inter) sont indépendants du protocole lui-même.

  • Déniabilité de participation à une session (il y a des signatures dedans).

Non-objectifs qui peuvent être partiellement réexaminés ou discutés :

  • Le degré de protection contre l’inspection approfondie des paquets (DPI)

  • Sécurité post-quantique (PQ)

  • Déniabilité

Objectifs liés

  • Mettre en œuvre un ensemble de test NTCP 1/2

Objectifs de sécurité

Nous considérons trois parties :

  • Alice, qui souhaite établir une nouvelle session.
  • Bob, avec qui Alice souhaite établir une session.
  • Mallory, l’« homme du milieu » entre Alice et Bob.

Au plus deux participants peuvent s’engager dans des attaques actives.

Alice et Bob sont tous deux en possession d’une paire de clés statiques, qui est contenue dans leur RouterIdentity.

Le protocole proposé tente d’autoriser Alice et Bob à convenir d’une clé secrète partagée (K) dans les conditions suivantes :

  1. Sécurité de la clé privée : ni Bob ni Mallory n’apprennent rien sur la clé privée statique d’Alice. Symétriquement, Alice n’apprend rien sur la clé privée statique de Bob.

  2. La clé de session K est connue uniquement par Alice et Bob.

  3. Confidentialité parfaite : la clé de session convenue reste secrète dans le futur, même lorsque les clés privées statiques d’Alice et/ou Bob sont révélées après que la clé ait été convenue.

  4. Authentification à deux voies : Alice est certaine qu’elle a établi une session avec Bob, et vice versa.

  5. Protection contre l’inspection approfondie des paquets en ligne : assurez qu’il n’est pas trivial de détecter qu’Alice et Bob sont engagés dans le protocole en utilisant uniquement des techniques d’inspection approfondie des paquets (DPI) simples. Voir ci-dessous.

  6. Déniabilité limitée : ni Alice ni Bob ne peuvent nier leur participation au protocole, mais si l’un d’eux divulgue la clé partagée, l’autre partie peut nier l’authenticité du contenu des données transmises.

La présente proposition tente de fournir les cinq exigences sur la base du protocole Station-To-Station (STS). Notez que ce protocole est également la base du protocole SSU .

Discussion supplémentaire sur DPI

Nous supposons deux composants DPI :

1) DPI en ligne

DPI en ligne inspectant tous les flux en temps réel. Les connexions peuvent être bloquées ou autrement altérées. Les données de connexion ou les métadonnées peuvent être identifiées et stockées pour une analyse hors ligne. L’DPI en ligne n’a pas accès à la base de données du réseau I2P. L’DPI en ligne a une capacité de calcul en temps réel limitée, y compris le calcul de longueur, l’inspection de champ et les calculs simples tels que XOR. L’DPI en ligne a la capacité de fonctions cryptographiques en temps réel rapides telles que AES, AEAD et hachage, mais celles-ci seraient trop coûteuses pour être appliquées à la plupart ou à tous les flux. Toute application de ces fonctions cryptographiques ne s’appliquerait qu’aux flux sur les combinaisons IP/Port précédemment identifiées par l’analyse hors ligne. L’DPI en ligne n’a pas la capacité de fonctions cryptographiques à forte surcharge telles que DH ou elligator2. L’DPI en ligne n’est pas conçu spécifiquement pour détecter I2P, bien qu’il puisse avoir des règles de classification limitées à cette fin.

Il est un objectif d’empêcher l’identification du protocole par un DPI en ligne.

La notion de DPI en ligne ou « droit » est prise ici pour inclure les capacités d’adversaire suivantes :

  1. La capacité d’inspecter toutes les données envoyées ou reçues par la cible.

  2. La capacité de réaliser des opérations sur les données observées, telles que l’application de chiffrement par bloc ou de fonctions de hachage.

  3. La capacité de stocker et de comparer avec des messages précédemment envoyés.

  4. La capacité de modifier, de retarder ou de fragmenter les paquets.

Cependant, le DPI en ligne est supposé avoir les restrictions suivantes :

  1. L’incapacité de mapper les adresses IP aux hachages de routeur. Même si cela est trivial avec un accès en temps réel à la base de données du réseau, il nécessiterait un système DPI spécifiquement conçu pour cibler I2P.

  2. L’incapacité d’utiliser les informations de temporisation pour détecter le protocole.

  3. En général, la boîte à outils DPI ne contient aucun outil intégré spécifiquement conçu pour la détection I2P. Cela inclut la création de « pièges à miel », qui incluraient par exemple un remplissage non aléatoire dans leurs messages. Notez que cela n’exclut pas les systèmes d’apprentissage automatique ou les outils DPI hautement configurables, tant qu’ils répondent aux autres exigences.

Pour contrer l’analyse de charge utile, il est garanti que tous les messages sont indiscernables d’une manière aléatoire. Cela nécessite également que leur longueur soit aléatoire, ce qui est plus compliqué que d’ajouter simplement un remplissage aléatoire. En fait, dans l’Appendice A, les auteurs soutiennent qu’un schéma de remplissage uniforme (naïf) ne résout pas le problème. L’Appendice A propose donc d’inclure soit des retards aléatoires, soit de développer un schéma de remplissage alternatif qui peut fournir une protection raisonnable contre l’attaque proposée.

Pour se protéger contre la sixième entrée ci-dessus, les implémentations doivent inclure des retards aléatoires dans le protocole. De telles techniques ne sont pas couvertes par cette proposition, mais elles pourraient également résoudre les problèmes de longueur de remplissage. En résumé, la proposition fournit une bonne protection contre l’analyse de charge utile (lorsque les considérations de l’Appendice A sont prises en compte), mais seulement une protection limitée contre l’analyse de flux.

2) DPI hors ligne

DPI hors ligne inspectant les données stockées par le DPI en ligne pour une analyse ultérieure. Le DPI hors ligne peut être conçu spécifiquement pour détecter I2P. Le DPI hors ligne a un accès en temps réel à la base de données du réseau I2P. Le DPI hors ligne a un accès à cette spécification I2P et à d’autres spécifications. Le DPI hors ligne a une capacité de calcul illimitée, y compris toutes les fonctions cryptographiques définies dans cette spécification.

Le DPI hors ligne n’a pas la capacité de bloquer les connexions existantes. Le DPI hors ligne a la capacité d’envoyer des données à l’hôte/port des parties, par exemple TCP RST, dans un délai de quelques minutes après la configuration. Le DPI hors ligne a la capacité de rejouer des messages précédents (modifiés ou non) pour « sonder » ou d’autres raisons.

Il n’est pas un objectif d’empêcher l’identification du protocole par un DPI hors ligne. Toute décoding de données obfusquées dans les deux premiers messages, qui est mise en œuvre par les routeurs I2P, peut également être mise en œuvre par le DPI hors ligne.

Il est un objectif de rejeter les tentatives de connexion en utilisant le replay de messages précédents.

Travail futur

  • Examiner le comportement du protocole lorsque les paquets sont supprimés ou réorganisés par un attaquant. Des travaux intéressants récents dans ce domaine peuvent être trouvés dans IACR-1150 .

  • Fournir une classification plus précise des systèmes DPI, en tenant compte de la littérature existante liée au sujet.

  • Discuter de la sécurité formelle du protocole proposé, idéalement en tenant compte du modèle d’attaquant DPI.

Cadre de protocole Noise

Cette proposition fournit les exigences basées sur le cadre de protocole Noise NOISE (Révision 33, 2017-10-04). Noise a des propriétés similaires au protocole Station-To-Station, qui est la base du protocole SSU . Dans le jargon Noise, Alice est l’initiateur, et Bob est le répondant.

NTCP2 est basé sur le protocole Noise Noise_XK_25519_ChaChaPoly_SHA256. (L’identifiant réel de la fonction de dérivation de clé initiale est « Noise_XKaesobfse+hs2+hs3_25519_ChaChaPoly_SHA256 » pour indiquer les extensions I2P - voir section KDF 1 ci-dessous) Ce protocole Noise utilise les primitives suivantes :

  • Modèle de poignée de main : XK Alice transmet sa clé à Bob (X) Alice connaît déjà la clé statique de Bob (K)

  • Fonction DH : X25519 X25519 DH avec une longueur de clé de 32 octets comme spécifié dans RFC-7748 .

  • Fonction de chiffrement : ChaChaPoly AEAD_CHACHA20_POLY1305 comme spécifié dans RFC-7539 section 2.8. 12 octets de nonce, avec les 4 premiers octets définis sur zéro.

  • Fonction de hachage : SHA256 Hachage standard de 32 octets, déjà utilisé de manière extensive dans I2P.

Ajouts au cadre

Cette proposition définit les améliorations suivantes du protocole Noise_XK_25519_ChaChaPoly_SHA256. Ces améliorations suivent généralement les directives de NOISE section 13.

  1. Les clés éphémères en clair sont obfusquées avec un chiffrement AES à l’aide d’une clé et d’un IV connus. Cela est plus rapide que elligator2.

  2. Un remplissage aléatoire en clair est ajouté aux messages 1 et 2. Le remplissage en clair est inclus dans le calcul du hachage de poignée de main (MixHash) calcul. Voir les sections KDF pour le message 2 et le message 3 partie 1. Un remplissage aléatoire AEAD est ajouté au message 3 et aux messages de phase de données.

  3. Un champ de longueur de cadre de deux octets est ajouté, comme requis pour Noise sur TCP, et comme dans obfs4. Cela est utilisé dans les messages de phase de données uniquement. Les cadres AEAD des messages 1 et 2 sont de longueur fixe. Le cadre AEAD du message 3 partie 1 est de longueur fixe. La longueur du cadre AEAD du message 3 partie 2 est spécifiée dans le message 1.

  4. Le champ de longueur de deux octets est obfusqué avec SipHash-2-4, comme dans obfs4.

  5. Le format de charge utile est défini pour les messages 1, 2, 3 et la phase de données. Bien sûr, cela n’est pas défini dans Noise.

Nouvelles primitives cryptographiques pour I2P

Les implémentations de routeur I2P existantes nécessiteront des implémentations pour les primitives cryptographiques standard suivantes, qui ne sont pas requises pour les protocoles I2P actuels :

  1. Génération de clé et DH X25519

  2. AEAD_ChaCha20_Poly1305 (abrégé en ChaChaPoly ci-dessous)

  3. SipHash-2-4

Estimation de la surcharge de traitement

Les tailles de message pour les 3 messages :

  1. 64 octets + remplissage (NTCP était 288 octets)
  2. 64 octets + remplissage (NTCP était 304 octets)
  3. environ 64 octets + info du routeur d’Alice + remplissage Moyenne info du routeur est d’environ 750 octets Total moyen 814 octets avant remplissage (NTCP était 448 octets)
  4. non requis dans NTCP2 (NTCP était 48 octets)

Total avant remplissage : NTCP2 : 942 octets NTCP : 1088 octets Remarque : si Alice se connecte à Bob pour envoyer un message DatabaseStore de son RouterInfo, ce message n’est pas requis, ce qui économise environ 800 octets.

Les opérations cryptographiques suivantes sont nécessaires à chaque partie pour compléter la poignée de main et commencer la phase de données :

  • AES : 2
  • SHA256 : 7 (Alice), 6 (Bob) (hors 1 Alice, 2 Bob précalculés pour toutes les connexions) (hors HMAC-SHA256)
  • HMAC-SHA256 : 19
  • ChaChaPoly : 4
  • Génération de clé X25519 : 1
  • DH X25519 : 3
  • Vérification de signature : 1 (Bob) (Alice a déjà signé lors de la génération de son RI) Présumé Ed25519 (dépendant du type de signature RI)

Les opérations cryptographiques suivantes sont nécessaires à chaque partie pour chaque message de phase de données :

  • SipHash : 1
  • ChaChaPoly : 1

Messages

Tous les messages NTCP2 sont inférieurs ou égaux à 65537 octets de longueur. Le format de message est basé sur les messages Noise, avec des modifications pour le encadrement et l’indiscernabilité. Les implémentations utilisant des bibliothèques Noise standard peuvent avoir besoin de prétraiter les messages reçus à partir/depuis le format de message Noise. Tous les champs chiffrés sont des ciphertexts AEAD.

La séquence d’établissement est la suivante :

Alice                           Bob

SessionRequest ------------------->
<------------------- SessionCreated
SessionConfirmed ----------------->

En utilisant la terminologie Noise, la séquence d’établissement et de données est la suivante : (Propriétés de sécurité de charge utile)

XK(s, rs) :           Authentification   Confidentialité
    <- s
    ...
    -> e, es                  0                2
    <- e, ee                  2                1
    -> s, se                  2                5
    <-                        2                5

Une fois qu’une session a été établie, Alice et Bob peuvent échanger des messages de données.

Tous les types de messages (SessionRequest, SessionCreated, SessionConfirmed, Data et TimeSync) sont spécifiés dans cette section.

Quelques notations :

  • RH_A = Hachage de routeur pour Alice (32 octets)
  • RH_B = Hachage de routeur pour Bob (32 octets)

Chiffrement authentifié

Il existe trois instances d’authentification de chiffrement distinctes (CipherStates). Une pendant la phase de poignée de main, et deux (transmettre et recevoir) pour la phase de données. Chacune a sa propre clé à partir d’une KDF.

Les données chiffrées/authentifiées seront représentées comme

+----+----+----+----+----+----+----+----+
|                                       |
+                                       +
|   Données chiffrées et authentifiées  |
~               .   .   .               ~
|                                       |
+----+----+----+----+----+----+----+----+

ChaCha20/Poly1305

Format de données chiffrées et authentifiées.

Entrées des fonctions de chiffrement/déchiffrement :

k :: 32 octets de clé de chiffrement, comme générée à partir de KDF

nonce :: Compteur de nonce, 12 octets.
         Démarre à 0 et incrémenté pour chaque message.
         Les 4 premiers octets sont toujours zéro.
         Les 8 derniers octets sont le compteur, codés little-endian.
         Valeur maximale est 2**64 - 2.
         La valeur 2**64 - 1 ne doit jamais être envoyée.

ad :: Dans la phase de poignée de main :
        Données associées, 32 octets.
        Le hachage SHA256 de toutes les données précédentes.
        Dans la phase de données :
        Octets zéro

data :: Données en clair, 0 ou plusieurs octets

Sortie de la fonction de chiffrement, entrée de la fonction de déchiffrement :

+----+----+----+----+----+----+----+----+
|Obfs Len |                             |
+----+----+                             +
|       ChaCha20 encrypted data         |
~               .   .   .               ~
|                                       |
+----+----+----+----+----+----+----+----+
|  Poly1305 Message Authentication Code |
+              (MAC)                    +
|             16 octets                  |
+----+----+----+----+----+----+----+----+

Obfs Len :: Longueur de (données chiffrées + MAC) à suivre, 16 - 65535
             Obfuscation à l'aide de SipHash (voir ci-dessous)
             Non utilisé dans le message 1 ou 2, ou le message 3 partie 1, où la longueur est fixe
             Non utilisé dans le message 3 partie 1, car la longueur est spécifiée dans le message 1

encrypted data :: Même taille que les données en clair, 0 - 65519 octets

MAC :: Code d'authentification de message Poly1305, 16 octets

Pour ChaCha20, ce qui est décrit ici correspond à RFC-7539 , qui est également utilisé de manière similaire dans TLS RFC-7905 .

Notes

  • Puisque ChaCha20 est un chiffrement à flux, les données en clair n’ont pas besoin d’être remplies. Des octets de flux supplémentaires sont supprimés.

  • La clé pour le chiffrement (256 bits) est convenue par le biais de la KDF SHA256. Les détails de la KDF pour chaque message sont dans des sections séparées ci-dessous.

  • Les cadres ChaChaPoly pour les messages 1, 2 et la première partie du message 3, sont de taille connue. À partir de la deuxième partie du message 3, les cadres sont de taille variable. La taille du message 3 partie 1 est spécifiée dans le message 1. À partir de la phase de données, les cadres sont préfixés avec une longueur de deux octets obfusquée avec SipHash comme dans obfs4.

  • Le remplissage est à l’extérieur du cadre de données authentifiées pour les messages 1 et 2. Le remplissage est utilisé dans la KDF pour le prochain message, donc toute altération sera détectée. À partir du message 3, le remplissage est à l’intérieur du cadre de données authentifiées.

Gestion d’erreur AEAD

  • Dans les messages 1, 2 et le message 3 parties 1 et 2, la taille du message AEAD est connue à l’avance. En cas d’échec d’authentification AEAD, le destinataire doit arrêter tout traitement de message ultérieur et fermer la connexion sans répondre. Cela devrait être une fermeture anormale (TCP RST).

  • Pour la résistance aux sondages, dans le message 1, après un échec AEAD, Bob devrait définir un délai aléatoire (plage TBD) et puis lire un nombre aléatoire d’octets (plage TBD) avant de fermer la socket. Bob devrait maintenir une liste noire d’IP avec échecs répétés.

  • Dans la phase de données, la taille du message AEAD est « chiffrée » (obfusquée) avec SipHash. Il faut prendre soin d’éviter de créer un oracle de déchiffrement. En cas d’échec d’authentification AEAD dans la phase de données, le destinataire devrait définir un délai aléatoire (plage TBD) et puis lire un nombre aléatoire d’octets (plage TBD). Après la lecture, ou à l’expiration du délai de lecture, le destinataire devrait envoyer une charge utile avec un bloc de terminaison contenant un code de raison « échec AEAD », et fermer la connexion.

  • Prendre la même action d’erreur pour une valeur de champ de longueur non valide dans la phase de données.

Fonction de dérivation de clé (KDF) (pour le message de poignée de main 1)

La KDF génère une clé de chiffrement de phase de poignée de main k à partir du résultat DH, en utilisant HMAC-SHA256(clé, données) comme défini dans RFC-2104 . Ce sont les fonctions InitializeSymmetric(), MixHash() et MixKey(), exactement comme défini dans la spécification Noise.

Ceci est le modèle de message « e » :

// Définir le nom du protocole.
Définir le nom du protocole = « Noise_XKaesobfse+hs2+hs3_25519_ChaChaPoly_SHA256 »
(48 octets, codage US-ASCII, sans terminaison NULL).

// Définir Hash h = 32 octets
h = SHA256(nom du protocole) ;

Définir ck = 32 octets de clé de chaînage. Copiez les données h dans ck.
Définir ck = h

Définir rs = 32 octets de clé statique de Bob comme publiée dans le RouterInfo

// MixHash(prologue null)
h = SHA256(h) ;

// jusqu'ici, tout peut être précalculé par Alice pour toutes les connexions sortantes

// Bob doit valider que la clé éphémère de Bob est un point valide sur la courbe ici.

// Clé statique de Bob
// MixHash(rs)
// || ci-dessous signifie append
h = SHA256(h || rs) ;

// jusqu'ici, tout peut être précalculé par Bob pour toutes les connexions entrantes

Ceci est le modèle de message « e » :

Alice génère une nouvelle paire de clés éphémères et stocke-la dans la variable e.

// Clé publique éphémère d'Alice X
// MixHash(e.pubkey)
// || ci-dessous signifie append
h = SHA256(h || e.pubkey) ;

// h est utilisé comme données associées pour l'AEAD dans le message 1
// Conserver le hachage h pour la KDF du message 2


Fin du modèle de message « e ».

Ceci est le modèle de message « es » :

// DH(e, rs) == DH(s, re)
Définir le matériel d'entrée = 32 octets de résultat DH de la clé éphémère d'Alice et de la clé statique de Bob
Définir le matériel d'entrée = résultat DH X25519

// MixKey(DH())

Définir temp_key = 32 octets
Définir HMAC-SHA256(clé, données) comme dans [RFC-2104](https://tools.ietf.org/html/rfc2104)
// Générer une clé temporaire à partir de la clé de chaînage et du résultat DH
// ck est la clé de chaînage, définie ci-dessus
temp_key = HMAC-SHA256(ck, matériel d'entrée)
// écraser le résultat DH en mémoire, plus nécessaire
matériel d'entrée = (tous zéros)

// Sortie 1
// Définir une nouvelle clé de chaînage à partir de la clé temporaire
// byte() ci-dessous signifie un seul octet
ck = HMAC-SHA256(temp_key, byte(0x01)).

// Sortie 2
// Générer la clé de chiffrement k
Définir k = 32 octets
// || ci-dessous signifie append
// byte() ci-dessous signifie un seul octet
k = HMAC-SHA256(temp_key, ck || byte(0x02)).
// écraser la clé temporaire en mémoire, plus nécessaire
temp_key = (tous zéros)

// conserver la clé de chaînage ck pour la KDF du message 2


Fin du modèle de message « es ».

1) SessionRequest

Alice envoie à Bob.

Contenu Noise : Clé éphémère d’Alice X Charge utile Noise : Bloc d’options de 16 octets Charge utile non Noise : Remplissage aléatoire

(Propriétés de sécurité de charge utile)

XK(s, rs) :           Authentification   Confidentialité
    -> e, es                  0                2

Authentification : 0.
Cette charge utile peut avoir été envoyée par n'importe quelle partie, y compris un attaquant actif.

Confidentialité : 2.
Chiffrement vers un destinataire connu, confidentialité parfaite pour la compromission du côté de l'expéditeur uniquement, vulnérable à la répétition. Cette charge utile est chiffrée uniquement sur la base de DH impliquant la paire de clés statiques du destinataire. Si la clé privée statique du destinataire est compromise, même à une date ultérieure, cette charge utile peut être déchiffrée. Cette charge utile peut également être répétée, puisqu'il n'y a pas de contribution éphémère du destinataire.

« e » : Alice génère une nouvelle paire de clés éphémères et stocke-la dans la variable e, écrit la clé publique éphémère en clair dans le tampon de message et hache la clé publique avec l'ancien h pour dériver un nouveau h.

« es » : Un DH est effectué entre la paire de clés éphémères d'Alice et la paire de clés statiques de Bob. Le résultat est haché avec l'ancienne ck pour dériver une nouvelle ck et k, et n est défini sur zéro.

La valeur X est chiffrée pour assurer l’indiscernabilité de la charge utile et l’unicité, qui sont des contre-mesures DPI nécessaires. Nous utilisons le chiffrement AES pour atteindre cet objectif, plutôt que des alternatives plus complexes et plus lentes telles que elligator2. Le chiffrement asymétrique vers la clé publique du routeur de Bob serait beaucoup trop lent. Le chiffrement AES utilise le hachage de routeur de Bob comme clé et l’IV de Bob comme publié dans la base de données du réseau.

Le chiffrement AES est utilisé uniquement pour la résistance DPI. Toute partie connaissant le hachage de routeur de Bob et l’IV, qui sont publiés dans la base de données du réseau, peut déchiffrer la valeur X dans ce message.

Contenu brut :

+----+----+----+----+----+----+----+----+
|                                       |
+        obfuscated with RH_B           +
|       AES-CBC-256 encrypted X         |
+             (32 octets)               +
|                                       |
+                                       +
|                                       |
+----+----+----+----+----+----+----+----+
|   ChaChaPoly frame                    |
+   Encrypted and authenticated data    +
|   32 octets                            |
+   k defined in KDF for message 1      +
|   n = 0; see KDF for associated data  |
+                                       +
|                                       |
+----+----+----+----+----+----+----+----+
|     unencrypted authenticated         |
+         padding (optional)            +
|     length defined in options block   |
~               .   .   .               ~
|                                       |
+----+----+----+----+----+----+----+----+

X :: 32 octets, clé éphémère X25519 chiffrée avec AES-256, little-endian
        clé : RH_B
        iv : Comme publié dans l'entrée de base de données de Bob

padding :: Données aléatoires, 0 ou plusieurs octets.
           La longueur totale du message doit être de 65535 octets ou moins.
           La longueur totale du message doit être de 287 octets ou moins si
           Bob publie son adresse comme « NTCP » (voir section Détection de version ci-dessous).
           Alice et Bob utiliseront les données de remplissage dans la KDF pour le message 2.
           Il est authentifié afin que toute altération entraînera l'échec du prochain message.

Données non chiffrées (tag d’authentification Poly1305 non affiché) :

+----+----+----+----+----+----+----+----+
|                                       |
+                                       +
|                   X                   |
+              (32 octets)               +
|                                       |
+                                       +
|                                       |
+----+----+----+----+----+----+----+----+
|               options                 |
+              (16 octets)               +
|                                       |
+----+----+----+----+----+----+----+----+
|     unencrypted authenticated         |
+         padding (optional)            +
|     length defined in options block   |
~               .   .   .               ~
|                                       |
+----+----+----+----+----+----+----+----+

X :: 32 octets, clé éphémère X25519, little-endian

options :: Bloc d'options, 16 octets, voir ci-dessous

padding :: Données aléatoires, 0 ou plusieurs octets.
           La longueur totale du message doit être de 65535 octets ou moins.
           La longueur totale du message doit être de 287 octets ou moins si
           Bob publie son adresse comme « NTCP » (voir section Détection de version ci-dessous)
           Alice et Bob utiliseront les données de remplissage dans la KDF pour le message 2.
           Il est authentifié afin que toute altération entraînera l'échec du prochain message.

Bloc d’options : Remarque : Tous les champs sont big-endian.

+----+----+----+----+----+----+----+----+
| id | ver|  padLen | m3p2len | Rsvd(0) |
+----+----+----+----+----+----+----+----+
|        tsA        |   Reserved (0)    |
+----+----+----+----+----+----+----+----+

id :: 1 octet, l'ID du réseau (actuellement 2, sauf pour les réseaux de test)
      Comme dans la proposition 147.

ver :: 1 octet, version du protocole (actuellement 2)

padLen :: 2 octets, longueur du remplissage, 0 ou plusieurs
          Directives minimales/maximales TBD. Taille de remplissage aléatoire de 0 à 31 octets minimum ?
          (Distribution à déterminer, voir Appendice A.)

m3p2Len :: 2 octets, longueur du deuxième cadre AEAD dans le message SessionConfirmed
           (message 3 partie 2) Voir notes ci-dessous

Rsvd :: 2 octets, défini sur 0 pour la compatibilité avec les options futures

tsA :: 4 octets, horodatage Unix, secondes non signées.
       Débordement en 2106

Reserved :: 4 octets, défini sur 0 pour la compatibilité avec les options futures

Notes

  • Lorsque l’adresse publiée est « NTCP », Bob prend en charge les protocoles NTCP et NTCP2 sur le même port. Pour la compatibilité, lorsque l’initiation d’une connexion à une adresse publiée comme « NTCP », Alice doit limiter la taille maximale de ce message, y compris le remplissage, à 287 octets ou moins. Cela facilite la détection automatique du protocole par Bob. Lorsqu’il est publié comme « NTCP2 », il n’y a pas de restriction de taille. Voir les sections Adresses publiées et Détection de version ci-dessous.

  • La valeur X unique dans le bloc AES initial garantit que le texte chiffré est différent pour chaque session.

  • Bob doit rejeter les connexions où la valeur d’horodatage est trop éloignée de l’heure actuelle. Appelez la différence d’horodatage maximale « D ». Bob doit maintenir une cache locale de valeurs de poignée de main précédemment utilisées et rejeter les doublons, pour empêcher les attaques de répétition. Les valeurs de la cache sont dépendantes de l’implémentation, cependant, la valeur X de 32 octets (ou son équivalent chiffré) peut être utilisée.

  • Les clés éphémères Diffie-Hellman ne peuvent jamais être réutilisées, pour empêcher les attaques cryptographiques, et la réutilisation sera rejetée comme une attaque de répétition.

  • Le « KE » et les options « auth » doivent être compatibles, c’est-à-dire que la clé secrète partagée K doit être de la taille appropriée. Si d’autres options « auth » sont ajoutées, cela pourrait implicitement changer le sens du drapeau « KE » pour utiliser une KDF différente ou une taille de troncature différente.

  • Bob doit valider que la clé éphémère d’Alice est un point valide sur la courbe ici.

  • Le remplissage doit être limité à une quantité raisonnable. Bob peut rejeter les connexions avec un remplissage excessif. Bob spécifiera ses options de remplissage dans le message 2. Directives minimales/maximales TBD. Taille de remplissage aléatoire de 0 à 31 octets minimum ? (Distribution à déterminer, voir Appendice A.)

  • En cas d’erreur, y compris AEAD, DH, horodatage, répétition apparente ou échec de validation de clé, Bob doit arrêter tout traitement de message ultérieur et fermer la connexion sans répondre. Cela devrait être une fermeture anormale (TCP RST). Pour la résistance aux sondages, après un échec AEAD, Bob devrait définir un délai aléatoire (plage TBD) et puis lire un nombre aléatoire d’octets (plage TBD), avant de fermer la socket.

  • Mitigation DoS : le DH est une opération relativement coûteuse. Comme pour le protocole NTCP précédent, les routeurs doivent prendre toutes les mesures nécessaires pour empêcher l’épuisement du CPU ou des connexions. Mettez des limites sur le nombre maximum de connexions actives et le nombre maximum de configurations de connexion en cours. Faites respecter les délais de lecture (à la fois par lecture et total pour « slowloris »). Limitez les connexions répétées ou simultanées à partir de la même source. Maintenez des listes noires pour les sources qui échouent à plusieurs reprises. N’essayez pas de répondre à un échec AEAD.

  • Pour faciliter une détection et une poignée de main rapides, les implémentations doivent s’assurer qu’Alice met en tampon et puis purge tout le contenu du premier message à la fois, y compris le remplissage. Cela augmente la probabilité que les données seront contenues dans un seul paquet TCP (sauf si segmenté par le système d’exploitation ou les middleboxes), et reçues toutes en une fois par Bob. C’est également pour l’efficacité et pour garantir l’efficacité du remplissage aléatoire.

  • « ver » champ : Le protocole Noise global, les extensions et le protocole NTCP, y compris les spécifications de charge utile, indiquant NTCP2. Ce champ peut être utilisé pour indiquer la prise en charge des changements futurs.

  • Longueur du message 3 partie 2 : Ceci est la taille du deuxième cadre AEAD (y compris la MAC de 16 octets) qui contiendra les informations du routeur d’Alice et le remplissage facultatif qui seront envoyés dans le message SessionConfirmed. Comme les routeurs régénèrent et republlient périodiquement leurs informations de routeur, la taille des informations de routeur actuelles peut changer avant l’envoi du message 3. Les implémentations doivent choisir l’une des deux stratégies : a) Enregistrer les informations de routeur actuelles à envoyer dans le message 3, afin que la taille soit connue, et ajouter éventuellement de l’espace pour le remplissage ; b) Augmenter la taille spécifiée suffisamment pour permettre une augmentation possible de la taille des informations de routeur, et ajouter toujours du remplissage lorsque le message 3 est réellement envoyé. Dans les deux cas, la longueur « m3p2len » incluse dans le message 1 doit être exactement la taille de ce cadre lorsqu’il est envoyé dans le message 3.

  • Bob doit échouer la connexion si des données entrantes restent après validation du message 1 et lecture du remplissage. Il ne devrait pas y avoir de données supplémentaires d’Alice, car Bob n’a pas encore répondu avec le message 2.

  • Le champ d’ID de réseau est utilisé pour identifier rapidement les connexions entre réseaux. Si ce champ est différent de zéro et ne correspond pas à l’ID de réseau de Bob, Bob devrait se déconnecter et bloquer les connexions futures. Comme dans la proposition 147 pour plus d’informations.

Fonction de dérivation de clé (KDF) (pour le message de poignée de main 2 et le message 3 partie 1)


// prendre h sauvegardé à partir de la KDF du message 1
// MixHash(ciphertext)
h = SHA256(h || 32 octets de charge utile chiffrée du message 1)

// MixHash(padding)
// Seulement si la longueur de remplissage est non nulle
h = SHA256(h || remplissage aléatoire du message 1)
// h est utilisé comme données associées pour l'AEAD dans le message 2
// Conserver le hachage h pour la KDF du message 3

Ceci est le modèle de message « e » :

Bob génère une nouvelle paire de clés éphémères et stocke-la dans la variable e.

// h est de la KDF pour le message de poignée de main 1
// Clé publique éphémère de Bob Y
// MixHash(e.pubkey)
// || ci-dessous signifie append
h = SHA256(h || e.pubkey) ;

// h est utilisé comme données associées pour l'AEAD dans le message 2
// Conserver le hachage h pour la KDF du message 3

Fin du modèle de message « e ».

Ceci est le modèle de message « ee » :

// DH(e, re)
Définir le matériel d'entrée = 32 octets de résultat DH de la clé éphémère d'Alice et de la clé éphémère de Bob
Définir le matériel d'entrée = résultat DH X25519
// écraser la clé éphémère d'Alice en mémoire, plus nécessaire
// Alice :
e(public et privé) = (tous zéros)
// Bob :
re = (tous zéros)

// MixKey(DH())

Définir temp_key = 32 octets
Définir HMAC-SHA256(clé, données) comme dans [RFC-2104](https://tools.ietf.org/html/rfc2104)
// Générer une clé temporaire à partir de la clé de chaînage et du résultat DH
// ck est la clé de chaînage, de la KDF pour le message de poignée de main 1
temp_key = HMAC-SHA256(ck, matériel d'entrée)
// écraser le résultat DH en mémoire, plus nécessaire
matériel d'entrée = (tous zéros)

// Sortie 1
// Définir une nouvelle clé de chaînage à partir de la clé temporaire
// byte() ci-dessous signifie un seul octet
ck = HMAC-SHA256(temp_key, byte(0x01)).

// Sortie 2
// Générer la clé de chiffrement k
Définir k = 32 octets
// || ci-dessous signifie append
// byte() ci-dessous signifie un seul octet
k = HMAC-SHA256(temp_key, ck || byte(0x02)).
// écraser la clé temporaire en mémoire, plus nécessaire
temp_key = (tous zéros)

// conserver la clé de chaînage ck pour la KDF du message 3

Fin du modèle de message « ee ».

2) SessionCreated

Bob envoie à Alice.

Contenu Noise : Clé éphémère de Bob Y Charge utile Noise : Bloc d’options de 16 octets Charge utile non Noise : Remplissage aléatoire

(Propriétés de sécurité de charge utile)

XK(s, rs) :           Authentification   Confidentialité
  <- e, ee                  2                1

Authentification : 2.
L'authentification de l'expéditeur est résistante à la compromission de la clé (KCI).
L'authentification de l'expéditeur est basée sur un DH éphémère-statique (« es » ou « se »)
entre la paire de clés statiques de l'expéditeur et la paire de clés éphémères du destinataire.
En supposant que les clés privées correspondantes soient sécurisées, cette authentification ne peut pas être forgée.

Confidentialité : 1.
Chiffrement vers un destinataire éphémère.
Cette charge utile a une confidentialité parfaite, puisque le chiffrement implique un DH éphémère-éphémère (« ee »).
Cependant, l'expéditeur n'a pas authentifié le destinataire,
donc cette charge utile pourrait être envoyée à n'importe quelle partie, y compris un attaquant actif.


  « e » : Bob génère une nouvelle paire de clés éphémères et stocke-la dans la variable e,
  écrit la clé publique éphémère en clair dans le tampon de message,
  et hache la clé publique avec l'ancien h pour dériver un nouveau h.

  « ee » : Un DH est effectué entre la paire de clés éphémères de Bob et la paire de clés éphémères d'Alice.
  Le résultat est haché avec l'ancienne ck pour dériver une nouvelle ck et k, et n est défini sur zéro.

La valeur Y est chiffrée pour assurer l’indiscernabilité de la charge utile et l’unicité, qui sont des contre-mesures DPI nécessaires. Nous utilisons le chiffrement AES pour atteindre cet objectif, plutôt que des alternatives plus complexes et plus lentes telles que elligator2. Le chiffrement asymétrique vers la clé publique du routeur d’Alice serait beaucoup trop lent. Le chiffrement AES utilise le hachage de routeur de Bob comme clé et l’état AES à partir du message 1 (qui a été initialisé avec l’IV de Bob comme publié dans la base de données du réseau).

Le chiffrement AES est utilisé uniquement pour la résistance DPI. Toute partie connaissant le hachage de routeur de Bob et l’IV, qui sont publiés dans la base de données du réseau, et a capturé les 32 premiers octets du message 1, peut déchiffrer la valeur Y dans ce message.

Contenu brut :

+----+----+----+----+----+----+----+----+
|                                       |
+        obfuscated with RH_B           +
|       AES-CBC-256 encrypted Y         |
+              (32 octets)               +
|                                       |
+                                       +
|                                       |
+----+----+----+----+----+----+----+----+
|   ChaChaPoly frame                    |
+   Encrypted and authenticated data    +
|   32 octets                            |
+   k defined in KDF for message 2      +
|   n = 0; see KDF for associated data  |
+                                       +
|                                       |
+----+----+----+----+----+----+----+----+
|     unencrypted authenticated         |
+         padding (optional)            +
|     length defined in options block   |
~               .   .   .               ~
|                                       |
+----+----+----+----+----+----+----+----+

Y :: 32 octets, clé éphémère X25519 chiffrée avec AES-256, little-endian
        clé : RH_B
        iv : En utilisant l'état AES à partir du message 1

Données non chiffrées (tag d’authentification Poly1305 non affiché) :

+----+----+----+----+----+----+----+----+
|                                       |
+                                       +
|                  Y                    |
+              (32 octets)               +
|                                       |
+                                       +
|                                       |
+----+----+----+----+----+----+----+----+
|               options                 |
+              (16 octets)               +
|                                       |
+----+----+----+----+----+----+----+----+
|     unencrypted authenticated         |
+         padding (optional)            +
|     length defined in options block   |
~               .   .   .               ~
|                                       |
+----+----+----+----+----+----+----+----+

Y :: 32 octets, clé éphémère X25519, little-endian

options :: Bloc d'options, 16 octets, voir ci-dessous

padding :: Données aléatoires, 0 ou plusieurs octets.
           La longueur totale du message doit être de 65535 octets ou moins.
           Alice et Bob utiliseront les données de remplissage dans la KDF pour le message 3 partie 1.
           Il est authentifié afin que toute altération entraînera l'échec du prochain message.

Notes

  • Alice doit valider que la clé éphémère de Bob est un point valide sur la courbe ici.

  • Le remplissage doit être limité à une quantité raisonnable. Alice peut rejeter les connexions avec un remplissage excessif. Alice spécifiera ses options de remplissage dans le message 3. Directives minimales/maximales TBD. Taille de remplissage aléatoire de 0 à 31 octets minimum ? (Distribution à déterminer, voir Appendice A.)

  • En cas d’erreur, y compris AEAD, DH, horodatage, répétition apparente ou échec de validation de clé, Alice doit arrêter tout traitement de message ultérieur et fermer la connexion sans répondre. Cela devrait être une fermeture anormale (TCP RST).

  • Pour faciliter une poignée de main rapide, les implémentations doivent s’assurer que Bob met en tampon et puis purge tout le contenu du premier message à la fois, y compris le remplissage. Cela augmente la probabilité que les données seront contenues dans un seul paquet TCP (sauf si segmenté par le système d’exploitation ou les middleboxes), et reçues toutes en une fois par Alice. C’est également pour l’efficacité et pour garantir l’efficacité du remplissage aléatoire.

  • Alice doit échouer la connexion si des données entrantes restent après validation du message 2 et lecture du remplissage. Il ne devrait pas y avoir de données supplémentaires de Bob, car Alice n’a pas encore répondu avec le message 3.

Bloc d’options : Remarque : Tous les champs sont big-endian.

+----+----+----+----+----+----+----+----+
| Rsvd(0) | padLen  |   Reserved (0)    |
+----+----+----+----+----+----+----+----+
|        tsB        |   Reserved (0)    |
+----+----+----+----+----+----+----+----+

Reserved :: 10 octets au total, défini sur 0 pour la compatibilité avec les options futures

padLen :: 2 octets, big-endian, longueur du remplissage, 0 ou plusieurs
          Directives minimales/maximales TBD. Taille de remplissage aléatoire de 0 à 31 octets minimum ?
          (Distribution à déterminer, voir Appendice A.)

tsB :: 4 octets, big-endian, horodatage Unix, secondes non signées.
       Débordement en 2106

Notes

  • Alice doit rejeter les connexions où la valeur d’horodatage est trop éloignée de l’heure actuelle. Appelez la différence d’horodatage maximale « D ». Alice doit maintenir une cache locale de valeurs de poignée de main précédemment utilisées et rejeter les doublons, pour empêcher les attaques de répétition. Les valeurs de la cache sont dépendantes de l’implémentation, cependant, la valeur Y de 32 octets (ou son équivalent chiffré) peut être utilisée.

Problèmes

  • Inclure des options de remplissage minimum/maximum ici ?

Chiffrement pour le message de poignée de main 3 partie 1, en utilisant la KDF du message 2)


// prendre h sauvegardé à partir de la KDF du message 2
// MixHash(ciphertext)
h = SHA256(h || 24 octets de charge utile chiffrée du message 2)

// MixHash(padding)
// Seulement si la longueur de remplissage est non nulle
h = SHA256(h || remplissage aléatoire du message 2)
// h est utilisé comme données associées pour l'AEAD dans le message 3 partie 1, ci-dessous

Ceci est le modèle de message « s » :

Définir s = clé publique statique d'Alice, 32 octets

// EncryptAndHash(s.publickey)
// EncryptWithAd(h, s.publickey)
// AEAD_ChaCha20_Poly1305(clé, nonce, associatedData, données)
// k est de la poignée de main du message 1
// n est 1
ciphertext = AEAD_ChaCha20_Poly1305(k, n++, h, s.publickey)
// MixHash(ciphertext)
// || ci-dessous signifie append
h = SHA256(h || ciphertext) ;

// h est utilisé comme données associées pour l'AEAD dans le message 3 partie 2

Fin du modèle de message « s ».

Fonction de dérivation de clé (KDF) (pour le message de poignée de main 3 partie 2)


Ceci est le modèle de message « se » :

// DH(s, re) == DH(e, rs)
Définir le matériel d'entrée = 32 octets de résultat DH de la clé statique d'Alice et de la clé éphémère de Bob
Définir le matériel d'entrée = résultat DH X25519
// écraser la clé éphémère de Bob en mémoire, plus nécessaire
// Alice :
re = (tous zéros)
// Bob :
e(public et privé) = (tous zéros)

// MixKey(DH())

Définir temp_key = 32 octets
Définir HMAC-SHA256(clé, données) comme dans [RFC-2104](https://tools.ietf.org/html/rfc2104)
// Générer une clé temporaire à partir de la clé de chaînage et du résultat DH
// ck est la clé de chaînage, de la KDF pour le message de poignée de main 1
temp_key = HMAC-SHA256(ck, matériel d'entrée)
// écraser le résultat DH en mémoire, plus nécessaire
matériel d'entrée = (tous zéros)

// Sortie 1
// Définir une nouvelle clé de chaînage à partir de la clé temporaire
// byte() ci-dessous signifie un seul octet
ck = HMAC-SHA256(temp_key, byte(0x01)).

// Sortie 2
// Générer la clé de chiffrement k
Définir k = 32 octets
// || ci-dessous signifie append
// byte() ci-dessous signifie un seul octet
k = HMAC-SHA256(temp_key, ck || byte(0x02)).

// h de la partie 1 du message 3 est utilisé comme données associées pour l'AEAD dans le message 3 partie 2

// EncryptAndHash(payload)
// EncryptWithAd(h, payload)
// AEAD_ChaCha20_Poly1305(clé, nonce, associatedData, données)
// n est 0
ciphertext = AEAD_ChaCha20_Poly1305(k, n++, h, payload)
// MixHash(ciphertext)
// || ci-dessous signifie append
h = SHA256(h || ciphertext) ;

// conserver la clé de chaînage ck pour la KDF de la phase de données
// conserver le hachage h pour la KDF de la clé symétrique supplémentaire (SipHash) de la phase de données

Fin du modèle de message « se ».

// écraser la clé temporaire en mémoire, plus nécessaire
temp_key = (tous zéros)

3) SessionConfirmed

Alice envoie à Bob.

Contenu Noise : Clé statique d’Alice Charge utile Noise : Informations du routeur d’Alice et remplissage aléatoire Charge utile non Noise : Aucune

(Propriétés de sécurité de charge utile)

XK(s, rs) :           Authentification   Confidentialité
  -> s, se                  2                5

Authentification : 2.
L'authentification de l'expéditeur est résistante à la compromission de la clé (KCI). L'authentification de l'expéditeur est basée sur un DH éphémère-statique (« es » ou « se »)
entre la paire de clés statiques de l'expéditeur et la paire de clés éphémères du destinataire. En supposant que les clés privées correspondantes soient sécurisées, cette authentification ne peut pas être forgée.

Confidentialité : 5.
Chiffrement vers un destinataire connu, confidentialité parfaite. Cette charge utile est chiffrée sur la base d'un DH éphémère-éphémère ainsi que d'un DH éphémère-statique avec la paire de clés statiques du destinataire. En supposant que les clés privées éphémères soient sécurisées, et que le destinataire n'est pas activement impersonné par un attaquant qui a volé sa clé privée statique, cette charge utile ne peut pas être déchiffrée.

« s » : Alice écrit sa clé publique statique à partir de la variable s dans le tampon de message, la chiffrant, et hache le résultat avec l'ancien h pour dériver un nouveau h.

« se » : Un DH est effectué entre la paire de clés statiques d'Alice et la paire de clés éphémères de Bob. Le résultat est haché avec l'ancienne ck pour dériver une nouvelle ck et k, et n est défini sur zéro.

Ceci contient deux cadres ChaChaPoly. Le premier est la clé publique statique chiffrée d’Alice. Le deuxième est la charge utile Noise : les informations du routeur d’Alice chiffrées, les options facultatives et le remplissage facultatif. Ils utilisent des clés différentes, car la fonction MixKey() est appelée entre eux.

Contenu brut :

+----+----+----+----+----+----+----+----+
|                                       |
+   ChaChaPoly frame (48 octets)         +
|   Encrypted and authenticated         |
+   clé statique S d'Alice               +
|      (32 octets)                       |
+                                       +
|     k defined in KDF for message 2    |
+     n = 1                             +
|     see KDF for associated data       |
+                                       +
|                                       |
+----+----+----+----+----+----+----+----+
|                                       |
+     Longueur spécifiée dans le message 1     +
|                                       |
+   ChaChaPoly frame                    +
|   Encrypted and authenticated         |
+                                       +
|       Informations du routeur d'Alice  |
+       en utilisant le format de bloc 2  +
|       Options d'Alice (facultatif)     |
+       en utilisant le format de bloc 1  +
|       Remplissage aléatoire           |
+       en utilisant le format de bloc 254 +
|                                       |
+                                       +
| k defined in KDF for message 3 part 2 |
+     n = 0                             +
|     see KDF for associated data       |
~               .   .   .               ~
|                                       |
+----+----+----+----+----+----+----+----+

S :: 32 octets, clé statique X25519 d'Alice chiffrée avec ChaChaPoly, little-endian
     à l'intérieur d'un cadre ChaChaPoly de 48 octets

Données non chiffrées (tags d’authentification Poly1305 non affichés) :

+----+----+----+----+----+----+----+----+
|                                       |
+                                       +
|              S                        |
+       clé statique d'Alice            +
|          (32 octets)                   |
+                                       +
|                                       |
+                                       +
+----+----+----+----+----+----+----+----+
|                                       |
+                                       +
|                                       |
+                                       +
|       Bloc d'informations du routeur d'Alice          |
~               .   .   .               ~
|                                       |
+----+----+----+----+----+----+----+----+
|                                       |
+       Bloc d'options d'Alice (facultatif)          +
|                                       |
~               .   .   .               ~
|                                       |
+----+----+----+----+----+----+----+----+
|                                       |
+       Bloc de remplissage aléatoire           +
|                                       |
~               .   .   .               ~
|                                       |
+----+----+----+----+----+----+----+----+

S :: 32 octets, clé statique X25519 d'Alice, little-endian

Notes

  • Bob doit effectuer la validation habituelle des informations du routeur. Assurez-vous que le type de signature est pris en charge, vérifiez la signature, vérifiez que l’horodatage est dans les limites, et effectuez toutes les vérifications nécessaires.

  • Bob doit vérifier que la clé statique d’Alice reçue dans le premier cadre correspond à la clé statique dans les informations du routeur. Bob doit d’abord rechercher les informations du routeur pour une adresse de routeur NTCP ou NTCP2 avec une version (v) d’option correspondante. Voir les sections Informations du routeur publiées et Informations du routeur non publiées ci-dessous.

  • Si Bob a une version plus ancienne des informations du routeur d’Alice dans sa netdb, vérifiez que la clé statique dans les informations du routeur est la même dans les deux, si présente,