Re: [Cryptography] prism-proof email in the degenerate case

2013-10-14 Thread Nicolas Rachinsky
* 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

2013-10-11 Thread d.nix
-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

2013-10-11 Thread Eugen Leitl
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

2013-10-11 Thread Erik de Castro Lopo
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

2013-10-11 Thread Nico Williams
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

2013-10-11 Thread Smári McCarthy
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


Re: [Cryptography] prism-proof email in the degenerate case

2013-10-11 Thread Joe St Sauver
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


Re: [Cryptography] prism-proof email in the degenerate case

2013-10-10 Thread John Kelsey
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

2013-10-10 Thread Salz, Rich
 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

2013-10-10 Thread Jerry Leichter
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

2013-10-10 Thread arxlight
-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

2013-10-10 Thread lists
 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

2013-10-10 Thread Ray Dillinger
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

2013-10-10 Thread John Kelsey
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

2013-10-10 Thread John Denker
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

2013-10-10 Thread grarpamp
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

2013-10-10 Thread Lars Luthman
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