原像攻击的成本

发布于 2024-09-07 08:39:36 字数 205 浏览 4 评论 0原文

我需要知道成功进行原像攻击的成本(“在密码学中,对加密哈希的原像攻击是试图找到具有特定哈希值的消息。”,维基百科)。

我想要散列的消息由六位数字(出生日期)组成,然后是四位随机数字。这是社会安全号码。

是否还可以使用特定密码对某些内容进行哈希处理。这将引入另一层安全性,因为人们必须知道密码才能为消息生成相同的哈希值。

我正在考虑使用 SHA-2。

I need to know the cost of succeeding with a Preimage attack ("In cryptography, a preimage attack on a cryptographic hash is an attempt to find a message that has a specific hash value.", Wikipedia).

The message I want to hash consists of six digits (the date of birth), then four random digits. This is a social security number.

Is there also a possibility to hash something using a specific password. This would introduce another layer of security as one would have to know the password in order to produce the same hash values for a message.

I am thinking about using SHA-2.

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

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

发布评论

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

评论(3

深府石板幽径 2024-09-14 08:39:36

如果您想知道为您所描述的字符串找到原像的成本有多大,您需要计算出有多少种可能的字符串。由于前 6 位数字是出生日期,因此它们的值比 10^6 的天真假设更受限制 - 我们的上限为 366*100(一年中的每一天,加上两位数年份)。

剩下的 4 个“随机”数字允许另外 10^4 种可能性,给出的不同哈希总数为 366 * 100 * 10^4 = 366,000,000 个哈希。

有了这几种可能性,在现代计算机上应该可以在不到一秒的时间内找到原像,或者就此而言,为每个可能的散列建立一个查找表。

正如汤姆建议的那样,使用盐将使查找表变得不切实际,但由于有效值的范围如此有限,暴力攻击仍然非常实用,因此仅凭它还不足以使攻击变得不切实际。

使事情变得更昂贵的一种方法是使用迭代散列 - 即散列散列,然后重复散列该散列。您必须比攻击者进行更少的哈希处理,因此成本的增加对他们的影响比对您的影响更大。然而,鉴于搜索空间较小,这仍然可能只是权宜之计。

就“使用密码”而言,听起来您正在寻找 HMAC - 使用哈希的构造,但只有在您拥有密钥时才能进行验证。如果您可以保守密钥的秘密(如果您假设只有系统一开始就受到损害才能获得哈希值,那么这不是一件容易的事)——这就是一个实用的系统。

编辑:好的,所以“几分之一秒”可能有点夸张,至少对于我的简单 Python 测试来说是这样。然而,在短时间内对一台计算机进行暴力破解仍然是完全容易的。

If you want to know how expensive it is to find a preimage for the string you're describing, you need to figure out how many possible strings there are. Since the first 6 digits are a date of birth, their value is even more restricted than the naive assumption of 10^6 - we have an upper bound of 366*100 (every day of the year, plus the two digit year).

The remaining 4 'random' digits permit another 10^4 possibilities, giving a total number of distinct hashes of 366 * 100 * 10^4 = 366,000,000 hashes.

With that few possibilities, it ought to be possible to find a preimage in a fraction of a second on a modern computer - or, for that matter, to build a lookup table for every possible hash.

Using a salt, as Tom suggests, will make a lookup table impractical, but with such a restricted range of valid values, a brute force attack is still eminently practical, so it alone is not sufficient to make the attack impractical.

One way to make things more expensive is to use iterative hashing - that is, hash the hash, and hash that, repeatedly. You have to do a lot less hashing than your attacker does, so increases in cost affect them more than they do you. This is still likely to be only a stopgap given the small search space, however.

As far as "using a password" goes, it sounds like you're looking for an HMAC - a construction that uses a hash, but can only be verified if you have the key. If you can keep the key secret - no easy task if you're assuming the hashes can only be obtained if your system is compromised in the first place - this is a practical system.

Edit: Okay, so 'fractions of a second' may have been a slight exaggeration, at least with my trivial Python test. It's still perfectly tractable to bruteforce on a single computer in a short timeframe, however.

温折酒 2024-09-14 08:39:36

SHA-2、盐、原像攻击、暴力破解受限制的 6 位数字 - 如果我们有一个可以转动的旋钮来调整安全性,那就太棒了。像这样的事情:

Time to compute a hash of an input:
 SHA-2, salted                                Better security!
  |                                            |
 \|/                                          \|/
 |-----------------------------------------------------|
.01 seconds                                           3 seconds

如果我们能够做到这一点,那么您的应用程序在验证用户输入的数据是否与您散列的数据匹配时,实际上会慢几秒钟。

但想象一下自己是攻击者!

太棒了,他正在使用盐对东西进行哈希处理,但只有 366,000,000 种可能的哈希值,我将以每秒 10,000 次的速度快速完成此操作,并在大约 10 小时内完成!

等等,这是怎么回事!我每 2.5 秒只能做 1 次?!这将花费我 29 年的时间!!

那会很棒,不是吗?

当然会。

我向您展示: scrypt 和 < a href="http://chargen.matasano.com/chargen/2007/9/7/enough-with-the-rainbow-tables-what-you-need-to-know-about-s.html" rel= “nofollow noreferrer”>bcrypt。他们给你那个拨号盘。想花一分钟的时间来散列密码吗?他们可以做到这一点。 (只要确保记住盐即可!)

SHA-2, salts, preimage atttacks, brute forcing a restricted, 6-digit number - man it would be awesome if we have a dial we could turn that would let us adjust the security. Something like this:

Time to compute a hash of an input:
 SHA-2, salted                                Better security!
  |                                            |
 \|/                                          \|/
 |-----------------------------------------------------|
.01 seconds                                           3 seconds

If we could do this, your application, when verifying that the user entered data matches what you have hashed, would in fact be a few seconds slower.

But imagine being the attacker!

Awesome, he's hashing stuff using a salt, but there's only 366,000,000 possible hashes, I'm gonna blaze through this at 10,000 a second and finish in ~10 hours!

Wait, what's going on! I can only do 1 every 2.5 seconds?! This is going to take me 29 years!!

That would be awesome, wouldn't it?

Sure would.

I present unto you: scrypt and bcrypt. They give you that dial. Want to spend a whole minute hashing a password? They can do that. (Just make sure you remember the salt!)

堇色安年 2024-09-14 08:39:36

我不确定您的问题到底是什么,但为了使您的加密值更安全,请使用 值。

编辑:我认为您在问题中描述了盐值。

I'm unsure what your question is exactly, but to make your encrypted value more secure, use salt values.

Edit: I think you are sort of describing salt values in your question.

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