<div dir="ltr"><div dir="ltr"><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, Aug 31, 2021 at 5:04 PM jrzx <<a href="mailto:jrzx@protonmail.ch">jrzx@protonmail.ch</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 style="font-size:small">On Sunday, August 22nd, 2021 at 12:17 PM, Phillip Hallam-Baker <<a href="mailto:phill@hallambaker.com" target="_blank">phill@hallambaker.com</a>> wrote:<br></div><div>> Threshold decryption allows encrypted documents to be shared and used with exactly the same<br></div><div>> ease as unencrypted documents, somewhat easier in fact as there is less need to be concerned<br></div><div>> about leaks on stolen laptops etc.<br></div><div><br></div><div>As I understand your proposal, you are not actually threshold encrypting the documents, but threshold encrypting the permissions request to the master server on the cloud, which holds secrets and whose operator has to manage those secrets.</div></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">??? I am not sure what you are saying. First off, there is no threshold 'encryption' and it is only decryption that may be shared.</div><br></div><div><div class="gmail_default" style="font-size:small">The GroupW public key is {W, w}</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Alice holds w</div><div class="gmail_default" style="font-size:small">Bob holds w-b, service holds b</div><div class="gmail_default" style="font-size:small">Carol holds w-c, service holds c</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Alice can add doug by creating a share w-d, d and sending them to Doug and the service.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Alice can remove Bob by telling the service to delete b.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">This is not a Snowden-is-my-keyserver-admin scheme. The service never sees w. In fact it never sees a value that even depends on w.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">We could even have a version of the scheme in which the service keys are generated from a primary seed held by Alice and the key used to claim them which would allow new users to be added without touching the service. </div></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>This runs into the same problems that lead to DKIM with DMARK being unable to stop spearfishing attacks.</div></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">DKIM and DMARK only authenticate the service, ridiculous amounts of electrons were expended on the difference between envelope from and message from.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The main reason DKIM and DMARK fail is that they are optional though. It is impossible to go from default insecure to default deny.</div></div><div class="gmail_default" style="font-size:small"><br></div></div></div></div></div>