在 .Net 中生成可打印的 HMAC 共享密钥

发布于 2024-10-05 07:33:00 字数 305 浏览 3 评论 0原文

我正在使用 HMACSHA512 使用共享密钥对数据进行哈希处理。由于密钥是共享的,我希望它全部是可打印字符,以便于传输。我想知道生成这些密钥的最佳方法是什么。

我当前正在使用 RNGCryptoServiceProvider 的 GetBytes() 方法生成密钥,但它返回的字节数组包含不可打印的字符。所以我想知道对结果进行 Base64 编码是否安全,或者这是否会过多地侵蚀随机性并使事情变得不那么安全?如果这不是一个好方法,你能推荐一个吗?

我确实明白,通过将键限制为可打印字符,我限制了键空间的整体宽度(即:砍掉 8 位中的 1 位),但我对此表示同意。

I'm using HMACSHA512 to hash data using a shared key. Since the key is shared I'd like for it to be all printable characters for ease of transport. I'm wondering what the best approach is to generating these keys.

I'm currently using the GetBytes() method of RNGCryptoServiceProvider to generate a key, but the byte array it returns contains non-printable characters. So I'm wondering if it is secure to base64 encode the result or does that erode the randomness too much and make things much less secure? If that isn't a good approach can you suggest one?

I do understand that by limiting the keys to printable characters I am limiting the overall breadth of the key space (ie: lopping off 1 of the 8 bits), but I am OK with that.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

萝莉病 2024-10-12 07:33:00

如果您可以处理不自动生成密钥的情况,则 http://www.grc.com/passwords 是非常随机的密钥材料的良好来源。

Base64 不会减少字节数组的底层熵。您可以生成密钥并以其原始形式使用它,但 Base64 对其进行编码以将其传输到您需要的位置。然后,您可以将其通过 Base64 解码回原始形式,然后再在新位置使用它。此操作中没有熵损失。 Base64编码将熵减少到每字节6位而不是8位,但编码的结果更长,因此总体熵是相同的。

另一种方法是获取 24 个随机字节以获得 192 位的熵。 Base64 编码会给你一个 32 个字符的字符串(256 位),它仍然具有原始的随机性和 192 位的熵。您可以直接使用它作为您的共享密钥。

If you can handle not auto-generating the key then http://www.grc.com/passwords is a good source of VERY random key material.

Base64 wouldn't reduce the underlying entropy of the byte array. You could generate the key and use it in its raw form, but Base64 encode it to transport it to where you need it to be. You'd then Base64 decode it back to the raw form before you use it in the new location. There is no loss of entropy in this operation. The Base64 encoding reduces the entropy to 6-bits per byte instead of 8, but the result of the coding is longer, so overall the entropy is the same.

The other way you could do it would be to get 24 random bytes for 192-bits worth of entropy. Base64 encoding this would give you a 32 character string (256-bits) which still has the original randomness and 192-bits of entropy. You could use this as your shared key directly.

愛放△進行李 2024-10-12 07:33:00

BASE64 转换字节序列,因此它仅使用某些可打印字符。

这种转换不会以任何方式改变信息,只是改变信息的存储方式。它也是可逆的:您可以通过解码 BASE64 输出来获得原始字节序列。

因此,使用 BASE64 不会“侵蚀随机性”或以任何方式限制密钥空间。

BASE64 transforms a byte sequence so it uses only certain printable characters.

This transformation does not change the information in any way, just how it is stored. It is also reversible: you can get the original byte sequence by decoding the BASE64 output.

So using BASE64 does not "erode the randomness" or limit the key space in any way.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文