Board logo

Subject: SHA256Hmac如何使用? [Print This Page]

Author: Star5    Time: 2017-9-30 12:06     Subject: SHA256Hmac如何使用?

procedure SHA256Hmac(Key: PAnsiChar; KeyLength: Integer; Input: PAnsiChar;
  Length: LongWord; var Output: TSHA256Digest);

请问这个如何使用?在d10.2.1中,报以下错误,应该是我用法不对。。。

PS:SHA256Print(SHA256StringA(AnsiString(edtSha256.Text)));是正常的,计算结果也正确。

---------------------------
Crypt/Decrypt DEMO
---------------------------
Access violation at address 005F9D68 in module 'Project1.exe'. Read of address 40404040.
---------------------------
确定   
---------------------------
Author: Passion    Time: 2017-9-30 14:31

参数Key是个指针指向Hmac的Key,KeyLength是64(如果大于64,则会针对整个Key做SHA256,以结果作为Key)
Input 和Length是待计算的内存块地址与长度。
Author: freecat    Time: 2017-9-30 14:47

procedure SHA1HmacInit(var Ctx: TSHA1Context; Key: PAnsiChar; KeyLength: Integer);
var
  I: Integer;
  Sum: TSHA1Digest;
begin
  if KeyLength > 64 then
  begin
    Sum := SHA1Buffer(Key, KeyLength);
    KeyLength := 32;
    Key := @(Sum[0]);
  end;

//  FillChar(Ctx.Ipad, $36, 64);
//  FillChar(Ctx.Opad, $5C, 64);
//全部HmacInit 相关的FillChar 都写反了.............................. x5你自己修改一下就行了. 这么大的bug怎么没人提?难道没人用?
  FillChar(Ctx.Ipad, 64, $36);
  FillChar(Ctx.Opad, 64, $5C);

  for I := 0 to KeyLength - 1 do
  begin
    Ctx.Ipad[I] := Byte(Ctx.Ipad[I] xor Byte(Key[I]));
    Ctx.Opad[I] := Byte(Ctx.Opad[I] xor Byte(Key[I]));
  end;

  SHA1Init(Ctx);
  SHA1Update(Ctx, @(Ctx.Ipad[0]), 64);
end;

[ 本帖最后由 freecat 于 2017-9-30 14:49 编辑 ]
Author: Star5    Time: 2017-9-30 15:28

在freecat的帮助下,已经解决,的确是代码写反了,CnSHA1.pas和CnSHA2.pas都需要修正一下,计算结果正常了。

HMACSHA256加密后:25eab476e7eb3ad282161b3aa8c03a63263cb9dacf6470ab1fa8dfc73f939481

三方网页版计算结果:25eab476e7eb3ad282161b3aa8c03a63263cb9dacf6470ab1fa8dfc73f939481
Author: Star5    Time: 2017-9-30 16:04

中文还是有问题,数字和英文加密出来的一样,中文的就乱了,继续研究。。。
Author: Star5    Time: 2017-9-30 17:55

中文不对,是因为网页版会因为页面编码受到影响,比如站长工具在线加解密是utf8格式的,所以中文转出来的结果是utf8的。

这样就没问题了。
Author: Star5    Time: 2017-9-30 19:54

汗~ 可能是运气吧,一开始试的就是HmacSHA256,英文、数字和utf8的中文,都正常了,并与其它工具生成的相同;
然后批量添加了HmacSHA1 HmacSHA224 HmacSHA384 HmacSHA512,以为全部搞定了,结果英文、数字和utf8的中文,一项也没能对上,对算法不太懂,这个需要管理员帮忙测试一下了,谢谢!

目前以下算法已经测试通过,d10.2.1下,中文为utf8编码:
SHA1 SHA224 SHA256 SHA384 SHA512 HmacSHA256
没通过的:
HmacSHA224 HmacSHA384 HmacSHA512

微信开发签名用到HmacSHA256和md5,目前够用了,希望管理员有空看下没通过的几个算法,谢谢!
Author: Passion    Time: 2017-10-17 21:18

抱歉才看到帖子,我看一下楼主提到的问题。
Author: Passion    Time: 2017-10-17 22:10

写反的问题我们纠正过来了,不过不通过的那几个算法,不知楼主是在哪个网页上在线计算核对的?我们核对一下。
Author: Passion    Time: 2017-10-18 23:45

git上做了一些修改,hmacmd5,hmacsha1,hmacsha224,hmacsha256已经通过。384/512的还没有找到头绪。
有些网页上的计算本身就有误差,参考时要注意。
Author: Passion    Time: 2017-10-19 17:28

https://tools.ietf.org/html/rfc4231 这是RFC里头的HMAC数据供开发者校验,目前384/512还核对通不过。
Author: Star5    Time: 2017-10-20 08:30

谢谢,幸苦了!
Author: Star5    Time: 2017-10-26 09:57

github上,cnvcl,Examples\Crypt
第222行错误,pnlMd5.Caption := MD5Print(MD5StringA(AnsiString(edtFrom.Text));
应改为:pnlMd5.Caption := MD5Print(MD5StringA(AnsiString(edtMD5.Text)));
Author: Star5    Time: 2017-10-26 11:41

今天测试了一下,情况如下:
HmacMD5、HmacSHA1、HmacSHA256 测试通过;
HmacSHA224、HmacSHA384、HmacSHA512 结果不正确,其中HmacSHA384结果一直在变。。。

AES和DES,使用d10.2.1的system.utf8encode编码后,utf8正确了,这两个也测试通过。
Author: Passion    Time: 2017-10-31 23:57

刚把SHA384/512 Hmac的计算也修正通过了,参考的是https://tools.ietf.org/html/rfc4231里头的计算结果。最新的代码在git中。
Author: Passion    Time: 2017-11-1 00:00

例子中的edtFrom笔误也已修正,谢谢指出。
Author: Star5    Time: 2017-11-1 09:12

感谢管理员的幸勤工作!

本次测试结果如下:(与站长之家、JSONS在线等网站核对)
测试内容 测试AbC123
测试编码 UTF8
测试通过 AES、DES、MD5、SHA1、SHA224、SHA256、SHA384、SHA512、BASE64、HmacMD5、HmacSHA1、HmacSHA256、HmacSHA512
结果错误 HmacSHA224、HmacSHA384

另外,您在计算结果中添加换行符,好像没有意义吧?
Author: Passion    Time: 2017-11-1 19:59

例子里在结果中添加换行符是为了显示完整避免太长,CnSHA2.pas中没添加。

HmacSHA224、HmacSHA384的有可能是网站计算有误,可以核对一下RFC中的:

   Test with a key shorter than the length of the HMAC output.

   Key =          4a656665                          ("Jefe")
   Data =         7768617420646f2079612077616e7420  ("what do ya want ")
                  666f72206e6f7468696e673f          ("for nothing?")

   HMAC-SHA-224 = a30e01098bc6dbbf45690f3a7e9e6d0f
                  8bbea2a39e6148008fd05e44
   HMAC-SHA-256 = 5bdcc146bf60754e6a042426089575c7
                  5a003f089d2739839dec58b964ec3843
   HMAC-SHA-384 = af45d2e376484031617f78d2b58a6b1b
                  9c7ef464f5a01b47e42ec3736322445e
                  8e2240ca5e69e2c78b3239ecfab21649
   HMAC-SHA-512 = 164b7a7bfcf819e2e395fbe73b56e0a3
                  87bd64222e831fd610270cd7ea250554
                  9758bf75c05a994a6d034f65f8f0e6fd
                  caeab1a34d4a6b4b636e070a38bce737

这个测试用例。
Author: Star5    Time: 2017-11-2 09:33

我所能找到的网站,都进行了测试,它们的计算结果是相同的,HmacSHA224和HmacSHA384,这就有点麻烦了,会不会是RFC进行了协议更新?
Author: Passion    Time: 2017-11-2 10:38

我也找过几个,也有点疑惑。像国外的https://www.freeformatter.com/hmac-generator.htmlhttps://www.liavaag.org/English/SHA-Generator/HMAC/ 这两个算出来的都是符合RFC的,但国内的几个站长什么的网站,似乎都是用的同一套带错的JS库,导致算出来的不对头。

这块的RFC照理不会随便更新,即使更新也不会只更新224/384,有可能是出错的JS库里对224、384的块尺寸或长度什么的判断有误,毕竟不是256、512这种整的。
Author: Star5    Time: 2017-11-2 11:30

先按目前的算法为准吧,目前没有224/384的接口可供测试,还是参考国外网站的结果为准先,国内那些网站抄来抄去的,有错误也是正常的。

谢谢管理员的劳动!
Author: Passion    Time: 2017-11-2 21:11






Welcome to CnPack Forum (http://bbs.cnpack.org/) Powered by Discuz! 5.0.0