Persisting sealed secrets

Architecture Spritely Goblins
1

Hello Goblins,
I would like to build an application able to persist secrets and to allow only authorized users to read them , Goblins always seemed the perfect way to achieve that. I read a couple of times the manual and Heart of Spritely but I wrote little code yet.

This is what I have in mind please let me know whether I’m on the right track or not. The POC I’m implementing should work like this:

user1@localhost:~ my-tool create --name secret-name --value secret-value --share-with=user2
created ~/secret.enc
user1@localhost:~ my-tool read ~/secret.enc --name secret-name
secret-value
user1@localhost:~ sudo -u user2 my-tool read ~/secret.enc --name secret-name
secret-value
user1@localhost:~ sudo -u user3 my-tool read ~/secret.enc --name secret-name
error: user3 doesn't have the capability to read

This example is assuming that all of the three users have already generated some kind of private key or identity file stored at a known location (probably under $XDG_CONFIG_HOME or something like that) that will allow the tool to map a linux user to a capabilities set. All of this is pretty vague for now, I understand, but it is just to give you the vision of where I’d like to go so that maybe my questions make more sense.

My questions for you Goblins are about persistence, access control, and privacy. My understanding is that a sealed object’s content is private and there are a lot of mentions of public key cryptography in the Goblins manual in the sealers sections, so:

  1. is a sealed object cryptographically private? as in it takes a comparable amount of time to brute force it or violate it as rsa or ecdsa? I understand that these are battle tested and Goblins is very new so there may be undiscovered security issues but my question is really of principle. if I serialize and store into a linux plain file a sealed object containing a password, is it a security concern?
  2. is it possible with current Goblins serialization/persistence to serialize a sealed object that can be unsealed by two different object (e.g. user1 and user2 in the example above) which should themselves be serialized/persisted somehow (the private key/identity file in the example)?
  3. are sealers even the way to implement this? am i completely out of track and there is a much more simpler way? please do let me know :wink:

Thank you for your awesome work and for being awesome persons from what I could gather,

2 Likes
2

Hi @paulbutgold! I’m excited to see your own excitement! :slight_smile: We love seeing people excited about Goblins and seeing how they can implement their own needs and interests with it.

  1. is a sealed object cryptographically private? as in it takes a comparable amount of time to brute force it or violate it as rsa or ecdsa? I understand that these are battle tested and Goblins is very new so there may be undiscovered security issues but my question is really of principle. if I serialize and store into a linux plain file a sealed object containing a password, is it a security concern?

Sealers and unsealers, as implemented in Goblins currently, are what we’ll call “language / object based sealers / unsealers” for now. You can seal an object and hand out the sealed objects over the network, and only the users with the relevant unsealer can get access to the information or capabilities within. However, current Goblins sealers/unsealers do not rely on cryptography, they rely on runtime language protections. This is explained in the Pre-Implementation: Sealers and unsealers section of Heart of Spritely as such:

Sealers and unsealers have an analogy with public key cryptography, where sealing resembles encryption, and unsealing resembles decryption. […] What is astounding is that all three of these operations can work without any cryptography at all, implemented purely in programming language abstractions.

From the standpoint of handing out sealers and unsealers and sealed objects over the network, Goblins does provide certain assurances. However, as of right now Goblins sealers/unsealers are “language / object sealers”… what I think you’re looking for is what we might call “crypto sealers”. These are possible to implement, but we haven’t implemented them as of yet. So I don’t think we can provide the assurances you are asking for yet.

  1. is it possible with current Goblins serialization/persistence to serialize a sealed object that can be unsealed by two different object (e.g. user1 and user2 in the example above) which should themselves be serialized/persisted somehow (the private key/identity file in the example)?

Goblins can serialize/persist quite well, and it can even persist sealers/unsealers and sealed objects! However, there is an assumption in Goblins that only one process is accessing the “persistence store” at a time, and I think in your example if two users are writing a secret at the same time, there could be a race condition.

Goblins might not be the right tech quite yet to pull off what you’d like, but you could pull it off also using more simple cryptography libraries. Let me instead give you a vision of something that Goblins could provide very well.

Let’s say you wanted to have two users read/write different values in a shared store, and we implement this store as a simple actor that simply keeps sealed values and the brand check predicate of what sealer/unsealer pair they correspond to. What you could absolutely do is hand this actor out to different users and users could generate their own sealers/unsealers and store values and share said sealers/unsealers… this wouldn’t be encrypted on disk, but you could ensure that over the network, only the relevant users could see the information (but the store could also). If we got crypto sealers/unsealers, even the store would not be able to see them, but that’s a bit off in the distance.

By the way, I think what you really might be interested in here is what Spritely will eventually provide as “Porta-Bella”. This is the same ideas as Tahoe-LAFS more or less, but I think this writeup for encrypted immutable storage and encrypted mutable storage. At the moment, we are considering using ERIS for this.

1 Like
3

Hi @cwebber , thank you for your detailed answer, I had to think about it. I am still determined to build this secret management tool with Goblins, even just to learn more about distributed capabilities.

I have updated the architecture I have in mind for this and I think I can still make use of Goblins nice network abstractions and capabilities enforcement. I think I need two different components:

  • a daemon component that is able to queue requests from clients to avoid race conditions. this daemon would store plain secrets in a syrup file (the risks would be not so different from the ones private ssh keys are exposed to I believe). To mitigate the risk of not having cryptosealers the syrup file could be stored in a gocryptfs-backed filesystem. the password for gocryptfs would of course need to be stored out of the secrets store
  • a client component. again similarly to ssh/age, this client would allow users to generate an identity and be able to request the capability to store secrets from the daemon, it would seal its secret and send the sealer triplet back to the daemon to be persisted.

Daemons in different machines then would be able to share secrets between themselves, so one could have a setup similar to hashicorp vault where one central node would host secrets for all clients in a network.

From what I understand Goblins currently is able to serialize references to local vats, what does it means for two vats to be local? Do they need to live in the same Guile process or can they run in two different processes in the same machine?

By the way, I think what you really might be interested in here is what Spritely will eventually provide as “Porta-Bella”. This is the same ideas as Tahoe-LAFS more or less, but I think this writeup for encrypted immutable storage and encrypted mutable storage. At the moment, we are considering using ERIS for this.

Definitely, it appears Porta-Bella would provide the features I need out of the box, I’ll keep a close eye on next Goblins releases, even if I understand it might take a while. Also ERIS looks like a game changer when it’ll be integrated in applications

Thank you for your help :smiley: