libsodium-signcryption VS postgrest-js

I like the "solve the now" perspective here, and having code examples is very helpful to understand some of the rational behind the approach. Having read your previous "tedious survey"[0] post on various token formats, I generally agree with a lot of your conclusions. Curious though about your thought process wrt macaroons vs biscuits.

To me the one major downside of macaroons has always been the single shared root symmetric key. Many use cases are addressed by third party attenuation, but then there are the problems like key rotation, having to do online verification, no built in encryption, no peer-to-peer support through an "untrusted" fly.io, and no third party token verification without decryption like in signcryption[1] schemes. Of course this is traded off by having to do PK issuance and management so I can see the simplicity of it.

Is fly.io scoping this pretty hard to just auth tokens with third party attenuation, or do you see further development and maybe moving to other token systems like biscuit when/if the need arises to address those known issues?

fwiw I've done a bit of research work myself on a token format using signcryption [2] where I explored addressing some of these ideas (but not the attenuation side of it yet, which I get is a big deal here).

[0] https://fly.io/blog/api-tokens-a-tedious-survey/

[1] https://github.com/jedisct1/libsodium-signcryption

[2] https://github.com/michelp/pgsodium/blob/feat/signcryption-t...

You've hit the nail right on the head with this question on how hard group encryption is, and we don't have all the answers yet as we are still working the use cases around it. We are hoping to reach a level of security that you mention in your SE question using something similar to the excellent accepted answer, distributed private key sharing among trusted participants.

The basis we are exploring is using an algorithm called Signcryption (https://github.com/jedisct1/libsodium-signcryption) that is already included in pgsodium. This doesn't solve any of the shared private key issues you mention above, but it is a useful foundation for distributing encrypted messages that separate out sender and receiver identifiers from their keys, a sort of lower level foundation on top of which distributed key sharing can occur.

I also think signcryption is a great foundation for a better token format than JWT or PASETO, as it covers all of their use cases without algorithm confusion attacks (despite PASETO's insistence on "Algorithm Lucidity") and supports more features such as third party verification and streaming shared key generation from any token without having to exchange the key, we hope to use these tokens so that end-to-end peers can exchange tokens, derive streaming shared keys, and then do direct point-to-point message exchange using libsodium crypto_secretstream API which supports key ratcheting for forward secrecy.

Would love to discuss more about your research with you and include it with attribution into our future work, send me an intro at [email protected] when any other ideas or resources you'd like us to see!

Another signcryption scheme as described in the article is also implemented by the libsodium author as an extension:

https://github.com/jedisct1/libsodium-signcryption

It's unclear from the article if this is the same algorithm age uses.

Signcryption schemes are also a good candidate algorithm for replacing JWTs and PASETO as they suffer from no algorithm confusion, and don't need what PASETO calls "Algorithm Lucidity" and serve both plaintext authentication, authenticated encryption, sender receiver verification, and shared key generation that can be used for unlimited encrypted streaming, for example with libsodium's crypto_secretstream API.

https://doc.libsodium.org/secret-key_cryptography/secretstre...

https://github.com/paseto-standard/paseto-spec/blob/master/d...

* Support for [SignCryption](https://github.com/jedisct1/libsodium-signcryption) Sign & Encrypt identity verification. Signcryption goes beyond public key verification to provide identity verification, and negotiating a shared-secret key between two parties to use fast streaming encryption of the payload.

From Mike's comments on Reddit[0]

pgsodium 2.0.0 is a postgres extension that uses the libsodium library to provide high-performance, modern cryptography support for PostgreSQL 10+.

2.0.0 includes a ton of new feature and a few bug-fixes:

* Support for XChaCha20-SIV[2] deterministic nonce-free encryption

* Support for SignCryption[3] Sign & Encrypt identity verification

* Key id support for HMACSHA 512/256, generichash, and shorthash

* Support for low level XChaCha20 streaming[4]

* More tests, docs, and small bug fixes in argument parsing

* In-memory key now protected with sodium_malloc[5]

[0] https://www.reddit.com/r/PostgreSQL/comments/s0b6o2/pgsodium...

[1] https://doc.libsodium.org/

[2] https://github.com/jedisct1/libsodium-xchacha20-siv

[3] https://github.com/jedisct1/libsodium-signcryption

[4] https://libsodium.gitbook.io/doc/advanced/stream_ciphers/xch...

[5] https://libsodium.gitbook.io/doc/memory_management

Support for SignCryption Sign & Encrypt identity verification

At one point, I really thought it was used in Supabase. But I guess they only wrote the js wrapper for it. https://github.com/supabase/postgrest-js

Came here to mention Hasura as well (not sure of it's popularity though) https://hasura.io/graphql/database/postgresql

Min/Max looks like it still has to be done via RPC (with sample code here) https://github.com/supabase/postgrest-js/issues/206

There's nothing wrong with this and they're pretty open about it. But the SDK they provide for direct database operations is the weakest of the ones I've used, when it should be the strongest I think. It leverages PostgREST which is a tool for auto generating REST APIs from schemas. From the README: "The goal of this library is to make an "ORM-like" restful interface."

Looks like there's an open github issue that might answer some of your questions: https://github.com/supabase/postgrest-js/issues/303

I think it’s great too. I wish they would shore up some of their existing releases though. Probably most notably, the ability to query aggregates via the officially supported route is missing: https://github.com/supabase/postgrest-js/issues/206

The workarounds suggested are not ergonomic for most use cases and it feels pretty out of place for such basic functionality to be missing in what otherwise feels like a pretty full featured product.

Their Realtime product is another example of something that languishes while new features get launched.

I haven't completely understood what you are looking for but I think Supabase could be potential useful alternative backend for you supabase.io ?

I used postgrest-js to communicate with my PostgREST endpoint. The library is easy to use and does everything for you.

yes you're right. The JS library is a thin wrapper around PostgREST's API (https://github.com/supabase/postgrest-js)

Supabase now offers a few more features which integrate with the Postgres database - File Storage (s3), Authentication, Deno Functions, and Realtime (database change listeners). Each of these services is a standalone server and each has a corresponding JS library.

"supabase-js" wraps up the modular JS libraries into a single library for convenience

* Swift Libraries are now underway thanks to @satishbabariya [2]

We still have a long way to go for mobile support, but the Apple logins is a big one. If you ship an app to the App Store with any third-party logins, you're required to enable Apple logins as well. While this sounds like a bit of over-reach, it's actually quite cool - if you use Apple login they obfuscate your email so that the 3rd party app don't get access to your personal data. Quite nice!

[0] CSV: https://github.com/supabase/postgrest-js/pull/187