<div dir="ltr">If you are willing to use distributed key servers you might build on an observation by Gus Simmons.<div><br></div><div>The RSA scheme usually generates a pair of keys, (d,n) and (e,n), where p and q are two large primes, n=p.q, and d.e is congruent to (p-1).(q-1). Encrypt by computing c = (m**e) mod n; decrypt by computing m = (c**d) mod n. Message padding is needed to guard again certain attacks, but is irrelevant to this example.</div>
<div><br></div><div>Simmons observed that you can construct three or more keys the same way: (d,n), (e,n), (f,n) where d.e.f is congruent to (p-1)(q-1).</div><div><br></div><div>I can give a server (f,n), declare (e,n) to be my public key, and retain (d,n) for myself. Together (d,n) and (f,n) comprise my private key. Encrypt as normal c = (m**e) mod n; decrypt by computing m = (((c**f) mod n) ** d) mod n. The server participates in decryption but can't complete the decryption operation. I can add further servers in a similar manner.</div>
<div><br></div><div>What I like about Simmons's scheme is that (e,n) is a normal RSA key so I may publish an S/MIME certificate for it. People who wish to send me encrypted messages don't need special software; they don't even need to be aware that my decryption is unusual.</div>
<div><br></div><div>Mark</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 23 March 2014 19:59, Peter Fairbrother <span dir="ltr"><<a href="mailto:zenadsl6186@zen.co.uk" target="_blank">zenadsl6186@zen.co.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On 21/03/14 07:10, Caspar Bowden (lists) wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 03/20/14 22:46, Peter Fairbrother wrote:<br>
</blockquote></div>
[...]<div class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
But FISA 702 in particular can force arbitrary service provider<br>
"co-operation" (as per Hushmail case, but that was actually Canada -<br>
anyone get to the bottom of that?)<br>
<br>
So anything you depend on the email service provider to do for your<br>
confidentiality can be subverted by law<br>
</blockquote>
<br>
<br></div>
Yes, that can be a problem.<br>
<br>
A suggestion, a distributed key service.<br>
<br>
Each keyserver accepts keys from (and generated by) users, sends them a confirm message to the email address attached to the key, then on receipt of the (signed) confirm reply adds the key to the shared list.<br>
<br>
Each shared list entry consists of: email address, server, date added, key. The list is hashed and updated between servers a bit like the bitcoin list (which might also pay for the key servers, eg the right to send spam).<br>

<br>
When a user wants to send an email he contacts his list server, the recipient's list server, and another list server chosen at random and asks each for the key. The recipient's key server also replies with a signed-by-the-recipient ephemeral key as well as the recipient's key.<br>

<br>
If there is only one key for the email address, and the three responses match, and the sender's own copy of the recipient's key (if he has one) all match, then he uses the signed and dated ephemeral key provided by the recipients key server.<br>

<br>
The replies from the servers are all signed, so if they don't match we want to know why - the replies can then be published, so if a server cheats then it can be found out and shamed.<br>
<br>
There is a little more, eg when there is no key or more than one key attached to a single email address, but that's basically how to find a new correspondent's key from his email address.<br>
<br>
Note that the key servers are separate from the email servers which just work in the normal way.<br>
<br>
<br>
<br>
*_You'll have to write some decent email and webmail clients_*  but after that in most cases it can be almost entirely transparent to the user - in that respect the gpg etc clients/addons/etc, not to put too fine a point on it, suck.<br>

<br>
I think most of the people who write secure email software don't spend nearly enough time and effort writing good clients, and good clients are essential if their solution is to be used.<div class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
eg, what happens if someone sends you an unencrypted email on your<br>
encrypted service?<br>
</blockquote>
<br>
Would be nice to have an autoresponder which bounced mail without right<br>
GPG header?<br>
</blockquote>
<br></div>
I don't know. That's the "security" answer, but it isn't necessarily correct - I don't know whether there is a single correct answer.<br>
<br>
The idea is to get people to use it, and use it in a secure manner. If eg secure m-messages are presented onscreen in red in one window, and insecure messages are in black in a differently-designed window, and the user both knows this and uses it correctly - then there is no need for an autoresponder-rejecter.<br>

<br>
Also, does it have to be secure all the time? If the idea is to have a generally secure encrypted email service on which you can send highly secure emails, the rest of the mails don't have to be super-secure against eg malware or phishing - especially if the supersecure and normally-secure versions look the same to an attacker. There is room there for some unencrypted emails too.<br>

<br>
But I can also think of situations where an autoresponder-rejecter is the correct solution.<span class="HOEnZb"><font color="#888888"><br>
<br>
<br>
-- Peter<br>
<br>
<br>
</font></span></blockquote></div><br></div>