BBCR4 on Crypto-wars today at 13:30
zenadsl6186 at zen.co.uk
Sun Mar 23 23:59:45 GMT 2014
On 21/03/14 07:10, Caspar Bowden (lists) wrote:
> On 03/20/14 22:46, Peter Fairbrother wrote:
> But FISA 702 in particular can force arbitrary service provider
> "co-operation" (as per Hushmail case, but that was actually Canada -
> anyone get to the bottom of that?)
> So anything you depend on the email service provider to do for your
> confidentiality can be subverted by law
Yes, that can be a problem.
A suggestion, a distributed key service.
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.
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
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.
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.
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.
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.
Note that the key servers are separate from the email servers which just
work in the normal way.
*_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.
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.
>> eg, what happens if someone sends you an unencrypted email on your
>> encrypted service?
> Would be nice to have an autoresponder which bounced mail without right
> GPG header?
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.
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
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.
But I can also think of situations where an autoresponder-rejecter is
the correct solution.
More information about the ukcrypto