問題タブ [block-cipher]

誰かがTCBアルゴリズムの説明を提供してもらえますか?

32ビットの符号付き整数を別の32ビットの符号付き整数に1対1でマッピング（つまり、衝突なし）できるアルゴリズムが必要です。

私の本当の懸念は、関数の出力がランダムに見えるように十分なエントロピーです。基本的に私はXOR暗号に似た暗号を探していますが、それはより任意に見える出力を生成することができます。あいまいさはありますが、セキュリティは私の本当の関心事ではありません。

明確にするために編集します。

1. キーペアなしで操作を元に戻すことができるように、アルゴリズムは対称である必要があります。
2. アルゴリズムは全単射である必要があり、32ビットの入力番号ごとに32ビットの一意の番号を生成する必要があります。
3. 関数の出力は十分にあいまいである必要があります。入力に1つだけ追加すると、出力に大きな影響を与えるはずです。

期待される結果の例：

F（100）= 98456
F（101）= -758
F（102）= 10875498
F（103）= 986541
F（104）= 945451245
F（105）= -488554

MD5と同じように、1つのものを変更すると、多くのことが変更される可能性があります。

私は数学関数を探しているので、整数を手動でマッピングすることは私にとって解決策ではありません。質問している人にとって、アルゴリズムの速度はそれほど重要ではありません。

暗号化を強化しますか？暗号文がより「ランダム」であることを確認するために使用されたと思いました。それは実際にはそれを強くしません、またはそう私は思います。

暗号化図とTDEA（Triple DES）のコツをつかもうとしています。TDEAは次のようになっていると思います。

暗号文=EK3（DK2（EK1（plaintext）））

また、チェーンブロック暗号はIVを使用して暗号化とプレーンテキストをシードしてから暗号化します。出力は暗号化されたブロックであり、新しいIVは最初のブロックの暗号文の出力から形成されます。正しい？

これは、CBCモードのTDEAが次のように流れることを意味します。

プレーンテキスト->IV->TDEA暗号化->NEWIV->暗号文

次のブロックは次のとおりです。

プレーンテキスト->NEWIV->TDEA暗号化->NEWNEWIV->暗号文

これは、n個のブロックの間続きます。これは正しいですか、それともどのように機能するのかわかりませんか？

現時点では、C で TEA ブロック暗号を解読しようとしています。これは代入であり、キーが 2 つの 16 ビット数値になるようにティー暗号が弱体化されています。

キーを使用して平文をエンコードし、キーを使用して暗号文をデコードするコードも提供されています。

私はいくつかの平文の例を持っています:

1. 平文 (1234,5678) エンコード (3e08,fbab)
2. 平文 (6789,dabc) エンコード (6617,72b5)

アップデート

エンコード メソッドは、プレーンテキストとキー、encode(plaintext,key1) を受け取ります。これは、エンコードされたメッセージを作成するための別のキーで再び発生します。

この暗号を解読するにはどうすればよいですか?

現時点では、既知の平文を可能なすべてのキーでエンコードしています。キーのサイズは 16 進値 ffffffff です。これをファイルに書き込みます。

しかし今、私は立ち往生しており、方向性が必要です。

同等の鍵という TEA の弱点を利用して、暗号の解読にかかる時間を短縮するにはどうすればよいでしょうか? また、中間攻撃で男を使うつもりです。

既知のプレーンテキストとすべてのキー 1 でエンコードすると、関連付けられたキーですべての暗号化されたテキストが作成され、テーブルに格納されます。

次に、キー 2 のすべての可能な値を使用して、割り当てにある既知の暗号文で復号化します。これにより、一度だけ復号化された復号化のテーブルが残ります。

次に、2 つのテーブルを比較して、key1 の暗号化が key2 の復号化と一致するかどうかを確認します。

誰かがこれをコードに実装するのを手伝ってくれるなら、私はequilenventの弱点も使いたいと思います。何か案は？

私の理解では、ストリーム暗号（またはAES CTRモード）では、キーは実際にはIVを使用して暗号化されています（または、一般に、キーKから疑似ランダムバイトを生成します）。それよりも、このキーを使用して、XORを使用して平文を暗号化します。

しかし、私が理解していることから、同じキーKが使用されていると仮定すると、平文の1ビットの変更は、暗号文の1ビットのみを変更します。

私は正しいですか、それとも完全に間違っていましたか？

そして、私が正しければ、それはCBCよりも安全性が低いのではないでしょうか。（CBCでは、平文の1ビットが変更されるため、変更の時点から暗号文のすべてのビットが変更されます）

ありがとう ！！！

重複の可能性:
C の例では AES、Serpent、または Twofish?

文字列を暗号化/復号化するための適切なブロック暗号 (AES、Blowfish など) を見つけようとしています。C で良い例を見つけることができません。C# と C++ でたくさん見つけましたが、c でもたくさん見つけましたが、それらは をサポートしていませんchar*。誰かが私を正しい方向に向けることができれば、それは素晴らしいことです.

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

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

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

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

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

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

AES で暗号化されたパケット (つまり、ストリームではない) を使用するプロトコルを作成しています。統合認証を提供し、NSA のスイート B の一部であるため、GCM (CTR に基づく) を使用することにしました。AES キーは ECDH を使用してネゴシエートされ、公開キーは web- ECDSAのようなものを使用した信頼の。GCM には 128 ビットの nonce / 初期化ベクトルが必要だと思います。なぜなら、AES に 256 ビットの鍵を使用しているにもかかわらず、常に 128 ビットのブロック暗号だからです (右?) 後で 96 ビットの IV を使用しますBCコードを読み取ります。

私は間違いなく独自のアルゴリズムを実装していません (プロトコルのみ -- 私の暗号プロバイダーは BouncyCastle です)。同じ DH キーを持つ 2 人の間で使用される AES キーは一定のままであるため、同じノンスを複数のパケットに使用すべきではないことがわかっています。

単純に 96 ビットの疑似乱数をパケットの先頭に追加し、受信者にこれをノンスとして使用させることはできますか? これはピア ツー ピア ソフトウェアであり、パケットはいつでも送信できます (例: インスタント メッセージ、ファイル転送要求など)。乱数ソース。ノンスは秘密にする必要はまったくありませんよね？それとも、必然的に「暗号的に安全な」PNRG と同じくらいランダムですか? ウィキペディアは、それはランダムであるべきだと言っています。さもなければ、選択された平文攻撃の影響を受けやすいと言っていますが、両方の主張の横に「引用が必要です」とあり、それがブロック暗号に当てはまるかどうかはわかりません. 特定のAESキーで送信されたパケットの数をカウントするカウンター（128ビットブロックの数のカウンターとは別）を実際に使用できますか？1から？明らかに、これによりノンスが予測可能になります。GCM が暗号化だけでなく認証も行うことを考えると、これはその認証機能を危うくするでしょうか?

1ビットストリームモードでCFB、OFB、またはCBCモードをサポートするJavaライブラリが見つかりませんでした。

これまでのところ、私が試したライブラリ（BouncyCastleとIAIK）は、8〜64の範囲しかサポートしていません。