Re: [Cryptography] prism-proof email in the degenerate case
* John Denker j...@av8n.com [2013-10-10 17:13 -0700]: *) Each server should publish a public key for /dev/null so that users can send cover traffic upstream to the server, without worrying that it might waste downstream bandwidth. This is crucial for deniabililty: If the rubber-hose guy accuses me of replying to ABC during the XYZ crisis, I can just shrug and say it was cover traffic. If the server deletes cover traffic, the nsa just needs to subscribe. Then the messages which you sent but which were not delivered via the list are cover traffic. Nicolas -- http://www.rachinsky.de/nicolas ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] prism-proof email in the degenerate case
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/10/2013 6:40 PM, grarpamp wrote: On Thu, Oct 10, 2013 at 11:58 AM, R. Hirschfeld r...@unipay.nl wrote: To send a prism-proof email, encrypt it for your recipient and send it to irrefrangi...@mail.unipay.nl. Don't include any information about To receive prism-proof email, subscribe to the irrefrangible mailing list at http://mail.unipay.nl/mailman/listinfo/irrefrangible/. Use a This is the same as NNTP, but worse in that it's not distributed. Is this not essentially alt.anonymous.messages, etc? http://ritter.vg/blog-deanonymizing_amm.html http://ritter.vg/blog-deanonymizing_amm_followup1.html ? - -- -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (MingW32) iQEcBAEBAgAGBQJSV6VAAAoJEDMbeBxcUNAekEcIAIYsHOI384C4RJfNdBcpD6NR a40C4LTQOwPJV335zUWWHjc6+6ZlUwwHimk2IQebNcEflNJn55O7k3N4CS7i4qtp A9dxDxilCrSpwwwPnsso5bfrA2/PEVfux1yzCZ4lmf39xwl/y/0PyBO7DB8CMQcA YatmYtzFAWktLYZSDuMIJPnzSKuaOnEQSiOXwCCTwgSIo3QRoNP+01JprroT168e mylxsVP2R46YIIWx6uWl+oU2oflaa3/r/nLdS2OCV99uZXmu8UlJAVNq222YwELn yhvkasfkRHtE6AhK1t5y9c4dB9cz5v2hTKNFlaRVf0PyA59ZRu8EAoZnWcJCDrM= =gsqL -END PGP SIGNATURE- ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] prism-proof email in the degenerate case
On Thu, Oct 10, 2013 at 03:54:26PM -0400, John Kelsey wrote: Having a public bulletin board of posted emails, plus a protocol for anonymously finding the ones your key can decrypt, seems like a pretty decent architecture for prism-proof email. The tricky bit of crypto is in making access to the bulletin board both efficient and private. This is what Bitmessage attempts to achieve, but it has issues. Assuming these can be solved (a rather large if), and glue like https://bitmessage.ch/ is available to be run by end users it could be quite useful. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] prism-proof email in the degenerate case
grarpamp wrote: On Thu, Oct 10, 2013 at 11:58 AM, R. Hirschfeld r...@unipay.nl wrote: To send a prism-proof email, encrypt it for your recipient and send it to irrefrangi...@mail.unipay.nl. Don't include any information about To receive prism-proof email, subscribe to the irrefrangible mailing list at http://mail.unipay.nl/mailman/listinfo/irrefrangible/. Use a This is the same as NNTP, but worse in that it's not distributed. This scheme already exists on Usenet/NNTP as alt.anonymous.messages. See the Google groups view here: https://groups.google.com/forum/#!forum/alt.anonymous.messages Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] prism-proof email in the degenerate case
On Thu, Oct 10, 2013 at 04:22:50PM -0400, Jerry Leichter wrote:
On Oct 10, 2013, at 11:58 AM, R. Hirschfeld r...@unipay.nl wrote:
Very silly but trivial to implement so I went ahead and did so:
To send a prism-proof email, encrypt it for your recipient and send it
to irrefrangi...@mail.unipay.nl
Nice! I like it.
Me too. I've been telling people that all PRISM will accomplish
regarding the bad guys is to get them to use dead drops, such as comment
posting on any of millions of blogs -- low bandwidth, undetectable. The
technique in this thread makes the use of a dead drop obvious, and adds
significantly to the recipient's work load, but in exchange brings the
bandwidth up to more usable levels.
Either way the communicating peers must pre-agree a number of things --
a traffic analysis achilles point, but it's one-time vulnerability, and
chances are people who would communicate this way already have such
meetings.
A couple of comments:
1. Obviously, this has scaling problems. The interesting question is
how to extend it while retaining the good properties. If participants
are willing to be identified to within 1/k of all the users of the
system (a set which will itself remain hidden by the system), choosing
one of k servers based on a hash of the recipient would work. (A
concerned recipient could, of course, check servers that he knows
can't possibly have his mail.) Can one do better?
Each server/list is a channel. Pre-agree on channels or use hashes. If
the latter then the hashes have to be of {sender, recipient}, else one
party has a lot of work to do, but then again, using just the sender or
just the recipient helps protect the other party against traffic
analysis. Assuming there are millions of channels then maybe
something like
H({sender, truncate(H(recipient), log2(number-of-channels-to check))})
will do just fine. And truncate(H(recipient, log2(num-channels))) can
be used for introduction purposes.
The number of servers/lists divides the total work to do to receive a
message.
2. The system provides complete security for recipients (all you can
tell about a recipient is that he can potentially receive messages -
though the design has to be careful so that a recipient doesn't, for
example, release timing information depending on whether his
decryption succeeded or not). However, the protection is more limited
for senders. A sender can hide its activity by simply sending random
messages, which of course no one will ever be able to decrypt. Of
course, that adds yet more load to the entire system.
But then the sender can't quite prove that they didn't send anything.
In a rubber hose attack this could be a problem. This also applies to
recipients: they can be observed fetching messages, and they can be
observed expending power trying to find ones addressed to them.
Also, there's no DoS protection: flooding the lists with bogus messages
is a DoS on recipients.
Nico
--
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] prism-proof email in the degenerate case
Having a public bulletin board of posted emails, plus a protocol for anonymously finding the ones your key can decrypt, seems like a pretty decent architecture for prism-proof email. The tricky bit of crypto is in making access to the bulletin board both efficient and private. --John ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] prism-proof email in the degenerate case
The simple(-minded) idea is that everybody receives everybody's email, but can only read their own. Since everybody gets everything, the metadata is uninteresting and traffic analysis is largely fruitless. Some traffic analysis is still possible based on just message originator. If I see a message from A, and then soon see messages from B and C, then I can perhaps assume they are collaborating. If I A's message is significantly larger then the other two, then perhaps they're taking some kind of vote. So while it's a neat hack, I think the claims are overstated. /r$ -- Principal Security Engineer Akamai Technology Cambridge, MA ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] prism-proof email in the degenerate case
On Oct 10, 2013, at 11:58 AM, R. Hirschfeld r...@unipay.nl wrote: Very silly but trivial to implement so I went ahead and did so: To send a prism-proof email, encrypt it for your recipient and send it to irrefrangi...@mail.unipay.nl Nice! I like it. A couple of comments: 1. Obviously, this has scaling problems. The interesting question is how to extend it while retaining the good properties. If participants are willing to be identified to within 1/k of all the users of the system (a set which will itself remain hidden by the system), choosing one of k servers based on a hash of the recipient would work. (A concerned recipient could, of course, check servers that he knows can't possibly have his mail.) Can one do better? 2. The system provides complete security for recipients (all you can tell about a recipient is that he can potentially receive messages - though the design has to be careful so that a recipient doesn't, for example, release timing information depending on whether his decryption succeeded or not). However, the protection is more limited for senders. A sender can hide its activity by simply sending random messages, which of course no one will ever be able to decrypt. Of course, that adds yet more load to the entire system. 3. Since there's no acknowledgement when a message is picked up, the number of messages in the system grows without bound. As you suggest, the service will have to throw out messages after some time - but that's a blind process which may discard a message a slow receiver hasn't had a chance to pick up while keeping one that was picked up a long time ago. One way around this, for cooperative senders: When creating a message, the sender selects a random R and appends tag Hash(R). Anyone may later send a you may delete message R message. A sender computes Hash(R), finds any message with that tag, and discards it. (It will still want to delete messages that are old, but it may be able to define old as a larger value if enough of the senders are cooperative.) Since an observer can already tell who created the message with tag H(R), it would normally be the original sender who deletes his messages. Perhaps he knows they are no longer important; or perhaps he received an application-level acknowledgement message from the recipient. -- Jerry ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] prism-proof email in the degenerate case
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Cool. Drop me a note if you want hosting (gratis) for this. On 10/10/13 10:22 PM, Jerry Leichter wrote: On Oct 10, 2013, at 11:58 AM, R. Hirschfeld r...@unipay.nl wrote: Very silly but trivial to implement so I went ahead and did so: To send a prism-proof email, encrypt it for your recipient and send it to irrefrangi...@mail.unipay.nl Nice! I like it. A couple of comments: 1. Obviously, this has scaling problems. The interesting question is how to extend it while retaining the good properties. If participants are willing to be identified to within 1/k of all the users of the system (a set which will itself remain hidden by the system), choosing one of k servers based on a hash of the recipient would work. (A concerned recipient could, of course, check servers that he knows can't possibly have his mail.) Can one do better? 2. The system provides complete security for recipients (all you can tell about a recipient is that he can potentially receive messages - though the design has to be careful so that a recipient doesn't, for example, release timing information depending on whether his decryption succeeded or not). However, the protection is more limited for senders. A sender can hide its activity by simply sending random messages, which of course no one will ever be able to decrypt. Of course, that adds yet more load to the entire system. 3. Since there's no acknowledgement when a message is picked up, the number of messages in the system grows without bound. As you suggest, the service will have to throw out messages after some time - but that's a blind process which may discard a message a slow receiver hasn't had a chance to pick up while keeping one that was picked up a long time ago. One way around this, for cooperative senders: When creating a message, the sender selects a random R and appends tag Hash(R). Anyone may later send a you may delete message R message. A sender computes Hash(R), finds any message with that tag, and discards it. (It will still want to delete messages that are old, but it may be able to define old as a larger value if enough of the senders are cooperative.) Since an observer can already tell who created the message with tag H(R), it would normally be the original sender who deletes his messages. Perhaps he knows they are no longer important; or perhaps he received an application-level acknowledgement message from the recipient. -- Jerry ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (Darwin) iQIcBAEBAgAGBQJSVxYkAAoJEAWtgNHk7T8Q+uwP/0sWLASYrvKHkVYo4yEjLLYK +s4Yfnz4sBJRUkndj6G3mhk+3lutcMiMhD2pWaTjo/FENCqMveiReI3LiA57aJ9l eaB2whG8pslm+NKirFJ//3AL6mBPJEqeH4QfrfaxNbu61T3oeU9jwihQ/1XpZUxb F1vPGN5GZyrW4GdNBWW+0bzgjoBKsyBNTe/0F/JhtKz/KD6aEQjzeNDJkgm4z6DA Euf+qYT+K3QlWWe8IMxliJcP4HacKhUPO6YUCx6mjbz34zNNa3th4eXXTzlcTWUR LWFXcDnmor3E9yMdFOdtN8+qXvauyi5HGq55Rge3fZ/TqZbNrfPh2AWqDSd/N1rW TFkx9w7b3ndfbkipK51lrdJsZcOudDgvPVnZUZBNm8H7dHi4jb4CJz+Cfr7e7Ar8 wze58qz/kYFqZ7h91e/m4TaIM+jXtPteAM2HZnAAtx3daNqcbcFd8DRtZGdOpjWt ugz2f1NUQrj8f17jUFRwIZfwi2E6wBfKTfVebQy7kMMBbN3fwvIHjyXJTHaz6o0I AX1u3bvAilFdxObwULP4PRl7ReDB42XonCf90VHSDetE/qHQy4CKiIiMrGQIlY7Y NhyAkd3dGvs57TP5gH+d39G0hkJ/iBqgaJtHcU1CwMxYABNasj2yyKPzA7Lvma62 8qzw2uTKepVPUkCjbqcy =mvZ0 -END PGP SIGNATURE- ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] prism-proof email in the degenerate case
Having a public bulletin board of posted emails, plus a protocol for anonymously finding the ones your key can decrypt, seems like a pretty decent architecture for prism-proof email. The tricky bit of crypto is in making access to the bulletin board both efficient and private. This idea has been around for a while but not built AFAIK. http://petworkshop.org/2003/slides/talks/stef/pet2003/Lucky_Green_Anonmail_PET_2003.ppt ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] prism-proof email in the degenerate case
On 10/10/2013 12:54 PM, John Kelsey wrote: Having a public bulletin board of posted emails, plus a protocol for anonymously finding the ones your key can decrypt, seems like a pretty decent architecture for prism-proof email. The tricky bit of crypto is in making access to the bulletin board both efficient and private. Wrong on both counts, I think. If you make access private, you generate metadata because nobody can get at mail other than their own. If you make access efficient, you generate metadata because you're avoiding the wasted bandwidth that would otherwise prevent the generation of metadata. Encryption is sufficient privacy, and efficiency actively works against the purpose of privacy. The only bow I'd make to efficiency is to split the message stream into channels when it gets to be more than, say, 2GB per day. At that point you would need to know both what channel your recipient listens to *and* the appropriate encryption key before you could send mail. Bear ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] prism-proof email in the degenerate case
On Oct 10, 2013, at 5:20 PM, Ray Dillinger b...@sonic.net wrote: On 10/10/2013 12:54 PM, John Kelsey wrote: Having a public bulletin board of posted emails, plus a protocol for anonymously finding the ones your key can decrypt, seems like a pretty decent architecture for prism-proof email. The tricky bit of crypto is in making access to the bulletin board both efficient and private. Wrong on both counts, I think. If you make access private, you generate metadata because nobody can get at mail other than their own. If you make access efficient, you generate metadata because you're avoiding the wasted bandwidth that would otherwise prevent the generation of metadata. Encryption is sufficient privacy, and efficiency actively works against the purpose of privacy. So the original idea was to send a copy of all the emails to everyone. What I'm wanting to figure out is if there is a way to do this more efficiently, using a public bulletin board like scheme. The goal here would be: a. Anyone in the system can add an email to the bulletin board, which I am assuming is public and cryptographically protected (using a hash chain to make it impossible for even the owner of the bulletin board to alter things once published). b. Anyone can run a protocol with the bulletin board which results in them getting only the encrypted emails addressed to them, and prevents the bulletin board operator from finding out which emails they got. This sounds like something that some clever crypto protocol could do. (It's related to the idea of searching on encrypted data.). And it would make an email system that was really resistant to tracing users. Bear --John ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] prism-proof email in the degenerate case
On 10/10/2013 02:20 PM, Ray Dillinger wrote: split the message stream into channels when it gets to be more than, say, 2GB per day. That's fine, in the case where the traffic is heavy. We should also discuss the opposite case: *) If the traffic is light, the servers should generate cover traffic. *) Each server should publish a public key for /dev/null so that users can send cover traffic upstream to the server, without worrying that it might waste downstream bandwidth. This is crucial for deniabililty: If the rubber-hose guy accuses me of replying to ABC during the XYZ crisis, I can just shrug and say it was cover traffic. Also: *) Messages should be sent in standard-sized packets, so that the message-length doesn't give away the game. *) If large messages are common, it might help to have two streams: -- the pointer stream, and -- the bulk stream. It would be necessary to do a trial-decode on every message in the pointer stream, but when that succeeds, it yields a pilot message containing the fingerprints of the packets that should be pulled out of the bulk stream. The first few bytes of the packet should be a sufficient fingerprint. This reduces the number of trial- decryptions by a factor of roughly sizeof(message) / sizeof(packet). From the keen-grasp-of-the-obvious department: *) Forward Secrecy is important here. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] prism-proof email in the degenerate case
On Thu, Oct 10, 2013 at 11:58 AM, R. Hirschfeld r...@unipay.nl wrote: To send a prism-proof email, encrypt it for your recipient and send it to irrefrangi...@mail.unipay.nl. Don't include any information about To receive prism-proof email, subscribe to the irrefrangible mailing list at http://mail.unipay.nl/mailman/listinfo/irrefrangible/. Use a This is the same as NNTP, but worse in that it's not distributed. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] prism-proof email in the degenerate case
On Thu, 2013-10-10 at 14:20 -0700, Ray Dillinger wrote: Wrong on both counts, I think. If you make access private, you generate metadata because nobody can get at mail other than their own. If you make access efficient, you generate metadata because you're avoiding the wasted bandwidth that would otherwise prevent the generation of metadata. Encryption is sufficient privacy, and efficiency actively works against the purpose of privacy. The only bow I'd make to efficiency is to split the message stream into channels when it gets to be more than, say, 2GB per day. At that point you would need to know both what channel your recipient listens to *and* the appropriate encryption key before you could send mail. This is starting to sound a lot like Bitmessage, doesn't it? A central message stream that is split into a tree of streams when it gets too busy and everyone tries to decrypt every message in their stream to see if they are the recipient. In the case of BM the stream is distributed in a P2P network, the stream of an address is found by walking the tree, and you need a hash collision proof-of-work in order for other peers to accept your sent messages. The P2P aspect and the proof-of-work (according to the whitepaper[1] it should represent 4 minutes of work on an average computer) probably makes it less attractive for mobile devices though. [1] https://bitmessage.org/bitmessage.pdf --ll signature.asc Description: This is a digitally signed message part ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] prism proof email, namespaces, and anonymity
John Kelsey crypto@gmail.com writes:
In the overwhelming majority of cases, I know and want to know the
people I'm talking with. I just don't want to contents of those
conversations or the names of people I'm talking with to be revealed
to eavesdroppers. And if I get an email from one of my regular
correspondents, I'd like to know it came from him, rather than being
spoofed from someone else.
That's a good description of stealthmail [1]. My only regret is that it
badly needs an update and I don't have time these days to work on it.
But it still works out of the box. Here's the Debian description:
Package: stealthmail
Architecture: all
Pre-Depends: gnupg
Depends: procmail, esubbf, openssl, dc, libssl0.9.6 | libssl0.9.7,
fetchmail | kmail, suck, ppp, solid-pop3d, exim | exim4, dpkg (= 1.10.21),
grep (= 2.5), bash (= 2.05b), ${shlibs:Depends}, ${misc:Depends}
Description: scripts to hide whether you're doing email, or when, or with whom
Maintain on-going random cover traffic via usenet newsgroup
alt.anonymous.messages, substituting encrypted live traffic when
available. A live message is indistinguishable from a random cover
message except with the decryption keys. All potential participants
send messages to alt.anonymous.messages with rigid periodicity
uncorrelated with any live traffic, and maintain an uninterrupted
full feed from alt.anonymous.messages, so that an observer cannot
determine whether, when, or among whom live communication is
happening.
.
Members of a stealthmail group -- call it OurGroup for purposes
of this discussion -- are defined by their knowledge of the
encryption keys created for the group. With this package installed,
mail addressed to OurGroup@stealthmail does not go directly to the
Internet like ordinary mail, but gets encrypted by the OurGroup key,
given an encrypted subject intelligible only with OurGroup keys, and
queued to go to alt.anonymous.messages in place of a piece of cover
traffic at the next scheduled sending time. Meanwhile, all messages
appearing on alt.anonymous.messages are downloaded into an incoming
queue. A POP3 server runs on the local host. The mail reader is
provided with filters so that when it fetches mail from this local
server, messages having subject lines encrypted for OurGroup (or any
other stealthmail group of which this host is a member) are decrypted
by the appropriate key and presented. Other messages are discarded.
[1] See mailto URL below.
--
-- StealthMonger stealthmon...@nym.mixmin.net
Long, random latency is part of the price of Internet anonymity.
anonget: Is this anonymous browsing, or what?
http://groups.google.ws/group/alt.privacy.anon-server/msg/073f34abb668df33?dmode=sourceoutput=gplain
stealthmail: Hide whether you're doing email, or when, or with whom.
mailto:stealthsu...@nym.mixmin.net?subject=send%20index.html
Key: mailto:stealthsu...@nym.mixmin.net?subject=send%20stealthmonger-key
pgpqkHhnE3m__.pgp
Description: PGP signature
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] prism proof email, namespaces, and anonymity
On Fri, Sep 13, 2013 at 10:12 PM, Perry E. Metzger pe...@piermont.comwrote: On Fri, 13 Sep 2013 16:55:05 -0400 John Kelsey crypto@gmail.com wrote: Everyone, The more I think about it, the more important it seems that any anonymous email like communications system *not* include people who don't want to be part of it, and have lots of defenses to prevent its anonymous communications from becoming a nightmare for its participants. If the goal is to make PRISM stop working and make the email part of the internet go dark for spies (which definitely includes a lot more than just US spies!), then this system has to be something that lots of people will want to use. There should be multiple defenses against spam and phishing and other nasty things being sent in this system, with enough designed-in flexibility to deal with changes in attacker behavior over tome. Indeed. As I said in the message I just pointed Nico at: http://www.metzdowd.com/pipermail/cryptography/2013-August/016874.html Quoting myself: Spam might be a terrible, terrible problem in such a network since it could not easily be traced to a sender and thus not easily blocked, but there's an obvious solution to that. I've been using Jabber, Facebook and other services where all or essentially all communications require a bi-directional decision to enable messages for years now, and there is virtually no spam in such systems because of it. So, require such bi-directional friending within our postulated new messaging network -- authentication is handled by the public keys of course. The keys. This to me is the critical point for widespread adoption, key management. How do you do this in a way that doesn't put people off immediately. There are two new efforts I'm aware if trying to solve this in a user friendly way are https://parley.co/#how-it-works and http://mailpile.is. Parley's approach does at least deal with the longevity of the private key although it does boil security down to a password, if I can obtain their packet and the salt I can probably brute force the password. I've exchanged mails with the mailpile.is guys and I think they're still looking at the options. Max ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] prism proof email, namespaces, and anonymity
On Fri, 13 Sep 2013 16:55:05 -0400 John Kelsey crypto@gmail.com wrote: Everyone, The more I think about it, the more important it seems that any anonymous email like communications system *not* include people who don't want to be part of it, and have lots of defenses to prevent its anonymous communications from becoming a nightmare for its participants. If the goal is to make PRISM stop working and make the email part of the internet go dark for spies (which definitely includes a lot more than just US spies!), then this system has to be something that lots of people will want to use. There should be multiple defenses against spam and phishing and other nasty things being sent in this system, with enough designed-in flexibility to deal with changes in attacker behavior over tome. Indeed. As I said in the message I just pointed Nico at: http://www.metzdowd.com/pipermail/cryptography/2013-August/016874.html Quoting myself: Spam might be a terrible, terrible problem in such a network since it could not easily be traced to a sender and thus not easily blocked, but there's an obvious solution to that. I've been using Jabber, Facebook and other services where all or essentially all communications require a bi-directional decision to enable messages for years now, and there is virtually no spam in such systems because of it. So, require such bi-directional friending within our postulated new messaging network -- authentication is handled by the public keys of course. Some thoughts off the top of my head. Note that while I think all these can be done with crypto somehow, I am not thinking of how to do them yet, except in very general terms. a. You can't freely send messages to me unless you're on my whitelist. That's my solution. As I note, it seems to work for Jabber, Facebook and other such systems, so it may be sufficient. b. This means an additional step of sending me a request to be added to your whitelist. This needs to be costly in something the sender cares about--money, processing power, reputation, solving a captcha, rate-limits to these requests, whatever. I'm not sure about that. Jabber doesn't really rate limit the number of friend requests I get per second but I don't seem to get terribly many, perhaps because fakes at most could hide some attempted phish in a user@domain name, which isn't very useful to scammers. g. The format of messages needs to be restricted to block malware, both the kind that wants to take over your machine and the kind that wants to help the attacker track you down. Plain text email only? Some richer format to allow foreign language support? My claim that I make in my three messages from August 25 is that it is probably best if we stick to existing formats so that we can re-use existing clients. My idea was that you still talk IMAP and SMTP and Jabber to a server you control (a $40 box you get at Best Buy or the like) using existing mail and chat clients, but that past your server everything runs the new protocols. In addition to the message I linked to above, see also: http://www.metzdowd.com/pipermail/cryptography/2013-August/016870.html http://www.metzdowd.com/pipermail/cryptography/2013-August/016872.html for my wider proposals. I agree this makes email delivered malware continue to be a bit of a problem, though you could only get it from your friends. Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] PRISM PROOF Email
On 08/22/2013 02:36 AM, Phillip Hallam-Baker wrote: Thanks to Snowden we now have a new term of art 'Prism-Proof', i.e. a security scheme that is proof against state interception. Having had an attack by the Iranians, I am not just worried about US interception. Chinese and Russian intercepts should also be a concern. We have two end to end security solutions yet Snowden used neither. If PGP and S/MIME are too hard to use for the likes of Snowden, they are too hard to use. The problem Snowden faced was that even if he could grok PGP, the people sending him emails probably couldn't. Observation: Silent Circle and Lavabit both ran encrypted email services. Lavabit shut down a few days ago rather than become complicit in crimes against the American People. I would say that's about as close as you can skate to We're facing a court order that we're not allowed to tell you about. Maybe even closer; we'll be forbidden to know whether anyone prosecutes them for violating the presumed gag order. Silent Circle shut down soon after, saying, We always knew the USG would come after us. Which perhaps a little less clearly indicates a court oder they can't talk about, but that's certainly one interpretation. Egypt, Oman, and India refused to allow Blackberry to operate with their end-to-end encrypted devices. In cases where Blackberry is now allowed to operate in those jurisdictions it is not at all clear that they are not doing so using compromised devices whose keys shared with those governments. Chinese military teams spent so much effort hacking at gmail and facebook accounts, in order to ferret out dissidents, that Google was eventually forced to cease doing business in China, and now gmail and facebook both have some end-to-end encrypted clients. My point I guess is that we have some evidence that Governments across the world are directly hostile to email privacy. Therefore any centralized server, CA, or company providing same may expect persecution, prosecution or subversion depending on the jurisdiction. And it can never, ever, not in a billion years, be clear to users which if any of those centralized servers or companies are trustworthy. Google now implements some end-to-end encryption for gmail but we also know that google is among those specifically mentioned as providing metadata access to the US government. The exact details of Blackberry's keys in Oman, UAE, India are now subject to largely unknown deals and settlements. Therefore, IMO, any possible solution to email privacy, if it is to be trusted at all, must be pure P2P with no centralized points of failure/control and no specialized routers etc. And it can have no built-in gateways to SMTP. Sure, someone will set one up, but there simply cannot be any dependence on SMTP or the whole thing is borked before it begins. It is time to simply walk away from that flaming wreckage and consider how to do email properly. S/Mime and PGP email-body encryption both fail to protect from traffic analysis because of underlying dependence on SMTP. Onion routing fails to protect due to timing attacks. So I say you must design your easy-to-use client completely replacing the protocol layer. No additional effort to install because this is the only protocol it handles. The traditional approach to making a system intercept proof is to eliminate the intermediaries. PGP attempts to eliminate the CA but it has the unfortunate effect on scalability. Due to the Moore bound on a minimum diameter graph, it is only possible to have large graphs with a small diameter if you have nodes of high degree. If every PGP key signer signs ten other people then we have to trust key chains of 6 steps to support even a million users and nine to support a global solution of a billion users. My solution is to combine my 'Omnibroker' proposal currently an internet draft and Ben Laurie's Certificate Transparency concept. I would start from a design in which mail is a global distributed database, with globs that can be decrypted by use of one or more of each user's set of keys, and all globs have expiry dates after which they cease to exist. Routing becomes a nonissue because routing, like old USENET, is global. Except instead of timestamp/ message ID's, we just use dates (because timestamps are too precise) and message hashes (because message IDs contain too much originating information). No certificate, no broker, no routing information unless the node that first hears about the new glob has been compromised. Each message (decrypted glob) optionally contains one or more replyable addresses (public keys). If we need more 'scalability' we could set up channels discriminated by some nine bit or so substring of the message hash, and require senders to solve hashes until they get a hash with the right nine bits to put it in the desired channel. Still no routing information as such. Now Eve can tell what channel/s a user is listening to, but the user has
Re: [Cryptography] PRISM PROOF Email
On Sun, 25 Aug 2013 10:37:52 -0700 Ray Dillinger b...@sonic.net wrote: Therefore, IMO, any possible solution to email privacy, if it is to be trusted at all, must be pure P2P with no centralized points of failure/control and no specialized routers etc. Quite agreed. I have a long message in draft that I'll hopefully be sending out later today on this topic. And it can have no built-in gateways to SMTP. Sure, someone will set one up, but there simply cannot be any dependence on SMTP or the whole thing is borked before it begins. It is time to simply walk away from that flaming wreckage and consider how to do email properly. S/Mime and PGP email-body encryption both fail to protect from traffic analysis because of underlying dependence on SMTP. That said, as I shall propose, it is not necessary to get rid of all our email infrastructure. In particular, RFC-2822 remains an entirely viable thing, and I think IMAP based clients can continue to be used, with at most small changes. Onion routing fails to protect due to timing attacks. Mix networks are not onion routing, though. If you're pure peer to peer, traffic analysis is possible. Real mix networks are now quite feasible, however, and unlike the Tor model where one is trying to make real time TCP connections secure, there is no need to be real time for IM and Email -- a delay of a couple of seconds is just fine. So I say you must design your easy-to-use client completely replacing the protocol layer. No additional effort to install because this is the only protocol it handles. I see this as a reasonable observation. As I said, I'll be explaining the rest of my proposal (of which I've put up the first two parts, which are reasonably independent) later. Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] PRISM PROOF Email
On 22 August 2013 10:36, Phillip Hallam-Baker hal...@gmail.com wrote: Preventing key substitution will require a combination of the CT ideas proposed by Ben Laurie (so catenate proof notaries etc) and some form of 'no key exists' demonstration. We have already outline how to make verifiable maps as well as verifiable logs, which I think is all you need. http://www.links.org/files/RevocationTransparency.pdf. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] PRISM PROOF Email
On Fri, Aug 23, 2013 at 6:02 PM, Philip Whitehouse phi...@whiuk.com wrote: Let me just see if I get where you're going: So essentially you've increased the number of CAs to the number of companies without really solving the PRISM problem. The sheer number mean it's impractical to do much more than a cursory check before approval. The number of CAs would not need to be very large, I would expect it to be in the hundreds in a global system but that is pretty much a function of their being hundreds of countries. If example.com wanted to run their own CA for their own email certs then the way to do it would be to issue them a cert signing cert that has name constraints to limit its use to just n...@example.com. The idea is that there are multiple CAs but their actions are all vetted for transparency and they all check up on each other. Any one CA can be served with an NSL, but if they issue a coerced certificate it will be immediately visible to the target. So a government can perform a DoS attack but not get away with an impersonation attack. PRISM for email is bad because we don't even know who we can trust. I can't trust the provider because they could have been served an NSL. The provider has to see the metadata or they can't route the email. So I'm doomed. Best case is I can secure the contents and use an alternate name. At that point I need an organization I trust to act as my Omnibroker who for some reason I don't trust with the mail itself. One other question: PPE = Prism Proof Email? Nor do I think key chain length was the problem - initial key authentication and distribution is the first issue. Philip Whitehouse Well the way that was solved in practice for PGP was Brian LaMachia's PGP Key server :-) Which turned into a node of very high degree... -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] PRISM PROOF Email
On Fri, Aug 23, 2013 at 6:42 PM, Joe St Sauver j...@oregon.uoregon.eduwrote: I wouldn't take Snowden's alleged opsec practice, or lack thereof, as a demonstration proof that PGP and/or S/MIME are impossibly difficult for technical people (or even motivated NON-technical people) to use when necessary or appropriate. Thats what the IETF folk told us when I worked on HTTP 0.9 against Gopher and FTP. Usability matters. In fact it is all that matters for adoption. Angry Birds has made a billion dollars because it is so nice to use that people will pay to use it. -- most email clients only integrate support for S/MIME; if you want to try to push anything else, your mission effectively devolves to advocating for native support for PGP in popular email clients (such as Thunderbird and Outlook), but when you do so, be prepared for pushback. Yep, I see no particular value in pushing PGP over S/MIME. Other than the fact that it has mind share. -- PRISM-proofing isn't just about encryption, since traffic analysis doesn't require full contents (and in fact, arguably, encryption ENHANCES traffic analysis in some ways, depending on how it ends up being used). Thats why message layer security is not a substitute for TLS. And the TLS should be locked to the email service via a policy statement such as DANE. #Everything has to be transparent to the #end user who is not a crypto expert and may well be a bit of a doof. You simply cannot produce doof-proof message-level crypto (I'd be surprised if there isn't already a CafePress tee shirt with this meme, in fact), any more than you can keep doofs from driving their cars into other vehicles, etc. I disagree. I think it is entirely tractable. If I understand your architecture correctly, it isn't end-to-end, is it? If it isn't end-to-end, that just means that the attack point shifts, it doesn't get eliminated. Depends on what you call the ends. The messages are encrypted email client to email client. But the trust relationships run from the CA to the Omnibroker. If you want to have full control then you would run your own omnibroker and configure it with the appropriate policy. If you are worried about foreign governments intercepting your email but not your own then a Symantec or Comodo provided Omnibroker service would be acceptable. People who trust us sufficiently to run our anti-virus are already trusting us to a far greater degree. And remember, end-to-end encryption isn't free. You may be reducing the risk of message eavesdropping, but the tradeoff may be that malicious content doesn't get scanned and blocked prior to delivery, just to mention one potential concern. (And of course, if your endpoint gets 0wn3d, your privacy expectations shouldn't be very high, right?) Which is one reason people would run their own omnibroker in certain situations (like enterprise) and encrypted mail is likely to be subject to policy controls (no executables) and only accepted from known parties with established reputations. #For spam control reasons, every email sent has to be authenticated which #means using digital signatures on the message (and likely DKIM + SSL client #auth). Auth doesn't prevent spam. Auth just enables the accumulation of reputation, which can then drive filtering decisions. Which is what most spam filtering works of these days, content filtering is not a very successful anti-spam strategy. -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] PRISM PROOF Email
On Fri, Aug 23, 2013 at 3:34 PM, Ben Laurie b...@links.org wrote: On 22 August 2013 10:36, Phillip Hallam-Baker hal...@gmail.com wrote: Preventing key substitution will require a combination of the CT ideas proposed by Ben Laurie (so catenate proof notaries etc) and some form of 'no key exists' demonstration. We have already outline how to make verifiable maps as well as verifiable logs, which I think is all you need. http://www.links.org/files/RevocationTransparency.pdf. Yeah, I think it is just a matter of being clear about the requirements and making sure that we fully justify the requirements for email rather than assume that email is the same. -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
