[Cryptography] DIME // Pending Questions // Seeking Your Input
Peter Fairbrother
zenadsl6186 at zen.co.uk
Sun Mar 1 18:45:23 EST 2015
On 27/02/15 16:08, Ladar Levison wrote:
> Hi,
[...]
> The December draft can be found here:
>
> https://darkmail.info/downloads/dark-internet-mail-environment-december-2014.pdf
Had a very quick look, seems like DIME is an email-like message-passing
service of some kind - though it is not email, it will not work on
normal email channels, it is not compatible with email - with end-to-end
encryption and some attempt to prevent traffic tracing and to provide
forward secrecy.
Neither the end-to-end encryption nor the traffic obfuscation is
particularly robust - the encryption is subject to MITM attack, and the
traffic obfuscation is at best partial, and depends on trusting the
sender's and the recipient's end servers, presumably operated by other
people than the sender or intended recipient.
Sender x sends a message through server X to recipient y's server Y.
Roughly, server X will serve clients using TLD X, and server Y will
serve clients using TLD Y, as both sending and receiving servers.
Clients can be offline when messages are passed.
To deter MITM there is a complicated system of "signets", where two key
signatures are obtained from somewhere - a CA? and the sender's server?
the recipient's server? I am unclear about this.
In any case, it would seem that this requirement to fetch (at least) 2
signets per message compromises the traffic tracing obfuscation - the
servers holding the signets would know who sent the request, and the
intended recipient it was meant for.
In order to make message tracing a little harder, an observer of traffic
between server X and server Y cannot immediately tell which of server
Y's clients the traffic is for.
However there is no delay or batching, so a passive observer of person x
and his server X can immediately tell that x has sent a message to
server Y, though he cannot immediately tell which of server Y's clients
the message is for.
This system is obviously not robust against compromise of the recipient
server, including legal requirements to store traffic data (formerly a
becoming-ubiquitous legal requirement in the EU, now the legal status of
traffic data retention is a bit indeterminate - though anyone operating
a server in the UK today, for instance, would be required to log the
relevant traffic data and store it for 12 months.)
I think the sender's server X is not intended to know which of server
Y's clients the traffic is for, just the recipient's server - however,
the requirements for obtaining signets and perhaps DH portions also make
server X susceptible to attack based on server compromise, and probably
server traffic data retention requirements as well.
Also, according to figure 1, server Y sends some data direct to the
sender. I am unclear about what data is sent, or why. so it is possible
server Y does not know for sure who the sender is, but it seems likely.
Again, from figure 1, it seems some data is sent from server X directly
to the recipient - so server X is likely to know who the recipient
There appears to be some form of forward secrecy, but details are
lacking - as far a I can tell the recipient y seems to have a permanent,
or at least semi-permanent, DH secret; so for instance message
confidentiality is not secure against legal or rubberhose demands for keys.
As I said, I only had a very quick look - is that about right?
-- Peter Fairbrother
More information about the cryptography
mailing list