[cryptography] Email is unsecurable

Natanael natanael.l at gmail.com
Tue Nov 26 16:15:52 EST 2013

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 addressing. 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.

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. No need to trust anybody with plaintext.

- Sent from my phone
Den 26 nov 2013 21:58 skrev <pjklauser at gmail.com>:

> >From: Stephen Farrell <stephen.farrell at cs.tcd.ie>
> >To: "Fabio Pietrosanti (naif)" <lists at infosecurity.ch>,
>         cryptography at randombit.net
> >Message-ID: <5293C66D.4040906 at cs.tcd.ie>
> >
> > On 11/25/2013 08:09 PM, Fabio Pietrosanti (naif) wrote:
> > > Let's first cut-off the massive passive traffic analysis, then improve
> > > current systems to provide some added protection against metadata,
> > > focusing in a far future, when the new system got already wide
> > > adoption, make it perfect.
> >
> > New work on improving hop-by-hop security for email and other things is
> > getting underway in the IETF. [1] Basically the idea is to document stuff
> > that can be turned on already in current deployments (to the extent
> > possible) that gets you PFS and modern TLS ciphersuites.
> Pre-working-group
> > charter discussion for this is being directed to the
> apps-discuss at ietf.org
> > list for now, or if folks aren't keen to get on that list, feel free to
> > send me comments and I'll make sure they get into the pot. I'll send a
> > mail here when the WG is officially kicked off (in a few weeks hopefully)
> > with a pointer to the eventual wg mailing list.
> way to go!
> Personally I don't see how using a P2P network in any next-gen email system
> helps anything. If I send a message to someone, I trust my service provider
> to deliver the message to the recipients service provider. If the
> communication path is limited to this minimum 3 hops - and each hop is
> "secure", then this could be good enough ( considering each service
> provider
> can be sure that it's talking with the other one directly and securely ).
> This is the system architecture proposed for TDMX[2] for a new
> transactional
> enterprise messaging (yet-to-be standard) system I'm working on. Between
> each hop is anyway an anonymous void of untrustworthyness - called the
> internet ( adding any application layer complexity seems overkill ).
> If you don't ( and you probably can't ) trust your service provider
> (enough)
> then there's nothing stopping you running your own.
> Furthermore, Email doesn't need anonymization ( it got to where it is today
> without it - it will survive some more) and in fact I argue in [1] that
> corporations cannot really use use end-to-end security either.
> [1]
> http://pjklauser.wordpress.com/2013/11/17/why-enterprises-wont-embrace-darkm
> ail/
> [2] http://tdmx.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.randombit.net/pipermail/cryptography/attachments/20131126/ec482df6/attachment.html>

More information about the cryptography mailing list