1

我正在实现将响应 HTTP 请求的服务的一部分，我要支持的标头之一是Content-MD5. RFC规定了以下关于Content-MD5计算的内容：

为了生成 Content-MD5 字段的值，MD5 算法是根据 MIME 实体对象的规范形式计算的。特别是，这意味着发送方在转换为规范形式后立即对数据应用 MD5 算法，然后再应用任何内容传输编码，并且接收方也在撤消任何内容后对规范形式应用 MD5 算法。传输编码。对于文本数据，这意味着 MD5 算法必须在适用换行符的规范形式的数据上进行计算，也就是说，每个换行符都由一个 CR-LF 对表示。MIME 的规范编码模型在1的附录 G 中进行了描述。

MD5 算法的输出是一个 128 位的摘要。当以网络字节顺序（大端顺序）查看时，这会产生 16 个八位字节的二进制数据序列。然后根据 base64 算法对这 16 个八位字节进行编码，以获得放置在 Content-MD5 字段中的值。因此，如果对 MIME 实体的原始数据应用 MD5 算法导致摘要具有（不太可能）值为“检查完整性！”，则该 MIME 实体的标头可能包含该字段

   Content-MD5:  Q2hlY2sgSW50ZWdyaXR5IQ==

（这不是来自 HTTP RFC，但它被它引用）

在这个阶段我没有做任何内容传输编码，所以这应该很简单，但我没有得到我期望的结果：

using System;
using System.Security.Cryptography;
using System.Text;

  //somewhere in the file...
  MD5 md5 = MD5.Create();
  responseBody = Encoding.ASCII.GetBytes("Check Integrity!");
  var hash = md5.ComputeHash(responseBody);
  string encodedHash = Convert.ToBase64String(hash);
  //now the following is true:
  encodedHash == "nwqq6b6ua/tTDk7B5M184w=="

知道这段代码哪里出错了吗？

4

1 回答 1

2

代码没有问题，但我确实误读了 RFC：

因此，如果对 MIME 实体的原始数据应用 MD5 算法导致摘要具有（不太可能）值“检查完整性！” (...)

这"Check Integrity!"是（不太可能的）MD5 散列结果而不是被散列的响应。该字符串正好是 16 个 ASCII 字符长，这并非巧合。

更新后的验证码按预期运行：

var hash = Encoding.ASCII.GetBytes("Check Integrity!");
Assert.AreEqual(16, hash.Count()); // true
string encodedHash = Convert.ToBase64String(hash);
Assert.AreEqual(encodedHash, "Q2hlY2sgSW50ZWdyaXR5IQ=="); // true
于 2013-09-10T23:32:47.590 回答