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
