加密32字节私钥的安全方法

Question

我在web应用程序的客户端使用32字节的EC私钥。这些密钥应该安全地存储在服务器数据库中。在用javascript发送到服务器之前，应该对密钥进行加密(AES)。当客户端已通过登录凭据进行身份验证时，密文将提供给客户端。然后，客户端将解密密文以获得私钥。

任何访问数据库密文的人都不应该能够导出私钥。

表面上看，欧洲央行似乎真的很好，因为私人密钥数据是伪随机的，但欧洲央行通常不会被推荐用于任何目的。在这种情况下，什么样的模式是合适的？从我所能看到的情况来看，CBC常常被用于类似的目的。

如果我使用GCM，客户总是能够认证密文吗？那么，如果客户端用特定的加密密钥加密了私钥，并且只保留了加密密钥，服务器就不能伪造使用相同密钥可解密的IV、身份验证标记和密文的组合？

我不确定这种身份验证是否有用，因为客户已经必须信任下载的客户端软件，但我认为这可能是一个“为什么不？”的问题。在这种情况下，使用GCM会有不利的一面吗？当然，需要存储更多的数据，但不是很多。

PBKDF2是导出密码AES密钥的一种合理方法，对吗？PBKDF2是否有任何弱点或其他算法的优点？

最后，我读过关于AES密钥包装算法的文章，尽管我对它不太了解，而且似乎没有很多开源实现。

Answer 1

SIV是为此目的专门设计的一种模式。SIV-AES将是一个不错的选择，但它有着与AES包装相同的问题；实现不多。如果你使用一个GCM，你应该确保IV是唯一的(如果你的明文从来不是随机的，否则你就会有问题)。

至于基于密码的密钥派生功能:是的，PBKDF2很好，迭代次数足够高。对于这类数据，我确实要确保pass短语有足够的熵。您可以考虑具有相对较高的内存使用率和可能附加的密钥访问限制/身份验证的scrypt。

Answer 2

1. 如果使用8字符密码加密私有密码，则解决方案的强度将不是32字节(256位)，而仅仅是8字节(32位)。以上"user4982“的评论是正确的。将加密过程做得更复杂并不会使其更安全。力量只取决于秘密的长度。在您的情况下，它将是私钥的密码。如果您不发送加密PK，没有人有机会拦截它，所以您的解决方案的强度将保持32字节(256位)。
2. 为什么要在服务器上保留私钥？为什么公钥不够？在服务器端，您将使用客户端的公钥加密文本，并将其发送给客户端。客户端将用他的私钥解密这个文本。您将在服务器端使用客户端的私钥做什么？
3. 如果您同意使用公钥，则根本不需要加密它。因为公钥应该是任何人都可以使用的。