问题标签 [commoncrypto]

我正在尝试使用 iPhone 的 PKI 库来加密一个短字符串（12345678），但每当我尝试使用 SecKeyEncrypt 时，我都会收到错误 -9809（即 errSSLCrypto）。SecureTransport.h 头文件将此错误简单地描述为“潜在的加密错误”，这不是很有意义。

我的代码如下：

我使用什么填充并不重要，它们都会给出相同的错误。公钥是从我的客户提供的证书中派生的，我已经检查以确保该密钥有效。我做错了什么以及如何正确使用该功能？

kCCKeySizeAES128 在哪里？kCC加密？

我通过在 iOS 开发中搜索 kCCKeySizeAES128 找到了“通用加密框架”。解放..

但是我的 MacBook 没有“通用加密框架”。

帮帮我...我需要使用 kCCKeySizeAES128 和 kCCEncrypt。

我想知道，如何在不使用 CCOptions 的情况下定义 CCCryptorStatus。文档说，如果我不设置kCCOptionECBMode，默认是CBC模式，这对我有好处。但是我也不需要 kCCOptionPKCS7Padding ，那么我该如何设置呢？

我尝试：

但这是正确的方法吗？因为如果我想使用这种方法，我会得到一个全为 0 的 NSData 对象，但大小正确。所以我不认为这个值是好的......感谢您的任何回复，madik

已解决- 我结合使用手动管理（绕过垃圾收集器）和映射的 NSData 选项。事实证明，iStat 没有正确的内存数字，而 Instruments 表明了预期的行为。此外，CC_MD5() 和 CC_SHA1() 调用确实已经调用了 CC_MD5_Update() 和 CC_SHA1_Update()，因此它们也不会引起问题。

我目前正在开发一个需要使用 SHA-1 和 MD5 散列大量文件的 Cocoa 应用程序。我正在使用 CC_MD5 和 CC_SHA1 并将文件读入 NSData 对象。但是，即使没有引用 NSData 对象，这也会使用大量 RAM 并且由于某种原因像筛子一样泄漏内存……我怀疑这是垃圾收集器努力跟上的原因。

什么是最好的（如果可能的话也是最简单的，但我不反对做一些额外的工作来加快速度）在这样的大量文件上执行 MD5 和 SHA-1 哈希？

跟进

如下所述，映射的 NSData 可能会有所帮助，但我想我找到了另一种选择。它仍然需要一些工作，但似乎是一个更强大的解决方案。这个想法是使用 NSFileHandle 并读取“块” - 所以一次最多可能是 256MB。然后（例如对于 MD5）使用 CC_MD5() 后跟一系列 CC_MD5_Update() 来计算块中的散列。将其与手动内存管理相结合应该会有所帮助。

我正在使用该CCCrypt方法。

我可以使用比 128 位更长的密钥吗？可以任意长吗？或者可能是 128 的倍数？

如果是这样，我会怎么做？

我不认为这是可能的，但我发现了这段文字：here

一些算法，如 AES 和 RSA 允许不同长度的密钥，但其他算法是固定的，如 DES 和 3DES。使用更长的密钥进行加密通常意味着对消息恢复的抵抗力更强。As usual, there is a trade off between security and time, so choose the key length appropriately.

AES 如何允许不同的长度，它会忽略高于 128 的位吗？

我正在为此拔头发。

当我尝试使用错误的密钥解密密文时，CCCrypt 返回 kCCDecodeError。

问题是，它这样做是否可靠（例如，我是否保证如果它返回成功，我的输入密钥是用于加密纯文本的密钥，我是否还保证我的输出数据是我的原始纯文本）以及如何它甚至可以知道我的密钥是否正确吗？

据我了解加密，引擎无法预测密钥是否有效，应该只给我随机噪声作为输出数据和成功的返回码。

我正在加密一个字符串并使用#import CommonCrypto/CommonKeyDerivation.h，但是 xcode 显示错误没有找到这样的文件，尽管我添加了安全框架并且我也使用了#import CommonCrypto/CommonCryptor.h，但它没有显示错误。

我在 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 应用程序中是否允许使用这些功能，如果允许，是否有任何官方参考来记录这一事实？

我需要将我的 ios 5 应用程序与 CommonCrypto 链接。问题是由于这个错误我无法编译：'Library not found for -lcommonCrypto'...我该如何解决？

有一个（相当复杂的）应用程序在 iOS 4 上运行良好，但在 iOS 5 上因解密问题而失败。它正在解密一个 SQLite DB 页面，最后 16 个字节似乎没有被正确解密。

这是否与任何人敲响警钟？

更新

我已经确定，当 CCCryptorUpdate 的缓冲区长度为 1008 (1024 - 16) 时，它只解密 992 个字节（如 dataOutMoved 参数中所述）。如果 CCCryptorFinal 返回剩余的字节，这将是可以的，但它报告移动的字节为零。然而，CCCryptorFinal 报告了一个 -4304 返回码（这是一个无用的 kCCDecodeError）。

更新 2

我已经非常确定它是一个彻头彻尾的错误。我逐字节比较了加密的输出和解密的输入，并比较了密钥。完全相同的。但是，如果缓冲区长度为 1008，那么解密总是会失败，即使给解密器提供了更大的输出缓冲区（它说在这种情况下它需要 1024）。我认为它适用于 1024，虽然我还没有通过第一个奇怪大小的缓冲区来告诉我。

ETC

好吧，似乎没有什么可以解密。这是使用“一体式”CCCrypt() 接口，该接口消除了 CCCryptorCreate/Update/Final 排序过程中出现任何错误的可能性。我想知道这是否是AES128的问题？

奇怪的是，当数据库的第 1 页被加密时，加密总是报告比我告诉它的移动多 16 个字节——如果我告诉它 1008 它报告 1024，如果我告诉它 1024 它报告 1040。没有其他页面这样做，我不明白 CCCrypt 如何知道它正在处理的页面。就像我说的，好奇。

找到了（我认为）

旧代码指定kCCOptionPKCS7Padding，据我了解，它仅应用于加密缓冲区长度不是块长度倍数的情况（并且提供了额外的输出缓冲区空间）。这导致几乎所有解密操作都以 -4304 失败。但是在 iOS 4 中，操作仍然会移动他们解密的数据（基本上就是全部），而 iOS 5 发生了变化，如果操作失败，所有数据移动都会被抑制（最后一个块几乎总是会失败）。

关闭填充选项可使代码正常工作而不会发布任何错误。