[prev in list] [next in list] [prev in thread] [next in thread]
List: cryptography
Subject: Re: [Cryptography] My deployment plan for end-to-end secure email.
From: Phillip Hallam-Baker <phill () hallambaker ! com>
Date: 2021-09-01 2:48:46
Message-ID: CAMm+Lwi=HhZvhmU3SVanS=FPjGXcqjj5jrd=uR033RzGWZvd_Q () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Tue, Aug 31, 2021 at 7:45 PM jrzx <jrzx@protonmail.ch> wrote:
> > > On Sunday, August 22nd, 2021 at 12:17 PM, Phillip Hallam-Baker <
> phill@hallambaker.com> wrote:
> > > > Threshold decryption allows encrypted documents to be shared
> > > > and used with exactly the same ease as unencrypted documents,
> > > > somewhat easier in fact as there is less need to be concerned
> > > > about leaks on stolen laptops etc.
>
> > On Tue, Aug 31, 2021 at 5:04 PM jrzx <jrzx@protonmail.ch> wrote:
> > > 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.
>
> Phillip Hallam-Baker <phill@hallambaker.com>
> > ??? I am not sure what you are saying. First off, there is no threshold
> > 'encryption' and it is only decryption that may be shared.
> >
> > The GroupW public key is {W, w}
> >
> > Alice holds w
> > Bob holds w-b, service holds b
> > Carol holds w-c, service holds c
>
> > Alice can add doug by creating a share w-d, d and sending them to Doug
> > and the service.
>
> This is not what the phrase threshold cryptography normally refers to,
> because there is no threshold. Rather unanimity between Bob and the
> server. Hence my confusion.
>
> Threshold cryptography refers to n of m schemes where n is
> substantially less than m. This is a two of two scheme.
>
t = n = 2.
Looks like threshold to me.
I do plan to make use of t<n in time but I don't need it for the simplest
case. The point at which it becomes necessary is if we want to transition
from one key service to another. In that case I use Shamir/Lagrange
techniques but that is not what I am planning for the initial release.
> > Alice can remove Bob by telling the service to delete b.
> >
> > 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.
>
> That is an elegant idea, and could be used to do a great many interesting
> things, but you have left out the parts where stuff actually gets
> encrypted and decrypted.
>
I will be making a podcast with a demo in due course. I am just in the
final stage of refactoring. The initial architecture used different
approaches for threshold group decryption and threshold device decryption.
So I have been correcting that. Was hoping to finish today but Rome wasn't
burned in a day.
> Attempting to fill the gaps in from my imagination, which doubtless
> differs from your own.
>
> Each document contains public key used once, a konce. Call the
> corresponding transient secret key k, the corresponding public key K.
>
> The corresponding transient private key k is thrown away after being
> used for one document once.
>
> The transient symmetric key that decrypts the document is kW=wK
>
Essentially El-Gamal Encryption., yes
> Anyone can encrypt a document so that only he, or Alice, or one of the
> holders of shares with the full cooperation of the server can decrypt it.
>
> The documents at rest are stored in their encrypted form on Bob's
> machine, and any time he wants to read one of them, he cooperates with
> the server to construct wK, the transient symmetric secret for each
> document he wants to read, without either party ever getting the full
> value of w.
>
> The transient symmetric secrets are stored on Bobs machine until he logs
> off, unless he does something naughty to keep them around - or more
> likely does something careless to keep the cleartext around.
>
> If Alice gets fired, the secret key w is reconstructed by the cooperation
> of
> the server and one of the shareholders, and documents at rest are
> re-encrypted to a new key All the old shares are then thrown away
> and old copies of the old documents become unreadable for most
> people.
>
I left that part out of the description but yes, we can threshold share the
administration role. I described that on my Facebook page a few weeks
back...
Basically, we can divide up the roles of the admins and service any way we
like and transition either. We just need to do work out the constraints and
configure the shares accordingly.
Normally, we just use Lagrange to recover the original shared secret but we
can also use it to create additional shares. I plan to use the key
fingerprint of the service to give the x coordinate for the corresponding
share...
[Attachment #5 (text/html)]
<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 7:45 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>> > 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<br></div><div>> > > and used with exactly the same ease as \
unencrypted documents,<br></div><div>> > > 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>> On Tue, Aug 31, 2021 at 5:04 PM jrzx \
<<a href="mailto:jrzx@protonmail.ch" target="_blank">jrzx@protonmail.ch</a>> \
wrote:<br></div><div>> > As I understand your proposal, you are not actually \
threshold<br></div><div>> > encrypting the documents, but threshold encrypting \
the<br></div><div>> > permissions request to the master server on the \
cloud,<br></div><div>> > which holds secrets and whose operator has to manage \
those secrets.<br></div><div><br></div><div>Phillip Hallam-Baker <<a \
href="mailto:phill@hallambaker.com" \
target="_blank">phill@hallambaker.com</a>><br></div><div>> ??? I am not sure \
what you are saying. First off, there is no threshold<br></div><div>> \
'encryption' and it is only decryption that may be \
shared.<br></div><div>><br></div><div>> The GroupW public key is {W, \
w}<br></div><div>><br></div><div>> Alice holds w<br></div><div>> Bob holds \
w-b, service holds b<br></div><div>> Carol holds w-c, service holds \
c<br></div><div><br></div><div>> Alice can add doug by creating a share w-d, d and \
sending them to Doug<br></div><div>> and the \
service.<br></div><div><br></div><div>This is not what the phrase threshold \
cryptography normally refers to,<br></div><div>because there is no threshold. \
Rather unanimity between Bob and the<br></div><div>server. Hence my \
confusion.<br></div><div><br></div><div>Threshold cryptography refers to n of m \
schemes where n is<br></div><div>substantially less than m. This is a two of two \
scheme.</div></blockquote><div><br></div><div><div class="gmail_default" \
style="font-size:small">t = n = 2.</div><div class="gmail_default" \
style="font-size:small"><br></div><div class="gmail_default" \
style="font-size:small">Looks like threshold to me.</div><div class="gmail_default" \
style="font-size:small"><br></div><div class="gmail_default" \
style="font-size:small">I do plan to make use of t<n in time but I don't need \
it for the simplest case. The point at which it becomes necessary is if we want to \
transition from one key service to another. In that case I use Shamir/Lagrange \
techniques but that is not what I am planning for the initial \
release.</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>> Alice can remove Bob by telling the \
service to delete b.<br></div><div>><br></div><div>> This is not a \
Snowden-is-my-keyserver-admin scheme. The service<br></div><div>> never sees w. In \
fact it never sees a value that even depends on w.<br></div><div><br></div><div>That \
is an elegant idea, and could be used to do a great many \
interesting<br></div><div>things, but you have left out the parts where stuff \
actually gets<br></div><div>encrypted and \
decrypted.</div></blockquote><div><br></div><div><div class="gmail_default" \
style="font-size:small">I will be making a podcast with a demo in due course. I am \
just in the final stage of refactoring. The initial architecture used different \
approaches for threshold group decryption and threshold device decryption. So I have \
been correcting that. Was hoping to finish today but Rome wasn't burned in a \
day.</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>Attempting to fill the gaps in from my \
imagination, which doubtless<br></div><div>differs from your \
own.<br></div><div><br></div><div>Each document contains public key used once, a \
konce. Call the<br></div><div>corresponding transient secret key k, the \
corresponding public key K.<br></div><div><br></div><div>The corresponding transient \
private key k is thrown away after being<br></div><div>used for one document \
once.<br></div><div><br></div><div>The transient symmetric key that decrypts the \
document is kW=wK</div></blockquote><div><br></div><div><div class="gmail_default" \
style="font-size:small">Essentially El-Gamal Encryption., yes</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>Anyone can encrypt a document so that \
only he, or Alice, or one of the<br></div><div>holders of shares with the full \
cooperation of the server can decrypt it.<br></div><div><br></div><div>The documents \
at rest are stored in their encrypted form on Bob's<br></div><div>machine, and \
any time he wants to read one of them, he cooperates with<br></div><div>the server to \
construct wK, the transient symmetric secret for each<br></div><div>document he wants \
to read, without either party ever getting the full<br></div><div>value of \
w.<br></div><div><br></div><div>The transient symmetric secrets are stored on Bobs \
machine until he logs<br></div><div>off, unless he does something naughty to keep \
them around - or more<br></div><div>likely does something careless to keep the \
cleartext around.<br></div><div><br></div><div>If Alice gets fired, the secret key \
w is reconstructed by the cooperation of<br></div><div> the server and one of the \
shareholders, and documents at rest are<br></div><div>re-encrypted to a new key All \
the old shares are then thrown away <br></div><div>and old copies of the old \
documents become unreadable for most \
<br></div><div>people.<br></div></blockquote><div><br></div><div><div \
class="gmail_default" style="font-size:small">I left that part out of the description \
but yes, we can threshold share the administration role. I described that on my \
Facebook page a few weeks back... </div><div class="gmail_default" \
style="font-size:small"><br></div><div class="gmail_default" \
style="font-size:small">Basically, we can divide up the roles of the admins and \
service any way we like and transition either. We just need to do work out the \
constraints and configure the shares accordingly.</div><div class="gmail_default" \
style="font-size:small"><br></div><div class="gmail_default" \
style="font-size:small">Normally, we just use Lagrange to recover the original shared \
secret but we can also use it to create additional shares. I plan to use the key \
fingerprint of the service to give the x coordinate for the corresponding share... \
</div><br></div><div> </div></div></div>
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
https://www.metzdowd.com/mailman/listinfo/cryptography
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic