4 ms·

Author here. I'd like to put it out there that pgsodium is relatively new work that hasn't seen any serious battle testing. At this point you should consider

Author here. I'd like to put it out there that pgsodium is relatively new work that hasn't seen any serious battle testing. At this point you should consider it more risky to use than pgcrypto, for now. That being said pgsodium is far less code than pgcrypto, it contains no algorithms or magic numbers, it's a straight no frills interface to libsodium which is a very well tested library based on solid cryptography. Also pgsodium has some features that pgcrypto doesn't have: - Public Key Signatures - Anonymous Sealed Boxes - Key Derivation Functions - Key Exchange - Server Managed Secret Keys Feel free to drop me any questions here!

stblack 6y ago
This is HN, where commenters liberally espouse variants and competitors. Props to you, the author of pgSodium, for being the first to mention pgCrypto. The extra features of PgSodium look handy. Is featureset the main reason you created PG sodium? Or are there other reasons, like performance, or interfaces, for example? New entrant risk aside, are there other reasons to maybe prefer pgCrypto at the moment?
- michelpp 6y ago
  I wrote pgjwt, a JWT implementation for Postgres, my primary motivation is that pgcrypto does not have public key signing, which is needed for JWT. Once I started experimenting with the one feature it sort of snowballed from there, I still haven't implemented public signing in pgjwt! To keep using pgcrypto? Well its got a lot of history, so its easy to find examples of its use. The documentation is decent. And it comes with most cloud providers where you are generally restricted from installing extensions like pgsodium. To not use pgcrypto? I'll use the words of a core PostgreSQL developer said recently on the pgsql-hackers mailing list: "I'd strongly advise against having any new infrastructure depend on pgcrypto. Its code quality imo is well below our standards and contains serious red flags like very outdated copies of cryptography algorithm implementations. I think we should consider deprecating and removing it, not expanding its use. It certainly shouldn't be involved in any potential disk encryption system at a later stage."
deleted 6y ago
[deleted]
deleted 6y ago
[deleted]

stblack 6y ago

This is HN, where commenters liberally espouse variants and competitors. Props to you, the author of pgSodium, for being the first to mention pgCrypto. The extra features of PgSodium look handy. Is featureset the main reason you created PG sodium? Or are there other reasons, like performance, or interfaces, for example? New entrant risk aside, are there other reasons to maybe prefer pgCrypto at the moment?

michelpp 6y ago
I wrote pgjwt, a JWT implementation for Postgres, my primary motivation is that pgcrypto does not have public key signing, which is needed for JWT. Once I started experimenting with the one feature it sort of snowballed from there, I still haven't implemented public signing in pgjwt! To keep using pgcrypto? Well its got a lot of history, so its easy to find examples of its use. The documentation is decent. And it comes with most cloud providers where you are generally restricted from installing extensions like pgsodium. To not use pgcrypto? I'll use the words of a core PostgreSQL developer said recently on the pgsql-hackers mailing list: "I'd strongly advise against having any new infrastructure depend on pgcrypto. Its code quality imo is well below our standards and contains serious red flags like very outdated copies of cryptography algorithm implementations. I think we should consider deprecating and removing it, not expanding its use. It certainly shouldn't be involved in any potential disk encryption system at a later stage."

deleted 6y ago

[deleted]

deleted 6y ago

[deleted]