問題タブ [commoncrypto]

iOS アプリケーションで Core Data API を使用しています。また、commoncrypto ライブラリ (CCCrypt()) を使用して、アプリケーションの状態 (バックグラウンド/フォアグラウンド) が変化したときにドキュメント フォルダーにあるデータベース ファイル (.sqlite ファイル) を暗号化/復号化しています。

私が直面している問題は...アプリケーションがバックグラウンド状態からユーザーによって手動で強制終了されると、データベース内のレコードの一部が失われ、この問題に一貫性がありません。

sqlite ファイルの内容を NSData に変換し、CCCrypt() 関数への入力として使用して暗号化/復号化するだけで、暗号化操作で入力データを復号化していません。

誰か助けてください.....データ損失の理由は何ですか? それも、アプリケーションがバックグラウンド状態から手動で強制終了された場合のみです..... 暗号化と復号化の両方の操作で、CCCrypt 関数は kCCSuccess としてステータスを返します...

CCCrypt 操作の前に、入力データ (生のバイト) をデコードする必要はありますか?

JavaでCTRモードでメッセージを暗号化し、iOSでメッセージを復号化しようとしています。ただし、私のテストプログラムは、復号化されると最後のブロックをスクランブルします

コードは次のとおりです。

テストコードは次のとおりです。

メッセージは次のようになります。Multiple block message

しかし、私が得ている出力は次のとおりです。

IVはランダムに生成され、暗号文の前に付加され、データはUTF8でエンコードされている必要があることに注意してください（ただし、エンコードをNSUTF8StringEncodingに設定するとNULL出力が得られます）

私はこれの上に髪を引っ張ってきました。iOSアプリケーションでCommonCryptoを使用してデータを暗号化し、それをWindowsサーバーに送信して復号化します。これは、iPhone 5（iOS 6）、iPad 3（iOS 6）、およびシミュレーター（Mac OS X 10.8.2）の両方のXcode（最新バージョン）開発環境で完全に機能します。

暗号化に使用している非常に単純なコードは次のとおりです。

繰り返しますが、これはXcodeからデバッグしているときにうまく機能します。

しかし、IPA（アーカイブファイル、つまりAppleがApp Storeに対してレビューするもの）を作成し、暗号化されたデータをWindowsサーバーに送信すると、サーバーは「パディングが無効です」と報告します。2つの間にコードの違いはありません！

これら2つのビルドモードのCommonCryptoで何かが違うのではないかと思いますが、それがどうなるかわかりません。そして、AppleのオープンソースサイトからCommonCryptoライブラリを取得してビルドしようとしましたが、それをコードにコンパイルすることを目的としていましたが、正常にビルドできませんでした。

他の誰かがこの問題に遭遇しましたか？ここに欠けているコンパイラオプションはありますか？

* 編集 *

問題の原因となっているフラグを見つけました。「最適化レベル」を「最小/最速」、「最速」、「高速」、または「高速」に設定すると、失敗します。ただし、「なし」に設定すると機能します。したがって、最適化の何かが暗号化を破っています！

並行環境でパスワードハッシュを生成および検証するために使用CCKeyDerivationPBKDFしていますが、それがスレッドセーフかどうかを知りたいです。関数のドキュメントではスレッド セーフについてはまったく言及されていないため、現在は安全のためにロックを使用していますが、必要がなければロックを使用したくありません。

CommonCryptorを使用して暗号化および復号化するためのラッパーがあります。ときどき復号化プロセスが失敗することがあります。その場合、次のようなエラーを入力します。

そして、次のようにエラーをログに記録します。

ただし、これにより、次のような文字列が生成されます。

-4304は、 CommonCryptor.h （-4300〜-4305）のエラーコードのいずれかである可能性があります。エラーコードを文字列値にマッピングする良い方法はありますか、それともswitch文字列を手動で調整するステートメントが必要ですか？に依存する必要がある場合switch、ベストプラクティスは、問題がログに記録される場所またはエラーが生成される場所に配置することです。

iOSアプリケーションでいくつかの文字列を暗号化および復号化するために使用しているコードがあります。コードには CCCrypt の使用が含まれます。キーを実際にどこにも保存せずに、使用されるキーの有効性をテストする信頼できる方法はありますか? 私の調査によると、鍵が有効かどうかを判断する唯一の方法は、鍵の長さと鍵のハッシュを使用することです。誰でもこれを適切な方向に導くことができますか?

これは私が始めているオープン ソース プロジェクトのためのものなので、理想的には、私が含めることができる他のオープン ソース作品を使用したいと考えています。

興味深いことに、RSAを使用してAESキーを暗号化しようとしています。次に、AES キーを使用してユーザーのデータを暗号化/復号化します。

暗号化されたデータ ストリーム (AES 128、CBC、PKCS7) が届いたときに復号化しようとしています。時折、長さ 334 のパケットを受け取り、それを解読しようとします。iPhone 5 でこれを行うと、返されますkCCBufferTooSmall(これは mod 16 以外のデータで予想されます)。ただし、iPhone 3GS で同じものを使用するkCCSuccessと、部分的に復号化されたストリームが返されて返されます (333 の最後の 10 バイト程度は偽物です - null ターミネータとランダム データ)。

どちらのデバイスも iOS 6.1.2 です。このアプリは、基本 SDK を最新の SDK (6.1) に設定し、展開ターゲットを iOS 5.0 にして構築されています。

この問題も示す次のテスト ケースを作成しました。

kCCSuccessブロックサイズが一致しないために失敗するはずのときに、なぜ取得するのですか?

HMAC-SHA1 アルゴリズムを使用して、残りのリクエストの base64 署名を作成しようとしています。私は特に SinglePlatform API を使用しています。手順は次のとおりです。

1. リクエストのドメイン部分を取り除き、パスとクエリのみを残します:/locations/haru-7?client=YOUR_CLIENT_ID
2. URL 用に変更された Base64 でエンコードされた秘密鍵を取得し、HMAC-SHA1 アルゴリズムを使用して上記の URL に署名します。署名キーを元のバイナリ形式にデコードする必要がある場合があります。多くの暗号化ライブラリでは、結果の署名はバイナリ形式になります。
3. URL 用に変更された Base64 を使用して結果のバイナリ署名をエンコードし、この署名を URL 内で渡すことができるものに変換します。sigparameter を使用して、この署名を URL に添付します。

私の現在の実装は次のとおりです。

最初に受け取った署名キーは Base64 に変更されているため、-+_/ 文字を置き換えています。この実装は適切な署名キーを返しましたが、一貫性がありません。

Objective-C を C に変換する際に明らかに間違ったことをしていますか? これを処理するより良い方法はありますか？

私のアプリケーションは ARC を使用しています。