在应用程序层进行加密会得到奇怪的结果

3个帖子/ 0个新帖子
最后发表
奥伦
离线
最后看到:1年2个月前
专家
加入:2014-06-28 22:03
在应用程序层进行加密会得到奇怪的结果

我尝试直接在应用层做aes-128加密,如下http://support.dialog-semiconductor.com/faq/does-da14580-support-aes-128..。

调用gapm:

uint8_t关键[16]={0,1,2,3,4,5,6,7,8,9,10,11,12日,13日,14日,15日};
uint8_t明文[16]= {0x00, 0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77, 0x88, 0x99, 0xAA, 0xBB, 0xCC, 0xDD, 0xEE, 0xFF};
struct gapm_use_enc_block_cmd *cmd = KE_MSG_ALLOC(gapm_use_enc_block_cmd,
TASK_GAPM TASK_APP,
gapm_use_enc_block_cmd);
cmd - >操作= GAPM_USE_ENC_BLOCK;
关键,memcpy (cmd - > operand_1 16);
memcpy (cmd - > operand_2明文16);

在app_task_handlers中处理结果:

(ke_msg_func_t) gapm_use_enc_block_ind_handler}, {GAPM_USE_ENC_BLOCK_IND

在app_task.c:

int gapm_use_enc_block_ind_handler (ke_msg_id_t是否,
struct gapm_use_enc_block_ind *参数,
ke_task_id_t dest_id,
ke_task_id_t src_id)

Memcpy (my_array, param, sizeof(struct gapm_use_enc_block_ind));
返回(KE_MSG_CONSUMED);


我没有得到密文69c4e0d86a7b0430d8cdb78070b4c55a(见http://seit.unsw.adfa.edu.au/staff/sites/lpb/src/AEScalc).
相反,我得到了一个以D0BFE1C7开头的缓冲区…

我做错什么了吗?
是简单的aes-ecb加密还是有IV ?

谢谢

——解决
一切都是逆转! !
反转密钥和明文后:

uint8_t关键[16]={15日,14日,13日,12日,11日,10、9、8、7、6、5、4、3、2、1、0};
uint8_t明文[16]= {0xFF, 0xEE, 0xDD, 0xCC, 0xBB, 0xAA, 0x99, 0x88, 0x77, 0x66, 0x55, 0x44, 0x33, 0x22, 0x11, 0x00};
struct gapm_use_enc_block_cmd *cmd = KE_MSG_ALLOC(gapm_use_enc_block_cmd, TASK_GAPM, TASK_APP, gapm_use_enc_block_cmd);
cmd - >操作= GAPM_USE_ENC_BLOCK;
关键,memcpy (cmd - > operand_1 16);
memcpy (cmd - > operand_2明文16);

我得到的结果是5AC5B47080B7CDD830047B6AD8E0C469,它是69c4e0d86a7b0430d8cdb78070b4c55a的反向。

因此,为了“正常”使用加密,我应该反转密钥,反转每个明文块,并反转结果……

summer20100514
离线
最后看到:4年1星期前
大师
加入:2014-12-30 05:01
你好,@oren,你能

你好@oren,你能把你的代码放出来吗,哪一个更详细?我尝试了您的代码,但得到了错误的结果,而不是相反。

summer20100514
离线
最后看到:4年1星期前
大师
加入:2014-12-30 05:01
对不起,我没读你的

抱歉,我之前没有仔细阅读你的帖子,现在我得到了你上面描述的正确答案。谢谢你的分享。