Doesn’t https://nsec.app literally do that? cc: @brugeman

Yup. There goes your main argument against #communikeys 😜

Or you could use NA 👀

Not really. The enclave dies, everything dies. If the enclave generates an nsec that is to never leave the enclave, then that nsec only lives as long as that physical machine lives, assuming you pay your monthly bills. What it does help with is management of a key you accept will be know by someone at the company who may in future not be at the company. But you still have to accept that, so the core problem remains.

- You can have multiple enclaves with the same nsec. Generated and sent to them by another enclave (for example) - You can play with conditional export of the nsec - You can verify if an nsec was exported by someone To me, those are #goodenough bulding blocks. And again, solution is needed regardless.

If going for an "unknowable nsec" you can't have multiple enclaves with the same nsec generated by one of the enclaves in anything other than a airtight daisy chain. Meaning if you start with enclaves A and B, you can have enclave A encrypt an nsec it self-generated to the key of enclave B, and then send it to enclave B (all under attestable code), then it exists in both and nowhere else. But they you're just moving the problem around, the same general point of failure just with a much lager bill. And you have all these encalves from day one, because you cannot update the code of enclave A to inform it of, say, enclave C. The only workable way is if it's sent from outside in, but that's the core issue again.

By the way, a single enclave of the cheapest possible type is $800 a year.

Ow damn ok.

You will soon be able to launch docker images in enclaved app server at a fraction of the cost

Noted