Yeah, I was thinking the same - that this could be a password manager as well. I have built in the ability to store private records. I use NIP-44 to encrypt but could easily add in the AES password encryption as you suggest.
The big idea is that this ‘thing’ (safebox, password manager), via relays, can live independently anywhere. I’ve already started to build a replication functionality to move it to other relays. IMO that’s a big advantage over any cloud service, or even a self-hosted machine because it could fail, or your house burns down.
Anyway, still early days of heavy experimentation. Thanks for the comments!
Exactly, sufficiently distributed encrypted backups, very powerful
Is the idea to AES-encrypt the .content with a password first, then do the NIP44 encryption? That way if the nsec is compromised, at least the records are still encrypted?
Correct, somewhat of a 2FA / post compromise secrecy.
Awesome. Thanks for the suggestions. I think it will be pretty straightforward to implement. Next cool feature project!
So, I wonder over the long term how much information can be leaked because it's publicly available on relay-servers?
I've shared my concerns with nip46 signing with public relays and clients hoovering decryption requests to see when and where you are decrypting your secrets. Even cryptographically how much noise might be generated when the whole world has your ciphertext message and can see you encrypt/decrypt your "passwords". You can hope relays require auth, but should trust them.
Of course there really is no way around it in your app, but for me, the less personal information stored on relays the better. I deny all client requests to even store my preferences because just store them locally unless I ask otherwise.
The next step would be private, personal relays running on your device/phone. I am working with the assumption that your personal data is being stored by an adversary to begin with. It’s all about tradeoffs.
> It’s all about tradeoffs.
For sure I just wonder how hard we should be relying on nip44 (I wrote the reference C impl) to protect us from ciperhtext hoovers and leakage, since it should be assumed the instance you publish your encrypted note its available to anyone in the world within seconds probably.
Good question. @Max Hillebrand suggested to additionally encrypt the content with AES/password before encrypting with NIP-44. So long the password is stored out of band completely, it still should be protected if the nsec is compromised.
In the end, all security relies on the protection of a private key stored somewhere. I’d like to have that under my control versus a randomly trusted admin.
Oddbean new post about login | logout