问题标签 [message-digest]

以下是作为 DigitalSigning 处理程序一部分的代码

我启用了 SOAP 调用的日志记录，并提取了正在计算 SHA-256 形式的摘要的字符串。我使用相同的字符串来计算 c 中的摘要。以下是计算该值的 C++ 代码。这两个值都不同。

在这方面的任何帮助都会有所帮助。谢谢

我盲目地遵循了 OWASP 关于在 java 中生成哈希的建议（见这里），我不确定我是否正确地完成了它。具体来说，我不确定 的目的和效果MessageDigest.reset()，因此不确定何时以及如何使用它。

1. 我正在“加载”我的盐和有效负载，update()方法是多次使用不同的值对摘要进行处理，这些值完全需要签名。我应该reset()事先摘要吗？还是之后？
2. 为什么摘要reset()在循环中（参见示例）？

这是我的代码：

我观察到的是，即使在更改时签名也保持不变serialNumber。如果我省略了“reset（）”调用，sig 确实会改变......

MessageDigest.getInstance("MD5")在我直截了当地忽略可以抛出的检查异常之前，我想知道MD5摘要算法是否保证在所有Android设备中都可用。

我正在尝试将字符串列表中的两个字符串转换为 MD5 消息摘要。

我的字符串列表称为“用户名密码”。

我的问题是——

A：这是正确的做法吗？B：我将如何返回它以便我可以在另一个类中使用每个单独的 MD5 哈希？

我一直在尝试在 FreeBSD 9.1 系统上使用 sha256.h 中的 SHA_256 函数，但它似乎正在破坏我的程序的内存空间，从而导致各种躁狂行为。我编写了一个快速程序来使用这些功能，但仍然遇到问题。

在下面的示例中，当我调用 SHA256_Init() 时， int i发生了变化，如围绕它的printf()语句的输出所示。

这就是我运行代码的原因。

为什么这个值变成 32？我错过了什么吗？代码如下...

我需要在性能关键的环境中使用 MessageDigest 对来自多个线程的多个键进行哈希处理。我开始知道 MessageDigest 不是线程安全的，因为它将状态存储在它的对象中。实现键的线程安全散列的最佳方法是什么？

用例：

具体来说：

1. ThreadLocal 能保证工作吗？它会有性能损失吗？
2. getInstance 返回的对象是不是不同，互不干扰？文档说“新”对象，但我不确定它是否只是（共享）共享具体类的包装器？
3. 如果 getInstance() 返回“真实”新对象，是否建议每次需要计算哈希时都创建一个新实例？在性能损失方面 - 它的成本是多少？

我的用例非常简单——只需散列一个简单的键。我负担不起使用同步。

谢谢，

这究竟是做什么的？我试图查找它，但没有找到任何东西。

问的原因是我想将 SALTbyte[]合并到一个值中，然后对其进行哈希处理。所以应该这样做（伪代码）：

这是否将两者都添加SALT到value最终摘要中，还是应该将两个变量合并为一个，然后再合并update一次？

我在任何文档中都找不到这个答案，任何澄清将不胜感激。

谢谢你，干杯。

我最近尝试在 C 中使用 openssl 进行 MD4 散列：MD4 hash with openssl, save result into char array。我想再做一次，但现在使用EVP_Digest. 但是有了这段代码，我的核心就被抛弃了——为什么？

我有一个应用程序需要将文件传输到像 S3 这样的服务。

我有一个InputStream传入文件（不一定是 a FileInputStream），我将其写入InputStream由 a 表示的多部分请求正文，OutputStream然后我需要在末尾写入文件的哈希（也通过请求正文）。

多亏了DigestInputStream，我能够实时计算散列，因此在将文件主体发送到 之后OutputStream，散列变得可用并且也可以附加到多部分请求中。

你可以检查这个相关的问题： 什么是更便宜的哈希算法？

特别是我自己的基准答案： https ://stackoverflow.com/a/19160508/82609

因此，我自己的计算机似乎能够以MessageDigest500MB/s 的 MD5 吞吐量和近 200MB/s 的 SHA-512 吞吐量进行散列。

我写入请求正文的连接的吞吐量为 100MB/s。如果我以更高的吞吐量写入 OutputStream，OutputStream 开始阻塞（这是故意这样做的，因为我们确实希望保持较低的内存占用并且不希望字节在应用程序的某些部分累积）

我已经完成了测试，我可以清楚地注意到算法对我的应用程序性能的影响。

我尝试上传 20 个 50MB 的文件（总共 1Gb）。

• 使用 MD5，大约需要 16 秒
• 使用 SHA-512，大约需要 22 秒

在进行单次上传时，我还可以看到相同顺序的减速。

所以最后没有并行计算哈希和写入连接：这些步骤是按顺序完成的：

• 从流中请求字节
• 散列请求的字节
• 发送字节

因此，由于散列的吞吐量 > 连接吞吐量，有没有一种简单的方法可以不减慢速度？它需要额外的线程吗？

我认为下一个数据块可以在前一个块被写入连接期间被预先计算和散列，对吗？

这不是一个过早的优化，我们需要上传很多文件，执行时间对我们的业务来说是明智的。

MySQL 的 TO_BASE64 URL 安全吗？使用java，我可以编写以下代码：