I think the major issue is that the service has access to both, the encrypted nsec and the key to decrypt it. Plus and service that is between the service and the client will have access to both, e.g., Cloudflare, TLS termination thingy. It’s just not a good approach to the storage of keys unless the organization hosts it in their own trusted infrastructure 🐶🐾🫡
Wut? End-to-end encryption; why would Cloudflare or any MITM have it?
The nsec is encrypted at disk, user needs to talk to the bunker to provide pssphrase to decrypt it every time it reboots/forgets the nsec.
Ofc there’s a trust element which is why open sourcing it is fundamental and reproducible builds and even better running in a secure enclave are ideal.
Because Cloudflare sees your traffic in clear, because they terminate your TLS connection. So are the other services or equipment that does that
I think the point was that service that runs nsecbunker has access to the nsec as is, it doesn’t matter if it’s stored encrypted or not, it’s an easy fix to intercept the key if service wanted to.
Enclave or HSM with the proper and standard encryption key exchange and zero exposure of unencrypted nsec or the key is the only way I see it being trustworthy. 🐶🐾🫡
the communications with the bunker are over relays, it's no direct HTTPS connection 🤔
I do not have full visibility into the code at this time, but how does the key gets into the bunker, and how does the passphrase get to nsec bunker to decode the key. I am strictly talking about the initial setup. 🐶🐾🫡
over nostr, nip04 encrypted payloads
it doesn't expose any direct APIs because the whole point was to be able to run it behind a firewall without doing any holepunching tricks (other than left-side-of-the-curve "just use nostr" holepunching)
Ok, that makes sense. Thanks for clarifying this 🐶🐾🫂🫡
Oddbean new post about login | logout