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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users