你好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_不_执行_KEY_扩展； 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.在您提供的代码段中，键展开由软件，
这是一种错误的方法，根据数据表，密钥扩展是基于初始密钥生成密钥数的过程。更具体地说，从128、192和256位的初始密钥分别生成11、13和15个密钥。每轮算法使用上述密钥中的每一个。对于每个128位输入的加密我们需要使用这个过程中生成的所有密钥。
这意味着，如果设置为由引擎执行，软件将读取15个32位AES密钥。请检查hw_aes_hash_store_keys（）的源代码。
我强烈建议您更改引擎执行的密钥扩展，如下所示：
密钥扩展将由专用硬件引擎执行。否则，应该由软件执行密钥扩展，生成的密钥应该存储在CRYPTO_KEYS内存中。
4.s、 moreDataToCome=false；：根据DA14683数据表的表32：加密限制，当CRYPTO_LEN CRYPTO_MORE_IN=0时，在AES CBC模式下没有限制，如果将其更改为“true”，则应为16的倍数。
谢谢，下午好
你好，PM_对话！
我听从了你的建议，按照你的要求修改了代码片段。当我做对的时候，应该是这样的：
这最终导致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_设置，以获得与其他平台类似的结果。
谢谢你的问候，
托马斯。
嗨，托马斯，
下面的代码片段在SDK的freertos_retarget示例中使用。
导入以下库:
以下代码在for（；；）循环之前的main（）中调用。输入向量增加了一倍，所以我得到了两倍的输出。
你能在你这边测试一下并分享结果吗？
谢谢，下午好
你好,
这需要一些时间，但现在我已经做到了，结果是：
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*const size\u out；
uint32_t size_in;
uint32_t padding_size;
uint8_t我;
//添加填充物Data_in [size_in + i] = padding_size;
*尺寸输出=（（尺寸输入-1）/16）+1）*16；
Padding_size = *size_out - size_in;
对于（i=0；i
}
大小_in+=填充大小；
你必须在加密之前做到这一点。这就是我使用input_data的原因。
我还发现openssl意味着块的最后一个字节总是由填充使用。这意味着您不能再使用有效负载匹配块的大小，或者您需要添加额外的块，以便始终传输填充数据。这就是openssl/android/iphone加密消息比DA消息长的原因。
希望能有帮助
顺致敬意，
西蒙