ノイズプロトコルフレームワーク
暗号プロトコルのフレームワーク

ノイズプロトコルフレームワークは、「ノイズ」または「ノイズフレームワーク」と呼ばれることもあり、 Diffie-Hellman鍵交換[2 ]に基づく安全な通信プロトコルを作成するためのパブリックドメイン暗号フレームワーク[1]です。Trevor Perrinによって開発されたこのフレームワークは、一連のハンドシェイクパターン（メッセージ交換の事前定義されたシーケンス）を定義し、当事者が通信を開始し、鍵を交換し、共有秘密を確立する方法を概説しています。これらのパターンは、相互認証、前方秘匿性、ID保護 などの特定のセキュリティ要件を満たすように組み合わせたりカスタマイズしたりできます

メッセージングプラットフォームのWhatsAppやSlack [3]、VPNプロトコルのWireGuardなど、いくつかの一般的なソフトウェアアプリケーションやプロトコルは、ユーザー通信のエンドツーエンド暗号化を確保するために、ノイズフレームワークの実装を使用しています。このフレームワークは、耐量子暗号への適応を含め、現在も開発が進められています。[4]このフレームワークは現在、2018年7月に公開されたリビジョン34です。[1]

歴史

ほとんどのセキュアチャネルプロトコルは、デジタル署名（認証用）とDiffie-Hellman（鍵交換用）を使用した認証鍵交換（AKE）に依存しています。2000年代から2010年代にかけて、署名を使用しない純粋なDiffie-HellmanベースのAKEの開発への関心が高まり、[5]理論的な進歩（例：Kudla-Paterson、[6] NAXOS、[7] Ntor）[8]と実用的な進歩（例：Ntor、[8] NaCl、CurveCP、DNSCurve、OPTLS [9] ）の両方が生まれました。これらは多くの場合、ゼロから開発されました。ノイズプロトコルフレームワークは、 Moxie Marlinspikeの支援を受けてTrevor Perrinによって開発され、2つの重要な革新をもたらしました。[5]

  1. 単純な要素を組み合わせてさまざまなプロトコルを構築します。
  2. 暗号学者マイク・ハンバーグ氏[10]のStrobeプロトコルフレームワーク[11]に触発された「スポンジのような」対称暗号を使用します。

このフレームワークは、SignalプロトコルとSignalメッセージングアプリの起源となったソフトウェア組織であるOpen Whisper Systemsで最初に行われた研究に基づいて発展しました。信号処理の概念であるノイズとは無関係ですが、この暗号プロトコルの名前として「Noise」が選ばれたのは、信号とノイズの概念をもじったものかもしれません。

当初は2013年2月10日からウィキとしてメンテナンスされていましたが、 [12]フレームワークの開発は、2014年8月4日の仕様への最初のコミットから始まりました。 [13]フレームワークは、メーリングリストの議論に従って多数の改訂を経て、2018年7月11日のバージョン34まで進化しました。[14]ノイズプロトコルフレームワークは、[15]以前の暗号設計（NaCl、CurveCP 、またはダブルラチェットアルゴリズムで使用されるKDFチェーンなど）からのインスピレーションと、暗号とコンピューティングの人物（Jason Donenfeld、Hugo Krawczykなど）の貢献を認めています。

ノイズプロトコルフレームワークは開発中、TLS 1.3と並行して進化し、2015年にはプロトコル、特に「OPTLS」提案[17]を比較する議論[ 16 ]が行われました。両方のプロジェクトは2014年から2018年にかけて行われ、TLS 1.3 RFC 8446 [18]の最初のドラフトは2014年8月にリリースされ、最終的な標準提案は2018年8月にリリースされました。 ノイズフレームワークは代替アプローチを提供し、特定のハンドシェイクパターンと暗号化アルゴリズムを選択して、特定のセキュリティ特性とパフォーマンスニーズに合わせたプロトコルを設計できるようにしました。

ノイズプロトコルフレームワークの形式検証[19]では、そのセキュリティ特性が評価されています。研究では、自動化ツールを用いてフレームワーク内の様々なハンドシェイクパターンをモデル化し検証し、[20] [21]様々な攻撃に対する耐性を評価しています。

概要

セキュアチャネルプロトコルには2つのフェーズがあります。

  • ハンドシェイクフェーズ：認証鍵交換（AKE）用のDiffie-Hellman鍵交換（DH）を使用して、共有秘密鍵を認証および確立します
  • トランスポートフェーズ: 共有秘密鍵を使用してデータを暗号化する

ハンドシェイク パターンは、図ではメッセージのセットとして記述できます。各メッセージには、パーティのハンドシェイク状態で実行される暗号化操作を記述するトークンのリストが注釈として付けられます。

 3 つのメッセージを持つハンドシェイク パターンの例:
 IK
        <- s
        ...
        -> e、es、s、ss
        <- e、ee、se

 ハンドシェイクの名前は定型的です:

  • I=アイデンティティの隠蔽が減少または欠如しているにもかかわらず、発信者Iの静的キーは応答者に直ちに送信される
  • K=応答者に知られているイニシエーターKの静的キー

 前の行は、...公開鍵の帯域外転送など、DH AKE の前のメッセージを表します。

仕様では、片方向ハンドシェイクのパターンを3つ、対話型ハンドシェイクの基本的なパターンを12個挙げています。これらのパターンには、以下のようなバリエーションがあります。

  • 1遅延パターンでは、認証DHは次のメッセージまで延期されます。最初の文字と/または2番目の文字の後に数字が使用されます（例：NK1または）。X1X1
  • 双方が32バイトの共有秘密鍵を持つプロトコルをサポートするための事前共有対称鍵、例：Npsk0またはXpsk1
  • 複合プロトコルでは、モディファイアを介してイニシエーターとレスポンダーの役割が逆転し、ネゴシエーションのメカニズムとなるfallback。ノイズパイプは§10.4に記載されている例である[22]

実際の例としては、ホワイトペーパーの 10 ページに「構築」Noise_IKpsk2_25519_ChaChaPoly_BLAKE2sと記載されている WireGuard が挙げられます。

各ハンドシェイクパターンは、仕様書に記載されている8つの暗号化アルゴリズムの16通りの組み合わせのいずれかと組み合わせることができます。これらのアルゴリズムは同等の品質であり、設計空間を拡大するものではありません。

仕様書では、§5 [23]で、それぞれが少数のメソッドを持つ以下のオブジェクトを使用してAPIの概要を示しています。

  • オブジェクトにはk個とn個のCipherState変数が含まれており、暗号文の暗号化と復号に使用されます。ハンドシェイクフェーズでは、各当事者は単一のオブジェクトを持ちますが、トランスポートフェーズでは、各当事者は送信用と受信用の2つのオブジェクトを持ちます。CipherStateCipherState
  • オブジェクトには、 aとckおよびhSymmetricStateという変数が含まれます。Noise で使用される「対称暗号」のすべてをカプセル化しているため、この名前が付けられています。ハンドシェイクフェーズでは、各当事者は を1つずつ持ち、ハンドシェイクが完了すると削除できます。CipherStateSymmetricState
  • オブジェクトには、DH変数（s、e、rs、reHandshakeState ）と、ハンドシェイクパターンを表す変数が含まれます。ハンドシェイクフェーズ中、各パーティは を1つずつ持ち、ハンドシェイクが終了すると削除できます。SymmetricStateHandshakeState

具体的なプロトコルの実装には、メッセージ表現の設計に加え、Noise Frameworkの外部の側面も考慮する必要があります。後者の例としては、UDPトランスポートを使用するプロトコル（例えばWireGuard）が挙げられます。WireGuardは、スライディングウィンドウを用いて順序外の到着を処理します。

仕様書には、いくつかのハンドシェイクパターンのセキュリティ特性が記述されており、相互認証、前方秘匿性、ゼロラウンドトリップ暗号化、身元隠蔽などの高度な機能をサポートできます。一般的なハンドシェイクパターンの正式な暗号解析は、学術文献に掲載されています。[24] [25] 2つ目の取り組みは、オンラインツール「Noise Explorer」に結実しました。[26]

以下の大部分は、フォーマットされた仕様からの抜粋で構成されています。

  • IKハンドシェイクパターン、暗号化、修飾子で構成されるプロトコル名
  • ハンドシェイクステートマシンの変数のck
  • メッセージパターン内のトークンのe
  • §は仕様書のセクションへの参照の接頭辞となる

重点は以下のとおりです。

  • ハンドシェイクパターン
  • セキュリティ特性とトレードオフ
  • アプリケーションの責任とセキュリティに関する考慮事項

プロトコル名と修飾子 §8

ノイズプロトコル名を生成するには、Initialize()ASCII文字列Noise_にアンダースコアで区切られた4つのセクション名を連結します。これらのセクション名は、ハンドシェイクパターン、DH関数、暗号関数、ハッシュ関数の順に指定します。結果として得られる名前は255バイト以下である必要があります。[27]例：

  • Noise_XX_25519_AESGCM_SHA256
  • Noise_N_25519_ChaChaPoly_BLAKE2s
  • Noise_IK_448_ChaChaPoly_BLAKE2b

各名前セクションは、英数字 (つまり、「A」...「Z」、「a」...「z」、および「0」...「9」の範囲の文字) と 2 つの特殊文字「+」および「/」のみで構成する必要があります。

以下に指定されているように、各名前セクションには追加のルールが適用されます。

ハンドシェイクパターン名セクション§8.1

ハンドシェイクパターン名セクションには、ハンドシェイクパターン名と0個以上のパターン修飾子のシーケンスが含まれます。[28]

ハンドシェイク パターン名は、英字または数字のみを含む大文字の ASCII 文字列である必要があります (例:XX1または IK)。

パターン修飾子は、ハンドシェイクパターンで指定された動作に対して任意の拡張または変更を指定します。例えば、ハンドシェイクパターンに修飾子を適用すると、何らかのルールに従って別のパターンに変換されます。 修飾子psk0とfallback修飾子はその一例であり、このドキュメントの後半で定義されます。

パターン修飾子は、小文字の英数字からなるASCII文字列で指定します。文字列はアルファベット（数字は不可）で始まる必要があります。パターン修飾子は、以下のように基本パターンに追加されます。

基本パターンに最初に追加される修飾子は、単に末尾に追加されるだけです。したがって、fallback修飾子をパターンに追加するとXX、 が生成されますXXfallback。追加の修飾子はプラス記号で区切られます。したがって、psk0修飾子を追加すると、名前セクションXXfallback+psk0、または のような完全なプロトコル名が生成されますNoise_XXfallback+psk0_25519_AESGCM_SHA256。

場合によっては、修飾子の順序によって異なるプロトコルが指定されることがあります。ただし、修飾子の順序が重要でない場合は、アルファベット順に並べる必要があります（これは相互運用性を確保するための任意の規則です）。

暗号アルゴリズム名セクション §8.2

DH、暗号、ハッシュ名セクションのルールは同じです。各名前セクションには、プラス記号で区切られた1つ以上のアルゴリズム名を含める必要があります。[29]

各アルゴリズム名は、英数字とスラッシュ（/）のみで構成する必要があります。アルゴリズム名は短くすることを推奨します。また、曖昧さを避けるため、必要な場合にのみ「/」文字を使用してください（例： はSHA3/256よりも推奨されますSHA3256）。

ほとんどの場合、各名前セクションには単一のアルゴリズム名（つまりプラス記号なし）が含まれます。複数のアルゴリズム名は、パターンまたは修飾子によって要求された場合にのみ使用されます。

このドキュメントのパターンや修飾子は、名前セクションに複数のアルゴリズム名を記述する必要はありません。ただし、この機能は将来の拡張において有用となる可能性があります。例えば、DHセクションで複数のアルゴリズム名を使用して「ハイブリッド」ポスト量子順方向秘密性を指定したり、異なる目的のために複数のハッシュアルゴリズムを指定したりすることが考えられます。

暗号アルゴリズム、§12

この仕様では、以下の名称の8つの最新アルゴリズムを列挙しています。[30] [31]

ディフィー・ヘルマン関数
25519 曲線25519
448 曲線448
暗号関数
ChaChaPoly チャチャ20 -ポリ1305
AESGCM ガロア/カウンターモード (GCM) の高度暗号化標準(AES)
ハッシュ関数
SHA256 SHA256
SHA512 SHA512
BLAKE2s BLAKE2s
BLAKE2b BLAKE2b

Wikiには非公式アルゴリズムのリストがあります。[32]ポスト量子暗号の項目は、 2016年に始まったNISTのポスト量子暗号標準化の取り組みよりも前のものであるため、省略しました。この取り組みでは、最初の3つのポスト量子暗号規格であるFIPS 203、FIP 204、およびFIP 205が2024年に制定されました。

ここで、私たち[誰? ] は、非標準アルゴリズムに使用できるいくつかの名前を文書化します。これにより、これらのアルゴリズムの実験的な使用では一貫した名前を使用できるようになります (注: これらのアルゴリズムはいずれも Noise での使用が推奨されていません。自己責任で使用してください)。

ディフィー・ヘルマン関数
secp256k1 secp256k1、[33] Lightningで使用
FourQ フォーQ [34]
NIST P256 P-256 [35]
NIST P384 P-384 [36]
NIST P521 P-521 [37]
暗号関数
DeoxysII ナイキスト法で使用
AESGCMSIV AES-GCM-SIV
AESPMACSIV AES-GCM-SIV
Kravatte クラヴァット法[38]
KravatteSIV Kravatte-SIV [39]
ハッシュ関数
SHA3/256 SHA-3インスタンス
SHA3/512 SHA-3インスタンス
SHAKE128 SHA-3#インスタンス(HASHLEN=32)
SHAKE256 SHA-3#インスタンス(HASHLEN=64)
K12 カンガルー12 [40]
M14 マルスピラミ14 [41]

プロローグ §6

ノイズプロトコルには、任意のデータをh変数にハッシュ化できるプロローグ入力があります。両当事者が同一のプロローグデータを提供しない場合、ハンドシェイクは復号エラーにより失敗します。これは、両当事者がハンドシェイク前にネゴシエーションを行い、そのネゴシエーションに関して双方の見解が一致していることを確認したい場合に有用です。[42]

例えば、ボブがアリスに、サポートしたいノイズプロトコルのリストを伝えたとします。アリスはそのうちの1つのプロトコルを選択して実行します。中間者（man-in-the-middle）がボブのリストを編集して選択肢を削除しないようにするため、アリスとボブはリストをプロローグデータとして含めることができます。

両当事者はプロローグが同一であることを確認していますが、プロローグデータを暗号鍵に混ぜることはありません。入力に暗号強化を目的とした秘密データが含まれている場合は、代わりにPSKハンドシェイクを使用する必要があります（§9参照）。

ハンドシェイクパターン

ハンドシェイクパターン：3 一方向 §7.4

以下のハンドシェイクパターンは、送信者から受信者への一方向のデータストリームをサポートする「一方向」ハンドシェイクを表しています。これらのパターンは、ファイル、データベースレコード、またはその他の非対話型データストリームの暗号化に使用できます。[43]

一方向ハンドシェイクに続いて、送信者は によって返された最初の CipherState を使用して暗号化したトランスポート メッセージのストリームを送信できます。Split()からの 2 番目のCipherStateSplit()は破棄されます。受信者はそれを使用してメッセージを送信してはなりません (これは §7.3 の規則に違反するため)。

一方向パターンは、送信者の静的キーのステータスを示す 1 文字で名前が付けられます。

  • N=送信者用の静的キーはありません
  • K=応答者に知られているイニシエーターKの静的キー
  • X= 送信者Xの静的キーが受信者に送信（「送信」）される

N: 

<-秒
 …
 -> e、es

K: 

-> s 
 <- s
 …
 -> e、es、ss

X: 

<-秒
 …
 -> e、es、s、ss

Nは、従来のDHベースの公開鍵暗号化です。他のパターンでは、送信者の認証が追加されます。この場合、送信者の公開鍵は受信者に事前に知られているか（K）、暗号化されて送信されます（X）。

ハンドシェイクパターン、12 基本インタラクティブ §7.5

以下のハンドシェイクパターンは対話型プロトコルを表す。これら12のパターンは「基本」対話型ハンドシェイクパターンと呼ばれる。[44]

基本的なインタラクティブ パターンは、イニシエーターとレスポンダーの静的キーの状態を示す 2 つの文字で名前が付けられます。

最初の文字はイニシエーターの静的キーを参照します。

  • N= No イニシエーターの静的キー
  • KK=応答者に知られている発信者の静的キー
  • XX= 発信側から応答側に送信される（「送信」される）静的キー
  • I=Iアイデンティティの隠蔽が減少または存在しないにもかかわらず、発信者の静的キーが応答者に直ちに送信される

2 番目の文字は、応答側の静的キーを参照します。

  • N= No 応答者の静的キー
  • KK=イニシエーターに知られているレスポンダーの静的キー
  • XX= 応答側から発信側へ送信（「送信」）される静的キー
NN
001        -> e
012        <- e, ee
013        ->
NK
1        <- s
          ...
022        -> e, es
213        <- e, ee
054        ->
NX
001        -> e
212        <- e, ee, s, es
053        ->
XN
001        -> e
012        <- e, ee
213        -> s, se
054        <-
XK
1        <- s
          ...
022        -> e, es
213        <- e, ee
254        -> s, se
255        <-
XX
001        -> e
212        <- e, ee, s, es
253        -> s, se
254        <-
KN
1        -> s
          ...
002        -> e
033        <- e, ee, se
214        ->
055        <-
KK
1        -> s
2        <- s
          ...
123        -> e, es, ss
244        <- e, ee, se
255        ->
25#6        <-
KX
1        -> s
          ...
002        -> e
233        <- e, ee, se, s, es
254        ->
255        <-
IN
001        -> e, s
032        <- e, ee, se
213        ->
054        <-
IK
1        <- s
          ...
122        -> e, es, s, ss
243        <- e, ee, se
254        ->
255        <-
IX
001        -> e, s
232        <- e, ee, se, s, es
253        ->
254        <-

上記の表の最初の2列は、各メッセージパターンの前に、§7.4のすべての一方向パターンと§7.5の基本パターンについて、ノイズハンドシェイクとトランスポートペイロードのセキュリティプロパティをリストしています。各ペイロードには、受信者に提供される送信者の認証の程度に関する「ソース」プロパティと、送信者に提供される機密性の程度に関する「宛先」プロパティが割り当てられています

送信者の場合：

  • 0.認証なし。このペイロードは、アクティブな攻撃者を含むあらゆる当事者によって送信された可能性があります

使用者: IN#1、IN#2、IN#4、IX#1、KN#2、KN#3、KN#5、KX#2、NK#2、NK#4、NN#1、NN#2、NN#3、NX#1、NX#3、XK#2、XN#1、XN#2、XN#4、XX#1

  • 1.送信者認証は鍵侵害偽装（KCI）に対して脆弱です。送信者認証は、双方の静的鍵ペアを用いた静的-静的DH（ss）に基づいています。受信者の長期秘密鍵が侵害された場合、この認証は偽造される可能性があります。Noiseの将来のバージョンでは署名が追加される可能性があり、これによりこのセキュリティ特性は向上する可能性がありますが、他のトレードオフも伴うことに注意してください。

使用者: IK#2、IN#3、KK#3、KN#4、NK#3、NN#2、NN#3、NX#2、XK#3、XN#2、XN#3、XX#2

  • 2.鍵侵害偽装に耐性のある送信者認証（KCI）。送信者認証は、送信者の静的鍵ペアと受信者の一時鍵ペア間の一時静的DH（esまたはse ）に基づいています。対応する秘密鍵が安全であると仮定すると、この認証は偽造できません。

使用者: IK#2、IK#3、IK#4、IK#5、IN#3、IX#2、 #3、 #4、#3、IX# 4、#5、#6、#4、#3、#4、#5、#2、#3、#2、# 3 、#4、#5 、#2 、#3、#2、#3、#4、 #5、 #3、#2、#3、#4 IXKKKKKKKKKNKXKXKXNKNKNXXKXKXKXKXNXXXXXX

受信者向け：

  • 0.機密性なし。このペイロードは平文で送信されます

使用者: IN#1、IN#2、IN#4、IX#1、KN#2、KN#3、KN#5、KX#2、NK#2、NK#4、NN#1、NN#2、NN#3、NX#1、NX#3、XK#2、XN#1、XN#2、XN#4、XX#1

  • 1.一時的な受信者への暗号化。このペイロードは、一時的な-一時的なDH（ee）による暗号化のため、前方秘匿性を備えています。ただし、送信者は受信者を認証していないため、このペイロードはアクティブな攻撃者を含むあらゆる相手に送信される可能性があります。

使用者: IK#2、IN#3、KK#3、KN#4、NK#3、NN#2、NN#3、NX#2、XK#3、XN#2、XN#3、XX#2

  • 2.既知の受信者への暗号化。送信者のみが侵害を受ける可能性がある前方秘匿性。リプレイに対して脆弱。このペイロードは、受信者の静的鍵ペアを含むDH（分散状態推定）のみに基づいて暗号化されています。受信者の静的秘密鍵が後日侵害された場合、このペイロードは復号可能です。受信者からの一時的な情報提供がないため、このメッセージもリプレイ可能です。

使用者: IK#2、IK#3、IK#4、IK#5、IN#3、IX#2、 #3、 #4、#3、IX# 4、#5、#6、#4、#3、#4、#5、#2、#3、#2、# 3 、#4、#5 、#2 、#3、#2、#3、#4、 #5、 #3、#2、#3、#4 IXKKKKKKKKKNKXKXKXNKNKNXXKXKXKXKXNXXXXXX

  • 3.既知の受信者への暗号化、弱い前方秘匿性。このペイロードは、受信者の静的鍵ペアを含むエフェメラル-エフェメラルDHとエフェメラル-静的DHに基づいて暗号化されています。しかし、受信者のエフェメラル公開鍵と受信者の静的公開鍵の結合は送信者によって検証されていないため、受信者のエフェメラル公開鍵はアクティブな攻撃者によって偽造されている可能性があります。この場合、攻撃者は後に受信者の静的秘密鍵を侵害し​​てペイロードを復号化できます。Noiseの将来のバージョンでは署名が含まれる可能性があり、これによりこのセキュリティ特性は向上する可能性がありますが、他のトレードオフも伴うことに注意してください。

使用者: IN#2、IX#2、KN#3、KX#3

  • 4.既知の受信者への暗号化。送信者の秘密鍵が侵害されている場合、前方秘匿性は弱くなります。このペイロードは、一時的-一時的DHと、受信者の静的鍵ペアを含む一時的-静的DHに基づいて暗号化されています。ただし、受信者の一時的公開鍵と受信者の静的公開鍵の結合は、これらの公開鍵と送信者の静的秘密鍵の両方を含むDHに基づいてのみ検証されています。したがって、送信者の静的秘密鍵が以前に侵害されている場合、受信者の一時的公開鍵はアクティブな攻撃者によって偽造されている可能性があります。この場合、攻撃者は後に意図した受信者の静的秘密鍵を侵害し​​てペイロードを復号化できます（これは「KCI」攻撃の亜種であり、「前方秘匿性」攻撃を可能にします）。Noiseの将来のバージョンには署名が含まれる可能性があり、これによりこのセキュリティ特性は向上する可能性がありますが、他のトレードオフも発生します。

使用者: IK#3、KK#4

  • 5.既知の受信者への暗号化、強力な前方秘匿性。このペイロードは、受信者の静的鍵ペアを用いたエフェメラル-エフェメラルDHとエフェメラル-静的DHに基づいて暗号化されます。エフェメラル秘密鍵が安全であり、受信者が攻撃者によって静的秘密鍵を盗まれ、なりすまされていないと仮定すると、このペイロードは復号できません。

使用者: IK#4、IK#5、IN#4、IX#3、IX#4、KK#5、KK#6、KN#5、KX#4、KX#5、NK#4、NX#3、XK#4、XK#5、XN#4、XX#3、XX#4

共通パターンの同一性隠蔽特性 §7.8

以下の表は、§7.4 のすべての片方向ハンドシェイクパターンと§7.5 の基本ハンドシェイクパターンの ID 隠蔽特性を列挙したものである。さらに、対応する基本パターンとは異なる ID 隠蔽特性を持つ遅延ハンドシェイクパターンをいくつか列挙する。[45]

各パターンには、イニシエータの静的公開鍵とレスポンダの静的公開鍵に付与される機密性を表すプロパティが割り当てられます。これらのパターンの根底にある前提は、一時的な秘密鍵は安全であり、相手側から信頼できない静的公開鍵を受け取った場合、当事者はハンドシェイクを中止するというものです。

このセクションでは、ハンドシェイクにおける静的な公開鍵フィールドを介したID漏洩についてのみ考察します。もちろん、ノイズ参加者のIDは、ペイロードフィールド、トラフィック分析、IPアドレスなどのメタデータなど、他の手段を通じて漏洩する可能性があります。

発信者 応答者
N - 3
K 5 5
X 4 3
NN - -
NK - 3
NK1 - 9
NX - 1
XN 2 -
XK 8 3
XK1 8 9
XX 8 1
KN 7 -
KK 5 5
KX 7 6
IN 0 -
IK 4 3
IK1 0 9
IX 0 6

関連する公開鍵の特性は次のとおりです

  • 0. クリアに送信されます。
  • 1. 前方秘匿性で暗号化されていますが、匿名のイニシエーターによって調査できます。
  • 2. 前方秘匿性で暗号化され、匿名の応答者に送信されます。
  • 3. 送信はされないものの、受動的な攻撃者は応答者の秘密鍵の候補を確認し、その候補が正しいかどうかを判断できます。また、攻撃者は以前に記録されたメッセージを新しい応答者に再生し、受信者がメッセージを受け入れるかどうかで、2つの応答者が「同一」であるかどうか（つまり、同じ静的鍵ペアを使用しているかどうか）を判断することもできます。
  • 4. 応答側の静的公開鍵に暗号化され、前方秘匿性は保持されません。攻撃者が応答側の秘密鍵を入手した場合、発信側の公開鍵を復号できます。
  • 5. 送信されませんが、受動的な攻撃者は (応答者の秘密鍵、発信者の公開鍵) のペアの候補を確認し、候補のペアが正しいかどうかを知ることができます。
  • 6. 暗号化されているが、前方秘匿性が弱い。発信者の静的秘密鍵を持たずに発信者を装う能動的な攻撃者が、後に発信者の秘密鍵を入手すれば、応答者の公開鍵を復号化できる。
  • 7. 送信されませんが、イニシエーターの静的秘密鍵を持たずにイニシエーターのふりをしたアクティブな攻撃者が、後でイニシエーターの秘密鍵の候補を知り、その候補が正しいかどうかを確認できます。
  • 8. 認証された相手に対して前方秘匿性を使用して暗号化されます。
  • 9. 発信者を装い、単一のプロトコル実行を記録するアクティブな攻撃者は、応答者の公開鍵の候補を確認できます。

ハンドシェイクパターン: 対話型、遅延 §7.6

前のセクションの基本的なハンドシェイクパターンは、認証（esとse）のためのDH操作をできるだけ早く実行します。[46]

これらの認証DHを次のメッセージまで延期するハンドシェイクパターンの追加セットを記述できます。これらの延期ハンドシェイクパターンに名前を付けるには、1基本パターン名の1文字目または2文字目、あるいはその両方の後に数字を使用し、イニシエータおよび／またはレスポンダの認証DHが次のメッセージまで延期されることを示します。

遅延パターンは、いくつかの理由で役立つ場合があります。

  • イニシエーターはレスポンダーの静的公開キーを事前に知っているものの、0-RTT で暗号化されたデータを送信したくない場合があります。
  • 場合によっては、認証を延期することで、ハンドシェイクの ID 秘匿性が向上することがあります (§7.8 を参照)。
  • Noiseの将来の拡張では、DH操作を署名またはKEM暗号文に置き換えることが可能になる可能性がありますが、送信者が自身を認証している場合（署名）、または送信者が受信者を認証している場合（KEM暗号文）のみに可能になります。したがって、すべての基本的なハンドシェイクパターンでは、認証DHを署名またはKEM暗号文に置き換えることしかできませんが、遅延バリアントでは両方の置き換えが可能になります。

以下に、左側に基本的なハンドシェイクパターン、右側に遅延ハンドシェイクのバリエーションを示す2つの例を示します。23種類の遅延ハンドシェイクパターンの完全なセットは、付録§18に記載されています。[47]

NKNK1
    <-秒    <-秒
    …    …
    → e、es    → e
    -> e、ee    -> e、ee、es
XXX1X
    → e     -> e
    <- e、ee、s、es     <- e、ee、s、es
    -> s、se     ->秒
         <-せ
XX1
         -> e
         <- e、ee、s
         -> es、s、se
X1X1
         -> e
         <- e、ee、s
         -> es、s
         <-せ

握手パターン：複合§10

[48]

複合プロトコルの根拠 §10.1

これまで、アリスとボブは、イニシエーター（アリス）が選択した単一のノイズプロトコルを実行したいと仮定してきました。しかし、ボブがアリスの最初のメッセージを受信した後、別のノイズプロトコルに切り替えたい理由はいくつかあります。例えば、[49]

アリスは、ボブがサポートしていない暗号、DH 機能、またはハンドシェイク パターンに基づいてノイズ プロトコルを選択した可能性があります。

アリスは、ボブの静的公開鍵または PSK の古いバージョンに基づいて、「ゼロ RTT」で暗号化された初期メッセージを送信した可能性があります。

これらのシナリオに対処するには、ボブがアリスが選択した最初のノイズプロトコルから新しいノイズプロトコルに切り替える複合プロトコルが必要です。このような複合プロトコルでは、イニシエーターとレスポンダーの役割が逆転し、ボブが新しい​​ノイズプロトコルのイニシエーターとなり、アリスがレスポンダーとなります。

複合プロトコルでは、アリスが開始するノイズ プロトコルと切り替え可能なノイズ プロトコルをアドバタイズする必要があり、両者が安全な移行をネゴシエートする必要があるため、大きな複雑さが生じます。

これらの詳細は、このドキュメントの範囲外です。ただし、複合プロトコルの構築例といくつかの構成要素を示すために、以下のセクションではフォールバック修飾子を定義し、それを用いてノイズパイプ複合プロトコルを作成する方法を示します。

ノイズ パイプはXXパターンをサポートしますが、アリスがボブの静的公開キーをキャッシュし、IK0-RTT 暗号化によるハンドシェイクを試行することもできます。

ボブがアリスの初期メッセージを解読できない場合IK、パターンに切り替えます。これにより、基本的に、アリスが初期メッセージではなく初期メッセージを送信したかのようにXXfallback、当事者はハンドシェイクを完了できます。 XXXXIK

修飾語fallback§10.2

修飾子fallbackは、アリス開始パターンをボブ開始パターンに変換します。具体的には、アリスの初期メッセージを、ボブが何らかの手段（例えばIKアリスからの初期メッセージ）で受信する必要がある事前メッセージに変換します。この変換後、ハンドシェイクパターンの残りの部分はボブ開始ハンドシェイクパターンとして解釈されます。[50]

たとえば、を生成するfallbackために に適用された修飾子は次のとおりです。 XXXXfallback

XX: 

-> e 
 <- e、ee、s、es 
 -> s、se

XXfallback: 

-> e
 …
 <- e、ee、s、es 
 -> s、se

フォールバックは、アリスの最初のメッセージが事前メッセージとして解釈できる (つまり、e、s、または " e、s " のいずれかである必要がある) アリス開始形式のハンドシェイク パターンにのみ適用できることに注意してください。

ゼロRTTとノイズプロトコル §10.3

ゼロRTT暗号化のための典型的な複合プロトコルには、3つの異なるノイズプロトコルが含まれます。[51]

  • アリスがゼロ RTT 暗号化を可能にするボブに関する保存情報を所有していない場合、またはゼロ RTT ハンドシェイクを使用しない場合は、完全なプロトコルが使用されます。
  • ゼロ RTT プロトコルでは、最初のメッセージ内のデータの暗号化が可能です。
  • ボブがアリスの最初のゼロ RTT ハンドシェイク メッセージを復号化できない場合、スイッチ プロトコルがトリガーされます。

ボブは最初のメッセージを受信した際に、フルRTTとゼロRTTのケースを区別する何らかの方法が必要です。アリスがゼロRTTを試行した場合、応答を受信した際にゼロRTTとスイッチRTTのケースを区別する何らかの方法が必要です。

例えば、各ハンドシェイクメッセージの前に、タイプバイト（§13参照）などのネゴシエーションデータが付加される場合があります。このデータはノイズメッセージ自体の一部ではなく、どのノイズプロトコルが使用されているかを示す信号です。

ノイズパイプ §10.4

このセクションでは、ノイズパイプ複合プロトコルを定義します。以下のハンドシェイクパターンは、前のセクションで説明したフル、ゼロRTT、およびスイッチの役割を満たすため、単純なゼロRTTオプションを備えたフルハンドシェイクを提供するために使用できます。[22]

XX: 

-> e 
 <- e、ee、s、es 
 -> s、se

IK: 

<-秒                     
 …
 -> e、es、s、ss 
 <- e、ee、se

XXfallback: 

-> e
 …
 <- e、ee、s、es 
 -> s、se

このXXパターンは、当事者が以前に通信したことがない場合に完全なハンドシェイクに使用され、その後、アリスはボブの静的公開キーをキャッシュできます。

このIKパターンは、ゼロ RTT ハンドシェイクに使用されます。

このパターンは、ボブが最初のメッセージの復号化に失敗した場合（おそらく静的キーを変更したため）、 XXfallbackスイッチ ハンドシェイクに使用されます。IK

NoiseSocket をベースにした NoiseLingo ネゴシエーション言語

2018年3月4日のトレバー・ペリンからの電子メール[52]

NoiseSocket（「NoiseLingoSocket」）にネゴシエーション言語（「NoiseLingo」）を追加する「NLS」フレームワークの仕様草案を作成しました。これは1のアイデアに基づいています。[53]

これには、NoiseSocketドラフトを微調整し、2 [54]から変更を加える必要があります（いくつかの名前を変更し、プロローグの計算を変更して「再試行」の場合を区別し、アプリケーションプロローグを追加します）。

  • NLSフレームワーク[55]
  • ノイズソケットプロトコル[56]

NLS ドラフトでは、アプリケーション開発者が使用できる高レベルプロトコルとして意図されたいくつかの「基本プロファイル」も定義されています。

  • NoiseLink（1-RTTハンドシェイク）
  • NoiseZeroLink（0-RTTハンドシェイク）
  • NoiseShortLink（ローエンド組み込み向け）
  • NoiseAnonBox（公開鍵暗号化）
  • NoseAuthBox（公開鍵暗号化+送信者認証）

NoiseLingoとNLSは、プロファイル作成時に簡単に選択できるネゴシエーションフィールドのメニューを提供します。また、これらのプロファイルは多くの類似性を持つため、相互運用性も期待できます（例えば、NoiseZeroLinkクライアントは1-RTTにフォールバックすることでNoiseLinkサーバーと通信できます）。NoiseLinkのようなシンプルなものから始めれば、新たなニーズが見つかった際に、新しいNLSフィールドやネゴシエーションオプションを簡単に追加できます。

アプリケーションの責任 §13

Noise上に構築されたアプリケーションは、いくつかの問題を考慮する必要があります。[57]

  • 暗号関数の選択：25519一般的な用途ではDH関数が推奨されますが、楕円曲線暗号448に対する暗号解読攻撃が開発された場合には、DH関数はより高いセキュリティを提供できる可能性があります。DH関数は、またはのような512ビットハッシュで使用する必要があります。DH関数は、またはのような256ビットハッシュでも使用できますが、より小さなハッシュ関数に対する暗号解読攻撃が開発された場合には、512ビットハッシュはより高いセキュリティを提供できる可能性があります。をソフトウェアで高速かつ一定時間で実装することは困難です。448SHA512BLAKE2b25519SHA256BLAKE2sAESGCM
  • 拡張性：アプリケーションは、すべてのメッセージのペイロードに拡張可能なデータ形式（例：JSON、プロトコルバッファ）を使用することを推奨します。これにより、古い実装では無視されるフィールドを将来的に追加できるようになります。
  • パディング：アプリケーションは、すべての暗号化メッセージのペイロードにパディングを許可するデータ形式を使用することを推奨します。これにより、実装においてメッセージサイズに関する情報の漏洩を回避できます。前述の項目に記載されているように、拡張可能なデータ形式を使用すれば十分な場合もあります。
  • セッション終了：アプリケーションは、Noiseトランスポートメッセージのシーケンスが攻撃者によって切り捨てられる可能性があることを考慮する必要があります。アプリケーションは、インタラクティブセッションの終了、または一方向のトランスポートメッセージストリームの終了を通知するために、トランスポートペイロード内に明示的な長さフィールドまたは終了シグナルを含める必要があります。
  • 長さフィールド：ノイズメッセージは最大65535バイトの長さになる可能性があるため、アプリケーションはノイズメッセージのフレーミングフィールドや追加の長さフィールドを処理する必要があります。明示的な長さフィールドが必要な場合は、各メッセージの前に16ビットのビッグエンディアンの長さフィールドを追加することを推奨します。
  • ネゴシエーションデータ：アプリケーションは、ハンドシェイクの前、または各ハンドシェイクメッセージの前に、ネゴシエーションデータの送信をサポートすることを望む場合があります。ネゴシエーションデータには、Noiseプロトコルのバージョン情報や識別子などが含まれる場合があります。例えば、シンプルなアプローチとしては、各Noiseハンドシェイクメッセージの前に1バイトの型フィールドを送信することが挙げられます。より柔軟なアプローチとしては、protobufなどの拡張可能な構造体を送信することが挙げられます。ネゴシエーションデータは、大幅な複雑さと、ロールバック攻撃などのセキュリティリスクをもたらします（次のセクションを参照）。

セキュリティに関する考慮事項 §14

このセクションでは、さまざまなセキュリティに関する考慮事項をまとめています。[58]

  • 認証：静的公開鍵を用いるノイズプロトコルは、対応する秘密鍵が参加者によって所有されていることを検証しますが、リモート側の静的公開鍵が許容されるかどうかを判断するのはアプリケーション側です。その方法としては、公開鍵に署名する証明書（ハンドシェイクペイロードで渡すことも可能）、事前設定された公開鍵リスト、あるいは「ピンニング」/「鍵連続性」アプローチ（参加者が遭遇した公開鍵を記憶し、同じ参加者が将来同じ公開鍵を提示するかどうかをチェックする）などがあります。
  • セッション終了: 攻撃者がトランスポートストリームを切り捨てるのを防ぐ
  • ロールバック：プロローグに含まれていない過去のネゴシエーションに基づいてノイズプロトコルを決定した場合、ロールバック攻撃を受ける可能性があります。これは複合プロトコルにおいて特にリスクが高く、ノイズハンドシェイクの前に当事者間で通信が行われる場合は注意が必要です。
  • 静的鍵の再利用：Noiseで使用される静的鍵ペアは、単一のハッシュアルゴリズムで使用する必要があります。この鍵ペアは、Noise以外、あるいは複数のハッシュアルゴリズムで使用することはできません。異なるNoiseプロトコルで静的鍵ペアを使用することは可能ですが、その場合はすべてのプロトコルで同じハッシュアルゴリズムが使用されている必要があります。（Noiseの静的鍵ペアをNoise以外で再利用する場合は、相互に侵害が生じないように、またセキュリティ証明が保持されるように、非常に慎重な分析が必要です。）
  • PSKの再利用：Noiseで使用されるPSKは、単一のハッシュアルゴリズムで使用する必要があります。PSKはNoise以外では使用しないでください。また、複数のハッシュアルゴリズムで使用することも避けてください。
  • 一時鍵の再利用：ノイズプロトコルに参加するすべての当事者は、暗号化されたデータを送信する前に、新しい一時鍵を送信する必要があります。一時鍵は決して​​再利用してはなりません。これらのルールに違反すると、壊滅的な鍵再利用が発生する可能性があります。これは、§7のパターンと§7.3の有効性ルールの背後にある一つの根拠です。また、一方向ハンドシェイクが送信者からのトランスポートメッセージのみを許可し、受信者からのトランスポートメッセージを許可しない理由でもあります。
  • 公開鍵を秘密鍵として誤用する：メッセージ前に公開鍵を設定するパターンを使用し、ハンドシェイクが成功すれば相手側も公開鍵を知っていると想定したくなるかもしれません。しかし、残念ながら、これは正しくありません。公開鍵を無効な値に設定すると、予測可能なDH出力が発生する可能性があるからです。例えば、Noise_NK_25519イニシエータが無効な一時的な公開鍵を送信した場合、応答側の静的公開鍵を知らないにもかかわらず、既知のDH出力がすべてゼロになる可能性があります。共有秘密鍵で認証を行う場合は、共有秘密鍵をPSKとして使用する必要があります。
  • チャネルバインディング：DH機能によっては、悪意のある者が公開鍵を無効な値に設定することで予測可能なDH出力を発生させ、複数のセッションで同じ共有秘密鍵を導出することが可能になる場合があります（前の箇条書き参照）。また、公開鍵を同等の値に設定することで、異なる入力に対して同じDH出力が発生する可能性もあります。そのため、§11.2で説明されているように、高レベルプロトコルでは、 ckではなくハンドシェイクハッシュ（ h ）を一意のチャネルバインディングとして使用する必要があります。
  • ノンスの増加：暗号化において、同じ鍵kでnのノンス値を再利用すると、壊滅的な結果を招く可能性があります。実装ではノンスの規則を厳守する必要があります。ノンスは整数オーバーフローによりゼロに戻ることは許可されておらず、最大のノンス値は予約されています。つまり、2 64 -1 を超えるトランスポートメッセージを送信することはできません。
  • プロトコル名：プロトコル名は、Initialize()使用されるすべての鍵（一時鍵ペア、静的鍵ペア、PSKのいずれであっても）のハンドシェイクパターンと暗号関数の組み合わせを一意に識別するものでなければなりません。同じプロトコル名で異なる暗号操作の組み合わせを持つ同じ秘密鍵を再利用した場合、問題が発生する可能性があります。
  • 事前共有対称キー: 事前共有対称キーは、256 ビットのエントロピーを持つ秘密の値である必要があります。
  • データ量：AESGCM単一の鍵で暗号化されるデータの量が増えるにつれて、暗号関数のセキュリティは徐々に低下します。そのため、単一の鍵で暗号化されたデータは2.56バイト（約72ペタバイト）を超えないようにする必要があります。このような大容量のデータを送信する可能性がある場合は、異なる暗号関数を選択する必要があります。
  • ハッシュ衝突：攻撃者がプロローグデータまたはハンドシェイクハッシュでハッシュ衝突を発見した場合、「トランスクリプト衝突」攻撃を実行し、両当事者にハンドシェイクデータに関する異なる見解を持たせることができる可能性があります。Noiseは衝突耐性のあるハッシュ関数と組み合わせて使用​​し、弱点の兆候が見られた場合はハッシュ関数を交換することが重要です。
  • 実装フィンガープリンティング：このプロトコルを匿名の通信相手が存在する環境で使用する場合、実装があらゆるケースで同一に動作するように注意する必要があります。これには、無効なDH公開鍵の処理について、厳密な動作を規定する必要があるかもしれません。

実装

言語 名前
C ノイズC [59]
C# Noise.NET [60]
CLI noisecat [61]
アーラン ノイズ[62]
Java ノイズ-Java [63]
JavaScript/WASM noise-c.wasm [64] (Noise-Cより)
ハスケル 不協和音[65]
ゴー ノイズ[66]
ゴー ナイキスト[67]
ゴー NoisePlugAndPlay [68]
Objective-C Noise.framework [69] (macOSおよびiOS対応フレームワーク、Swift対応)
Python ノイズプロトコル[70]
Python 不協和音[71]
ラケット ノイズプロトコル[69]
ルビー ノイズ[72]
錆 雪[73]
錆 ノイズ-錆[74]

具体的なプロトコル

  • Googleの「低TCBの信頼できる実行環境のための検証済みノイズプロトコル」
  • I2P (ntcp2 ルーター)
  • ライトニング
  • libp2p
  • FacebookのLibra / Diem（デジタル通貨）（2022年に終了[75]）
  • nQUIC [76]
  • SlackのNebula [3]「スケーラブルなオーバーレイネットワーキングツール」
  • WhatsApp
  • WireGuard

参照

一般的な暗号の意味でのノイズの他の用法：

参考文献

  1. ^ ab 「ノイズプロトコルフレームワーク - IPR」noiseprotocol.org。2024年12月15日閲覧
  2. ^ 「ノイズプロトコルフレームワークの紹介」Cisco Duo . 2025年2月25日閲覧。
  3. ^ ab slackhq/nebula、Slack、2024年12月15日、 2024年12月15日閲覧
  4. ^ Angel, Yawning; Dowling, Benjamin; Hülsing, Andreas; Schwabe, Peter; Weber, Fiona Johanna (2022), Post Quantum Noise, 2022/539 , 2025年2月25日閲覧
  5. ^ ab Real World Crypto (2018-01-14). ノイズプロトコルフレームワーク| | Trevor Perrin | RWC 2018 . 2025年2月25日閲覧– YouTube経由。
  6. ^ チェン、リクン;クドラ、キャロライン。パターソン、ケネス G. (2004)。 「同時署名」。カチンではクリスチャン。 Camenisch、Jan L. (編)。暗号学の進歩 - EUROCRYPT 2004。コンピューターサイエンスの講義ノート。 Vol. 3027. ベルリン、ハイデルベルク：シュプリンガー。 pp.  287–305。土井:10.1007/978-3-540-24676-3_18。ISBN 978-3-540-24676-3.
  7. ^ 「認証鍵交換のセキュリティ強化」（PDF） . Microsoft
  8. ^ ab 「鍵交換プロトコルにおける匿名性 と一方向認証」（PDF）。cacr.uwaterloo.ca 。
  9. ^ 「OPTLSとTLS 1.3」（PDF）www.ndss-symposium.org。
  10. ^ “Mike Hamburg”. iacr.org . 2024年12月15日閲覧。
  11. ^ 「Strobeプロトコルフレームワーク」www.cryptologie.net . 2024年12月15日閲覧。
  12. ^ “ホーム”. GitHub . 2024年12月15日閲覧。
  13. ^ 「進行中の仕様を追加します。 · noiseprotocol/noise_spec@213237c」。GitHub 。2024年12月15日閲覧。
  14. ^ “rev34draft -> rev34 · noiseprotocol/noise_spec@ecdf084”. GitHub . 2024年12月15日閲覧。
  15. ^ 「ノイズプロトコルフレームワーク」noiseprotocol.org . 2025年2月25日閲覧。
  16. ^ "[noise] TLS 1.3". moderncrypto.org . 2024年12月15日閲覧。
  17. ^ 「OPTLSプロトコルとTLS 1.3」(PDF) . eprint.iacr.org . 2015年10月9日.
  18. ^ Rescorla, Eric (2018年8月). トランスポート層セキュリティ (TLS) プロトコル バージョン 1.3 (レポート). インターネット技術タスクフォース.
  19. ^ Kobeissi, Nadim; Nicolas, Georgio; Bhargavan, Karthikeyan (2018), Noise Explorer: Fully Automated Modeling and Verification for Arbitrary Noise Protocols, 2018/766 , 2025年2月25日閲覧
  20. ^ Dowling, Benjamin; Rösler, Paul; Schwenk, Jörg (2019), Flexible Authenticated and Confidential Channel Establishment (fACCE): Analyzing the Noise Protocol Framework, 2019/436 , 2025年2月25日閲覧
  21. ^ Ho, Son; Protzenko, Jonathan; Bichhawat, Abhishek; Bhargavan, Karthikeyan (2022), Noise*: A Library of Verified High-Performance Secure Channel Protocol Implementations (Long Version), 2022/607 , 2025年2月25日閲覧
  22. ^ ab 「ノイズプロトコルフレームワーク - ノイズパイプ」noiseprotocol.org . 2024年12月15日閲覧。
  23. ^ 「ノイズプロトコルフレームワーク - 処理ルール」noiseprotocol.org . 2024年12月15日閲覧。
  24. ^ ダウリング、ベンジャミン、ロスラー、ポール、シュウェンク、ヨルグ（2020年）、"Flexible Authenticated and Confidential Channel Establishment (fACCE): Analyzing the Noise Protocol Framework", Lecture Notes in Computer Science、Cham: Springer International Publishing、pp.  341– 373、doi :10.1007/978-3-030-45374-9_12、hdl : 20.500.11850/399156、ISBN 978-3-030-45373-22024年5月17日閲覧{{citation}}：CS1メンテナンス：ISBNを使用した作業パラメータ（リンク）
  25. ^ Kobeissi, Nadim; Nicolas, Georgio; Bhargavan, Karthikeyan (2019年6月). 「Noise Explorer: 任意のノイズプロトコルのための完全自動モデリングと検証」. 2019 IEEE European Symposium on Security and Privacy (EuroS&P) . IEEE. pp.  356– 370. doi :10.1109/eurosp.2019.00034. ISBN 978-1-7281-1148-3.
  26. ^ 「ノイズエクスプローラー：パターンを探る」noiseexplorer.com。2024年12月15日閲覧
  27. ^ 「ノイズプロトコルフレームワーク - プロトコル名と修飾子」noiseprotocol.org . 2024年12月15日閲覧。
  28. ^ 「ノイズプロトコルフレームワーク - ハンドシェイクパターン名セクション」noiseprotocol.org . 2024年12月15日閲覧。
  29. ^ 「ノイズプロトコルフレームワーク - 暗号化アルゴリズム名セクション」noiseprotocol.org . 2024年12月15日閲覧。
  30. ^ 「ノイズプロトコルフレームワーク - DH関数、暗号関数、ハッシュ関数」noiseprotocol.org . 2024年12月15日閲覧。
  31. ^ 「ノイズプロトコルフレームワーク - 暗号関数」noiseprotocol.org . 2024年12月15日閲覧。
  32. ^ 「非公式暗号アルゴリズムリスト」GitHub 。 2024年12月15日閲覧。
  33. ^ "secp256k1". neuromancer.sk . 2024年12月15日閲覧。
  34. ^ “FourQ”. neuromancer.sk . 2024年12月15日閲覧。
  35. ^ "P-256". neuromancer.sk . 2024年12月15日閲覧。
  36. ^ “P-384”. neuromancer.sk . 2024年12月15日閲覧。
  37. ^ “P-521”. neuromancer.sk . 2024年12月15日閲覧。
  38. ^ 「クラヴァッテ」。ケチャックチーム。2024 年 12 月 15 日に取得。
  39. ^ “Keccak Team”. keccak.team . 2024年12月15日閲覧。
  40. ^ 「KangarooTwelve: Keccak-pに基づく高速ハッシュ」keccak.team . 2024年12月15日閲覧。
  41. ^ 「なぜKangarooTwelveは12ラウンドしか使わないのか？」Cryptography Stack Exchange . 2024年12月15日閲覧。
  42. ^ 「ノイズプロトコルフレームワーク - プロローグ」noiseprotocol.org . 2024年12月15日閲覧。
  43. ^ 「ノイズプロトコルフレームワーク - 一方向ハンドシェイクパターン」noiseprotocol.org . 2024年12月15日閲覧。
  44. ^ 「ノイズプロトコルフレームワーク - インタラクティブハンドシェイクパターン（基本）」noiseprotocol.org . 2024年12月15日閲覧。
  45. ^ 「ノイズプロトコルフレームワーク - アイデンティティ隠蔽」noiseprotocol.org . 2024年12月15日閲覧。
  46. ^ 「ノイズプロトコルフレームワーク - インタラクティブハンドシェイクパターン（延期）」noiseprotocol.org . 2024年12月15日閲覧。
  47. ^ 「ノイズプロトコルフレームワーク - 付録」noiseprotocol.org . 2024年12月15日閲覧。
  48. ^ 「ノイズプロトコルフレームワーク - 複合プロトコル」noiseprotocol.org . 2024年12月15日閲覧。
  49. ^ 「ノイズプロトコルフレームワーク - 複合プロトコルの根拠」noiseprotocol.org . 2024年12月15日閲覧。
  50. ^ 「ノイズプロトコルフレームワーク - フォールバック修飾子」noiseprotocol.org . 2024年12月15日閲覧。
  51. ^ 「ノイズプロトコルフレームワーク - ゼロRTTとノイズプロトコル」noiseprotocol.org . 2024年12月15日閲覧。
  52. ^ "[ノイズ] NLS?". moderncrypto.org . 2024年12月15日閲覧。
  53. ^ "[noise] NoiseLink のカスタマイズ". moderncrypto.org . 2024年12月15日閲覧。
  54. ^ 「[noise] ドキュメントのステータスと計画」moderncrypto.org . 2024年12月15日閲覧。
  55. ^ "nls_spec/output/nls.pdf at master · noiseprotocol/nls_spec" (PDF) . GitHub . 2024年12月15日閲覧。
  56. ^ "noisesocket_spec/output/noisesocket.pdf at master · noiseprotocol/noisesocket_spec" (PDF) . GitHub . 2024年12月15日閲覧。
  57. ^ 「ノイズプロトコルフレームワーク - アプリケーションの責任」noiseprotocol.org . 2024年12月15日閲覧。
  58. ^ 「ノイズプロトコルフレームワーク - セキュリティに関する考慮事項」noiseprotocol.org . 2024年12月15日閲覧。
  59. ^ rweather (2024-12-07), rweather/noise-c , 2024-12-15閲覧
  60. ^ ミハイロビッチ、ネマニャ (2024-11-18)、Metalnem/ノイズ、2024-12-15取得
  61. ^ Di Giacomo、Gerardo (2024-11-16)、gedigi/noisecat 、2024-12-15取得
  62. ^ aeternity/enoise, æternity, 2024-09-14 , 2024-12-15閲覧
  63. ^ rweather (2024-11-27), rweather/noise-java 、2024年12月15日閲覧
  64. ^ Mokrynskyi, Nazar (2024-05-17), nazar-pc/noise-c.wasm 、2024年12月15日閲覧。
  65. ^ haskell-cryptography/cacophony、Haskell Cryptography Group、2024年9月23日、 2024年12月15日取得
  66. ^ flynn/noise, Flynn, 2024-12-02 , 2024-12-15閲覧
  67. ^ Angel, Yawning (2024-11-26), Yawning/nyquist , 2024年12月15日閲覧
  68. ^ “NoiseGo/noise at master · mimoo/NoiseGo”. GitHub . 2024年12月15日閲覧。
  69. ^ ab OuterCorner/Noise、Outer Corner、2024年11月18日、 2024年12月15日閲覧
  70. ^ Lizończyk、Piotr (2024-12-07)、plizonczyk/noiseprotocol 、2024-12-15取得
  71. ^ Tarek (2024-11-12), tgalal/dissononce 、 2024年12月15日閲覧
  72. ^ 山口 (2024-06-28), Yamaguchi/noise , 2024-12-15閲覧
  73. ^ McGinty, Jake (2024-12-15), mcginty/snow 、2024年12月15日閲覧。
  74. ^ Guanhao, Yin (2024-12-05), blckngm/noise-rust , 2024-12-15閲覧
  75. ^ Victor (2024年12月2日). 「デイビッド・マーカスがリブラ閉鎖の理由を明かす」Altcoin Buzz . 2024年12月15日閲覧。
  76. ^ Hall-Andersen, Mathias; Wong, David; Sullivan, Nick; Chator, Alishah (2019), nQUIC: Noise-Based QUIC Packet Protection , 2024年12月15日閲覧
  • 仕様とWikiを含む公式ウェブサイト
  • Githubリポジトリ
  • 2017年の講演「ノイズプロトコルフレームワーク」のスライド
  • ノイズプロトコルフレームワークの紹介
  • ノイズプロトコルフレームワークを使用して分散機能システムを設計する
  • ノイズキャット：ノイズの万能ナイフ

プレゼンテーション：

  • トレバー・ペリンによるReal World Crypto 2018での20分間の講演
  • デビッド・ウォンによる25分間の講演
「https://en.wikipedia.org/w/index.php?title=Noise_Protocol_Framework&oldid=1332168068」から取得