E-mail with deniable authentication

[Andrew Gallagher]

On 31/08/17 03:35, Mario Castelán Castro wrote:
> Writer and recipient have a Diffie-Hellman key over the same group and
> know each other's public key.
> 
> The writer computers the shared secret per the DH algorithm

This is the real trick though - the DH algorithm requires two-way
synchronisation in advance of sending the payload. This is easy enough
with a realtime connection, but much harder with email.

Most "modern" communication protocols can implement deniability and
forward secrecy relatively easily, because they assume a realtime (or
near realtime) connection that allows for cooperative algorithms like
DH. These protocols are a form of data-in-motion security, where the
sequencing of the data is significant, and the integrity of the data is
only valid for the duration of the session.

But emails are data-at-rest. Their integrity has to be mantained for an
indefinite time, since the correspondents may not be online at the same
instance. They are closer (conceptually) to a collection of tiny
encrypted disk volumes than to communication streams, even if those
volumes are then transferred over data-in-motion-secure channels such as
TLS.

To take a concrete example, when you download a file over HTTPS, your
web browser decrypts the file immediately and throws away the
now-useless ciphertext. If you save that file, it's either saved in
plaintext, or encrypted again using a completely separate system. By
contrast, when your MTA receives a PGP email, it does no decryption on
it before saving it to disk (save for whatever the TLS connection
requires). If you come back to that mail a year later, you have to
decrypt it at the point of reading. In the intervening time, the email
has sat in the pristine encrypted form.

Real-time syncronisation such as required by DH can't happen when I'm
asleep and/or my mail client is turned off. It can't happen if I don't
read my emails for a month while I'm on holiday. Now, it is still
possible to implement DH over a high-latency connection such as email -
however this would either have to involve manual intervention at each
stage (e.g. opening an attachment for each step in the DH handshake), or
a mail client that was aware of the protocol and parsed the handshake
emails both automatically and transparently. Perhaps one could adapt the
signal/whisper protocol so that each encrypted message contained part of
the handshake for future messages - but you'd have to open your
encrypted emails in the correct order and maintain an ever-expanding
cryptographic state indefinitely, which itself opens a can of worms.
What happens if you read email using multiple clients? What if someone
roots your laptop?

And as others have pointed out, plausible deniability isn't a panacea.
It's only really useful in the case where your adversary must prove
their assertions to an independent fourth party beyond reasonable doubt.
It might keep you out of jail in a well-functioning democracy, but it
won't save you from the mafia, the CIA or Kim Jong Un.

-- 
Andrew Gallagher

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 862 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20170901/c7fddf04/attachment.sig>