[cryptography] Email is unsecurable

pjklauser at gmail.com pjklauser at gmail.com
Wed Nov 27 01:45:56 EST 2013

>From: Natanael [mailto:natanael.l at gmail.com] 
>Sent: Dienstag, 26. November 2013 22:16
>To: pjklauser at gmail.com
>Cc: stephen.farrell at cs.tcd.ie; grarpamp; cypherpunks at cpunks.org;
p2p-hackers at lists.zooko.com; cryptography at randombit.net
>Subject: RE: [cryptography] Email is unsecurable
> Bote mail doesn't have to be used for it's anonymous properties, for me
that is just a bonus.
> For many people it is more than enough to be able to know that it is
impossible for anybody 
> else than the intended recipient to read the message thanks to public key
> Guaranteed end-to-end security if you can verify the 
> address. 
> I don't think anything that doesn't fundamentally rely on public key
addressing is the (long 
> term) future. There will inevitably issues otherwise, including more
issues of the type we
> have with CA:s today.

To achieve end2end security - yes it is inevitable that endpoints will have
"public key" identities, but this should not be confused with the
An address should have meaning to the sender and typically has a longer
lifetime duration than a credential which needs changing over time and due
to expiration/loss etc. 

> For those who want to make it more user friendly, nothing stops you from
adding a transparent > "address translation layer" where servers are
involved. When you want to send a message to a > person with a human
readable address at a server, then the server could then reply with the 
> public key based address to the mail client, and the user would have the
option to see what 
> that address is. It could even be logged by the client, with TOFU/POP
style trust system that 
> reduces the amount of trust you have to place in the server. 

I think an "address translation layer" is inevitable and should be

It's a possible to augment standard email with an address to say PGP-key/PK
translation layer which piggybacks off DNS. 
1) a service provider puts a URL link to an authoritative address to public
key resolution service in a DNS record ( TXT or new MX_ADDRESS_RESOLUTION ).
For example
2) anyone can find and query for the PK(s) to an address via the provider's
3) the service provider can sign the resolution responses - the service
provider is the authority on which addresses exist anyway.
4) recipients can provide their providers with their PKs which match their
addresses through proprietary interfaces - the how here is not so important.
5) recipients can check that their service provider publishes their correct
PKs - since the recipient can check directly. If a service provider doesn't
publish accurately / timely customers would change provider to ones which do
- so there is no incentive here to cheat on the part of the provider. To
really avoid the possibility that the service provider is performing a MITM
attack, the sender would sign and send to the recipient a signed copy of the
PK ( or better the authoritative response from the resolution service ).
This way the recipient can check that the sender had the used the correct PK
and not some forgery.

> No need to trust anybody with plaintext. 

Too true - you cannot trust anyone with plaintext:)


More information about the cryptography mailing list