Earlier quoted context omitted.
Can you expand on "strict protocols" please?
"strict protocols" refer to our will execution schedule, which ensures that the keys are only accessible after the switch is triggered. Even if someone were to hack the system and access the keys before execution, only the designated beneficiaries would have the ability to decrypt the data.
Show HN: End-to-End Encrypted Dead Man's Switch
41–50 of 56 posts
Re: Show HN: End-to-End Encrypted Dead Man's Switch
#42Where an how is user data stored? Do you use cloud providers/SaaS and in which jurisdiction? Considering legal requests for user data are being served, location/jurisdiction for both CipherWill and its servers are important and I don't seem to find this mentioned. Aside, but I don't think I'm alone in considering this a non-starter combined with the whole stack including the client being closed-source. Fresh advertis…
We’re committed to transparency and are exploring ways to improve our documentation, including our Terms of Service and Privacy Policy. Your input is valuable, and we’ll take it into account as we develop the platform further.
> Where an how is user data stored? Do you use cloud providers/SaaS and in which jurisdiction? Considering legal requests for user data are being served, location/jurisdiction for both CipherWill and its servers are important and I don't seem to find this mentioned.
Re: Show HN: End-to-End Encrypted Dead Man's Switch
#43Re: Show HN: End-to-End Encrypted Dead Man's Switch
#44Earlier quoted context omitted.
Sheesh; no excuse not to back up your BIP-39 mnemonic phrases using SLIP-39 (Shamir secret sharing): https://slip39.com/app
Furthermore, you can use the same App to SLIP-39 any arbitrary 128-, 256- or 512-bit key in a way that your family can combine their data to recover.
Anyway, I decided I didn't want to migrate my wallet, so I'll look into this. Arbitrary key support is also interesting. Thanks for the tip!
Re: Show HN: End-to-End Encrypted Dead Man's Switch
#45Earlier quoted context omitted.
Furthermore, you can use the same App to SLIP-39 any arbitrary 128-, 256- or 512-bit key in a way that your family can combine their data to recover.
I can't remember why I didn't pursue this, something about the hardware wallets having a way to do the Shamir upfront? In a different way than just sharing the words. Such that each person winds up with 24 words rather than a subset. Anyway, I decided I didn't want to migrate my wallet, so I'll look into this. Arbitrary key support is also interesting. Thanks for the tip!
Using the app, we actually produce the SLIP-39 recovery mnemonics from the underlying BIP-39 seed, and since we can recover the underlying seed, we can regenerate the BIP-39 mnemonics, and import that into a standard hardware wallet.
Re: Show HN: End-to-End Encrypted Dead Man's Switch
#46Re: Show HN: End-to-End Encrypted Dead Man's Switch
#47You’re in the fun phase of designing the tech, but that’s not where the problem lies. I don’t trust you at all. You can tell me about the system you’ve designed, but I only have your word that it really works that way. Trust is 90% of your problem, and the tech is only 10%. I can’t think of anything you could write that would change that. I guess I have to trust my bank with my safe deposit box, but there I see keys,…
Re: Show HN: End-to-End Encrypted Dead Man's Switch
#48Earlier quoted context omitted.
We’re committed to transparency and are exploring ways to improve our documentation, including our Terms of Service and Privacy Policy. Your input is valuable, and we’ll take it into account as we develop the platform further.
You didn't address the main question: > Where an how is user data stored? Do you use cloud providers/SaaS and in which jurisdiction? Considering legal requests for user data are being served, location/jurisdiction for both CipherWill and its servers are important and I don't seem to find this mentioned.
Re: Show HN: End-to-End Encrypted Dead Man's Switch
#49Earlier quoted context omitted.
"strict protocols" refer to our will execution schedule, which ensures that the keys are only accessible after the switch is triggered. Even if someone were to hack the system and access the keys before execution, only the designated beneficiaries would have the ability to decrypt the data.
What exactly is preventing someone with the key decrypting the data before some other code in your system runs?
Re: Show HN: End-to-End Encrypted Dead Man's Switch
#50You’re in the fun phase of designing the tech, but that’s not where the problem lies. I don’t trust you at all. You can tell me about the system you’ve designed, but I only have your word that it really works that way. Trust is 90% of your problem, and the tech is only 10%. I can’t think of anything you could write that would change that. I guess I have to trust my bank with my safe deposit box, but there I see keys,…
I completely understand — building trust is key, and we’re working on adding transparency through decentralization and exploring open-sourcing to give users more control over their data.