Re: [cryptography] [Cryptography] Email is unsecurable
Il 11/27/13, 10:01 PM, Jeffrey Walton ha scritto: The problem with DANE is the lack of DNSSEC. If we had both [...] When I refer to DANE, I also mean that DNSSEC must be there. We're getting there. Isn't the key distribution problem being pushed into DNS? The underlying problem still exists. To fix massive interception, that's passive, we do not need authenticated encryption. We just need to have a widely used and diffused opportunistic encryption with unauthenticated TLS on SMTP-to-SMTP communications. Authenticating keys with DNSSEC/DANE or TOFU, is imho a nice additional feature, but it's not required to fix the massive interception, that's passive. -- Fabio Pietrosanti (naif) HERMES - Center for Transparency and Digital Human Rights http://logioshermes.org - http://globaleaks.org - http://tor2web.org ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] Email is unsecurable
On Mon, Nov 25, 2013 at 09:51:41PM +, Stephen Farrell wrote: New work on improving hop-by-hop security for email and other things is getting underway in the IETF. [1] Basically the idea I see nothing in the proposed charter you linked to about hop-by-hop security. I could imagine something like Received headers to document how each SMTP (and SUBMIT) end-point was authenticated (if they were) along a mail transfer path. This would be of some utility, particularly for *short* paths (MUA-MSA-MTA-mailbox); for longer paths this loses its utility. Nico -- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] Email is unsecurable
On Wed, Nov 27, 2013 at 06:02:08PM +, Stephen Farrell wrote: On 11/27/2013 05:42 PM, Nico Williams wrote: On Mon, Nov 25, 2013 at 09:51:41PM +, Stephen Farrell wrote: New work on improving hop-by-hop security for email and other things is getting underway in the IETF. [1] Basically the idea I see nothing in the proposed charter you linked to about hop-by-hop security. Isn't the Using TLS part enough? At least for the applications listed. Could be worth adding a sentence to the charter though I guess. Maaayyybe. I could imagine something like Received headers to document how each SMTP (and SUBMIT) end-point was authenticated (if they were) along a mail transfer path. This would be of some utility, particularly for *short* paths (MUA-MSA-MTA-mailbox); for longer paths this loses its utility. Not sure I get the utility there, at least as in scope for this proposed WG. Do you mean the receiving MUA would display the message differently or something? Yes. You get an e-mail from me. Your edge MTA authenticated my MTA and my MTA claims to have authenticated me. Add in a signature by my MSA over the relevant headers and body and your MUA can display my e-mail as more authenticated than one that transited a non-secure link (or where the transfer path was longer). Note that there'd be a need for using DANE to authenticate MTAs acting as *clients*. There'd be no need to prove the use of DANE for authenticating MTAs acting servers: if the mail gets to its intended destination, and the transit path is the shortest possible path, then we're good to go. But it'd still be desirable to use DANE for authenticating MTAs acting servers: to prevent e-mail falling into the wrong hands. Note too that if a path is longer than the absolute shortest possible path then it's difficult to verify that there was no MITM in the path. That is, an MTA along the path could have had its DNS MX RR lookups spoofed so as to transfer my email to you via an MITM (who then gets to see it). It's not like a client can prove to a server that the client used DANE to authenticate the server, so the servers can't protect against this. The shortest path will generally be: my MUA-my MSA, my MTA - your MTA, your MTA - your mailbox. Internal MTA hops on my and/or your side are irrelevant and can be noted as such or even not recorded (assuming our respective internal networks are secure). Policy could be used to validate longer-than-shortest paths, but in practice just the shortest-path approach will suffice. There might be an idea there though if some of the hops used e.g. anon-DH and someone developed a generic witness protocol to help try spot MITM attacks on that, and if the MSA and MTAs DKIM-sign messages, then a message header field containing the inbound outbound witness-protocol PDUs that was included in the DKIM signature could be good. If there's just anon-DH it's not terribly useful except as a way to bootstrap up to using DANE. If you use DANE then you get the above property (all hops authenticated == much better than one [or more] hops not authenticated). That sounds like it'd be a bit out the scope for UTA but if that's what you meant (or similar) but I'd say a mail to apps-discuss on that would be useful. Right. But I don't think we'd want the UTA WG to be the one to develop a protocol for how to post-facto spot a MITM on anon-DH or other TLS sessions though. (Anyone got suggestions for that btw? Probably a different thread though.) Agreed. (And yes, the above would depend on DKIM public key records in the non-DNSSEC DNS, so a DANE like thing and DNSSEC would be stronger, but given that lots of large and small mail services already do DKIM and don't change their keys that often, even the non-DNSSEC thing might be good enough.) I'd prefer the hop-by-hop DANE thing for e-mail. It makes much more sense. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] Email is unsecurable
Hiya, On 11/27/2013 06:58 PM, Nico Williams wrote: I could imagine something like Received headers to document how each SMTP (and SUBMIT) end-point was authenticated (if they were) along a mail transfer path. This would be of some utility, particularly for *short* paths (MUA-MSA-MTA-mailbox); for longer paths this loses its utility. Not sure I get the utility there, at least as in scope for this proposed WG. Do you mean the receiving MUA would display the message differently or something? Yes. You get an e-mail from me. Your edge MTA authenticated my MTA and my MTA claims to have authenticated me. Add in a signature by my MSA over the relevant headers and body and your MUA can display my e-mail as more authenticated than one that transited a non-secure link (or where the transfer path was longer). I'm not sure detecting the path length in terms of ADMDs is so easy, not so useful in terms of MTAs (with all the spam checking that can go on), nor that the above is really explicable to users. We'd need to ask some mail folks. But I like the emerging scheme below a good bit more:-) Note that there'd be a need for using DANE to authenticate MTAs acting as *clients*. There'd be no need to prove the use of DANE for authenticating MTAs acting servers: if the mail gets to its intended destination, and the transit path is the shortest possible path, then we're good to go. But it'd still be desirable to use DANE for authenticating MTAs acting servers: to prevent e-mail falling into the wrong hands. Note too that if a path is longer than the absolute shortest possible path then it's difficult to verify that there was no MITM in the path. That is, an MTA along the path could have had its DNS MX RR lookups spoofed so as to transfer my email to you via an MITM (who then gets to see it). It's not like a client can prove to a server that the client used DANE to authenticate the server, so the servers can't protect against this. The shortest path will generally be: my MUA-my MSA, my MTA - your MTA, your MTA - your mailbox. Internal MTA hops on my and/or your side are irrelevant and can be noted as such or even not recorded (assuming our respective internal networks are secure). Policy could be used to validate longer-than-shortest paths, but in practice just the shortest-path approach will suffice. There might be an idea there though if some of the hops used e.g. anon-DH and someone developed a generic witness protocol to help try spot MITM attacks on that, and if the MSA and MTAs DKIM-sign messages, then a message header field containing the inbound outbound witness-protocol PDUs that was included in the DKIM signature could be good. If there's just anon-DH it's not terribly useful except as a way to bootstrap up to using DANE. If you use DANE then you get the above property (all hops authenticated == much better than one [or more] hops not authenticated). Not sure I agree with you there, esp if something could be bound to DKIM at or by the ADMD TLS endpoints. The problem with DANE is the lack of DNSSEC. If we had both I fully agree it'd be better than using anon-DH. But I figure there's a chance mail providers could do a DKIM thing in the very near future and get some benefit. Otherwise I think we're in agreement and I'll send a pointer to this sub-thread to apps-discuss so follow up can happen there. (I think you're on that list right?) Cheers, S. That sounds like it'd be a bit out the scope for UTA but if that's what you meant (or similar) but I'd say a mail to apps-discuss on that would be useful. Right. But I don't think we'd want the UTA WG to be the one to develop a protocol for how to post-facto spot a MITM on anon-DH or other TLS sessions though. (Anyone got suggestions for that btw? Probably a different thread though.) Agreed. (And yes, the above would depend on DKIM public key records in the non-DNSSEC DNS, so a DANE like thing and DNSSEC would be stronger, but given that lots of large and small mail services already do DKIM and don't change their keys that often, even the non-DNSSEC thing might be good enough.) I'd prefer the hop-by-hop DANE thing for e-mail. It makes much more sense. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] Email is unsecurable
On Wed, Nov 27, 2013 at 08:01:19PM +, Stephen Farrell wrote: On 11/27/2013 06:58 PM, Nico Williams wrote: [...] I'm not sure detecting the path length in terms of ADMDs is so easy, not so useful in terms of MTAs (with all the spam checking Sure it is! Nowadays the path should generally be: sender's MUA- sender's MSA sender's MSA- sender's MTA (this is generally internal, and anyways it can be marked as such) sender's MTA- recipient's MTA recipient's MTA - recipient's mailbox Internal-to-sender/recipient's-infra hops are irrelevant/uninteresting. Now, a recipient might use a third-party MX, but the recipient's MUA can check that the MX RRs for the recipient's domain match the unexpected path element. (MX RRs can change, which can cause the path validation results for an e-mail with non-shortest path to change over time.) that can go on), nor that the above is really explicable to users. We'd need to ask some mail folks. No need to explain to users. The MUA either validates the path and marks the mail as verified to be from the sender, or... not. It's a boolean. Users can be expected to understand a boolean. Of course, it doesn't help the user that a phisher is authenticated; phishers and spammers would be the first to implement this, as with DKIM. But the MUA can also AND the sender's presence in the recipient's address book to the expression producing that boolean result. But I like the emerging scheme below a good bit more:-) :) The problem with DANE is the lack of DNSSEC. If we had both [...] When I refer to DANE, I also mean that DNSSEC must be there. We're getting there. Otherwise I think we're in agreement and I'll send a pointer to this sub-thread to apps-discuss so follow up can happen there. (I think you're on that list right?) I am. Thanks for sending this there. Nico -- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] Email is unsecurable
On Wed, Nov 27, 2013 at 3:34 PM, Nico Williams n...@cryptonector.com wrote: On Wed, Nov 27, 2013 at 08:01:19PM +, Stephen Farrell wrote: On 11/27/2013 06:58 PM, Nico Williams wrote: [...] The problem with DANE is the lack of DNSSEC. If we had both [...] When I refer to DANE, I also mean that DNSSEC must be there. We're getting there. Isn't the key distribution problem being pushed into DNS? The underlying problem still exists. Perhpas we could have higher confidence in DNS if it was not controlled by the US. A diversification strategy won't work when 10 or so of the 13 servers are required to give bad answers. That is, cross checking A (Verisign) with, for example, E, F, G, and H (ISC, GOV and DoD) won't validate anything. And getting an authentic answer from a non-US controlled server is another problem altogether. Jeff ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] Email is unsecurable
On 11/27/2013 09:01 PM, Jeffrey Walton wrote: Isn't the key distribution problem being pushed into DNS? The underlying problem still exists. Depends. If say someone ended up sampling the mail header field values seen over a lot of messages then exceptions to key continuity for mail service providers would perhaps be enough to flag potential MITM attacks on the TLS sessions, or odd MTAs popping up from nowhere, which are at least some of the goals here. So DKIM-level security could actually be quite useful in this case I reckon. S. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] Email is unsecurable
So, Convergence/Perspectives done on email headers? - Sent from my phone Den 27 nov 2013 22:07 skrev Stephen Farrell stephen.farr...@cs.tcd.ie: On 11/27/2013 09:01 PM, Jeffrey Walton wrote: Isn't the key distribution problem being pushed into DNS? The underlying problem still exists. Depends. If say someone ended up sampling the mail header field values seen over a lot of messages then exceptions to key continuity for mail service providers would perhaps be enough to flag potential MITM attacks on the TLS sessions, or odd MTAs popping up from nowhere, which are at least some of the goals here. So DKIM-level security could actually be quite useful in this case I reckon. S. ___ 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] [Cryptography] Email is unsecurable
Viktor Dukhovni says that anything like DKIM/SPF is bound to fail. One problem is confusables: users can't really distinguish them, and some can be counted on just doing whatever it takes to give their money to the phisher, no matter what. In other words, the problem with e-mail is that strangers can start conversations with you. (Whereas with web services you start the conversations with them, which is not as big a problem.) Nico -- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] Email is unsecurable
On 11/27/2013 09:29 PM, Nico Williams wrote: Viktor Dukhovni says that anything like DKIM/SPF is bound to fail. One problem is confusables: users can't really distinguish them, and some can be counted on just doing whatever it takes to give their money to the phisher, no matter what. In other words, the problem with e-mail is that strangers can start conversations with you. (Whereas with web services you start the conversations with them, which is not as big a problem.) I'm not talking about MUAs at all here though. On 11/27/2013 09:24 PM, Natanael wrote: So, Convergence/Perspectives done on email headers? Almost. (I'm sure we could throw in a twist of CT too to keep Ben happy:-) But not with the goal of verifying web server public keys. In this case we want to verify that the same TLS master secret got used on each side of each TLS hop, even for anon-DH. But I think is interesting to do that even at the level where all we can detect a pervasive attack, either due to different TLS master secrets where they should be the same or else because of additional unexpected or untraceable hops. (Maybe more is achievable but that's the attack I'm thinking of right now.) Mind you, even if it'd be ok crypto-wise, I'd not be surprised if it falls down for some mail reason. S. ___ 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 stephen.farr...@cs.tcd.ie 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
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 stephen.farr...@cs.tcd.ie 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
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 r...@isolved.it: 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 stephen.farr...@cs.tcd.ie 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] [Cryptography] Email is unsecurable
Say hello to Bote mail on I2P. I2P provides encrypted anonymizing networking, Bote mail provides DHT based serverless encrypted mailing with public crypto keys as addresses (ECDSA or NTRU). http://i2p2.de and i2pbote.i2p (if you don't have I2P installed, add .us to visit it via an inproxy). There is also I2P Messenger that is encrypted P2P IM within I2P also using public keys as addresses. - Sent from my phone Den 25 nov 2013 19:15 skrev grarpamp grarp...@gmail.com: On Mon, Nov 25, 2013 at 1:01 AM, ianG i...@iang.org wrote: On 23/11/13 15:30 PM, Ralf Senderek wrote: On Sat, 23 Nov 2013, David Mercer wrote: But of course you're right about actual current usage, encrypted email is an epic fail on that measure regardless of format/protocol. Yes, but it's about time we do something about that. Do we *exactly know why* it is such a failure? It's an interesting question, and one worth studying for pedagogical motives. From my experiences from both sides, it is clear that both sides failed. But for different reasons. Hence, I've concluded that email is unsecurable. Obviously. It will never be able to escape the non-body header content and third party routing, storage and analysis with any form of patching over today's mail. And it's completely ridiculous that people continue to invest [aka: waste] effort in 'securing' it. The best you'll ever get clients down to is exposing a single 'To:' header within an antique transport model that forces you to authenticate to it in order to despam, bill, censor and control you. That system is cooked, done and properly fucked. Abandon it. What the world needs now is a real peer to peer messaging system that scales. Take Tor for a partial example... so long as all the sender/recipient nodes [onions] are up, any message you send will get through, encrypted, in real time. If a recipient is not up, you queue it locally till they are... no third party ever needed, and you get lossless delivery and confirmation for free. Unmemorable node address?, quit crying and make use of your local address book. Doesn't have plugins for current clients?, so what, write some and use it if you're dumb enough to mix the old and new mail. The only real problem that still needs solved is scalability... what p2p node lookup systems are out there that will handle a messaging world's population worth of nodes [billions] and their keys and tertiary data? If you can do that, you should be able to get some anon transport over the p2p for free. Anyway, p2p messaging and anonymous transports have all been dreamed up by others before. But now is the time to actually abandon traditional email and just do it. If you build it, they will come. ___ 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] [Cryptography] Email is unsecurable
On Mon, Nov 25, 2013 at 1:01 AM, ianG i...@iang.org wrote: On 23/11/13 15:30 PM, Ralf Senderek wrote: On Sat, 23 Nov 2013, David Mercer wrote: But of course you're right about actual current usage, encrypted email is an epic fail on that measure regardless of format/protocol. Yes, but it's about time we do something about that. Do we *exactly know why* it is such a failure? It's an interesting question, and one worth studying for pedagogical motives. From my experiences from both sides, it is clear that both sides failed. But for different reasons. Hence, I've concluded that email is unsecurable. Obviously. It will never be able to escape the non-body header content and third party routing, storage and analysis with any form of patching over today's mail. And it's completely ridiculous that people continue to invest [aka: waste] effort in 'securing' it. The best you'll ever get clients down to is exposing a single 'To:' header within an antique transport model that forces you to authenticate to it in order to despam, bill, censor and control you. That system is cooked, done and properly fucked. Abandon it. What the world needs now is a real peer to peer messaging system that scales. Take Tor for a partial example... so long as all the sender/recipient nodes [onions] are up, any message you send will get through, encrypted, in real time. If a recipient is not up, you queue it locally till they are... no third party ever needed, and you get lossless delivery and confirmation for free. Unmemorable node address?, quit crying and make use of your local address book. Doesn't have plugins for current clients?, so what, write some and use it if you're dumb enough to mix the old and new mail. The only real problem that still needs solved is scalability... what p2p node lookup systems are out there that will handle a messaging world's population worth of nodes [billions] and their keys and tertiary data? If you can do that, you should be able to get some anon transport over the p2p for free. Anyway, p2p messaging and anonymous transports have all been dreamed up by others before. But now is the time to actually abandon traditional email and just do it. If you build it, they will come. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] Email is unsecurable
I'm strongly against most the ideas to abbandon current email systems, because the results will be to create wallet garden. We need something interoperable with existing systems or the system will just be used by a bunch of paranoid people or fostered by the marketing of few cryptography company acquiring customers, not user. So we need IETF standards, interoperable with existing email standard protocols (SMTP, IMAP, MIME). I'm just very disappointed that many of us look at the moon, trying to invent something new, when there are so many improvements to be done on existing interoperable platforms. 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. Fabio Il 11/25/13, 7:20 PM, Natanael ha scritto: Say hello to Bote mail on I2P. I2P provides encrypted anonymizing networking, Bote mail provides DHT based serverless encrypted mailing with public crypto keys as addresses (ECDSA or NTRU). http://i2p2.de and i2pbote.i2p (if you don't have I2P installed, add .us to visit it via an inproxy). There is also I2P Messenger that is encrypted P2P IM within I2P also using public keys as addresses. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] Email is unsecurable
And there's your problem - you can at best only add gateways/proxies, you can't actually improve the existing protocols in any meaningful way. - Sent from my phone Den 25 nov 2013 21:09 skrev Fabio Pietrosanti (naif) li...@infosecurity.ch: I'm strongly against most the ideas to abbandon current email systems, because the results will be to create wallet garden. We need something interoperable with existing systems or the system will just be used by a bunch of paranoid people or fostered by the marketing of few cryptography company acquiring customers, not user. So we need IETF standards, interoperable with existing email standard protocols (SMTP, IMAP, MIME). I'm just very disappointed that many of us look at the moon, trying to invent something new, when there are so many improvements to be done on existing interoperable platforms. 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. Fabio Il 11/25/13, 7:20 PM, Natanael ha scritto: Say hello to Bote mail on I2P. I2P provides encrypted anonymizing networking, Bote mail provides DHT based serverless encrypted mailing with public crypto keys as addresses (ECDSA or NTRU). http://i2p2.de and i2pbote.i2p (if you don't have I2P installed, add .us to visit it via an inproxy). There is also I2P Messenger that is encrypted P2P IM within I2P also using public keys as addresses. ___ 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] [Cryptography] Email is unsecurable
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. That does address the short-term/quick-win stuff that we can get for foo-over-TLS protocols like SMTP, IMAP etc., but doesn't address end-to-end mail security, for lots of the reasons already stated in this thread. So if you think there's value in that short-term work too, then I'm sure more help and expertise will be welcomed. 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. Cheers, S. [1] http://www.ietf.org/mail-archive/web/ietf-announce/current/msg12140.html ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] Email is unsecurable
On Mon, Nov 25, 2013 at 1:51 PM, Stephen Farrell stephen.farr...@cs.tcd.ie 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... ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
