我有 oracle 数据库可以转移到新的 postgresql 服务器。
一些表具有字段敏感，并且这些表都通过 DBMS_OBFUSCATION_TOOLKIT.DESENCRYPT/DESDECRYPT 加密。
问题就在这里。postgresql的加密数据大小（bytea类型）应该和oracle的一样。
我试图用 aes（加密/解密）来完成它，它几乎是原始数据的三倍。（oracle 使用 des 算法需要 16 字节，postgresql 使用 aes 需要 33 字节，原始数据是 13 字节。）
我也尝试了 postgresql crypt，但手册没有提到将其解密的方式，限制了 8 字节的原始数据大小。
现在我真的需要加密方法，它需要尽可能小的加密数据大小并提供解密方法。
有什么好方法或其他选择吗？？？提前致谢。
普通的旧 DES 是一种过时的算法。您无法将其与 AES128 进行比较。这就像抱怨 SHA256 哈希值比 MD5 哈希值大 - 是的，但其中只有一个可能会在一段时间内减慢攻击者的速度。即使在 1999 年， DES 也被广泛认为是弱的，永远不应该在新的应用中使用。不要使用它。
我认为寻求“提供尽可能小的数据大小”的加密方法不是一个好主意——因为使用 DES 加密数据基本上是浪费时间。为什么不使用 ROT13（凯撒密码）？“加密”结果与输入的大小相同，可惜加密可以被 3 岁的孩子破解。
crypt是类似的年份。旧的UNIX crypt 散列算法......老旧......并且完全不适合任何新应用程序。哈希应该至少是 SHA256，真的。
至于无法弄清楚如何解密加密数据：crypt不是加密算法，它是加密哈希函数或“单向哈希”。一种方法哈希适用于验证数据未修改，与存储的加盐哈希相比，用于密码身份验证，用于质询-响应身份验证等。您无法解密加密数据。
使用体面的加密功能并适应大小的增加。bf或者aes128是您可以合理使用的最弱的。
就个人而言，我更喜欢在应用程序中进行加密/解密，而不是在数据库中。如果它是在数据库中完成的，则密钥可以通过pg_stat_statements、在日志中通过log_statement或错误等来显示。更好的是，密钥永远不会与存储的数据在同一个地方。
大多数编程语言都有很好的加密例程可以使用。
很难提供更多建议，因为您还没有真正解释您正在加密的内容、原因、您的要求是什么、威胁是什么等。
如果您要存储密码，那么您可能做错了。
如果可能，让其他人进行身份验证：
互联网的 OAuth 或 OpenID
用于 Intranet 的 SSPI、Kerberos/GSSAPI、Active Directory、LDAP 绑定、SASL、HTTP DIGEST 等
如果您真的必须自己进行身份验证，请在密码中添加盐并对结果进行哈希处理。存储哈希和盐。当您必须比较密码时，使用您用于存储散列的相同盐对来自用户的新明文加盐，散列新密码+盐，并查看散列是否与您存储的相同。如果是，他们给出了正确的密码。
您几乎可以肯定不需要恢复明文密码。改为实施安全密码重置。如果你真的，真的必须，使用像 aes 这样相当安全的算法来加密它们，并仔细考虑密钥存储和管理。请参阅 SO 上有关使用 pgcrypto 进行密钥存储/管理的其他帖子。
也可以看看：
根据您的 postgresql 的构建方式，它可能在 pgcrypto 模块中具有 DES 支持。这取决于 Postgres 是否配置了 OpenSSL 支持，因为它依赖 OpenSSL 来执行 DES（而使用其他更现代的算法，它自己实现它们）。
如果包含 openssl 支持并且您将 DES 指定为encryptand的算法decrypt，则数据应该与您从 Oracle 获得的数据相同（尽管您可能需要指定填充选项）。
正如 Craig 所说，DES 算法很弱，它弱的原因之一是因为输出密文太小了。