你好PM_dialog !
我使用这个代码加密数据在我的应用程序:
hw_aes_hash_setup年代;memset(郑清奎0 sizeof (hw_aes_hash_setup));uint8 aesKey [32] = {1, 2, 3, 4, 5, 6, 7, 8, 1, 2, 3, 4, 5, 6, 7, 8, 1, 2, 3, 4, 5, 6, 7, 8, 1, 2, 3, 4, 5, 6, 7, 8,};char p[] = "Sic transit gloria mundi-123456.";char e [128];memset (e, 0, sizeof (e));s.mode = HW_AES_CBC;s.aesDirection = HW_AES_ENCRYPT;s.aesKeySize = HW_AES_256;s.aesKeyExpand = HW_AES_DO_NOT_PERFORM_KEY_EXPANSION; s.aesKeys = (uint32)&aesKey; s.aesIvCtrblk_0_31 = 0x01020304; s.aesIvCtrblk_32_63 = 0x05060708; s.aesIvCtrblk_64_95 = 0x090A0B0C; s.aesIvCtrblk_96_127 = 0x0D0E0FA1; s.aesWriteBackAll = true; s.moreDataToCome = false; s.sourceAddress = (uint32)&p; s.destinationAddress = (uint32)&e; s.dataSize = 32; s.enableInterrupt = false; s.callback = 0; hw_aes_hash_init(&s); hw_aes_hash_start(); while(hw_aes_hash_is_active()){}; hw_aes_hash_disable_clock();正如我在相关文档中读到的，在这种情况下，e[128]中的长度应该是48字节。因为纯文本长度是32 +基于AES的填充CBC。但实际上，e[128]中的加密结果在处理后只有32字节长。
与此应用程序相对应的是一个iOS和Android应用程序。加密显示了前32字节的相同结果-如预期的。但是iOS和Android在结果中添加了填充数据，就像这样:
26 9d f3 2b 94 e9 CD de 7a d2 6f e8 7a 7e 8d a8 1f e1 ca b7 bf a7 4f c7 17 f3 d4 2f bb e6 c3 c7 39 7a 92 fe 54 98 c7 f8 2f 13 93 15 3a 43 b0 3eda14683的加密结果是:
26 9d f3 2b 94 e9 CD de 7a d2 6f e8 7a 7e 8d a8 1f e1 ca b7 bf a7 4f c7 17 f3 d4 2f bb e6 c3 c7所以你能解释一下如何得到相同的结果或者还能做什么吗?
谢谢你！
托马斯。
设备:
你好托马斯,
我已经用SDK1.0.14和DA14683在我这边运行了你所附的代码。请看下面我的评论:
1.输出向量(e[])的大小将与输入向量(p[])的大小相等。为此，如果您希望输出中有128个字节，那么您应该相应地调整输入。
2.s.dataSize项被设置为32。根据输入的大小动态配置数据大小。我的建议是如下更改:
3.在您提供的代码段中，键展开由软件，
这是一种错误的方法，根据数据表，key - expansion是基于初始键生成键数的过程。更具体地说，从128位、192位和256位的初始密钥中分别生成11、13和15个密钥。算法的每一轮都使用上面的每一个密钥。为了加密每个128位输入，我们需要使用从这个过程中生成的所有密钥。
这意味着如果它被设置为由引擎执行，软件将读取15个32位的AES密钥。请检查hw_aes_hash_store_keys()的源代码。
我强烈建议你更改引擎执行的键展开，如下:
密钥扩展将由专用硬件引擎执行。否则，应该由软件执行密钥扩展，生成的密钥应该存储在CRYPTO_KEYS内存中。
4.s.moreDataToCome = false;:根据表32:对DA14683数据表的CRYPTO_LEN的限制，当CRYPTO_LEN CRYPTO_MORE_IN = 0时，在AES CBC模式下没有限制，如果改为true，则为16的整数倍。
谢谢,PM_Dialog
你好PM_Dialog !
我听从了您的建议，按照您的要求修改了代码片段。当我做对了，它应该是这样的:
这最终会在hw_aes_hash_init()上崩溃。所以我很怀疑你的建议是否对你有效。你能把你测试过的代码贴出来吗?
我可能解释得不够清楚问题是什么。通常AES-CBC加密需要在末尾填充0x10。为此计算为:
如果是“Sic transit gloria mundi-123456”，计算结果是48。即使消息长度为32字符，计算的加密长度也是48。我已经在上面测试过了https://cryptii.com/pipes/aes-encryption在iOS和Android上，我都会得到相同的加密结果。只有da14683没有使用适当的填充扩展加密的结果。据我所知，AES-CBC加密必须使用PKCS#7填充。
因此，我想再次了解如何参数化hw_aes_hash_setup以获得与其他平台上类似的结果。
谢谢你的亲切问候，
托马斯。
你好托马斯,
下面的代码片段在SDK的freertos_retarget示例中使用。
导入以下库:
下面的代码在main()中在for(;,)循环。输入向量增加了一倍，输出向量也增加了一倍。
你能不能也在你身边测试一下，并分享结果?
谢谢,PM_Dialog
你好,
这花了一些时间，但现在我做到了，结果是:
b86fd2d7de80d4e7cb626ca6e75343695066e13445430c9fbbb8dcccf8df0e34
a33003f124e39ed42b53e200502c4a251e936b50bcb71261c1ad1e06735abe4f
03
加密的结果是65字节长，因为输入数据也是65字节长(字符串+结束符0)。
因此，结论是AES-CBC加密不支持PKCS#7填充。AES-CBC模式的加密可以在任何平台(iOS, Android..)使用PKCS#7填充。在我看来，这种做法是错误的。也许我只是不知道如何配置它。也许你们都不知道。：-）
问候,
托马斯。
你好
你是对的，PKCS7没有在DA1468x平台上实现。如果希望AES-CBC数据与openssl兼容，则必须手工实现它。
请看我之前的帖子:
https://support.dialog-semiconductor.com/forums/post/dialog-smartbond-bl..。
下面是我编写的使用AES-CBC-256进行openssl解码的实现
Uint32_t * const size_out;
uint32_t size_in;
uint32_t padding_size;
uint8_t我;
/ /添加填充
*size_out = ((((size_in - 1) / 16) + 1) * 16;
Padding_size = *size_out - size_in;
For (i = 0;我< padding_size;我+ +){
Data_in [size_in + i] = padding_size;
｝
size_in + = padding_size;
你必须在加密之前做到这一点。这就是我使用input_data的原因。
我还发现，openssl意味着填充总是使用块的最后一个字节。这意味着你不能再使用有效载荷匹配块的大小，或者你需要添加一个额外的块，所以你总是有填充数据传输。这就是为什么openssl/android/iphone加密的消息比DA 1长。
希望它能帮助
致以最亲切的问候
西蒙