3

iOS 4 では正常に動作するが、iOS 5 では復号化の問題で失敗する (かなり複雑な) アプリを用意します。SQLite DB ページを復号化していますが、最後の 16 バイトが適切に復号化されていないようです。

これは誰かとベルを鳴らしますか?

アップデート

私は、CCCryptorUpdate に 1008 (1024 - 16) のバッファー長が与えられた場合、992 バイトのみを復号化することを確認しました (dataOutMoved パラメーターで報告されているように)。CCCryptorFinal が残りのバイトを返した場合、これは問題ありませんが、移動したバイト数がゼロであると報告されます。ただし、CCCryptorFinal は -4304 リターン コードを報告しています (これは役に立たない kCCDecodeError です)。

更新 2

私はそれを完全なバグとしてかなり釘付けにしました。暗号化からの出力と復号化への入力をバイトごとに比較し、キーを比較しました。同一。ただし、バッファー長が 1008 の場合、復号化プログラムに大きな出力バッファーが与えられた場合でも、復号化は常に失敗します (その場合は 1024 が必要であると表示されます)。1024 では問題なく動作すると思いますが、最初の奇妙なサイズのバッファーを通過したことはありません。

まあ、何も復号化されないようです。これは、CCCryptorCreate/Update/Final のシーケンスでエラーが発生する可能性を排除する「オールインワン」の CCCrypt() インターフェイスを使用しています。AES128の問題なのかな?

興味深いことに、DB のページ 1 が暗号化されている場合、暗号化は常に、私が伝えたよりも 16 バイト多く移動したことを報告します。1008 と伝えると 1024 と報告され、1024 と伝えると 1040 と報告されます。他のページはありません。 CCCrypt がどのページを処理しているかを知る方法がわかりません。私が言ったように、好奇心旺盛です。

見つけた(と思う)

古いコードは を指定していましたがkCCOptionPKCS7Padding、これは、私が理解しているように、バッファー長がブロック長の倍数でない場合 (および追加の出力バッファー スペースが提供される場合) の暗号化にのみ使用する必要があります。これにより、事実上すべての復号化操作が -4304 で失敗しました。しかし、iOS 4 では、操作は復号化したデータ (基本的にはすべてのデータ) を移動しますが、iOS 5 では、操作が失敗した場合にすべてのデータ移動が抑制されるように変更されました (そして、最後のブロックはほとんど常に失敗します)。

パディング オプションをオフにすると、エラーが発生することなくコードが機能します。

4

2 に答える 2

5

上記のように、iOS4からiOS5に変更があり、エラーが発生した場合にデータがターゲットバッファーにコピーされなくなりました。したがって、iOS 4では、エラーを無視しても良好な結果が得られる可能性がありますが、iOS 5では機能しません(元のコードを記述していません。エラーを無視することはありませんでした)。

エラーは、kCCOptionPKCS7Padding固定長のブロック複数操作の実行中に指定したことが原因でした。(パディングを行うときにバッファをどのように配置するかは完全にはわかりませんが、私が行う必要はありません。)このオプションを削除すると、操作にエラーが発生しなくなります。

于 2011-11-21T23:26:59.723 に答える
0

kCCOptionPKCS7Paddingonを削除するkCCDecrypt場合、 before の元のデータkCCEncryptがブロック長の倍数でない場合、 after の出力データ長kCCDecryptは before の元のデータとは異なる長さになりますkCCEncrypt

したがって、エラーはありませんが、結果は間違っています。

于 2012-05-08T16:49:32.917 に答える