重用身份验证密钥对来加密和解密数据
我们有一个 openssl/kerberos/openssh 用户身份验证，需要私钥和公钥对。
我需要登录并从数据库中获取一些数据。但我不允许以普通形式将数据存储在数据库中。 并且用于解密的私钥需要异地存储。
我们不想使用像 oracle、db2、mysql 等那样的透明数据加密，而是创建我们自己的。
我可以重新使用已有的密钥对，而不是添加另一个加密层。
这是为了符合存储敏感数据的 PCIDSS 要求。 https://www.pcisecuritystandards.org/security_standards/index.php
一些最佳实践建议真的很感激。
谢谢
We have a openssl/kerberos/openssh user-authentication which require a private and public keypair.
I need to log in and fetch some data from a database. But I'm not allowed to store the data in the database in plain form.
And the private key used to decrypt it needs to be stored offsite.
We do not want to use transparrent data encryption like in oracle,db2,mysql etc but create our own.
Instead of adding another encryption layer can I resue the keypair I already have.
This is to comply with PCIDSS requirements for storing sensitive data.
https://www.pcisecuritystandards.org/security_standards/index.php
Some best practice advices really appreciated.
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
通常不鼓励使用相同的密钥对进行身份验证和加密。这就是为什么 GnuPG 密钥实际上包含 2 个私钥。从密码学家的角度来看，您需要存储另一个密钥对进行加密或使用对称密钥进行数据加密。
您是否始终使用同一客户端读取和写入数据库内容？如果是这样，您可以使用对称加密并将密钥存储在客户端上。
Generally it is discouraged to use the same key pair for authentication and encryption. That is why a GnuPG key contains actually 2 private keys for instance. From the cryptographer's point of view you'll need to store another key pair for encryption or use a symmetric key for data encryption.
Do you read and write database contents with always the same client? If so, you can use a symmeric encryption and store the key on the client.
PCI 规模庞大，出错可能会毁掉一家企业，因此寻找专家可能是最好的选择。
也就是说，我的想法是：如果所有数据只需要加密以便只有场外方才能打开它，请使用良好的公钥密码系统来保存数据。 （充分阅读文档以确保库使用会话密钥加密数据，并使用远程方的公钥加密会话密钥。您永远不想使用以下方式加密数据公钥，只有会话密钥。）
如果所有数据都需要使用每个用户密钥存储，您也可以这样做，但 Kerberos 是专门为避免公钥密码系统而设计的 - 他们去了付出巨大的努力仅使用对称密码来构建几乎类似的东西。很聪明，但这可能意味着您甚至无法使用您希望使用的密钥（如果确实要求只有异地存储的密钥才能解密存储的密文）。
希望这有帮助。
PCI is huge and getting it wrong could destroy a business, so finding an expert might be best.
That said, here's my thoughts: If all data just needs to be encrypted so that only an off-site party can open it, use a good public key cryptosystem to save the data. (Read the documentation enough to make sure that the library encrypts the data with a session key, and encrypts the session key with the public key of the remote party. You don't ever want to encrypt data with a public key, only session keys.)
If all data needs to be stored with a per-user key, you can do that too, but Kerberos was designed specifically to avoid public key cryptosystems -- they went to a huge amount of effort to build something almost similar using only symmetric ciphers. Clever, but this might mean you can't even use the keys you were hoping to use (if the requirement really is that only an offsite-stored-key can decrypt the stored ciphertext).
Hope this helps.