Encrypted in a distributed filesystem. Distributed between your own devices and any backup agreements you have with close contacts.
Most application specific keys would be unlocked as needed by a bearer token from authorized applications. Even if they had access to your key file they could only get the keys they are already authorized to use, and which will expire anyway.
The master key would get unlocked by a passphrase or similar that you train people to never actually use, unless they are rotating keys. Kind of like how cert chains work.
1) Bob creates a master keypair
2) Bob immediately creates and signs domain specific keypairs, communication, banking.
3) Bob locks his master keypair with a key derived from a passphrase and a server key for his parent device and an on device nonce.
4) Bob uses his domain specific keys to create application specific keys.
5) Bob befriends Alice
6) Alice agrees to be a sort of notary for Bob. They do a key exchange that Bob uses to re-encrypt his master key instead of the server key.
7) Bob deletes the nonce on his key server thereby locking his original key file forever.
8) Bob can now only unlock the new key file by repeating the key exchange with Alice.
I am somewhat making this up as I go, but I have thought about it a good deal in the past. You can specify the key derivation however you want and do it as many times as you want. This way Bob could require help from Alice AND Alicia for additional security or Alice OR Alicia for flexibility. You could do N out of M friends from a trusted list.
You just don't want people to have to know that is what is happening. All of the above is automated.
There would need to be some careful UI choices on your trusted friends devices so even if Bob is completely compromised, the attacker would have to convince Alice they were really Bob in person. Maybe that feature only works via nearfield communication etc.
To keep Bob from just going to Alice to help rotate his keys and reclaim his account the attacker would have to compromise Alice as well. Under and N out of M scheme (death happens) it would get pretty difficult.
Daniel Wigton
npub1w4j…30zp
2024-05-17 22:01:19
in reply to nevent1q…hn75
Author Public Key
npub1w4jkwspqn9svwnlrw0nfg0u2yx4cj6yfmp53ya4xp7r24k7gly4qaq30zpPublished at
2024-05-17 22:01:19Event JSON
{
"id": "a587f0085e3b8d13d6e083493700f47012682f138a9287c8fbc273663d0c8b40",
"pubkey": "75656740209960c74fe373e6943f8a21ab896889d8691276a60f86aadbc8f92a",
"created_at": 1715976079,
"kind": 1,
"tags": [
[
"e",
"6b04dd09609cd2705b7592a789fa25d37b2016a795463be85f6922e11bbc0147",
"",
"root"
],
[
"e",
"59dfe4666f5198c441603ad4b1df4071067560ce5215d53747b83acc3386af49"
],
[
"e",
"63490abb31cb1fcca547d5c18283dccab2d06f31ac093fc0f3a83f7a56026c21",
"",
"reply"
],
[
"p",
"7b3f7803750746f455413a221f80965eecb69ef308f2ead1da89cc2c8912e968"
],
[
"p",
"75656740209960c74fe373e6943f8a21ab896889d8691276a60f86aadbc8f92a"
],
[
"p",
"9a4acdeb978565e27490dca65c83e9f65745eaec1d9a0405a52d198c1489913b"
]
],
"content": "Encrypted in a distributed filesystem. Distributed between your own devices and any backup agreements you have with close contacts.\n\nMost application specific keys would be unlocked as needed by a bearer token from authorized applications. Even if they had access to your key file they could only get the keys they are already authorized to use, and which will expire anyway.\n\nThe master key would get unlocked by a passphrase or similar that you train people to never actually use, unless they are rotating keys. Kind of like how cert chains work.\n\n1) Bob creates a master keypair\n2) Bob immediately creates and signs domain specific keypairs, communication, banking.\n3) Bob locks his master keypair with a key derived from a passphrase and a server key for his parent device and an on device nonce.\n4) Bob uses his domain specific keys to create application specific keys.\n5) Bob befriends Alice\n6) Alice agrees to be a sort of notary for Bob. They do a key exchange that Bob uses to re-encrypt his master key instead of the server key.\n7) Bob deletes the nonce on his key server thereby locking his original key file forever.\n8) Bob can now only unlock the new key file by repeating the key exchange with Alice.\n\nI am somewhat making this up as I go, but I have thought about it a good deal in the past. You can specify the key derivation however you want and do it as many times as you want. This way Bob could require help from Alice AND Alicia for additional security or Alice OR Alicia for flexibility. You could do N out of M friends from a trusted list.\n\nYou just don't want people to have to know that is what is happening. All of the above is automated.\n\nThere would need to be some careful UI choices on your trusted friends devices so even if Bob is completely compromised, the attacker would have to convince Alice they were really Bob in person. Maybe that feature only works via nearfield communication etc.\n\nTo keep Bob from just going to Alice to help rotate his keys and reclaim his account the attacker would have to compromise Alice as well. Under and N out of M scheme (death happens) it would get pretty difficult.\n",
"sig": "d9b3b41e68eeff6e2fddf61238ad7343a817eb79db128763725ea0410475cf739c20aea3f286b1a7f70877d55cfb584651275a126f55d46188bb14ae5cf623d7"
}