我将如何实施关键强化(NOT Key Stretching)-忘掉随机盐 [英] How would I implement key Strengthening (NOT Key Stretching) -- Forgetting the Random Salt

查看:207
本文介绍了我将如何实施关键强化(NOT Key Stretching)-忘掉随机盐的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

您好,有人最好用C#演示代码,其次是在Delphi/Pascal中,关于如何实现密钥加强而不是像Wikipedia上解释的那样进行密钥扩展.

我的想法是使用随机或密码随机函数生成 x 个字节(SALT).
但是,我不必处理/哈希SALT并就正确答案是什么留下一些提示.因为如果我不知道正确答案是什么,我将如何强行使用正确的随机字节/SALT?

以及如何以这样一种方式来表明线索,即我是随机字节/SALT的原始创建者,而不是让竞争方也试图强行使用随机字节/SALT的优势.

另外,如何确定 x 字节数的大小必须始终固定?看到字节数越大,用暴力破解重新创建字节所花费的时间就越长.

我坐在这里是一个假设的想法,不需要任何加密.

任何答复都将受到欢迎.

Hi does somebody have some demo code preferably in C# or secondly in Delphi/Pascal on how I could implement Key Strengthening and not Key Stretching like it is explained on Wikipedia.

My Idea was using a random or cryptographic random function to generate x amount of bytes(SALT).
However would I not have to process/hash the SALT and leave some hint as to what the correct answer is. Because how will I brute force the correct random bytes/SALT if I do not leave a clue to what the correct answer is ?

And how do I make the clue in such a way that I the original creator of the random bytes/SALT have an advantage over lets say a competing party which is also trying to brute force the random bytes/SALT.

Also how do I determine the size of x amount of bytes must they always be fixed ? Seeing that the larger the amount of bytes the longer it will take to brute force recreate them.

This is a hypothetical idea I am sitting with not a requirement for any encryption.

Any replies will be welcome.

推荐答案

它不会加强它.

随机添加盐的原因是为了防止创建彩虹表.如果您使用衍生盐,则会削弱加密效果.

例如,它将呈现GetSalt("Foo")的结果为"Bar".但这永远是酒吧"!没有什么随机的.因此始终只有一种盐,由于它们之间是一对一的关系,因此很容易再次使用彩虹表.

祝你好运!
It wouldn''t strengthen it.

The reason for the random salt is to prevent creating a rainbow table. If you use a derived salt you would weaken the encryption.

For example, it would render the result of GetSalt("Foo") to be "Bar". But it would always be "Bar"! There is nothing random about it. So there is always just a single salt making it very easy to use rainbow tables again because of the 1 on 1 relation between them.

Good luck!


我想我会尝试通过以下方式解决此问题.
Step.1获取KEY表单用户.
Step.2生成随机SALT.
Step.3将KEY和SALT用于任何加密目的.
步骤4散列盐. (任何SHA-3哈希都足够.)
Step.5使用KEY加密哈希.
Step.6永久删除HASH.

但是,这迫使用户将SALT的加密HASH与新加密的文本一起存储.
我认为这没有问题,因为以下情况适用. SALT实际上是随机的,可以通过任何方法得出. SALT的HASH是经过加密的,因此任何可能的攻击者都必须首先获得正确的HASH,而不能获得随机生成的SALT.但是,这将迫使用户也开始强行强制随机SALT,因为哈希是一种单向函数.

据我所知,我认为这会起作用.
I think I will attempt to solve this in the following way.
Step.1 Get KEY form user.
Step.2 Generate random SALT.
Step.3 Use KEY and SALT for whatever cryptographic purpose.
Step.4 Hash SALT. (Any SHA-3 hash should suffice.)
Step.5 Encrypt Hash with KEY.
Step.6 Permanently delete HASH.

This however forces the user to store the encrypted HASH of the SALT with the newly encrypted text.
I can see no problem with this as the following applies. The SALT is truly random and derived via any method. The HASH of the SALT is encrypted so that any possible attacker would first have to derive the correct HASH without he cannot derive the randomly generated SALT. This will however force the user also to start brute forcing the random SALT as hashing is a one way function.

To the best of my knowledge I think this will work.


这篇关于我将如何实施关键强化(NOT Key Stretching)-忘掉随机盐的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆