BBCR4 on Crypto-wars today at 13:30

[Peter Fairbrother]

On 25/03/14 03:58, Ben Laurie wrote:
> On 25 March 2014 03:41, Peter Fairbrother <zenadsl6186 at zen.co.uk> wrote:
>> That's cool, but it isn't much use here, and the resulting key can still be
>> used for encryption - we need a key which can't be used for encryption here,
>> only for signatures (else it can be demanded).
>
> a) DSA
>
> b) If you can sign, you can encrypt
> (http://en.wikipedia.org/wiki/Chaffing_and_winnowing)
>

Yep - the bigger problem is when other people use your signing key to 
encrypt :(


Separately, to Alan B., thanks for the info.


below is a kinda-draft, ignore if not interested.

-- Peter Fairbrother




Improved email:

Objectives:

1) to eventually get a majority of all email sent end-to-end encrypted 
to a minimum security standard, such that active measures are needed to 
intercept and read it.

2) to be usable in a highly secure manner if and when that is required.

3) to resist demands for decryptions and for keys.

4) to be as future-proof as possible.

5) we think anonymity is not immediately practicable.



In order to achieve these objectives the following requirements must be met:


** Legal requirements:

To be entirely open source and free, as in BSD or similar license.

    If not then Wassenaar and/or other crypto export requirements may 
apply, defeating objective 1)



** Software requirements:

A] be as widely compatible as possible, so that many people will use it

B] be easy to use, indeed almost transparent to the user, so that many 
people will use it

C) well-developed email reader and webmail clients are essential. If 
they aren't consumer-grade consumers won't use them,  writing 
non-consumer-grade clients is just a waste of time and effort.

D) must be compatible with normal email, but default to encrypted mode

E) must be cheap to install and operate, and not require normal email 
servers to do anything



** Cryptographic and security requirements:

a) an automatic key server, probably distributed/shared. We don't want 
the user to have to do anything to obtain a relevant key, otherwise he 
may not bother [1]

b) ephemeral keys, signature-only keys [2]

c) high-secure mode must look the same as low-secure mode to an attacker

d) clear distinction to the user between security modes in use





notes:

[1] 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.

Though perhaps the security level of the key server isn't that great, 
it's better than nothing. If the user wants better key security he can 
get it in many ways, eg by sharing keys in person, which can be 
displayed in a menu somewhere onscreen.




[2] ephemeral keys for resistance to subject-matter-key demands, 
signature-only keys to prevent legal demands for keys which authenticate 
the ephemeral keys.

Ephemeral keys are updated automatically, the user should need to make 
no input to update the keys.