
<html>


<head>


<meta http-equiv="Content-Type" content="text/html; charset=utf-8">


</head>


<body dir="auto">


<div><br>


</div>


<div><br>


</div>


<div><br>


</div>


<blockquote type="cite">Phillip Hallam-Baker <<a href="mailto:phill@hallambaker.com">phill@hallambaker.com</a>> şunları yazdı (4 Haz 2019 23:10):</blockquote>


<blockquote type="cite">


<div dir="ltr">


<div dir="ltr">


<div class="gmail_quote">


<div dir="ltr" class="gmail_attr">On Tue, Jun 4, 2019 at 2:12 AM Bill Cox <<a href="mailto:waywardgeek@gmail.com">waywardgeek@gmail.com</a>> wrote:<br>


</div>


<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">


<div dir="ltr">


<div dir="ltr"></div>


<div class="gmail_quote">


<div dir="ltr" class="gmail_attr">On Mon, Jun 3, 2019 at 8:39 AM Osman Kuzucu <<a href="mailto:bizbucaliyiz@hotmail.com" target="_blank">bizbucaliyiz@hotmail.com</a>> wrote:<br>


</div>


<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">


<div dir="ltr"><br>


<div style="font-family:Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">


Also, as for the application of the scheme, I wanted to ask one more situation. Assuming we have a secret


<i>S</i> (a private key maybe?) distributed to <i>n</i> different secret share holders by using a secret sharing scheme, and we are periodically (say every month) producing data, namely


<i>D<sub>1</sub>, D<sub>2</sub>, D<sub>3</sub> ... D<sub>n</sub></i>. Our rule is, if


<i>k</i> amount of people come together, they should be able to produce a data <i>


D<sub>i</sub></i>, which would be verifiable by the public that it was generated by at least


<i>k</i> amount of share holders' collaboration. However, we do not want any share holder, or anyone from public to learn the actual secret


<i>S</i>, so that no share holder, who contributed to the data production, will not be able to produce any other data <i>D</i><sub style="font-style:italic">i+1


</sub>in the future without other share holders' help. As far as I know, at all secret sharing schemes collaborating once is enough for share holders to learn the main secret


<i>S <span style="font-family:Calibri,Helvetica,sans-serif;font-style:normal;background-color:rgb(255,255,255);display:inline">


(in the case of the papers, it was almost an integer number). Is there a way that we could use, or maybe combine public-private viewkeys, or make the secret


</span><span style="font-family:Calibri,Helvetica,sans-serif;background-color:rgb(255,255,255);display:inline">S</span><span style="font-family:Calibri,Helvetica,sans-serif;font-style:normal;background-color:rgb(255,255,255);display:inline"> some encrypted


 data, or any other thing that would allow such real life application? </span></i></div>


</div>


</blockquote>


<div><br>


</div>


<div>Sure, you can use <span class="gmail_default" style="font-size:small"></span>partially-homomorphic ElGamal threshold encryption based on Shamir secret sharing.  You want to add a way for each member to prove they did their end of the computation honestly,


 so you'll need some custom zero-knowledge proofs.  There are frameworks for generating them for code like this.  You can encrypt, decrypt, re-encrypt to a new public key, or sign which such a scheme.  No member learns anything about the shared secret, and


 every so often the group can re-key, so if an attacker has some shares < t, those shares become useless.</div>


</div>


</div>


</blockquote>


<div><br>


</div>


<div>


<div class="gmail_default" style="font-size:small">There are some very nice theoretical schemes but when you start to implement them for real, they tend to collapse down to all being variants of the same thing.</div>


<div class="gmail_default" style="font-size:small"><br>


</div>


<div class="gmail_default" style="font-size:small">This is a work in progress. </div>


<div class="gmail_default" style="font-size:small"><a href="https://datatracker.ietf.org/doc/draft-hallambaker-mesh-architecture/">https://datatracker.ietf.org/doc/draft-hallambaker-mesh-architecture/</a> </div>


<div class="gmail_default" style="font-size:small"><br>


</div>


<div class="gmail_default" style="font-size:small">I use Shamir Secret sharing for the purpose of providing a key escrow mechanism that does not depend on hardware for key recovery.<br>


</div>


<div class="gmail_default" style="font-size:small"><br>


</div>


<div class="gmail_default" style="font-size:small">I also use a very simple key splitting mechanism where I require m of m keys to be used to decrypt. This covers the case where Alice wants to read her end-to-end encrypted mail on her mobile phone but have


 some means of disabling access if the phone is lost, she is passing through customs, etc. So if her private key a = x+y, she puts x on her phone and y in the cloud. The cloud machine cannot encrypt on its own and neither can her mobile. They must both co-operate.</div>


<div class="gmail_default" style="font-size:small"></div>


<div class="gmail_default" style="font-size:small">Now I can imagine extending the same approach to allow the key to be split so that n<m keys are required to decrypt. It is just a matter of working out the math. I am sure someone has done it. What I find harder


 to understand is a real world use case or how to construct a user experience that is viable.</div>


<br>


</div>


<div>


<div class="gmail_default" style="font-size:small">Sure call the result homomorphic encryption if you like but I don't think it comes close to meeting the criteria. In fact, the technique I am using was probably developed before the term homomorphic encryption


 was established. For a system to be called homomorphic, I want to be able to give it a non-trivial calculation to perform on that data and get back a result. Otherwise it is just a threshold key scheme and those problems were solved to my satisfaction back


 in the 1990s and all the patents therof have expired.</div>


</div>


<div> </div>


</div>


</div>


</div>


</blockquote>


<div><br>


</div>


<div>


<div><span style="background-color: rgba(255, 255, 255, 0);">Thanks a lot for the reply! </span></div>


<div><span style="background-color: rgba(255, 255, 255, 0);"><br>


</span></div>


<div><span style="background-color: rgba(255, 255, 255, 0);">I think at this point I realized that, whatever I do, there is no way of me knowing if some malicious share holder revealed their key to other third parties, or leaked information or not. We can know


 if they are honestly giving us their share, but we can not know if they did something else with it, or not. Because we are doing digital encryption, and not giving real physical amulets to any knight, we can't know some things for certain.</span></div>


<div><span style="background-color: rgba(255, 255, 255, 0);"><br>


</span></div>


<div><span style="background-color: rgba(255, 255, 255, 0);">And I realized it all depends on the real life applications of above mentioned protocols, because when I think about it, there has to be a person first, who decides what is the <i>SECRET</i>. So actually,


 one man on the earth already knows what's the secret, and distributes the keys before the key owners themselves see the key. It all comes down to a point, where a centralized server would ask for the keys from each share holder, and verify their integrity.</span></div>


<div><span style="background-color: rgba(255, 255, 255, 0);"><br>


</span></div>


<div><span style="background-color: rgba(255, 255, 255, 0);">even better application could be, generating a<i> </i>master private key<i> K</i>, and a secret <i>S, </i>encrypt the secret <i>S</i> with the<i> </i>private master key <i>K </i>to get<i><span style="font-style: normal;">encrypted


 data </span><i>S</i><sub>e</sub>. </i>Later, divide that <i><i>S</i><sub>e</sub></i> to how many parts we want, according to any secret sharing scheme and distribute them. Once enough share holders come together, they can reveal only the encrypted data <i>S<sub>e</sub></i>,


 but not the actual secret <i>S</i>. And as for verification, the key master, or the centralized official app, could just use their own master view key (view key of <i>K)</i> to make sure those share holders actually collaborated. And at any point, if the key


 master is worried about the shares being leaked (so the generation of <i>S<sub>e</sub></i> from those shares actually don't prove that real share holders collaborated ) key master can simply change the private key<i>K</i> to some other private key <i>K'</i>,


 then generate a new <i>S'</i><sub style="font-style: italic;">e </sub>by using that <i>K'</i>, and re-distribute new shares for the <i>S'<sub>e</sub></i>. This way allows key master to make sure, even if all share holders act malicious and they publicly announce


 their shares, no one still can reach the main secret <i>S</i>, because it never got revealed in any way. Of course, by adding extra security measures as in your e-mail, we can add more cryptographic measures (threshold encryption or better distribution way)


 to make it as secure as possible. But our standing point of secret not being revealed at all allows us to secure our secret even if all shares get leaked. This eliminates the risk of malicious share holders selling their keys or other stuff. As once key master


 realizes such activity, key master changes the master private key and even if people calculate <i>S<sub>e</sub></i> from the previous shares, no problem at all.</span></div>


<div><span style="background-color: rgba(255, 255, 255, 0);"><br>


</span></div>


<div><span style="background-color: rgba(255, 255, 255, 0);">As for verifying the message from public, I believe it is better for them to trust one authorized person's approval (key master claiming that everyone collaborated) than trusting n different share


 holders about their honesty. Key master can lie to the public, but at the end, he was the one who created and distributed shares. If key master wanted to lie to others, he wouldn't share the keys with others at the first place. </span></div>


</div>


</body>


</html>