[atonse]

Do you guys post any details about the storage format?

Like if I had the encryption key and any salt etc, can I decrypt it without your product?

Also how much has the encrypted format been vetted?

I saw your example and the last name seemed to be massive even compared to using something like KMS.

[hexedpackets]

We still need to add the format to our docs, but it's essentially:

prefix + base64(len_encode(metadata) + len_encode(key_tag) + aes_encrypt(data))

So definitely possible to decrypt it without JumpWire, if you have the keys. There are some pieces of metadata we add in that we could make optional if you want to reduce the resulting ciphertext size. That metadata adds a few extra bytes, but it doesn't grow with the data size.

[atonse]

Thank you – I would recommend writing up a page with all the details on your docs because that would appease a whole lot of people that would be your target customer (like myself)

Although I might be biased cuz I'm a founder from a tech background so I want those details, but even with those details, I'm one of your target market but my worry with these kinds of products tends to be more about things like:

- am I adding an unreliable piece of infra to my stack? this is going to be a critical gatekeeper, so if this fails, not only is it like my DB being down, as the only method of decrypting my data, does it have the ability to fail in a way that results in permanent data loss (whereby I can't decrypt some subset of the data)

- if I had to yank this out, what's the process? will I be stuck?

- what are the chances of us doing something stupid and lock OURSELVES out of our own data? what guardrails are available there?

- what is the key management story? (which answers a lot of the above questions)

- is this roll-your-own crypto (not just which algorithm, but how the messages are constructed, etc) or something standard and vetted? Because there's no secret sauce to be had there, it's more in making all those OTHER elements easier for me.