我有oracle数据库转移到新的postgresql服务器。
有些表具有字段敏感性，并且这些表都通过DBMS_OBFUSCATION_TOOLKIT.DESENCRYPT / DESDECRYPT加密。
问题出在这里。 postgresql的加密数据大小（bytea类型）的大小应该与oracle相同。
我试图用aes（加密/解密）完成它，它比原始数据大近三倍。（oracle使用des算法需要16byte，postgresql使用aby需要33byte而原始数据需要13byte。）
我也尝试过postgresql crypt，但是手册没有提到解密它的方式，限制了8byte的原始数据大小。
现在我真的需要加密方法，它采用尽可能小的加密数据大小，并提供解密方法。
对我来说有没有好方法或其他选择？ 提前谢谢。
答案 0 :(得分：6)
普通旧DES是一种过时的算法。你无法真正将它与AES128进行比较;这就像抱怨SHA256散列大于MD5散列 - 是的，但是只有其中一个可能会让攻击者慢下来一段时间。 DES是widely considered weak even in 1999，不应该在新的应用程序中使用。不要使用它。
我认为寻找“提供尽可能小的数据大小”的加密方法并不是一个好主意 - 因为使用DES加密数据基本上是浪费时间。为什么不使用ROT13（caesar cypher）？ “加密”结果与输入的大小相同，可惜加密可以被3岁的孩子打破。
crypt 具有类似的年份。旧UNIX crypt hashing algorithm是......老人......并且完全不适合任何新申请。哈希至少应该是SHA256。
至于无法弄清楚如何解密加密数据： crypt 不是加密算法，它是cryptographic hash function或“单向散列”。单向散列适用于验证数据未经修改，与存储的salted散列进行密码验证相比较，适用于challenge-response authentication等。您无法解密加密数据。
使用适当的加密功能，并随着尺寸的增加而生活。 bf或aes128是您可以合理使用的最弱的。
我个人更喜欢在应用程序中进行加密/解密，而不是在数据库中。如果在数据库中完成，则pg_stat_statements可以显示密钥，log_statement可以显示密钥，等等。更好的是，密钥永远不会与存储的数据位于同一位置。< / p>
大多数编程语言都有可以使用的良好加密例程。
很难提供更多建议，因为您还没有真正解释您的加密内容，原因，您的要求是什么，威胁是什么等等。
如果您正在存储密码，那么您可能做错了。
如果可能，请让其他人进行身份验证：
OAuth或OpenID for Internet
内部网的SSPI，Kerberos / GSSAPI，Active Directory，LDAP绑定，SASL，HTTP DIGEST等
如果您真的必须自己进行身份验证，请在密码中添加一个盐并对结果进行哈希处理。存储哈希和盐。如果必须比较密码，请使用与存储的哈希相同的盐对用户的新明文进行加盐，对新密码+ salt进行哈希处理，并查看哈希是否与存储的哈希值相同。如果是，他们会给出正确的密码。
您几乎肯定不需要恢复明文密码。实现安全密码重置。如果你真的必须使用像aes这样的安全算法加密它们并仔细考虑密钥存储和管理。请参阅有关使用pgcrypto进行密钥存储/管理的其他帖子。
另见：
答案 1 :(得分：1)
根据postgresql的构建方式，它可能在pgcrypto模块中具有DES支持。这取决于Postgres是否配置了OpenSSL支持，因为它依赖于OpenSSL来执行DES（与其他更现代的算法一起实现它们本身）。
如果包含openssl支持并且您将DES指定为encrypt和decrypt的算法，则数据应与从Oracle获得的数据相同（尽管您可能需要指定填充选项）。
正如Craig所说，DES算法很弱，其弱点之一是因为输出密文太小了。