4 ms·

This is a really great idea, with a really poor execution. I'm just a regular guy, but the messages and details that I would leave in a service like this are t

by josho 10y ago

This is a really great idea, with a really poor execution. I'm just a regular guy, but the messages and details that I would leave in a service like this are too sensitive to be put on someone else's server for a period of years. (Maybe I'm just too private in this age of social networks). We really need a PGP like solution for the masses. On that note, I wonder why someone like Mozilla doesn't take this on and push for human friendly client certificate authentication.

rtkwe 10y ago
> We really need a PGP like solution for the masses. How would that solve the issue of putting the secret on someone else's server and guaranteeing that it'll be available after death only? They'd have to have a key to decrypt to release it (in any useful meaning of the word) then you're dealing with storing the key and the encrypted secret. You still have to ensure that the decrypt key will get released on your death but not before and used to unlock your other secret.
- josho 10y ago
  Assuming we restrict the solution to this problem space. Since I trust the service to send the message, then I trust them as well to generate the encrypted package and communicate the passphrase needed to decrypt. I trust them enough to not keep that passphrase around. Then the workflow would be something like the service sending an email to each intended recipient with a short message saying keep this message saved it includes a passphrase that you will need later. Then when the switch fires another email is sent asking the recipient to provide the passphrase. The service will then decrypt the message with the passphrase. I know this still requires a lot of trust, but it at least protects the data at rest.
  - rtkwe 10y ago
    That at least protects it on the server but the secret sitting in the email is pretty insecure since the generated decryption key is only as strong as the least secure recipients security.

by josho 10y ago

rtkwe 10y ago

> We really need a PGP like solution for the masses. How would that solve the issue of putting the secret on someone else's server and guaranteeing that it'll be available after death only? They'd have to have a key to decrypt to release it (in any useful meaning of the word) then you're dealing with storing the key and the encrypted secret. You still have to ensure that the decrypt key will get released on your death but not before and used to unlock your other secret.

josho 10y ago
Assuming we restrict the solution to this problem space. Since I trust the service to send the message, then I trust them as well to generate the encrypted package and communicate the passphrase needed to decrypt. I trust them enough to not keep that passphrase around. Then the workflow would be something like the service sending an email to each intended recipient with a short message saying keep this message saved it includes a passphrase that you will need later. Then when the switch fires another email is sent asking the recipient to provide the passphrase. The service will then decrypt the message with the passphrase. I know this still requires a lot of trust, but it at least protects the data at rest.
- rtkwe 10y ago
  That at least protects it on the server but the secret sitting in the email is pretty insecure since the generated decryption key is only as strong as the least secure recipients security.