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.
---------------------------
确定   
---------------------------

参数Key是个指针指向Hmac的Key，KeyLength是64（如果大于64，则会针对整个Key做SHA256，以结果作为Key）
Input 和Length是待计算的内存块地址与长度。

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 编辑 ]

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

HMACSHA256加密后：25eab476e7eb3ad282161b3aa8c03a63263cb9dacf6470ab1fa8dfc73f939481

三方网页版计算结果：25eab476e7eb3ad282161b3aa8c03a63263cb9dacf6470ab1fa8dfc73f939481

中文还是有问题，数字和英文加密出来的一样，中文的就乱了，继续研究。。。

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

这样就没问题了。

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

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

微信开发签名用到HmacSHA256和md5，目前够用了，希望管理员有空看下没通过的几个算法，谢谢！

抱歉才看到帖子，我看一下楼主提到的问题。

写反的问题我们纠正过来了，不过不通过的那几个算法，不知楼主是在哪个网页上在线计算核对的？我们核对一下。

git上做了一些修改，hmacmd5，hmacsha1，hmacsha224，hmacsha256已经通过。384/512的还没有找到头绪。
有些网页上的计算本身就有误差，参考时要注意。

https://tools.ietf.org/html/rfc4231 这是RFC里头的HMAC数据供开发者校验，目前384/512还核对通不过。

谢谢，幸苦了！

github上，cnvcl，Examples\Crypt
第222行错误，pnlMd5.Caption := MD5Print(MD5StringA(AnsiString(edtFrom.Text));
应改为：pnlMd5.Caption := MD5Print(MD5StringA(AnsiString(edtMD5.Text)));

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

AES和DES，使用d10.2.1的system.utf8encode编码后，utf8正确了，这两个也测试通过。

刚把SHA384/512 Hmac的计算也修正通过了，参考的是https://tools.ietf.org/html/rfc4231里头的计算结果。最新的代码在git中。

例子中的edtFrom笔误也已修正，谢谢指出。

感谢管理员的幸勤工作！

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

另外，您在计算结果中添加换行符，好像没有意义吧？

例子里在结果中添加换行符是为了显示完整避免太长，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

这个测试用例。

我所能找到的网站，都进行了测试，它们的计算结果是相同的，HmacSHA224和HmacSHA384，这就有点麻烦了，会不会是RFC进行了协议更新？

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

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