<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div></div><br><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₁, D₂, D₃ ... D_n</i>. Our rule is, if
<i>k</i> amount of people come together, they should be able to produce a data <i>
D_i</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>