Topic: Heritage/Insurance Encapsuled Encryption System (Read 345 times)
The idea is quite nice, but I'm not completely sure if this is the way to go. What I'm trying to say is that I don't think this could work exactly how it's portaraied, but the overall general idea is amazing. If we take a look at the Insurance industry and some of its statistics we shoudl understand why this is something that we need to potentially focus on in the future. I think it could be done by the insurance companies themselves, not necessarly by thir party companies and follow the path of idea that you had, but rethought a bit on the general population.
I'm not against automation, don't get me wrong, but the ultimate utility of automation and machinery is to serve humans somehow. We wouldn't be polluting the planet and crave for power sources just for fun.
What is interesting atm, is to discuss possible flaws and exploits, trim and cook the idea, eventually even weight it's pros and cons against other concurrent systems that may show up. But discussing about hypothetical software... What would be the point?
And death of someone is not to be taken lighten; the deceased could well blow his money on women and cars instead of save anything, but if he chose another path and his soul must have some way to rest in peace about the loved ones he left behind. So we must add some romantic and human vector to the whole system. Taken must of us, if not all, use strong passwords and/or strong security systems, way too complex sometimes, figure a way to open it when needed is far from an easy task or, like the widow of the Canadian exchange owner, crypto ends locked for good, practically dying with the owner.
Thank you for your offer.
What is interesting atm, is to discuss possible flaws and exploits, trim and cook the idea, eventually even weight it's pros and cons against other concurrent systems that may show up. But discussing about hypothetical software... What would be the point?
And death of someone is not to be taken lighten; the deceased could well blow his money on women and cars instead of save anything, but if he chose another path and his soul must have some way to rest in peace about the loved ones he left behind. So we must add some romantic and human vector to the whole system. Taken must of us, if not all, use strong passwords and/or strong security systems, way too complex sometimes, figure a way to open it when needed is far from an easy task or, like the widow of the Canadian exchange owner, crypto ends locked for good, practically dying with the owner.
Thank you for your offer.
Now your trust party is a batalion of people?
300 to 1000 people? lol
I didn't know you had resistance to automation, so I'm sorry for bringing it up again. Personally, I would rather have something than remember something, so I've never used phrase codes.
I cannot contribute constructively to your idea, but I can offer you free hosting if you need a place to organize.
Now your trust party is a batalion of people?
Let's put things a bit straight here; there're two opposite PoV in inheritances, the PoV of the heirs, who probably want the money ASAP, but that's their problem, and the person who actually gathered the wealth and eventually deceased. My system is towards the PoV of the former, not heirs, a more personal and human way to provide a last will, not some random characters and an automatic email with a weird key of sorts, which could land in some spam box.
If you have a better idea: develop and present it. But it turns kind of annoying to keep reading "I would send emails", "I would go with smart contracts", "I would use multi sig", "I would... whatever" -> Great! Do it!
A valid idea and valid discussion about this issue is on how to trim its usage, like AGD addressed and posed the issue.
Technology has the sole purpose of serving "rotting flesh", without humans all of Bitcoin, all of the electronic junk we created, would be rendered plain useless and worthless.
Let's put things a bit straight here; there're two opposite PoV in inheritances, the PoV of the heirs, who probably want the money ASAP, but that's their problem, and the person who actually gathered the wealth and eventually deceased. My system is towards the PoV of the former, not heirs, a more personal and human way to provide a last will, not some random characters and an automatic email with a weird key of sorts, which could land in some spam box.
If you have a better idea: develop and present it. But it turns kind of annoying to keep reading "I would send emails", "I would go with smart contracts", "I would use multi sig", "I would... whatever" -> Great! Do it!
A valid idea and valid discussion about this issue is on how to trim its usage, like AGD addressed and posed the issue.
Technology has the sole purpose of serving "rotting flesh", without humans all of Bitcoin, all of the electronic junk we created, would be rendered plain useless and worthless.
So, what if your trusted third party get acquainted with one of the interested parties?
If my trusted authority is 11 of my family, I'm not going to worry about 6 of them deciding to commit fraud against me.
You didn't read/understand my idea, so I'm sorry for the hijack.
@Vod
How is that any easier?!
How is that any easier?!
You type in the names and email addresses of your friends. Done!
The key is automation, and avoiding rotting meat (the human memory lol)
So, what if your trusted third party get acquainted with one of the interested parties? Guess what... you'll "die early" and someone will be sharing your wealth while you entertain yourself finding a lawyer and engage the funny and long civil court processing.
To not mention that would be a plain money-grab...
@Vod
How is that any easier?!
How is that any easier?!
You type in the names and email addresses of your friends. Done!
The key is automation, and avoiding rotting meat (the human memory lol)
@Vod
How is that any easier?!
How is that any easier?!
@OgNasty
Yes, you can call it a sort of "Encryption for Dummies"
Yes, you can call it a sort of "Encryption for Dummies"
But your idea doesn't sound like it's for dummies - it's fairly complicated.
How about something like this?
Trust an authority to declare you dead.
Trust three friends.
Trust the chaincode.
Create your information package, and put it on hyperfabric. The smart contract can execute once it receives notification from authority. After a delay, the package can be delivered. Each of the three of the friends are notified and can further delay the delivery in case of fraud. The authority can bring you back to life.
This "authority" can be as simple as an odd number (no ties) of your friends/family.
Those are good questions indeed.
The informatics part is quite straight forward, it's just encrypt, encrypt, encrypt.
The human part however isn't that easy, and I believe there's no "one-size fits all" solution for it and my system isn't fail proof.
If one of the addressees dies shortly after you, the best shot would be to resource his closest relative (wife, husband, sons...). We have "layers of communication", there are things we say to family, but not to friends or strangers, others maybe to friends but not even to family.
For the custody, you could use a testament lawyer office, or you can intruct one of the addressees (preferentially not the #1) or a third party you trust, or you can leave it in a vault with a note on what to do next.
Yes, it's possible, however the other 2 already gave their answers, so they're already triggered by what's going on and would probably chase down or sue that last one.
EDIT:
One of the cases that inspired me to do this: https://www.newser.com/story/270824/crypto-investors-woe-widow-cant-open-founders-laptop.html
The informatics part is quite straight forward, it's just encrypt, encrypt, encrypt.
The human part however isn't that easy, and I believe there's no "one-size fits all" solution for it and my system isn't fail proof.
If one of the addressees dies shortly after you, the best shot would be to resource his closest relative (wife, husband, sons...). We have "layers of communication", there are things we say to family, but not to friends or strangers, others maybe to friends but not even to family.
For the custody, you could use a testament lawyer office, or you can intruct one of the addressees (preferentially not the #1) or a third party you trust, or you can leave it in a vault with a note on what to do next.
Yes, it's possible, however the other 2 already gave their answers, so they're already triggered by what's going on and would probably chase down or sue that last one.
EDIT:
One of the cases that inspired me to do this: https://www.newser.com/story/270824/crypto-investors-woe-widow-cant-open-founders-laptop.html
I was thinking about one of the 3 dies AFTER me and BEFORE he was able to answer the questions, but your answer explained it anyway.
Another question: How would they know about this file? Do I have to give them the file incl the questions BEFORE I die? Wouldn't this lead to possible collusion between the 3 while I'm alive?
I mean I could use a dead man's switch, but this is not part of your idea, is it?
Another thing is this one: What if I die and the 3 people start answering questions to open the layers until it comes to the last question, where only one person is able to unlock the money, without the need for the other two. If he takes the file which is almost resolved, he could go away, answer the last question alone and keep the money. Is this possible with your script?
Another question: How would they know about this file? Do I have to give them the file incl the questions BEFORE I die? Wouldn't this lead to possible collusion between the 3 while I'm alive?
I mean I could use a dead man's switch, but this is not part of your idea, is it?
Another thing is this one: What if I die and the 3 people start answering questions to open the layers until it comes to the last question, where only one person is able to unlock the money, without the need for the other two. If he takes the file which is almost resolved, he could go away, answer the last question alone and keep the money. Is this possible with your script?
If Paul, Sue or John dies before being able to answering all 3 questions or one of them forgets only one answer, the remaining two will not be able to decrypt the file, am I right? Is there a way to let it work like a 2 of 3 multi sig?
If one party dies before you do, don't forget to redo your system. As no, there's no way to skip or create partial solvers.
About forgetting, they've all the tries they want to remember, will take them longer to solve.
The encryption system works like peeling an onion; each layer of encrypted text just uncovers the next layer of encrypted text.
If Paul, Sue or John dies before being able to answering all 3 questions or one of them forgets only one answer, the remaining two will not be able to decrypt the file, am I right? Is there a way to let it work like a 2 of 3 multi sig?
@OgNasty
Yes, you can call it a sort of "Encryption for Dummies", it is intended for the easiest usage possible assuming one or several of the target parties couldn't be tech savvy.
IDK any already in place system for this purpose of "e-Testaments". As for memory loss, you will probably also forget you'd any crypto assets, so the custodian part can show up and tell you about your system and those you need to summon to help you out on regain access.
There's a lot of human side to this system, creating a good Q&A set is one of them.
@STT
You can combine it with a dead man's switch for sending the said email (but don't forget email services die as well, imagine you'd an @cjb.net; wouldn't be of much use now), just sending the msg.js (where the encrypted final text resides) and the other two files, the HTML and CryptoJS.js, as attachment.
But this shouldn't obviously be the "only option" or the "only path", just "another option" or "another way".
Yes, you can call it a sort of "Encryption for Dummies", it is intended for the easiest usage possible assuming one or several of the target parties couldn't be tech savvy.
IDK any already in place system for this purpose of "e-Testaments". As for memory loss, you will probably also forget you'd any crypto assets, so the custodian part can show up and tell you about your system and those you need to summon to help you out on regain access.
There's a lot of human side to this system, creating a good Q&A set is one of them.
@STT
You can combine it with a dead man's switch for sending the said email (but don't forget email services die as well, imagine you'd an @cjb.net; wouldn't be of much use now), just sending the msg.js (where the encrypted final text resides) and the other two files, the HTML and CryptoJS.js, as attachment.
But this shouldn't obviously be the "only option" or the "only path", just "another option" or "another way".
Sounds like PGP only with security questions instead of private keys. I'm not sure about your claim it is safe against memory loss though. Don't you have to then rely on others to not forget the answers to their questions, or to select questions that can't be known by anyone else? I like the effort, but I'd like to better understand the benefits to using this system as opposed to systems already in place. It appears the lack of needing a key makes it a bit of an 'Encryption For Dummies' service. Is that the intended benefit?
Shamir's system, which is pair to multi-sign, doesn't requires all parties to cooperate, also requires the parties to know before hand what they're holding and its use.
This system doesn't require to inform anyone or you can inform a third unrelated party (custodian) of its existence to summon the needed parties when it becomes needed.
This system doesn't require to inform anyone or you can inform a third unrelated party (custodian) of its existence to summon the needed parties when it becomes needed.
Ideally I always prefer a simple system but multi sign could be the best route least easily taken advantage of before time. I always thought the simplest system would be a delayed email and you would have to refer to the password indirectly but recently familiar to all parties previously for other reasons. Perhaps thats not secure enough but I wouldn't want to rely on one path in its entirety. There's probably somewhere that allows something to be sent on a date in the future and you can just keep renewing that date.
Not trying to sell anything, it's GPL licensed, and it doesn't send any email or communicate anywhere at all.
But probably can be handy for lawyer offices that offers testament's custody services.
But probably can be handy for lawyer offices that offers testament's custody services.
Sorry, by "sell" I meant convince others, not profit.
Sending emails including detailed/vetted instructions, along with links is infinitely better than simply asking a friend to do this and hoping they understand what you mean.
People make money developing ways to use free services more efficiently.
I think this is too complicated to ever work - but ideas are always great!
Take your idea and wrap it in an easy to use GUI with clear instructions in each automatic email sent out.
Your technical solution is not unique or difficult, but you need to sell it.
Take your idea and wrap it in an easy to use GUI with clear instructions in each automatic email sent out.
Your technical solution is not unique or difficult, but you need to sell it.
Not trying to sell anything, it's GPL licensed, and it doesn't send any email or communicate anywhere at all.
But probably can be handy for lawyer offices that offers testament's custody services.
I think this is too complicated to ever work - but ideas are always great!
Take your idea and wrap it in an easy to use GUI with clear instructions in each automatic email sent out.
Your technical solution is not unique or difficult, but you need to sell it.
Take your idea and wrap it in an easy to use GUI with clear instructions in each automatic email sent out.
Your technical solution is not unique or difficult, but you need to sell it.
Still don't see your point... it's like "hey, don't use RIPEMD160, use MD5 instead" or something alike. There's no technical advantage whatsoever in your solution, to the least both solutions can achieve the same, being your more unnecessarily complicated, unless space is a constraint (which isn't much these days, with regular entry levels USB pens to be up to several Gb).
I believe you're more thinking of the informatics part than the human part of the question. The human part requires that:
1. An human solvable and reasonably easy way to pose the questions (your heirs might not be nerds).
2. No previous advice of the existence of the system by the heirs (they might get greedy... we never know).
3. Enforce a way for all parties to cooperate, no threshold of partial parties (a few of them may conspirate to leave others out of the scene).
4. Personalize your message; it's your TESTAMENT, not some random hashed characters.
5. Also you might want those you love to remind you one last time, instead of doing a simple cash grab. By posing questions of your co-existence, you can be sure that will happen.
But you're free to present your system. Like at RAR, ACE, 7Z, ZIP and other compressing algorithmics, you don't see one of them to come over to say the other must do as he does, do you?
Still your system of Xor'ing the hashes with the question doesn't pose much difference than AES'ing it. But that would provide a way they might solve the questions individually and not as a group, forwarding their hashes through lawyers or so, unlike the intended way of this solution that forces them to be together or take a very long time by proxying it through representatives.
I believe you're more thinking of the informatics part than the human part of the question. The human part requires that:
1. An human solvable and reasonably easy way to pose the questions (your heirs might not be nerds).
2. No previous advice of the existence of the system by the heirs (they might get greedy... we never know).
3. Enforce a way for all parties to cooperate, no threshold of partial parties (a few of them may conspirate to leave others out of the scene).
4. Personalize your message; it's your TESTAMENT, not some random hashed characters.
5. Also you might want those you love to remind you one last time, instead of doing a simple cash grab. By posing questions of your co-existence, you can be sure that will happen.
But you're free to present your system. Like at RAR, ACE, 7Z, ZIP and other compressing algorithmics, you don't see one of them to come over to say the other must do as he does, do you?
Still your system of Xor'ing the hashes with the question doesn't pose much difference than AES'ing it. But that would provide a way they might solve the questions individually and not as a group, forwarding their hashes through lawyers or so, unlike the intended way of this solution that forces them to be together or take a very long time by proxying it through representatives.
I got your point but I do not agree.
SSS's core is about:
1) threshold agreement, a sort of "tuneable cooperation enforcement" (very useful, because... what in your schema if one of the guys knowing one answer die with you in a car crash? Of course POTUS & VP never travel together by-law, but what for all of us, poor guys?
) ;2) freedom from a specific order in key/answers provisioning.
It's not about participants before-hand coordination and/or knowledge of the goal.
Here is a schema you could use:
1) create a random secret s for your AES-encoded "message for the future"
2) split s via SSS in, for example, 3 parts: s1, s2, s3
3) serialize s1, s2, s3, aka from now consider them just as bits-sequences
4) choose 3 questions q1, q2, q3 and their 3 answers a1, a2, a3 each known by your heirs
5) hash the answers obtaining h1=hash(a1), h2=hash(a2), h3=hash(a3)
6) calculate the (let me introduce a bit of fun in this sadness
) magic numbers: m1=s1 XOR h1, m2=s2 XOR h2, m3=s3 XOR h3the instruction given to each of your heir AFTER your death will be:
1) answer q_i (the question you have chosen to ask to heir i)
2) calculate h_i as hash of answer a_i
3) calculate s_i=h_i XOR m_i
4) provide s_i to a procedure which will collect all of them and then will apply SSS reconstruction of secret s
5) decode the message
Of course, for the sake of simplicity, I have omitted quorum threshold choice and one more technical stuff about s_i and h_i needing to be the same size in bits, but nothing impossible to deal with imho.
Of course you could object the after-death instruction are quite complicated, but of course they can be "web-ized" no more no less than your original program
Shamir's system, which is pair to multi-sign, doesn't requires all parties to cooperate, also requires the parties to know before hand what they're holding and its use.
This system doesn't require to inform anyone or you can inform a third unrelated party (custodian) of its existence to summon the needed parties when it becomes needed.
This system doesn't require to inform anyone or you can inform a third unrelated party (custodian) of its existence to summon the needed parties when it becomes needed.
Hi! Thanks for sharing,
but
if you are intererest in this topics, I suggest you to read about Shamir Secret Sharing: it seems more general than your solution (I don't see any benefit in questions/answers strict order or in multi question per heir/ess ) and I guess more deeply analyzed before production:
https://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing
And for wider perspective:
https://www.smartcustody.com
or:
https://www.amazon.com/Cryptoasset-Inheritance-Planning-Simple-Owners/dp/1947910116
Solves the problem when you want your assets to be accessed only by cooperation of a set of people (if you've more than one heir that is).
Isn't any "traces wipe out system" as a dead man's switch, it's the opposite, it's to provide your heirs access to what's normally encrypted.
Isn't any "traces wipe out system" as a dead man's switch, it's the opposite, it's to provide your heirs access to what's normally encrypted.
One thing that bothers everyone that has cryptoassets is on how to leave them once we die or if some accident happens that leaves us unable to respond. This can be handy too if we suffer from memory loss.
So I came up with this idea, a set of questions posed to several people, where each answer is the key to another AES encrypted layer.
~
Download link: https://www.asw.pt/EES.zip
So I came up with this idea, a set of questions posed to several people, where each answer is the key to another AES encrypted layer.
~
Download link: https://www.asw.pt/EES.zip
Wait upon only by reading, I'm a little confused on what problem does that program really solves? I mean yeah it has multi layered encryption which each and every answer are the key to the other, but on what case we must use this instead of just using native encryptions and store such data in either a hardware wallet or simply in a piece of paper hidden in a vault? Also, there are programs that can run and encrypt everything on your device once a certain condition doesn't met its scheduled response, try looking for Dead Man's Switch scripts. Such programs are helpful once there would be incident but you'd still wanted to have an assurance that no one could see either your assets or just your personal files. Hence, what would make us download and try this one?
One thing that bothers everyone that has cryptoassets is on how to leave them once we die or if some accident happens that leaves us unable to respond. This can be handy too if we suffer from memory loss.
So I came up with this idea, a set of questions posed to several people, where each answer is the key to another AES encrypted layer.
Let's say you want to put your questions to Paul, Sue and John in a set of 3 questions each. The system will start by asking Paul one question, then Sue, then John, then Paul again, Sue, John, Paul, Sue, John. There's no way one can answer his 3 questions without the other two answer their questions too. Paul won't be able to see his questions if Sue and John doesn't answer first, nor Sue if John and Paul don't answer in between, and won't even be able to know what questions are those...
The system is purely JS and HTML. And I'm sorry if it's a bit sketchy, just got this idea a couple of days ago.
Download link: https://www.asw.pt/EES.zip
So I came up with this idea, a set of questions posed to several people, where each answer is the key to another AES encrypted layer.
Let's say you want to put your questions to Paul, Sue and John in a set of 3 questions each. The system will start by asking Paul one question, then Sue, then John, then Paul again, Sue, John, Paul, Sue, John. There's no way one can answer his 3 questions without the other two answer their questions too. Paul won't be able to see his questions if Sue and John doesn't answer first, nor Sue if John and Paul don't answer in between, and won't even be able to know what questions are those...
The system is purely JS and HTML. And I'm sorry if it's a bit sketchy, just got this idea a couple of days ago.
Code:
WHAT IT DOES?
This system encrypts a message under several layers of AES encryption.
The ideia is that you be able to leave a message in case of your death or any accident that leaves you unable to respond that can be opened only by a group of persons you know by answering a set of questions you made.
TIPS:
The system has two vectors, informatics and human. The informatics vector is covered under a well known strong encryption algorithm (Advanced Encryption Standard), in CBC mode with PKCS7 padding.
For the human vector, you should select well the persons and the questions, try to not be too obvious, like "what's your favorite color?", or provide questions whose answers could be easily guess by other participants.
Try to be personal, ask things those persons wouldn't tell anyone over any casual chat, and things that you know only you and that person could possibly know, like "When we first met?", "Where we first kiss/make love?", etc.
You can also use a third party you trust, and unrelated to the question targets, to keep the message safe.
In combination, if you want to leave many data, you can strongly encrypt a True/VeroCrypt partition or file container and leave its password as message here.
This system REQUIRES NO INTERNET CONNECTION. For safety you should do it OFFLINE.
INSTRUCTIONS:
Open the Maker module (maker.html) with your browser (the system was made and tested using Firefox 83.0 for 64 bit Linux) and fill the form, some fields are dynamical and will appear only after other actions are done.
You must set:
- A welcome message, that will display in the header of the Viewer Module.
- A message to encrypt
- A final question and its answer (will be used as password to AES encrypt the message itself)
- The number of people you want to be answering your questions, and their names.
- The number of questions to pose each of those persons.
Once done, press the Generate Code button, it will provide you a file to download named msg.js - download it to the same folder of the "Viewer Module".
To use it:
Open the Message.html file, once the msg.js is in that same folder, at the Viewer module and start to roll the questions.
THIRD PARTY SOFTWARE USED:
CryptoJS v3.1.2
jQuery v3.5.1
Download link: https://www.asw.pt/EES.zip
Jump to: