問題タブ [commoncrypto]

iPhoneのPKIライブラリを使用して短い文字列（12345678）を暗号化しようとしていますが、SecKeyEncryptを使用しようとすると、エラー-9809（つまり、errSSLCrypto）が発生し続けます。SecureTransport.hヘッダーファイルは、このエラーを単に「根本的な暗号化エラー」として記述していますが、これはあまり意味がありませんでした。

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

どのパディングを使用するかは関係ありません。どちらも同じエラーを出します。公開鍵はクライアントから提供された証明書から取得され、鍵が有効であることを確認しました。何が間違っているのですか？関数を正しく使用するにはどうすればよいですか？

kCCKeySizeAES128はどこにありますか？kCCEncrypt？

iOS開発でkCCKeySizeAES128を検索して「CommonCryptoFramework」を見つけました。lib.。

しかし、私のMacBookには「CommonCryptoFramework」がありません。

助けて...kCCKeySizeAES128とkCCEncryptを使用する必要があります。

CCOptionsを使用せずにCCCryptorStatusを定義するにはどうすればよいですか。ドキュメントによると、kCCOptionECBModeを設定しない場合、デフォルトはCBCモードであり、これは私にとって適切です。しかし、kCCOptionPKCS7Paddingも必要ないので、どうすればこれを設定できますか？

私は試してみます：

しかし、これは正しい方法ですか？このメソッドを使用したい場合は、0でいっぱいのNSDataオブジェクトを取得しますが、サイズは正しいためです。だから私はこの値が良いとは思わない...返信をありがとう、マディク

解決済み-手動管理（ガベージコレクターをバイパスする）とマップされたNSDataオプションの組み合わせを使用しました。結局のところ、iStatには正しいメモリの数値がなく、Instrumentsは期待される動作を示していました。さらに、CC_MD5（）およびCC_SHA1（）呼び出しは、実際にはすでにCC_MD5_Update（）およびCC_SHA1_Update（）を呼び出しているため、どちらも問題を引き起こしていません。

私は現在、SHA-1とMD5を使用して大量のファイルをハッシュする必要があるCocoaアプリケーションに取り組んでいます。CC_MD5とCC_SHA1を使用しており、ファイルをNSDataオブジェクトに読み込んでいます。ただし、これは大量のRAMを使用し、NSDataオブジェクトが参照されていなくても、何らかの理由でふるいのようにメモリをリークします…ガベージコレクターが追いつくのに苦労しているのではないかと思います。

このような大規模なファイルに対してMD5およびSHA-1ハッシュを実行するための最良の方法（可能な場合は最も簡単ですが、速度を上げるために余分な作業を行うことを嫌がりません）は何ですか？

ファローアップ

以下で説明するように、マップされたNSDataが役立つ場合がありますが、別のオプションを見つけたと思います。それでもいくつかの作業が必要ですが、はるかに堅牢なソリューションのようです。アイデアは、NSFileHandleを使用して「チャンク」を読み取ることです。したがって、一度に最大256MBになる可能性があります。次に（たとえばMD5の場合）CC_MD5（）を使用し、続いて一連のCC_MD5_Update（）を使用して、ハッシュをチャンクで計算します。それを手動のメモリ管理と組み合わせると役立つはずです。

CCCryptメソッドを使用しています。

128bit よりも長いキーを使用できますか? 任意の長さにできますか？それとも128の倍数？

もしそうなら、どうすればいいですか？

これが可能だとは思いませんでしたが、次のテキストを見つけました: here

AES や RSA などの一部のアルゴリズムでは、さまざまな長さのキーを使用できますが、DES や 3DES などの固定されたアルゴリズムもあります。一般に、より長いキーを使用した暗号化は、メッセージの復元に対する抵抗力が強いことを意味します。いつものように、セキュリティと時間の間にはトレードオフがあるため、適切なキーの長さを選択してください。

AES はどのようにして異なる長さを許可するのですか? 128 を超えるビットは無視されますか?

この上で髪を伸ばしています。

間違ったキーを使用して暗号化テキストを復号化しようとすると、CCCrypt は kCCDecodeError を返します。

問題は、それが確実に行われるかどうか (たとえば、成功を返す場合、入力キーがプレーン テキストの暗号化に使用されたキーであることが保証されているか、出力データが元のプレーン テキストであることも保証されているか)、およびどのように行うかです。私のキーが正しいかどうかを知ることさえできますか?

私が暗号を理解している限り、エンジンはキーが有効かどうかを予測できず、出力データとしてランダムなノイズと成功のリターン コードを返す必要があります。

文字列を暗号化して #import CommonCrypto/CommonKeyDerivation.h を使用していますが、セキュリティ フレームワークを追加しても #import CommonCrypto/CommonCryptor.h を使用しても xcode でエラーが表示されませんが、エラーは表示されません。

openSource でファイルを見つけましたが、コードやダウンロードで使用するアイデアが見つかりませんでした

前もって感謝します

iOS 4 以降を対象とした iOS アプリケーションで MD5 または SHA-1 を利用したいと考えています。CommonCrypto/CommonDigest.h の CC_MD5() および CC_SHA1() 関数を使用します。iOS 4.1 の iPhone と iPhone 4.0 シミュレータでは問題なく動作するようですが、XCode 4.2 に付属の iOS 5 SDK では次のように関数が宣言されているため、懸念されます。

これは、機能が iOS 5 以降でのみ使用可能であることを示しているようです。

これらの機能は iOS 4 アプリケーションで許可されていますか? 許可されている場合、その事実を文書化するための公式の参照はありますか?

iOS5アプリをCommonCryptoにリンクする必要があります。問題は、このエラーのためにコンパイルできないことです：'-lcommonCryptoのライブラリが見つかりません'...どうすれば解決できますか？

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 では、操作が失敗した場合にすべてのデータ移動が抑制されるように変更されました (そして、最後のブロックはほとんど常に失敗します)。

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