blocks|key|2868003|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|entityMap^0^^$0|@$1|2|3|-4|4|5|6|B|7|@]|8|@]|9|$]]]|A|$]]

<blockquote>
 Does having a hash of a password jeopardize the security of plaintext that was encrypted with that password?
</blockquote>

As usual in password-based cryptography, we'll consider that the password was chosen from a relatively small set, small enough that password enumeration by an adversary can generate passwords including the one of a target user with fair probability, but large enough that additionally computing the (purposely slow) password hash for each password enumerated is too costly for the attacker.

Three cases must be distinguished.

<ol>
<li>If the password hash is directly the key of an encryption algorithm, having that password hash is having the encryption algorithm's key, and the security is compromised.</li>
<li>If the password (rather than its hash) is directly the key of a fast encryption algorithm, then the security is jeopardized by that, not by the disclosure of the password hash. Problem is, an adversary can enumerate passwords and test each to find the right key, under the standard assumption of availability of a suitable plaintext/ciphertext pair, or just ciphertext if plaintext is redundant.</li>
<li>If the password is processed thru a purposely slow password-to-key derivation function, either different from the one used for the password hash, or the same parametrized for independent results given the same password, then the encryption system is not compromised by the disclosure of the password hash, under the "large enough" hypothesis in preamble, which implies in practice that the password hash is quite slow, and [passwords are imposed to users, or [users are motivated to not have their password guessed, and neither lazy nor stupid]].</li>
</ol>

(There could in theory be something intermediary between 1 and 3, where the password hash gives a little usable info about the key; but that's unlikely. The closest is that, in a nightmare scenario, the only difference between the password hash and the key is more iterations for the later, and somewhat re-hashing the password hash gives the cipher's key; but neither PBKDF2, nor anything I have studied, has such weakness).

In conclusion:

<ul>
<li>Try hard to not let the password hashes leak: password hashing should be a second line of defense.</li>
<li>Make the results of the password-to-key derivation function and password-to-password-hash function independent (in the sense that one can't be efficiently found from the other). One way that works for most purposely-slow key-or-password derivation functions is to use a different salt, or different prefixes to the same salt (empty being a valid prefix).</li>
<li>Especially if you must use password-based encryption, take the password-to-key derivation seriously: use a memory-hard construction such as Argon2 or scrypt, and parametrize generously.</li>
</ul>

<hr>

Addition per <a href="https://crypto.stackexchange.com/posts/comments/179699">comment</a>:

<blockquote>
 Are there techniques to use password based encryption but at the same time, have confidence in 128 bit security ?
</blockquote>

The best we have combines

<ul>
<li>Sensitizing users to the choice of good passwords, perhaps starting with calling these "passphrase" instead. That simple and unobtrusive thing has gone miles in PGP.</li>
<li>Using <a href="https://en.wikipedia.org/wiki/Argon2" rel="nofollow noreferrer">Argon2</a> or other well-thought memory-hard iterated hash to transform password into key, before using it for standard encryption. Merely using a hash requiring sizable memory makes attack using GPUs, FPGAs and ASICs decimal orders of magnitude less attractive than they are to well-funded attackers targeting users of a plain iterated hash like PBKDF2. Password cracking is commonly assisted by GPUs, sometime by FPGAs. I have no hard evidence for ASICs, but technology and greedy mentality in cryptocurrencies are perfect fit.</li>
</ul>

See <a href="https://crypto.stackexchange.com/q/81098/555">this</a> for an exploratory idea: in addition to the above, with a lot of ifs, a memory-hard <a href="https://en.wikipedia.org/wiki/All-or-nothing_transform" rel="nofollow noreferrer">all-or-nothing transformation</a> of plaintext to ciphertext could force the adversary to decipher the whole file (or a sizable part of the start) in order to test a password. This could be useful to a degree for files of large but still common size.

Regarding the memory-hard iterated hashes: there are iteration, memory, and parallelism parameters to choose.

<ol>
<li>When we double the iterations (e.g. increase the user-perceived delay from 4 to 8 seconds),

<ul>
<li>Attackers are hit by a double of energy cost, and of time at constant investment.</li>
<li>Legitimate users also are hit by a sizable increase in energy cost/battery drain, beyond the delay. Thus that adds next to 1 bit of cryptanalytic resistance, but is a pain.</li>
</ul></li>
<li>When we double the memory (e.g. from 4 to 8 GiB), and that whole memory can be put to use within the delay, and a number of plausible assumptions hold, then

<ul>
<li>Attackers using specialized hardware are hit by a double of the time at constant RAM cost, and a RAM cost increase at constant time to a possibly lesser but still sizable degree.</li>
<li>Legitimate users gain some sizable fraction of a bit of key, quite painlessly until they hit the limits of available memory.</li>
</ul></li>
<li>When we double the number of CPUs used, which is possible to small (but increasing) degree, this has a chance of decreasing the user delay to some degree, and shouldn't harm much more than making the machine less responsive for other tacks, and noisier/hotter. Thus that can allow raising the iteration count, see 1. Also, for small delay, that may allow to increase the amount of memory actually used, see 2.</li>
</ol>

I wish I could rationally tell how better it is to use Argon2d vs directly using (a very fast hash of) the password in AES-128. But can't. Using hypothesis so wild that I won't state them, I get anywhere from +20 to +50 bits. One thing is sure: that can't stretch anywhere near to true 128-bit-ness most passwords chosen by a large sample of computer users.

<hr>

<blockquote>
 Is it time to move on to ECIES ?
</blockquote>

It does not solve that issue. Any good public-key encryption scheme solves the problem of confidentiality in key distribution, but not the problem of integrity in key distribution. And go figure how to use public-key to authenticate a human to a machine.

A malicious actor wants to decrypt ciphertext that was encrypted with a password. He also possesses the hash (bcrypt/PBKDF2) of that password. Does he have any significant practical advantage in decrypting that ciphertext as compared to just having the encrypted ciphertext (with no hash)?

I believe that the clear advantage would come from the ability of being able to do a dictionary attack, since the guessed passwords could be deterministically checked against the hash. However, I could not find or come up with any other advantage. How does this change the situation if the password used is stronger (making dictionary attacks less dangerous)?

Does having a hash of a password jeopardize the security of plaintext that was encrypted with that password?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云AI代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

功能1上新10个字符

功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符。

功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符。

功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符

功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符

功能4上新

文章&问答评论现已支持表情

全新交互，全新视觉，新增快捷键、悬浮工具栏、高亮块等功能并同时优化现有功能，全面提升创作效率和体验

社区富文本编辑器全新改版！诚邀体验～ 

精选全网热门MCP server，让你的AI更好用 🚀

💥开发者 MCP广场重磅上线！

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

恶意参与者希望解密用密码加密的密文。他还拥有该密码的哈希(bcrypt/PBKDF2 2)。与只有加密的密文(没有散列)相比，他在解密该密文方面有什么显著的实际优势吗？我认为，明显的优势在于能够进行字典攻击，因为猜测的密码可以根据哈希进行决定性的检查。然而，我找不到或想出任何其他优势。如果使用的密码更强(使字典攻击不那么危险)，这会如何改变这种情况？

问密码的散列是否会危及使用该密码加密的明文的安全性？
EN

回答 1

Cryptography用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问密码的散列是否会危及使用该密码加密的明文的安全性？EN