問題タブ [ctr-mode]

Web アプリケーションによって書き込まれる Cookie を暗号化し、Cookie のサイズを最小限に抑えたいと考えているため、AES/CTR/NoPadding を選択しました。

十分にランダムで、アプリをステートレスに保つ IV として使用することをお勧めします。ランダムな IV を生成してメッセージに追加できることはわかっていますが、そうすると Cookie のサイズが大きくなります。

さらに、128 ビット AES の IV の推奨サイズは?

みんなは他にどうやってこれをやっているの？「実証済みの」方法はありますか? 車輪の再発明はしたくありません。

暗号化にCTRモードでAES128暗号を使用し、さまざまなクライアント（Android/JavaおよびiOS/ObjC）に実装しています。パケットの暗号化に使用される16バイトのIVは、次のようにフォーマットされます。

パケットカウンタ（送信されたパケットに含まれる）は、送信されるパケットごとに1つずつ増加します。最後のバイトはブロックカウンターとして使用されるため、256ブロック未満のパケットは常に一意のカウンター値を取得します。CTRモードでは、ブロックごとにカウンターを1ずつ増やし、最後の8バイトをビッグエンディアンの方法でカウンターとして使用するように指定されているか、少なくともこれがデファクトスタンダードであると想定していました。これは、Sun暗号化の実装にも当てはまるようです。

対応するiOS実装（CommonCryptor、iOS 5.1を使用）がパケットをデコードするときの最初のブロックを除いてすべてのブロックをデコードできなかったとき、私は少し驚いた。CommonCryptorは他の方法でカウンターを定義しているようです。CommonCryptorは、ビッグエンディアンモードとリトルエンディアンモードの両方で作成できますが、CommonCryptorコードのあいまいなコメントは、これが完全にはサポートされていない（または少なくともサポートされていない）ことを示しています。

ブロックごとにデコードすることにより、上記のようにIVを設定するたびに、うまく機能します。

私の質問：一度に複数のブロックをデコードするときにCTR / IVモードを実装する「正しい」方法はありますか、それとも異なる暗号ライブラリを使用するときに相互運用性の問題になると予想できますか？CommonCryptoはこの点でバグがありますか、それともCTRモードを別の方法で実装するだけの問題ですか？

それで、DESの暗号ライブラリであるpyDespyDes.des(key, [mode], [IV], [pad], [padmode])には、このようなAPIがあります。使用法は次のようになりますk = des("DESCRYPT", CBC, "\0\0\0\0\0\0\0\0", pad=None, padmode=PAD_PKCS5)-暗号化のCBCまたはECBモードを使用できます.ただし、教授からの割り当てとして、pyDesライブラリを使用して暗号化するように指示されましたが、CBCとカウンターモードを手動で使用します.

私はCBCモードをうまくやることができましたが、残念ながら私はカウンターモードで立ち往生しています。指定された API をdes(key, CBC, IV ...)使用すると、CBC または ECB モードの操作を使用する場合にのみ IV を使用できます。「foo」が私のIVであるようなものを使用することはできませんdes("hello", mode = None, "foo",....)（カウンターモードの操作を実装することになっており、ivはすべての反復でランダムです）したがって、私の質問は誰かがこの問題に直面し、克服しようとしたことですそれ。

1MB のテスト ファイルがあり、最初からではなく 500KB から解読したいと考えています。ファイルの 500 KB から正確に開始する必要はありません。最初でない限り、任意のチャンクの先頭から開始できます。その方法を学びたいだけです。

このスクリプトを使用すると、ファイルが 0KB から始まる限り、ファイルを復号化できます。

少なくとも可能であれば、誰かが私に説明してもらえますか?