* 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

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

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

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

On 10/10/2013 08: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.
An alternative I've been considering is having e-mail clients support
bouncing messages if they are received for an incorrect envelope
address. So you can have an envelope address and a PGP encrypted blob,
and when you decrypt that blob there's a new RFC822 with a new envelope
address and another PGP encrypted blob. If e-mail clients honor a
forwarding agreement on this kind of message, it will be practically
impossible to tell who sent the original message and who is the final
recipient.
The really hard bit about this is that there are a lot of e-mail clients
out there, and getting them all to support this - even optionally - is
may take some doing.
--John
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

Hi,
sm...@immi.is commented:
#An alternative I've been considering is having e-mail clients support
#bouncing messages if they are received for an incorrect envelope
#address. So you can have an envelope address and a PGP encrypted blob,
#and when you decrypt that blob there's a new RFC822 with a new envelope
#address and another PGP encrypted blob. If e-mail clients honor a
#forwarding agreement on this kind of message, it will be practically
#impossible to tell who sent the original message and who is the final
#recipient.
#
#The really hard bit about this is that there are a lot of e-mail clients
#out there, and getting them all to support this - even optionally - is
#may take some doing.
-- If you're checking the envelope address, the check really should
be happening on the MTA, not the mail client, because users
typically don't get envelope addresses (the don't get the whole
MAIL FROM or EHLO thing)
This makes me think of the extensive and protracted discussions
that the email community has had around SPF/Sender-ID and DKIM.
Nice starting point: http://www.openspf.org/SPF_vs_Sender_ID
-- If you're checking the message body address, that's something
that users DO see (and think they get) but then the question
devolves to which address is the 'right' one? (see the
discussions of Purported Responsible Address in RFC4407, just to
get your toes wet)
-- Forwarding issues have dogged SPF for a long time; rewriting is
an option, but that obviously introduces new problems of its own.
(See http://www.openspf.org/SRS if interested)
-- I'll also say that I have real concerns about any protocol that
bounces unwanted/unaccepted email (rather than rejecting email at
connect time, while the remote MTA is still connected) because of
the potential for abuse (e.g., mail bounce attacks against innocent
third parties)
Anyhow, just a couple of thoughts on this,
Regards,
Joe
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

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

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

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

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

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

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

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

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

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