虽然很感兴趣，但我只是信息安全方面的专家，如果我的问题很愚蠢，请将我重定向到任何有用的资源，或者如果我的假设错误，请纠正我。
在阅读Keepass Security 页面时，在我看来，从用户输入的密码（假设没有使用密钥文件或 Windows 用户帐户）生成实际用于加密 kdbx 文件的密码的工作流程如下：
N使用来自 2 的密钥对来自 1 的哈希进行加密然后，4 的输出是实际用于加密数据库的密钥。
我想知道的是：为什么要以明文和加密方式存储密钥？为什么不干脆省略步骤2,3和散列用户输入的密码N（或者也许C*N，与C为AES加密和SHA-256散列之间的时间关系）的时间？我很确定我在这里忽略了一些重要的事情，如果你能启发我，我将不胜感激。
[披露：我为 1Password 的制造商 AgileBits 工作]
我的历史可能在这里错了，但我相信 KeePass 旨在与 PasswordSafe 数据库一起使用，并且 PasswordSafe 是在 PBKDF2 普遍采用之前设计的。所以我们在这里看到的是一种“本土”方法来完成 PBKDF2 旨在完成的工作。（当然 PBKDF2 并不理想，这就是世界正在寻找继任者的原因）。
选择 AES（在 KeePass 中）而不是 HMAC（通常在 PBKDF2 中使用）作为每一轮的 PRF 并没有太大的区别，因为两者都是 PRF。事实上，PBKDF2 可以在这种模式下使用（尽管我只见过它与 HMAC 一起使用）。
有趣的是，这两种方案都存在为 PRF 使用恒定键/盐的问题。这现在被认为是 PBKDF2 的一个（小）问题（在较大的问题中）。
因此，从我的脑海中，仅根据您上面的描述，我认为该方案并不比 PBKDF2 更差（尽管也好一点）。就派生密钥大小的灵活性而言，它不如 PBKDF2 通用，但这可能是一件好事。除此之外，它的优点和缺点似乎（再次，只是随便一瞥）与 PBKDF2-HMAC 非常相似。
多年来，我已经从将 PBKDF2 描述为“花生酱也让狗保持友好”到“人们的婴儿也保持 Dingos Feed”。尽管如此，我们仍然（小心地）在 1Password 中使用它，但我们急切地等待PBKDF2、scrypt 和 bcrypt 的继任者。
KeePass 所做的似乎是自定义密码散列，使用 AES 加密作为过程的一部分。此处的 AES 密钥起着salt的作用。salt 是一个非秘密参数，它选择用于处理输入密码的实际函数（即，没有一个散列函数，而是一个全族，salt 告诉您要使用哪个函数）。Salts 可以阻止预先计算的表，并且更一般地说，防止攻击实例之间的成本分摊：攻击者不能重用用于破解一个散列密码到另一个散列密码的工作，因为另一个散列密码使用不同的盐。
那里有更多关于密码散列函数的理论和实践。
KeePass 功能似乎是一些自定义设计，这（一般来说）是一件坏事。此外，它基于AES，因此攻击者可以通过使用包含AES-NI操作码的PC（即基本PC）来加速攻击。