BBCR4 on Crypto-wars today at 13:30

[Peter Fairbrother]

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 
send spam).

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 
an autoresponder-rejecter.

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.


-- Peter