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 では、操作が失敗した場合にすべてのデータ移動が抑制されるように変更されました (そして、最後のブロックはほとんど常に失敗します)。
パディング オプションをオフにすると、エラーが発生することなくコードが機能します。