Re: [cryptography] Email is unsecurable
>From: Natanael [mailto:natanae...@gmail.com]
>Sent: Dienstag, 26. November 2013 22:16
>To: pjklau...@gmail.com
>Cc: stephen.farr...@cs.tcd.ie; grarpamp; cypherpu...@cpunks.org;
p2p-hack...@lists.zooko.com; cryptography@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
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.
To achieve end2end security - yes it is inevitable that endpoints will have
"public key" identities, but this should not be confused with the
"address"[1].
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
standardized.
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
TXT="https://pk-resolver.gmail.com/resolve-address?emailaddress={}";
2) anyone can find and query for the PK(s) to an address via the provider's
service.
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:)
[1]
http://pjklauser.wordpress.com/2013/03/09/deconfusing-addresses-and-identiti
es/
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Quality of HAVEGE algorithm for entropy?
On Tue, Nov 26, 2013 at 10:09 AM, Joachim Strömbergson wrote: > ... > I have concerns though on embedded SSL stacks that use Havege as entropy > source on MCUs such as AVR32 and ARM. > ... > On an x86-based server you can use Havege, but use it to feed > /dev/random, not as a RNG directly. The same goes for Jytter. good points! haveged should work fine on StrongArm, A8, A9, Xscale, anything with a high res timer like ARM Cycle Counter (in place of TSC). older ARM processors and x86 without high res TSC (pre-pentium?) will have trouble. and as mentioned, all entropy sources should feed into host entropy pool via an entropy daemon that verifies entropy, mixes / compresses it, and then feed into host pool. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
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 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 : > > >From: Stephen Farrell > >To: "Fabio Pietrosanti (naif)" , > cryptography@randombit.net > >Message-ID: <5293c66d.4040...@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-disc...@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 > > > ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Email is unsecurable
>From: Stephen Farrell >To: "Fabio Pietrosanti (naif)" , cryptography@randombit.net >Message-ID: <5293c66d.4040...@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-disc...@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 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Quality of HAVEGE algorithm for entropy?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Aloha! Fabio Pietrosanti (naif) wrote: > i found such a very nice piece of software that's said to provide > added entropy using HAVEGE algorithm: > http://www.issihosts.com/haveged/ > http://www.irisa.fr/caps/projects/hipsor/ Yes. I've done some testing of Havege. Generating ~100 MByte of data and tested it with Dieharder. Data generated on late x86-64 arch yielded good quality random numbers. Havege generates entropy in good quantity and the entropy source is does not depend on an external physical source. I have concerns though on embedded SSL stacks that use Havege as entropy source on MCUs such as AVR32 and ARM. Havege is based on the assumption that instruction execution varies and tries to force cache misses to increase execution variance by forcing hitting all levels in the cache hierarchy including main store. But on RISC architectures with few or no levels of cache memories this assumption does not hold. Note that I have not yet tested Havege on these architectures though. Also, the entropy estimator supplied with Havege is (was) broken. We tested Havege in a system simulator where we could manipulate/force the TSC which means that Havege generated predictable values. The estimator happily reported good entropy. On an x86-based server you can use Havege, but use it to feed /dev/random, not as a RNG directly. The same goes for Jytter. - -- Med vänlig hälsning, Yours Joachim Strömbergson - Alltid i harmonisk svängning. -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlKU47wACgkQZoPr8HT30QHXggCfVDh0SCq2wO1fyc9ACQ5ETsj9 0OUAn0yb8GHVZDTjiMPNyADITWWVnkfr =mrK9 -END PGP SIGNATURE- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] Email is unsecurable
That can really only be solved by gateways, IMHO. It's the only way to talk between the systems that don't put limits on how secure either one can be. - Sent from my phone Den 26 nov 2013 16:09 skrev "c1cc10" : > If we're discussing about this topic it is because of people. emails are > one people's need: as techis we could create and use any other fancy > communication means and do not bother. > So if we want to bring a new communication infrastructure for everybody > we cannot jump over the existing one, which sadly is the unsecurable email. > Thus we need to consider back-compatibility for any upgrade of the email > protocol, in order to let anyone use it as they do it now. > > my 2 cents > > Francesco Rana > >> On Mon, Nov 25, 2013 at 1:51 PM, Stephen Farrell > >> wrote: > >>> ... > >>> Personally, I'm not at all confident that we can do something > >>> that provides end-to-end security, can be deployed at full > >>> Internet scale and is compatible with today's email protocols. > >>> But if others are more optimistic then I'm all for 'em trying > >>> to figure it out and would be delighted to be proven wrong. > >> > > ___ > cryptography mailing list > cryptography@randombit.net > http://lists.randombit.net/mailman/listinfo/cryptography > ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Quality of HAVEGE algorithm for entropy?
On Mon, Nov 25, 2013 at 6:46 PM, coderman wrote: > On Sun, Nov 24, 2013 at 2:04 PM, Fabio Pietrosanti (naif) > wrote: >> ... >> i found such a very nice piece of software that's said to provide added >> entropy using HAVEGE algorithm: >> http://www.issihosts.com/haveged/ >> http://www.irisa.fr/caps/projects/hipsor/ >> >> Any opinion on the usefulness of that kind of tool as an additional >> entropy source for crypto operations on a Linux system? > > do it yesterday! i have been using this (haveged) for many years, in > addition to physical entropy sources, and it is very much a useful > addition to host entropy sources. Yes. See here for another one, possibly more suitable on very limited systems like phones or routers, and a PDF that discusses several others including Havege. ftp://ftp.cs.sjtu.edu.cn:990/sandy/maxwell/ ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] Email is unsecurable
If we're discussing about this topic it is because of people. emails are one people's need: as techis we could create and use any other fancy communication means and do not bother. So if we want to bring a new communication infrastructure for everybody we cannot jump over the existing one, which sadly is the unsecurable email. Thus we need to consider back-compatibility for any upgrade of the email protocol, in order to let anyone use it as they do it now. my 2 cents Francesco Rana >> On Mon, Nov 25, 2013 at 1:51 PM, Stephen Farrell >> wrote: >>> ... >>> Personally, I'm not at all confident that we can do something >>> that provides end-to-end security, can be deployed at full >>> Internet scale and is compatible with today's email protocols. >>> But if others are more optimistic then I'm all for 'em trying >>> to figure it out and would be delighted to be proven wrong. >> ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] Email is unsecurable
On 26/11/13 03:03 AM, coderman wrote: On Mon, Nov 25, 2013 at 1:51 PM, Stephen Farrell wrote: ... Personally, I'm not at all confident that we can do something that provides end-to-end security, can be deployed at full Internet scale and is compatible with today's email protocols. But if others are more optimistic then I'm all for 'em trying to figure it out and would be delighted to be proven wrong. this would make an interesting bet! i too believe this to be impossible given the constraints. a more suspicious individual might even consider these efforts to be a ruse by intelligence agencies to further the use of insecure (email) systems with "fig leaf" protections added on top while metadata and usability failures continue unabated... IMHO the TLAs bet big on pushing the CA/PKI solution in the 1990s. I've not seen any hard evidence of it, but there is enough anecdotal evidence to conclude it. Some for different reasons, for example the DoD was very keen on COTS which we can see as benign enough, in and of itself. In terms of mass surveillance and espionage, the PKI is a slam dunk. CVPs (centralised vulnerability partners), many of whom are national champions or nationally regulated, browsers hiding the CAs, lock-in via clients, open sharing of certificates. This is an "open internet" solution that only an attacker could truly love. That's not to say there is no value in it for us. Just that we'll end up with strange bedfellows, and we may not be happy who the real winners are. E.g., supporting HTTPS everywhere carries big risks if it is forced through without opportunistic encryption, or other escape valves for society. So I'd suggest caution to both sides of this debate. And careful cost-benefit analysis and careful risk analysis. History has not been kind to open internet crypto projects. iang ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
