[Cryptography] Dark Mail Alliance specs?
Peter Fairbrother
zenadsl6186 at zen.co.uk
Tue Mar 25 18:26:12 EDT 2014
Does anyone have any more info on DarkMail?
On 23/11/13 20:11, Stephan Neuhaus wrote:
> In my opinion, massive user-controlled email encryption will not happen.
> Not now, and not in the next ten years.
Depends. Some thoughts on what might work in ten years or less:
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 a 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.
-- Peter Fairbrother
More information about the cryptography
mailing list