pgsodium
enclaver
pgsodium | enclaver | |
---|---|---|
15 | 8 | |
509 | 119 | |
- | 4.2% | |
4.4 | 8.1 | |
10 days ago | 3 months ago | |
C | Rust | |
GNU General Public License v3.0 or later | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
pgsodium
-
Macaroons Escalated Quickly
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...
-
PostgreSQL Encryption: The Available Options
pg_sodium [1] is another great options for transparent (column level!) encryption. Its integrated with Supabase [2] if you want to give it a try
[1] https://github.com/michelp/pgsodium
-
Update - I built an app that analyses your worries and challenges your thoughts, looking for feedback
Yes! Concerning privacy: The entries are saved in Supabase and encrypted with pgsodium. I think there's a lot more to privacy, though – currently working on other safety measures like anonymization that I'll include before scaling. What sets the app apart: I have built the app specifically to integrate therapy tactics into your daily life and to make them a habit (e. g. if you talk to ChatGPT or Wysa it tells you what tactics to integrate and learn about them, with my app you actually integrate them) => less about learning, more about doing.
-
I built an app that helped me move on by teaching me how to react differently to my thoughts.
Valid concern. The entries are saved in Supabase and encrypted with pgsodium. I think there's a lot more to privacy, though – currently working on other safety measures like anonymization that I'll include before scaling and releasing the app to the broader public. Still looking for testers; sent you a DM. Let me know if you're in!
- pgsodium- Modern cryptography for PostgreSQL using libsodium.
-
Supabase secrets management available in beta
> Is Vault something that can handle this without getting into my app code? Basically, if i gave a someone root access to my supabase instance is that encrypted data safe?
The answer is slightly offset from your question, so let me start by pointing out that the Vault is about Encrypted Data At Rest. This is mentioned in the docs and in the blog and video, but it's something that I like to always mention first in discussions. The main purpose of the Vault is to store your data encrypted, so that it's encrypted on disk, and in backups. In SQL the decrypted secrets are available to you, because that's where you are using them and encrypted data must be decrypted to be useful.
If someone roots access to your database, then yes they can access the decrypted secrets through the view. This is by design, the secrets must be decrypted to be useful in query code. This risk is similar to someone rooting your application code, they will see decrypted secrets via your environment key, so no it won't protect you against anyone rooting processes in your stack that need useful access to secrets and it's not meant to. Like all security you must take a layered approach, the Vault is just one storage level layer strategy.
One big difference from the env var approach though is that the key Supabase uses to encrypt your secrets with the Vault is stored outside the database, it is inaccessible to SQL, which is an enhancement over sticking the raw key into an environment variable or a table that is accessible to your application. Instead of revealing the raw key, pgsodium has a feature called [Server Key Management](https://github.com/michelp/pgsodium#server-key-management) where you do not have access to the raw key, but instead reference keys by an key identifier. It is safe to store this identifier alongside the data it encrypts. The raw key itself is never stored. I'm very intentionally overusing the word "store" here, because that's specifically the layer of security that the Vault provides.
-
Supabase Vault
The article links directly to here, which may answer your question:
https://github.com/michelp/pgsodium#server-key-management
- Encrypting data for a Finance App
- How do I encrypt data before sending it to the database?
-
Show HN: Pgsodium – A Crytographic PostgreSQL Extension
Hey HN, I shared an earlier prototype version of pgsodium but I just released 2.0 and felt this could be a good opportunity to share some updates!
[pgsodium](https://github.com/michelp/pgsodium) 2.0.0 is a postgres extension that uses the [libsodium](https://doc.libsodium.org/) 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](https://github.com/jedisct1/libsodium-xchacha20-siv) deterministic nonce-free encryption, this is useful for one-time workflows sacrificing a bit of speed and larger key size without worrying about nonce-handling issues.
enclaver
-
PostgreSQL Encryption: The Available Options
If you're looking for the best way to take a container and run it with Nitro, I work on https://github.com/edgebitio/enclaver
Works great with Kubernetes as a DaemonSet or straight on a VM.
-
Ask HN: What Are You Working on This Year?
Building a tool for running secure enclaves called Enclaver (https://github.com/edgebitio/enclaver). There is a big opportunity for keeping data encrypted while running code against it within enclaves.
And a more secure software supply chain is possible with device attestation and cryptographic measurements of software.
-
My company open sourced our tool to mix pods with secure enclaves into a regular EKS cluster
Check out the code on GitHub: https://github.com/edgebitio/enclaver
-
Supabase secrets management available in beta
I'm building the "in-use" part of this right now...what if you could encrypt your data with an encryption key (at-rest), _but also_ to a set of code that is allowed to decrypt it (in-use). If that code is identified cryptographically, its identity can't be spoofed or stolen.
We're exploring secure enclaves as the protected runtime env and the code attestation generation: https://github.com/edgebitio/enclaver
- Enclaver - run code in secure enclaves so it can't be observed by any human (like your iPhone enclave, but on AWS servers instead)
- Show HN: Enclaver – create and run secure enclaves
-
What’s the coolest thing you did this year?
I have been building out an open source project called Enclaver, which allows you to wrap sensitive workloads inside of a secure enclave (the same as your iPhone, but on servers). It's intended for anything you don't want observed, like JWT signers, encryption/decryption, partner integrations using highly privileged API keys, etc.
-
The Security Design of the AWS Nitro System
I found the side channel protection and CPU/L1 isolation between customers to be particularly interesting.
Very cool to see the physical hardware interconnects for resetting the system. Also the PCI bus as one of the isolating boundaries.
I have built an open source project for managing Nitro Enclaves (https://github.com/edgebitio/enclaver), so it is cool to see how these build on this foundation to provide even more protection.
What are some alternatives?
libsodium-xchacha20-siv - Deterministic/nonce-reuse resistant authenticated encryption scheme using XChaCha20, implemented on libsodium.
salty - Simple Saltstack-like deployment system in 1k lines of Python
libsodium.js - libsodium compiled to Webassembly and pure JavaScript, with convenient wrappers.
vault - Extension for storing encrypted secrets in the Vault
libsodium-signcryption - Signcryption using libsodium.
terraform-provider-proxmoxve - Terraform provider for ProxMox Virtual Environment
postgrest-js - Isomorphic JavaScript client for PostgREST.
bevy - A refreshingly simple data-driven game engine built in Rust
VW_Flash - Flashing tools for VW AG control units over UDS. Compression, encryption, RSA bypass, and checksums are supported for Simos18.1/6/10, DQ250-MQB, DQ381-MQB, and Haldex4Motion-Gen5-MQB.
OpenSSL - TLS/SSL and crypto library
supabase - The open source Firebase alternative.