問題タブ [initialization-vector]

私は決して暗号化の専門家ではありません。スタック オーバーフローやウィキペディアでいくつかの質問を読んでいますが、IV とその使用法を定義するという点で、本当に「明確」なものはありません。

私が発見したポイント：

• IV は、暗号化を強化するために平文メッセージの先頭に追加されます。
• IVは本当にランダムです
• 各メッセージには固有の IV があります
• ランダム値の代わりにタイムスタンプと暗号化ハッシュが使用されることもありますが、タイムスタンプは予測できるため、これらは安全ではないと見なされます
• WEP (802.11) の弱点の 1 つは、IV が一定量の暗号化の後にリセットされるため、IV が繰り返されることです。

他にも多くのポイントがあると思いますが、私が見逃した他の特徴を誰か思いつくことができますか?

TripleDES 暗号化の IV 初期化ベクトルを作成しようとすると、次のエラーが発生します。

コード例を参照してください。

これは、VS から得られる例外です。

指定された初期化ベクトル (IV) が、このアルゴリズムのブロック サイズと一致しません。

どこが間違っていますか？

ありがとうございました

暗号化と、暗号化がキーと初期化ベクトルの生成にどのように影響するかについて頭を悩ませています。

TripleDESCryptoServiceProviderASCIIエンコーディングを使用して24バイトのキーと8バイトの初期化ベクトルを必要とするを使用しています。別のエンコーディングを使用することにした場合、これはキーの生成と初期化ベクトルにどのように影響しますか？

代わりにUTF8/16/32を使用する必要があるエンコーディングはどれですか？

ありがとうございました

暗号化されたテキストが予測できないように、AES で IV を使用しようとしています。ただし、暗号化された 16 進文字列は常に同じです。

私は実際にいくつかの追加パラメーターを暗号の初期化呼び出しに渡すことによって、いくつかのランダム性を追加しようとするいくつかの方法を試しました。

1) マニュアル IV 生成

2) cipher に IV の生成を依頼する

3) PBEParameterSpec の使用

これらはすべて、暗号化されたテキストに影響を与えないようです....助けて!!!

私のコード:

Rockbox 用のパスワード格納プラグイン (C で記述) の場合、初期化ベクトルを生成する必要があります。

問題は、ランダム性の良いソースがないことです。Rockbox が提供する random() は暗号化 RNG ではありません。そして、アクセスできるランダム性のソースはほとんどありません（マウスの動きはありません... Rockboxを実行しているiPodでは）。

キーは現在、PBKDF2 を介してユーザー提供のパスワードとソルト (定数プレフィックス + random() からのデータ) から導出されます。疑似乱数データは、PBKDF2 の 10000 回の反復でソルトに十分なはずだと思います。

しかし、どこから初期化ベクトルを取得しますか? 半ランダムなデータ (time + random()) と SHA を、たとえば 10000 回取得しても問題ありませんか? random() から取得したシードで arc4random を取得する必要がありますか?

同じキーを実質的に 2 回使用しない場合 (保存されたデータが変更されるたびにソルトが再計算されます)、IV も必要ですか? このような状況に対処する最善の方法は何ですか?

編集: 1 人のユーザー (IPod を所有している私)、暗号化アルゴリズム: AES-CBC 256 ビット。このファイルには、さまざまな Web サイトのサイト/アカウント/パスワード リストが格納されているだけです。それが変更されることはめったにありません (Web サイトで新しいアカウントを作成するときはいつでも)。変更が行われると、新しいソルトと新しい IV が生成されます。

私の知る限り、CTRモードは初期ベクトルを使用しません。カウンターを取得し、指定されたキーで暗号化してから、暗号文を取得するために結果をプレーンテキストでXORします。

暗号化を行う前のCBCのような他のブロック暗号モードは、平文を初期ベクトルとXORします。

これが私の問題です。私はJavaで次のコードを持っています（bouncycastleライブラリを使用）：

同じキーを使用して上記のコードを呼び出すたびに、異なる出力が得られます。しかし、行うとき：

上記のコードを呼び出すたびに同じ結果が得られます。しかし、これはなぜですか？つまり、CTRはIVを必要としないので、すべての呼び出しでIVを与えないと、異なる結果が得られ、IVを与えたときに同じ結果が返されるのはなぜですか？クリック率を使用するときに常に上記のIV（すべてゼロ）を使用する場合、それは安全ですか？

どんなアイデアも非常に役に立ちます。ありがとうございました

データベースに暗号化して保存したい小さな秘密がたくさんあります。データベース クライアントにはキーがあり、データベース サーバーは暗号化と復号化を処理しません。私のシークレットはすべて 16 バイト以下です。これは、AES を使用する場合に 1 ブロックだけを意味します。私は定数 IV (およびキー) を使用して暗号化を決定論的にしています。決定論的暗号化を行う理由は、暗号文を使用してデータベースに簡単にクエリを実行し、同じ秘密が 2 回格納されないようにするためです (列を UNIQUE にすることにより)。 ）。私が見る限り、キーが秘密である限り、これを行うことに問題はないはずです。しかし、私は確信したい: 私は正しいか間違っているか? 私が間違っている場合、どのような攻撃を行うことができますか?

ところで: 考えられる平文の数が比較的少ないため、ここではハッシュはまったく役に立ちません。ハッシュを使用すると、元の平文を取得するのは簡単です。

暗号化と.NETFrameworkに慣れてきたところです。多くの例を見た後、.NETクラスを使用するときに混乱するパターンが繰り返されているのがわかりますRfc2898DeriveBytes。このクラスを使用して暗号化キーと初期化ベクトルを取得する場合、同じメソッドが使用されているようです。

キーと初期化ベクトルの取得を示すMSDNブログのコードを次に示します。

これは他の場所でも使われているのを見たことがあります。こんな感じだと思っていたのではないでしょうか...

私はここで何かが欠けているに違いありません。キーと初期化ベクトル（IV）が単なる乱数である場合、適切なパスワードとソルトを使用すると、それらはどのように再度取得されますか？

今日、私はのんびりと読んでいて、離散対数暗号を使用したペアワイズキー確立スキームの推奨事項（改訂版）（NIST Special Publication 800-56A）のセクション5.8（45ページ）に出くわしました。私はこれに非常に混乱しました：

承認された鍵導出関数（KDF）を使用して、共有秘密から秘密鍵の材料を導出する必要があります。KDFからの出力は、データの暗号化またはメッセージの整合性に使用される対称鍵、秘密の初期化ベクトル、または他の鍵の生成に使用されるマスター鍵（おそらく別のプロセスを使用）などの秘密鍵の素材にのみ使用されます。 ）。非シークレットキーイングマテリアル（非シークレット初期化ベクトルなど）は、共有シークレットを使用して生成してはなりません。

今はアラン・チューリングではありませんが、初期化ベクトルを秘密にする必要はないと思いました。どのような状況で「秘密の初期化ベクトル」が必要になるでしょうか。 Thomas Porninは、IVは公開されており、暗号化に精通しているようだと述べています。同様にcafで。

ほとんどの暗号では、適切なノンスが非常に重要であることを理解しています。私は AES-GCM を使用しており、256 ビットの AES キーで 96 ビットの nonce を使用しています。セキュリティで保護されていないチャネルを介して nonce をネゴシエートする方法について、ここで以前にいくつか質問しました。

私は ECDH を使用して共有シークレットを導出し、X9.63 標準メソッドを使用してキーイング マテリアルを導出する予定です。キーをネゴシエートするときに、ソルトの末尾にランダムに生成された 96 ビットを追加するだけでよいことはわかっています。次に、XOR のように (これはピア ツー ピア システムです) 何らかの方法で 2 つを組み合わせて、ランダムで適切なナンスを持つことができます。

もちろん、これは ARP なりすましなどの MITM 攻撃を阻止するものではありません。公開鍵自体は、公開鍵がアプリケーションとともに配布される中央サーバーによって認証されます。したがって、GCM を使用しているため、証明書を改ざんすることはできません。ただし、ナンスはもちろん認定されていないため、キーを同一に保ちながら、IVを予測可能なものまたは静的なもの（またはすべてゼロなど）に置き換えると、ピアをMITMする可能性があります。これにより、選択された（既知の？）平文攻撃。

紛らわしい場合に備えて、私が話していることのシナリオを次に示します。Alice (A) と Bob (B) はどちらも、適切なランダムな 96 ビット nonce マテリアル (Am と Bm) を生成し、x.509 証明書に追加します。説明のために、小さな数字 Am=1234 と Bm=4321 を使用します。MITMed でない場合、それぞれが Am⊕Bm = 5171 を計算します。これが nonce として使用されます。イブは、IVを倒すためにそれらをMITMすることにしました。彼女は、彼らが一定の IV「6666」で終わることを確認します。A が Am "1234" を B に送信すると、Eve ARP は Bm を偽装し、これを "2795" に置き換えます。BがBm「4321」をAに送ると、Eveはこれを「7896」に置き換えます。1234⊕7896 == 4312⊕2795 == 6666.

ここに私の考え/考えがあります：

nonce マテリアルに署名鍵 (ECDSA) で署名する: この時点で、GCM 自体以外のものを認証する機能はありません (つまり、ECDSA キーを使用したり管理したりしていません)。Suite B アルゴリズムに厳密に固執したいと思います。GCM（AEADの「AD」部分-関連データによる認証済み暗号化）でプレーンテキストを認証できることは知っていますが、もちろん、まだIVを確立していません...したがって、これでIV素材を認証することはできません。私？とにかく暗号化する必要がないため、GCMとの対称キーのみを使用してこれを認証できるように思われます（ECDHを介してすでに確立しています）ので、秘密はありません-プレーンテキストとGCM MACだけです-- しかし、BC で IV なしで AEADBlockCipher を初期化する方法がわかりません。「だます」のはばかげているでしょうか？最初にすべてゼロの IV、正しい鍵で暗号を初期化してから、ナンスを「関連付けられたデータ」(暗号化されていない) として処理し、(MAC を追加するために) バッファをファイナライズし、これをピアに送信してから、本物のIVと同じ鍵で暗号化？あるいは、ECDSA を使用してノンスに署名できると確信しています (おそらく、必要に応じて ECDH 公開鍵と共に)。ただし、それには、サーバーによっても認証されている ECDSA 公開鍵を配布する必要があり、複雑さが増します。むしろ避けてください（したがって、私の最初の署名のアイデア）

同じ IV/キー コンボの繰り返し使用を記録して禁止する: IV で重要なことは、指定されたキーで一度しか使用されないことです。したがって、誰かが上記の MITM 攻撃を繰り返し行って IV を人為的なものに置き換えると、このアイデアは単に接続を認識して閉じるだけです。未使用の IV を導出する有効な代替ペアでそれを置き換えた場合、攻撃者は何の利点も得られません (そうですか?)。私の設計の ECDH ペアの秘密鍵は、実際にはディスクにヒットしないため、プログラムの呼び出しの間にすべての新しい対称鍵が作成されるため、このキー + IV ペアのセットを簡単にメモリに保持できるため、このアプローチが本当に気に入っています:- )

ECDHの秘密素材を「マスク」として使用し、秘密のIVを作成: 確立された ECDH シークレット マテリアルを取得します (まだ X9.63 キー ジェネレーター (BC の ECDHKEKGenerator) に渡されていません)。マテリアル自体の最初の 96 ビットや、マテリアルの SHA-1 ダイジェストの最初の 96 ビットなど、何らかの方法でそれ (Km) から 96 ビットを取得します。Alice と Bob は、ランダムな 96 ビット nonce マテリアル (Am と Bm) を生成します。A と B はそれぞれ Am⊕Km と Bm⊕Km を計算し、その値を相手に送信します。A が Bm⊕Km を持ち、B が Am⊕Km を持っている場合、A は Km⊕(Bm⊕Km) を実行して Bm を取得し、B は Km⊕(Am⊕Km) を実行して Am を取得します。次に、A と B の両方が Am⊕Bm を実行し、最終的に IV を取得します。イブはKmを知らないので、正確に操作できないので、改ざんされた場合、AとBのIVが異なりますよね？これにより、最初のメッセージが交換されたときに GCM が改ざんを検出するため、害はありません。このアプローチの何が問題なのですか?

長い質問で申し訳ありませんが、自分のプロトコルを実装しないように言わないでください。CS の学生として実装の詳細を学ぶためにこれを行っているためです。それらを無視する方法ではありません。