Re: [cryptography] Potential funding for crypto-related projects

2013-07-04 Thread danimoth
On 30/06/13 at 01:04am, Jacob Appelbaum wrote:
 Yeah, about that...
 
 Have you seen the most recent paper by Egger et al?


IMHO that's is unfair. There are many publications on Tor
vulnerabilities as well, and this is unavoidable.
Are you sure that in the next two months Tor will not be the main actor
of a similar publication?

You should have pointed us over principles and design, rather than
vulnerabilities.

By principles, I like i2p more than tor, for its decentralization, and
for its focus on providing an anonymous network layer than a exit
point to existing internet. But this is completely personal, and each
of us as his/her requirements to satisfy. And, by the way, I am aware
that the most important bug (which can't be corrected) of any systems is 
the human who is using it.

With respect,

   danimoth
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography


Re: [cryptography] Potential funding for crypto-related projects

2013-07-04 Thread Michael Rogers
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 04/07/13 13:34, danimoth wrote:
 IMHO that's is unfair. There are many publications on Tor 
 vulnerabilities as well, and this is unavoidable. Are you sure that
 in the next two months Tor will not be the main actor of a similar
 publication?
 
 You should have pointed us over principles and design, rather than 
 vulnerabilities.
 
 By principles, I like i2p more than tor, for its decentralization,
 and for its focus on providing an anonymous network layer than a
 exit point to existing internet. But this is completely personal,
 and each of us as his/her requirements to satisfy.

I think the point is that i2p's decision to use a decentralised
directory service led to the vulnerabilities described in the paper.
You can't separate principles from their practical effects. I agree
with you that i2p's principles are great, but that shouldn't stop us
from discussing their practical effects (including the bad ones).

I don't like the idea that respect == not talking about problems. How
are problems with i2p and Tor supposed to get fixed if we don't
discuss them?

As for personal choice - yes, it's a matter of personal choice whether
you prefer i2p's goals or Tor's goals. But whether those systems
achieve their goals is not a matter of personal choice - it's a matter
of objective fact that should be settled by examining the evidence.

Cheers,
Michael

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJR1ZS7AAoJEBEET9GfxSfM8uMH/2YtCTowxckwougMGb+9Sx4+
b0hgxBUGSwoowIACGCr5uFbKEWUTCK53q0h24qdbUejdjaiehiZh0MzaoL/HWIq3
T3993RRvDV8bDXdEJ6oOh9zwZLS2Y7IeOvJLipJjBrR0P9kkoXP0d9KHUxAARZE9
6zIhp+Dr6NHoqUL7u1mM8s9JmJ/4z2Mbb6q7Rtx1e3uZG23prxkOd1V/9OwOBgly
Df3f1En6kuAs1nHD0fmP+OrNEMVR+edoQdOdSNVtkhjrtZEe1kT1ycZBT4dTof0Y
WdInJPXu0vGDRcwxQxnm+I77iQA+CeQi2NmreBo7BGeZLRecLt3d0BKDrE3UaFo=
=tPPD
-END PGP SIGNATURE-
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography


Re: [cryptography] Potential funding for crypto-related projects

2013-07-04 Thread John Young

The more fiercely defended security system (anything)
the more likely indefensible. Best ones require constant
patching and understatement, without exculpation, apologia
and bullying arrogance of ignorance.

But cloying humility, obsequiousness and masochism
seduces sadists for backdooring STD.

IMHO, IYCFFT.


At 08:34 AM 7/4/2013, you wrote:

On 30/06/13 at 01:04am, Jacob Appelbaum wrote:
 Yeah, about that...

 Have you seen the most recent paper by Egger et al?


IMHO that's is unfair. There are many publications on Tor
vulnerabilities as well, and this is unavoidable.
Are you sure that in the next two months Tor will not be the main actor
of a similar publication?

You should have pointed us over principles and design, rather than
vulnerabilities.

By principles, I like i2p more than tor, for its decentralization, and
for its focus on providing an anonymous network layer than a exit
point to existing internet. But this is completely personal, and each
of us as his/her requirements to satisfy. And, by the way, I am aware
that the most important bug (which can't be corrected) of any systems is
the human who is using it.

With respect,

   danimoth
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography



___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography


Re: [cryptography] Potential funding for crypto-related projects

2013-07-04 Thread danimoth
On 04/07/13 at 04:28pm, Michael Rogers wrote:
 I think the point is that i2p's decision to use a decentralised
 directory service led to the vulnerabilities described in the paper.

Uhm, I don't consider it a matter of centralization vs decentralization.
I think the point is how I2P select peers to communicate with; attacker
DoS'd previous high-performance peers, then replace them with nodes
under its control, and then do measurements to estimate the victim
identity. In the section 5 authors confirm that Tor shares with I2P
a number of vulnerabilities (for example, repeated measurements could be made
on hidden services). I consider myself a bit stupid, so I could be wrong.

 You can't separate principles from their practical effects. I agree
 with you that i2p's principles are great, but that shouldn't stop us
 from discussing their practical effects (including the bad ones).
 I don't like the idea that respect == not talking about problems. How
 are problems with i2p and Tor supposed to get fixed if we don't
 discuss them?
 
 As for personal choice - yes, it's a matter of personal choice whether
 you prefer i2p's goals or Tor's goals. But whether those systems
 achieve their goals is not a matter of personal choice - it's a matter
 of objective fact that should be settled by examining the evidence.


I completely agree with you, I only disliked the I2P is flawed, don't
use it but instead use Tor which is safe tone used, as we all know that
no existing methods or systems are bug-free.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography


Re: [cryptography] Potential funding for crypto-related projects

2013-07-04 Thread Michael Rogers
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 04/07/13 17:15, danimoth wrote:
 Uhm, I don't consider it a matter of centralization vs
 decentralization. I think the point is how I2P select peers to
 communicate with; attacker DoS'd previous high-performance peers,
 then replace them with nodes under its control, and then do
 measurements to estimate the victim identity. In the section 5
 authors confirm that Tor shares with I2P a number of
 vulnerabilities (for example, repeated measurements could be made 
 on hidden services). I consider myself a bit stupid, so I could be
 wrong.

As far as I can see, the attacks work by seizing control of the netDB,
which is i2p's decentralised directory service.

We first show how an attacker can tamper with the group of nodes
providing the netDB, until he controls most of these nodes.

To mount a similar attack against Tor, the attacker would have to
compromise the directory authorities that sign the network consensus.
As far as we know that hasn't been done, so i2p's decision to use a
decentralised netDB instead of centralised directory authorities has
the practical effect of making these attacks possible.

I don't see any reference to Tor in section 5 of the paper - perhaps
we're looking at different versions?

 I completely agree with you, I only disliked the I2P is flawed,
 don't use it but instead use Tor which is safe tone used, as we
 all know that no existing methods or systems are bug-free.

I agree that we should always keep in mind that there are
vulnerabilities we don't know about. However, we still have to make
day-to-day decisions about which systems to use based on the
vulnerabilities we do know about.

Cheers,
Michael

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJR1aZqAAoJEBEET9GfxSfM9ZkH/j6WnVh5gWyLI7ILi78dMFmj
tU08GelNbIUblsi4YauJ8vdrRf2Z2go7fAnYxcObWl9zwN0/OdyVj+HOzi9nzn+g
nZnL6C+2ZXw7QjqyiarrgYeiYH2AF9Ff5Ndk0AQ5w9EQb/ApXQWIczY62CkLdgEn
viSSJoUjXTONPE3fRkE8S7fA21BFLo3tkyJKCjJ4A0Xxvj4VQexK4NYLeyhgr1NY
7RqJgtkYqnPDkjC/Rs//PQwooAmjnRRgXxyB8/rn0xlwizNc+Fgur0/j5clXIYqL
SXlCwSrNxUwWFtIa/g+Nf1B6BOJL8fQDsE+h/l6UTfbSJOXpewbVdos4Qco7ZNE=
=QELT
-END PGP SIGNATURE-
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography


Re: [cryptography] Potential funding for crypto-related projects

2013-07-03 Thread Michael Rogers
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03/07/13 13:26, danimoth wrote:
 Not directly related to remailer, but what about dc nets [1] ?
 
 [1] The Dining Cryptographers Problem:
 Unconditional Sender and Recipient Untraceability (David Chaum)

DC nets have two major drawbacks: they don't scale, and any participant
can anonymously jam the channel. Dissent is a recent system that aims to
address both drawbacks:
https://www.usenix.org/conference/osdi12/strong-scalable-anonymity-safetynet

Cheers,
Michael

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJR1BmZAAoJEBEET9GfxSfMwvgIAKimVf4ggHuvE0vYLeB4f2gH
sUFiZSF+pMY1VCQ8+h32emd4zZoPYOA069y/QAuBbdW1ChJCBcOPsn0trbnZGivW
gmJyOd5llb42gDWEMe++G4tYPRvJZ8K7txyrkEqw/W8s/QRxVUOI35258tDitOKB
I+NEK53Z0qTOpxhWRyCUgszqXn2zGeGs5h9LY1wbaSCFHpxUqQvKjZDOF49ecjjv
M76eoCJ0OAP1b90vTc+TuPvBpxo+hTN5WcMVnBddTpe35Zt5sUIrrLlpSuHjVH8E
JuTZwFl278ijaflBhKHtTRweBj1D3/jLXaURWuRY8MW818Q3DebUn78AX4Mu8I8=
=0jEp
-END PGP SIGNATURE-
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography


Re: [cryptography] Potential funding for crypto-related projects

2013-07-03 Thread danimoth
On 30/06/13 at 07:32pm, Jacob Appelbaum wrote:
  I'd love to see a revitalisation of remailer research, focussing on
  unlinkability (which we know many people would benefit from) rather
  than sender anonymity (which fewer people need, and which is prone to
  abuse that discourages people from running mixes).
  
 
 I'd also like to see revitalisation of remailer research. Though
 anonymity as Tor is designed is specifically about unlinkability. To
 reduce it to sender anonymity is pretty ... ridiculous. What one does
 with an anonymous communications channel is up to them - many people do
 actually want that feature for chatting, web browsing, news, email, etc.


Not directly related to remailer, but what about dc nets [1] ?

[1] The Dining Cryptographers Problem:
Unconditional Sender and Recipient Untraceability (David Chaum)
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography


Re: [cryptography] Potential funding for crypto-related projects

2013-07-03 Thread Wasabee

On 03/07/2013 13:31, Michael Rogers wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03/07/13 13:26, danimoth wrote:

Not directly related to remailer, but what about dc nets [1] ?

[1] The Dining Cryptographers Problem:
 Unconditional Sender and Recipient Untraceability (David Chaum)

DC nets have two major drawbacks: they don't scale, and any participant
can anonymously jam the channel. Dissent is a recent system that aims to
address both drawbacks:
https://www.usenix.org/conference/osdi12/strong-scalable-anonymity-safetynet


is it really feasible to get good latency/bandwith with such system? it 
seems users need to transmit packets at the same time; so it seems the 
latency and bandwidth is a bottleneck because everyone must wait for the 
users with highest latency and lowest bandwidth? Or is there a 
scheduling mechanism involved (which would eat up usable bandwidth)?


Also, how much trust is put on servers compared to Tor? At first sight, 
it seems that the compromise of one server will compromise all clients 
connected to this server since servers knows all their shared secret.


m no expert so any explanation is very welcome!
And forgive if my questions are too basic :)



Cheers,
Michael

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJR1BmZAAoJEBEET9GfxSfMwvgIAKimVf4ggHuvE0vYLeB4f2gH
sUFiZSF+pMY1VCQ8+h32emd4zZoPYOA069y/QAuBbdW1ChJCBcOPsn0trbnZGivW
gmJyOd5llb42gDWEMe++G4tYPRvJZ8K7txyrkEqw/W8s/QRxVUOI35258tDitOKB
I+NEK53Z0qTOpxhWRyCUgszqXn2zGeGs5h9LY1wbaSCFHpxUqQvKjZDOF49ecjjv
M76eoCJ0OAP1b90vTc+TuPvBpxo+hTN5WcMVnBddTpe35Zt5sUIrrLlpSuHjVH8E
JuTZwFl278ijaflBhKHtTRweBj1D3/jLXaURWuRY8MW818Q3DebUn78AX4Mu8I8=
=0jEp
-END PGP SIGNATURE-
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography


___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography


Re: [cryptography] Potential funding for crypto-related projects

2013-07-03 Thread Michael Rogers
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Wasabee,

I'm no expert either but I'll try to answer to the best of my
understanding. I'm CCing Henry Corrigan-Gibbs, one of the Dissent
designers, who will hopefully correct my mistakes. :-)

On 03/07/13 17:11, Wasabee wrote:
 is it really feasible to get good latency/bandwith with such
 system? it seems users need to transmit packets at the same time;
 so it seems the latency and bandwidth is a bottleneck because
 everyone must wait for the users with highest latency and lowest
 bandwidth? Or is there a scheduling mechanism involved (which would
 eat up usable bandwidth)?

Dissent has a scheduling mechanism that allows the members of each
DC-net to transmit different amounts of data in each round. I assume
each member must send and receive as many bits as all the members want
to transmit in total, plus the scheduling overhead, but that could
still be a big efficiency gain compared with each member having a
fixed-length transmission slot.

 Also, how much trust is put on servers compared to Tor? At first
 sight, it seems that the compromise of one server will compromise
 all clients connected to this server since servers knows all their
 shared secret.

Every client shares a secret with every server, and a client's
anonymity is only broken if all the servers collude. So there only
needs to be one honest server, and the client doesn't need to know
which one it is.

It would be interesting to imagine a network where the servers were
run by mutually distrusting parties, and every client was satisfied
that there was at least one trustworthy server, but different clients
trusted different servers. Then clients would be able to communicate
anonymously with each other even if they couldn't agree on any server
they could all trust.

Cheers,
Michael
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJR1HZ0AAoJEBEET9GfxSfMxvAIALjs5bIPKwL9uHA+v0ttnVl/
PRMF7+8JnvLZq7QzgdgflnboW4qydYyIO3e7sbJflMJgQuEhlmTt1HASPEIh9CM0
/iu9c5ePw9DKxyl2hnZ7avnzZLl/nVH1QQcrvo3sVL/JYpkYlLdAq8BGQlrVkpMW
X1tLxuIXKvtFljF4iG+c6pBZ/jqjs3CdssZQf4AFfF7OKclyR0bS6rScDY+nKU+m
LKLaMuwn1CKSoDgsNG1+mdRhE3pr6dpUBixfy+6J55xh/e1lN3KZMVD12aeYNodE
JTbngl78mfacZYIqXs9d2692THf3QyycK+mmuIiiRq/mBe0WtCSStEOPBtlMPgk=
=RUVT
-END PGP SIGNATURE-
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography


Re: [cryptography] Potential funding for crypto-related projects

2013-07-03 Thread James A. Donald

On 2013-07-04 2:11 AM, Wasabee wrote:

On 03/07/2013 13:31, Michael Rogers wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03/07/13 13:26, danimoth wrote:

Not directly related to remailer, but what about dc nets [1] ?

[1] The Dining Cryptographers Problem:
 Unconditional Sender and Recipient Untraceability (David Chaum)

DC nets have two major drawbacks: they don't scale, and any participant
can anonymously jam the channel. Dissent is a recent system that aims to
address both drawbacks:
https://www.usenix.org/conference/osdi12/strong-scalable-anonymity-safetynet 



is it really feasible to get good latency/bandwith with such system? 
it seems users need to transmit packets at the same time; so it seems 
the latency and bandwidth is a bottleneck because everyone must wait 
for the users with highest latency and lowest bandwidth? Or is there a 
scheduling mechanism involved (which would eat up usable bandwidth)?


Also, how much trust is put on servers compared to Tor? At first 
sight, it seems that the compromise of one server will compromise all 
clients connected to this server since servers knows all their shared 
secret.


It suffices that one server is not controlled by your adversary, even if 
all the others are NSA plants, even if the server you are using is an 
NSA plant.


However, a single evil server can jam the channel, so have to identify 
and throw out actively disruptive servers.


Effectively, the servers form a DC net, and client anonymity is layered 
on top of that.

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography


Re: [cryptography] Potential funding for crypto-related projects

2013-07-02 Thread aortega
 The more interesting point is high vs low latency. I really like the
 idea of having a high-latency option in Tor. It would still need to
 have a lot of users to actually be useful, though. But it seems there
 are various protocols that would be ore high-latency-friendly than
 HTTP - SMTP, of course, and XMPP spring to mind.

 I think if Tor had an arbitrary queue with store and forward as a high
 latency module of sorts, we'd really be onto something. Then there would
 be tons of traffic on the Tor relays for all kinds of reasons - high and
 low latency - only to all be wrapped in TLS and then in the Tor protocol.

I was looking for something like this. It would be incompatible with
anything that uses TCP, but better that way. I have always found weird
that there is no a UDP-like transport in tor.

IMHO only the TCP initial hand-shake gives your attacker enough info to
leak your position easily (just a tought, never did any sort of serious
tests on this) but UDP would be immune to it, even more if it's
implemented using high-latency queues. Probably most existing UDP services
should work unmodified.

Best regards,

Alfred

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography


Re: [cryptography] Potential funding for crypto-related projects

2013-07-02 Thread aortega
 Given those shortcomings I think is not wise to recommend it unless your
 enemy doesn't have the resources of a country. That being said, it's the
 best tool at the moment, lights year ahead of other popular software
 like
 Cryptocat, whose end-point security should be considered not only
 sub-par
 but dangerous. (who in their right mind will consider browser crypto?)

 It's definitely a new field that needs a lot of work. I invite you to
 read:

 The paper describing the improvements we're making for browser crypto:
 http://arxiv.org/abs/1306.5156

 My blog post on the improving state of browser crypto implementation:
 http://log.nadim.cc/?p=33

 NK

Hi! nice to see that improvements are coming. I was reacting to some
papers reporting about Cryptocat being used to defeat evil governments,
etc.  IMHO if the FBI can beat TOR, surely they can beat Cryptocat as
well.

But I don't blame you. I don't think any real-time chat can ever be made
safe and by safe I mean anonymous, because of its low-latency nature.
You can have privacy by using OTR and that's good in many situations, but
won't protect you from somebody with enough money to hire techs and put
some taps.

And then your users get killed or thrown into prison and then can't report
any bug. Crypto dev is like that :)

Best regards,

Alfred

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography


Re: [cryptography] Potential funding for crypto-related projects

2013-07-02 Thread ianG

On 2/07/13 11:17 AM, aort...@alu.itba.edu.ar wrote:


But I don't blame you. I don't think any real-time chat can ever be made
safe and by safe I mean anonymous, because of its low-latency nature.



On a tangent, I have often wanted high-latency chat because high-speed 
chat is so damn disruptive at work.




You can have privacy by using OTR and that's good in many situations, but
won't protect you from somebody with enough money to hire techs and put
some taps.



The threat is always on the node, never on the wire...



And then your users get killed or thrown into prison and then can't report
any bug. Crypto dev is like that :)



Makes hell with ones OODA loops :)


iang
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography


Re: [cryptography] Potential funding for crypto-related projects

2013-07-02 Thread Michael Rogers
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 30/06/13 20:32, Jacob Appelbaum wrote:
 Michael Rogers:
 I'd love to see a revitalisation of remailer research, focussing
 on unlinkability (which we know many people would benefit from)
 rather than sender anonymity (which fewer people need, and which
 is prone to abuse that discourages people from running mixes).
 
 I'd also like to see revitalisation of remailer research. Though 
 anonymity as Tor is designed is specifically about unlinkability.
 To reduce it to sender anonymity is pretty ... ridiculous. What one
 does with an anonymous communications channel is up to them - many
 people do actually want that feature for chatting, web browsing,
 news, email, etc.

I'm not sure if I understand you right, but it sounds like you think I
was saying that Tor is only designed for sender anonymity, and that
sender anonymity isn't useful in general. I wasn't saying either of
those things.

My point was much smaller in scope: remailers have tried to provide
sender anonymity for email, but in the current climate that's useful
to fewer people than unlinkability for email, which a remailer-like
system could provide more easily than sender anonymity.

By all means let's build that remailer-like system on top of Tor, if
it can be done in such a way that the low-latency and high-latency
traffic share anonymity sets.

If on the other hand it's effectively two different networks sharing
an implementation then it might make sense to build a separate system.

Cheers,
Michael

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJR0sYGAAoJEBEET9GfxSfMVDEIALPCMHLloyB76MSSonEPyLOU
4Nc/mMDD5w4uYxfMh5ynfQb7b1KqRcYZjK+AMJudj/1CRrHdVbKSKm2sxiJleFSu
w6/CQ05T10jrsEFkALPgMF8mMERGIRc0S1HXPGpZgNW1PrjGdsTpVYa+z83/VBg2
50deiWPfSY1EctAavun2Zzble/VMwQOjJcu+ElOE6d9zyQIDe5SmsMhryf2775eV
ySU0fQALd3NP+o5Vsw9WlHc5JjHtopYFXvwEGvnrssggyepVTTN8ovKBsEIgtQ7Z
FmPzs2v2XZD+L75M8L15d3MtnGahxnlnscScOXHCsZtLwO/5rLc7nhwzaUQam5k=
=XGbu
-END PGP SIGNATURE-
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography


Re: [cryptography] Potential funding for crypto-related projects

2013-07-02 Thread Fabio Pietrosanti (naif)

Il 7/1/13 1:32 PM, Tom Ritter ha scritto:

I'm not saying GlobaLeaks+Tor is safe.  I'm saying I think our current
remailer network is wildly unsafe.  (Now what I think about fixing
it... that's a whole other story, for a whole other time.)


While it's outside the scope of GlobaLeaks to provide a wide and 
complete solution to those kind of problems, in our pipelines there are 
a set of features that will provide some help in making certain time 
correlations attacks slightly more difficult.


Prevent Time Correlation Attack on Notification
https://github.com/globaleaks/GlobaLeaks/issues/264

Widget to create Cover Traffic to Tor2web sites exposing GlobaLeaks
https://github.com/globaleaks/GlobaLeaks/issues/263

PGP Encryption of Email Notification
https://github.com/globaleaks/GlobaLeaks/issues/187


--
Fabio Pietrosanti (naif)
HERMES - Center for Transparency and Digital Human Rights
http://logioshermes.org - http://globaleaks.org - http://tor2web.org

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography


Re: [cryptography] Potential funding for crypto-related projects

2013-07-02 Thread Jacob Appelbaum
aort...@alu.itba.edu.ar:
 The more interesting point is high vs low latency. I really like the
 idea of having a high-latency option in Tor. It would still need to
 have a lot of users to actually be useful, though. But it seems there
 are various protocols that would be ore high-latency-friendly than
 HTTP - SMTP, of course, and XMPP spring to mind.

 I think if Tor had an arbitrary queue with store and forward as a high
 latency module of sorts, we'd really be onto something. Then there would
 be tons of traffic on the Tor relays for all kinds of reasons - high and
 low latency - only to all be wrapped in TLS and then in the Tor protocol.
 
 I was looking for something like this. It would be incompatible with
 anything that uses TCP, but better that way. I have always found weird
 that there is no a UDP-like transport in tor.

I'm not sure that this is true. Mixminion uses TCP, for example.

 
 IMHO only the TCP initial hand-shake gives your attacker enough info to
 leak your position easily (just a tought, never did any sort of serious
 tests on this) but UDP would be immune to it, even more if it's
 implemented using high-latency queues. Probably most existing UDP services
 should work unmodified.

Tor does not transport connections - it transports streams. The
connection setup happens at the exit node - which is already a known
list of ip addresses.

All the best,
Jacob

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography


Re: [cryptography] Potential funding for crypto-related projects

2013-07-02 Thread Nadim Kobeissi

On 2013-07-02, at 4:17 AM, aort...@alu.itba.edu.ar wrote:

 Given those shortcomings I think is not wise to recommend it unless your
 enemy doesn't have the resources of a country. That being said, it's the
 best tool at the moment, lights year ahead of other popular software
 like
 Cryptocat, whose end-point security should be considered not only
 sub-par
 but dangerous. (who in their right mind will consider browser crypto?)
 
 It's definitely a new field that needs a lot of work. I invite you to
 read:
 
 The paper describing the improvements we're making for browser crypto:
 http://arxiv.org/abs/1306.5156
 
 My blog post on the improving state of browser crypto implementation:
 http://log.nadim.cc/?p=33
 
 NK
 
 Hi! nice to see that improvements are coming. I was reacting to some
 papers reporting about Cryptocat being used to defeat evil governments,
 etc.  IMHO if the FBI can beat TOR, surely they can beat Cryptocat as
 well.

Most definitely true. That kind of reporting is really frustrating. Thankfully, 
it hasn't happened much in the past year, now that we're taking serious efforts 
on making sure journalists don't run off and misrepresent our work.

 
 But I don't blame you. I don't think any real-time chat can ever be made
 safe and by safe I mean anonymous, because of its low-latency nature.
 You can have privacy by using OTR and that's good in many situations, but
 won't protect you from somebody with enough money to hire techs and put
 some taps.

The goal is to make private, encrypted chat (using OTR) more accessible to 
people who would otherwise use something like Facebook chat. There are 
definitely a lot of issues that come with going for maximum accessibility, and 
those are the issues we are trying to address or at least improve upon. :-)

NK

 
 And then your users get killed or thrown into prison and then can't report
 any bug. Crypto dev is like that :)
 
 Best regards,
 
 Alfred
 

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography


Re: [cryptography] Potential funding for crypto-related projects

2013-07-01 Thread Ben Laurie
On 1 July 2013 01:55, Jacob Appelbaum ja...@appelbaum.net wrote:
 So then - what do you suggest to someone who wants to leak a document to
 a press agency that has a GlobaLeaks interface?

I would suggest: don't use GlobalLeaks, use anonymous remailers.
Bottom line: Tor is weak against powerful adversaries because it is
low latency. High latency mixes are a lot safer.

GlobalLeaks should have an email API, IMO.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography


Re: [cryptography] Potential funding for crypto-related projects

2013-07-01 Thread Ben Laurie
On 1 July 2013 01:55, Jacob Appelbaum ja...@appelbaum.net wrote:
 I would like to see a tor configuration flag that sacrifices speed for
 anonymity.

 You're the first person, perhaps ever, to make that feature request
 without it being in a mocking tone. At least, I think you're not mocking! :)

Let me add a second vote for that.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography


Re: [cryptography] Potential funding for crypto-related projects

2013-07-01 Thread Tom Ritter
On 1 July 2013 05:04, Ben Laurie b...@links.org wrote:
 On 1 July 2013 01:55, Jacob Appelbaum ja...@appelbaum.net wrote:
 So then - what do you suggest to someone who wants to leak a document to
 a press agency that has a GlobaLeaks interface?

 I would suggest: don't use GlobalLeaks, use anonymous remailers.
 Bottom line: Tor is weak against powerful adversaries because it is
 low latency. High latency mixes are a lot safer.

 GlobalLeaks should have an email API, IMO.

Having looked a lot at the current remailer network, and a bit at
GlobaLeaks - I'm going to wade in and disagree here. (Although this
thread has gotten woefully off topic after I've bumped it. =/)  Ben: I
love mix networks. I've been learning everything I can about them, and
have been researching them voraciously for a couple years.[0]  But IMO
the theoretical gains of high latency *today* are weaker than the
actual gains of low latency *today*.

Virtually all remailer use is Mixmaster, not Mixminion.  If you want
to use anything but a CLI on Linux - you're talking Mixmaster.  So I'm
assuming you mean that.  Mixmaster uses a very, very recognizable SMTP
envelope, that often goes out with no TLS, let alone no PFS.  There's
also precious few people actually using it.  And finally, if you look
at the public attacks on remailers (the unfortunate bombing threats of
last summer) and Tor (the Jeremy Hammond case) - you see that Feds are
willing to go on fishing expeditions for remailers, but less so Tor.
Tor was traffic confirmation, Remailers was fishing.[1]

Compare to GlobaLeaks.  Tor Hidden Service, Tor network.  The two
biggest threats are Traffic Correlation and the recent attacks on
Hidden Services.

Assume a Globally Passive Adversary logging all SMTP envelopes
(because... they are. So don't assume, know.).  Now assume a leak
arrives over email.  Light up all the nodes who sent a message via
Mixmaster within a couple days, and you'll get at most, a couple
hundred.  Now dim all the lights who've never sent a mixmaster message
before.  You'll get a couple.  That's enough to investigate them all
using traditional methods.

Now you *do* have to assume a GPA who's logging all Tor traffic.  It's
possible.  Some would even say it's probable.  But we've seen no
evidence. Do the same light-up.  You get a hundreds if not thousands
of nodes.  Too many to investigate traditionally.  And to do Traffic
Confirmation, you need to identify the Hidden Service.  And there's
the issue that it's not trivial to do traffic confirmation.

Oh and there's also the little problem of sending anything over 10,236
bytes via Mixmaster splits the message into multiple messages that all
emanate from your machine which makes it wildly probable some won't
arrive, and also drastically makes you stand out the crazy person
who's trying to send anything other than text through Mixmaster.

I'm not saying GlobaLeaks+Tor is safe.  I'm saying I think our current
remailer network is wildly unsafe.  (Now what I think about fixing
it... that's a whole other story, for a whole other time.)

-tom

[1] https://crypto.is/blog
http://defcon.org/html/defcon-21/dc-21-speakers.html#Ritter
[1] If you don't like my last argument, fine, ignore it, and work with
the others.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography


Re: [cryptography] Potential funding for crypto-related projects

2013-07-01 Thread Jacob Appelbaum
Ben Laurie:
 On 1 July 2013 12:32, Tom Ritter t...@ritter.vg wrote:
 On 1 July 2013 05:04, Ben Laurie b...@links.org wrote:
 On 1 July 2013 01:55, Jacob Appelbaum ja...@appelbaum.net wrote:
 So then - what do you suggest to someone who wants to leak a document to
 a press agency that has a GlobaLeaks interface?

 I would suggest: don't use GlobalLeaks, use anonymous remailers.
 Bottom line: Tor is weak against powerful adversaries because it is
 low latency. High latency mixes are a lot safer.

 GlobalLeaks should have an email API, IMO.

 Having looked a lot at the current remailer network, and a bit at
 GlobaLeaks - I'm going to wade in and disagree here. (Although this
 thread has gotten woefully off topic after I've bumped it. =/)  Ben: I
 love mix networks. I've been learning everything I can about them, and
 have been researching them voraciously for a couple years.[0]  But IMO
 the theoretical gains of high latency *today* are weaker than the
 actual gains of low latency *today*.

 Virtually all remailer use is Mixmaster, not Mixminion.  If you want
 to use anything but a CLI on Linux - you're talking Mixmaster.  So I'm
 assuming you mean that.  Mixmaster uses a very, very recognizable SMTP
 envelope, that often goes out with no TLS, let alone no PFS.  There's
 also precious few people actually using it.  And finally, if you look
 at the public attacks on remailers (the unfortunate bombing threats of
 last summer) and Tor (the Jeremy Hammond case) - you see that Feds are
 willing to go on fishing expeditions for remailers, but less so Tor.
 Tor was traffic confirmation, Remailers was fishing.[1]

 Compare to GlobaLeaks.  Tor Hidden Service, Tor network.  The two
 biggest threats are Traffic Correlation and the recent attacks on
 Hidden Services.

 Assume a Globally Passive Adversary logging all SMTP envelopes
 (because... they are. So don't assume, know.).  Now assume a leak
 arrives over email.  Light up all the nodes who sent a message via
 Mixmaster within a couple days, and you'll get at most, a couple
 hundred.  Now dim all the lights who've never sent a mixmaster message
 before.  You'll get a couple.  That's enough to investigate them all
 using traditional methods.

 Now you *do* have to assume a GPA who's logging all Tor traffic.  It's
 possible.  Some would even say it's probable.  But we've seen no
 evidence. Do the same light-up.  You get a hundreds if not thousands
 of nodes.  Too many to investigate traditionally.  And to do Traffic
 Confirmation, you need to identify the Hidden Service.  And there's
 the issue that it's not trivial to do traffic confirmation.

 Oh and there's also the little problem of sending anything over 10,236
 bytes via Mixmaster splits the message into multiple messages that all
 emanate from your machine which makes it wildly probable some won't
 arrive, and also drastically makes you stand out the crazy person
 who's trying to send anything other than text through Mixmaster.

 I'm not saying GlobaLeaks+Tor is safe.  I'm saying I think our current
 remailer network is wildly unsafe.  (Now what I think about fixing
 it... that's a whole other story, for a whole other time.)
 

The above argument is one I have had more than a few times - I think Tom
really did a fantastic job.

 You are probably right - remailers are not what they used to be.

The thing is - I'm not sure they were ever what they used to be - if we
look at the disclosures from Snowden, we should assume a kind of GPA -
the level of traffic from remailers is just too small. There isn't
enough traffic because the desire for one very specific application
(email) is extremely small.

 
 The more interesting point is high vs low latency. I really like the
 idea of having a high-latency option in Tor. It would still need to
 have a lot of users to actually be useful, though. But it seems there
 are various protocols that would be ore high-latency-friendly than
 HTTP - SMTP, of course, and XMPP spring to mind.
 
I think if Tor had an arbitrary queue with store and forward as a high
latency module of sorts, we'd really be onto something. Then there would
be tons of traffic on the Tor relays for all kinds of reasons - high and
low latency - only to all be wrapped in TLS and then in the Tor protocol.

It would actually be rather straight forward to add a new cell type that
did something interesting like the above. It would also be dead simple
to use torsocks to torify MixMinion or mixmaster. I've done it and the
main problem was that none of the remailer networks really work very
well for other properties - other than anonymity, I mean. Using Tor with
mixmaster at least augments the forward secrecy problem a bit - that is
Tor adds what mixmaster is missing.

I think having Mixmaster and MixMinion support in Tails and run over Tor
would be a good way to start. I also agree that GlobaLeaks should have
an interface for receiving leaks via either of those networks - though I
sometimes wonder if GL wouldn't be 

Re: [cryptography] Potential funding for crypto-related projects

2013-07-01 Thread Ben Laurie
On 1 July 2013 14:33, Jacob Appelbaum ja...@appelbaum.net wrote:
 I think having Mixmaster and MixMinion support in Tails and run over Tor
 would be a good way to start. I also agree that GlobaLeaks should have
 an interface for receiving leaks via either of those networks - though I
 sometimes wonder if GL wouldn't be better off with only type-III
 remailer support? Forward secrecy seems absolutely critical.

While we're shooting the high-latency breeze, I should mention Minx,
which was designed to be more robust against active attacks (the
original had a slight flaw, so I am pointing to the fix for that):
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.140.9884.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography


Re: [cryptography] Potential funding for crypto-related projects

2013-07-01 Thread Moritz
On 01.07.2013 15:33, Jacob Appelbaum wrote:
 I think if Tor had an arbitrary queue with store and forward as a high
 latency module of sorts, we'd really be onto something.

Isn't that what Roger proposed as Alpha Mixing?

http://freehaven.net/anonbib/#alpha-mixing:pet2006

It could be valuable if someone with enough knowledge of Tor's code
sketched the required code and spec changes, no?

--Mo
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography


Re: [cryptography] Potential funding for crypto-related projects

2013-07-01 Thread James A. Donald

On 2013-07-01 9:50 PM, Ben Laurie wrote:

On 1 July 2013 12:32, Tom Ritter t...@ritter.vg wrote:

On 1 July 2013 05:04, Ben Laurie b...@links.org wrote:

On 1 July 2013 01:55, Jacob Appelbaum ja...@appelbaum.net wrote:

So then - what do you suggest to someone who wants to leak a document to
a press agency that has a GlobaLeaks interface?

I would suggest: don't use GlobalLeaks, use anonymous remailers.
Bottom line: Tor is weak against powerful adversaries because it is
low latency. High latency mixes are a lot safer.

GlobalLeaks should have an email API, IMO.

Having looked a lot at the current remailer network, and a bit at
GlobaLeaks - I'm going to wade in and disagree here. (Although this
thread has gotten woefully off topic after I've bumped it. =/)  Ben: I
love mix networks. I've been learning everything I can about them, and
have been researching them voraciously for a couple years.[0]  But IMO
the theoretical gains of high latency *today* are weaker than the
actual gains of low latency *today*.

Virtually all remailer use is Mixmaster, not Mixminion.  If you want
to use anything but a CLI on Linux - you're talking Mixmaster.  So I'm
assuming you mean that.  Mixmaster uses a very, very recognizable SMTP
envelope, that often goes out with no TLS, let alone no PFS.  There's
also precious few people actually using it.  And finally, if you look
at the public attacks on remailers (the unfortunate bombing threats of
last summer) and Tor (the Jeremy Hammond case) - you see that Feds are
willing to go on fishing expeditions for remailers, but less so Tor.
Tor was traffic confirmation, Remailers was fishing.[1]

Compare to GlobaLeaks.  Tor Hidden Service, Tor network.  The two
biggest threats are Traffic Correlation and the recent attacks on
Hidden Services.

Assume a Globally Passive Adversary logging all SMTP envelopes
(because... they are. So don't assume, know.).  Now assume a leak
arrives over email.  Light up all the nodes who sent a message via
Mixmaster within a couple days, and you'll get at most, a couple
hundred.  Now dim all the lights who've never sent a mixmaster message
before.  You'll get a couple.  That's enough to investigate them all
using traditional methods.

Now you *do* have to assume a GPA who's logging all Tor traffic.  It's
possible.  Some would even say it's probable.  But we've seen no
evidence. Do the same light-up.  You get a hundreds if not thousands
of nodes.  Too many to investigate traditionally.  And to do Traffic
Confirmation, you need to identify the Hidden Service.  And there's
the issue that it's not trivial to do traffic confirmation.

Oh and there's also the little problem of sending anything over 10,236
bytes via Mixmaster splits the message into multiple messages that all
emanate from your machine which makes it wildly probable some won't
arrive, and also drastically makes you stand out the crazy person
who's trying to send anything other than text through Mixmaster.

I'm not saying GlobaLeaks+Tor is safe.  I'm saying I think our current
remailer network is wildly unsafe.  (Now what I think about fixing
it... that's a whole other story, for a whole other time.)

You are probably right - remailers are not what they used to be.

The more interesting point is high vs low latency. I really like the
idea of having a high-latency option in Tor. It would still need to
have a lot of users to actually be useful, though. But it seems there
are various protocols that would be ore high-latency-friendly than
HTTP - SMTP, of course, and XMPP spring to mind.


One solution would be to have an anonymizing remailer inside  tor as a 
hidden service.  You send emails to that service.  A random time later, 
they are sent to their destination.







-tom

[1] https://crypto.is/blog
http://defcon.org/html/defcon-21/dc-21-speakers.html#Ritter
[1] If you don't like my last argument, fine, ignore it, and work with
the others.

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography



___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography


Re: [cryptography] Potential funding for crypto-related projects

2013-07-01 Thread grarpamp
 I think if Tor had an arbitrary queue with store and forward as a high
 latency module of sorts, we'd really be onto something. Then there would
 be tons of traffic on the Tor relays for all kinds of reasons - high and
 low latency - only to all be wrapped in TLS and then in the Tor protocol.

That would work for things you're able to 'encapsulate' within some
compatible form of transmission. Email is essentially a single message
in one direction. Various stackable modules could be apply to certain
compatible things... random delay, storage at some prescribed levels
of redundancy, add/remove padding, etc.

Also of issue is if, when or where you're required to interact with clearnet.
TCP and websites do not like any of these modules. They'll timeout
or break. And you'd need a huge application specific volunteer army
writing clearnet interface modules for each BBS, website app, etc.
Which few would use since they need access tokens and exits
can't be trusted (though see below if you would so choose to).

But if you're able to throw out old models, things are possible, particularly
over/within your own transports... for example, I2P-Bote.

There may even come a time where you can view these overlays
as your own implicitly trusted execution platform into which you
launch a command packet/agent whose parameters will be followed
according to various rules on your behalf.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography


Re: [cryptography] Potential funding for crypto-related projects

2013-06-30 Thread Nadim Kobeissi

On 2013-06-29, at 11:48 PM, Jacob Appelbaum ja...@appelbaum.net wrote:

 Natanael:
 I'm not seeing that many options though. The Phantom project died pretty
 fast;
 https://code.google.com/p/phantom/
 https://groups.google.com/forum/#!forum/phantom-protocol
 http://phantom-anon.blogspot.se/
 
 So who's out there developing any useful protocols for anonymization today?
 *Anybody*? Could we try to start a new project (if needed) to create one?
 (I would like one with at least the same level of functionality as I2P,
 even if it would have to have a very different architecture.)
 
 I guess you might be interested in this project called Tor? A few of us
 have spent a decade working on it:
 
  https://www.torproject.org/

There should be a disclaimer somewhere that Tor is a competitor to I2P, is far 
from perfect itself (actually has a few glaring weaknesses, such as exit 
nodes), and the guy critiquing I2P works for Tor.

I'm a Tor supporter personally, but those things should be clarified!

NK

 
 I'd suggest if you want to experiment with Tor and i2p, to try Tails:
 
  https://tails.boum.org
 
 All the best,
 Jacob
 
 ___
 cryptography mailing list
 cryptography@randombit.net
 http://lists.randombit.net/mailman/listinfo/cryptography

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography


Re: [cryptography] Potential funding for crypto-related projects

2013-06-30 Thread grarpamp
 There should be a disclaimer somewhere that Tor is a competitor to I2P, is 
 far from perfect itself (actually has a few glaring weaknesses, such as exit 
 nodes), and the guy critiquing I2P works for Tor.

There should be a table somewhere that shows that
all these different systems have different *features*.
One such feature is exit to clearnet, which is not in
itself a 'weakness' unless further supporting information
as to how the feature is broken, not its mere presence,
is supplied. Note also that I2P 'exits' as well, albeit
from one of any particular list of known exits configured
by the user. Furthermore, such wikitable could very
well include actual weaknesses, whether by design
limitations/concessions or work in progress.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography


Re: [cryptography] Potential funding for crypto-related projects

2013-06-30 Thread grarpamp
 I'm not seeing that many options though. The Phantom project died pretty
 fast;
 https://code.google.com/p/phantom/
 https://groups.google.com/forum/#!forum/phantom-protocol
 http://phantom-anon.blogspot.se/

I would bet that Phantom both ran out of developer time and
has discouraged further takeup by using the unfamiliar
HESSLA instead of say the simply free 2-clause BSD.

As opposed to having been proven to use an [unfixably]
flawed protocol design, no? (this being more on topic).
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography


Re: [cryptography] Potential funding for crypto-related projects

2013-06-30 Thread Jacob Appelbaum
Nadim Kobeissi:
 
 On 2013-06-29, at 11:48 PM, Jacob Appelbaum ja...@appelbaum.net
 wrote:
 
 Natanael:
 I'm not seeing that many options though. The Phantom project died
 pretty fast; https://code.google.com/p/phantom/ 
 https://groups.google.com/forum/#!forum/phantom-protocol 
 http://phantom-anon.blogspot.se/
 
 So who's out there developing any useful protocols for
 anonymization today? *Anybody*? Could we try to start a new
 project (if needed) to create one? (I would like one with at
 least the same level of functionality as I2P, even if it would
 have to have a very different architecture.)
 
 I guess you might be interested in this project called Tor? A few
 of us have spent a decade working on it:
 
 https://www.torproject.org/
 
 There should be a disclaimer somewhere that Tor is a competitor to
 I2P, is far from perfect itself (actually has a few glaring
 weaknesses, such as exit nodes), and the guy critiquing I2P works for
 Tor.
 

Ha. There isn't a competition. This isn't zero sum.

We're all interested in similar goals and in some cases, the designs are
totally different and for good reason. Also, the security properties and
reviews of claims have different results.

I didn't just critique i2p offhand because I work on Tor - which I
disclosed by saying a few of us have spent a decade working on it - I
linked to a paper that broke it!

 I'm a Tor supporter personally, but those things should be
 clarified!
 

Read my email more carefully next time. I specifically encouraged
experimentation in a way that seems reasonably safe:

 
 I'd suggest if you want to experiment with Tor and i2p, to try
 Tails:
 
 https://tails.boum.org

All the best,
Jacob

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography


Re: [cryptography] Potential funding for crypto-related projects

2013-06-30 Thread Nadim Kobeissi

On 2013-06-30, at 9:40 AM, Jacob Appelbaum ja...@appelbaum.net wrote:

 Nadim Kobeissi:
 
 On 2013-06-29, at 11:48 PM, Jacob Appelbaum ja...@appelbaum.net
 wrote:
 
 Natanael:
 I'm not seeing that many options though. The Phantom project died
 pretty fast; https://code.google.com/p/phantom/ 
 https://groups.google.com/forum/#!forum/phantom-protocol 
 http://phantom-anon.blogspot.se/
 
 So who's out there developing any useful protocols for
 anonymization today? *Anybody*? Could we try to start a new
 project (if needed) to create one? (I would like one with at
 least the same level of functionality as I2P, even if it would
 have to have a very different architecture.)
 
 I guess you might be interested in this project called Tor? A few
 of us have spent a decade working on it:
 
 https://www.torproject.org/
 
 There should be a disclaimer somewhere that Tor is a competitor to
 I2P, is far from perfect itself (actually has a few glaring
 weaknesses, such as exit nodes), and the guy critiquing I2P works for
 Tor.
 
 
 Ha. There isn't a competition. This isn't zero sum.
 
 We're all interested in similar goals and in some cases, the designs are
 totally different and for good reason. Also, the security properties and
 reviews of claims have different results.
 
 I didn't just critique i2p offhand because I work on Tor - which I
 disclosed by saying a few of us have spent a decade working on it - I
 linked to a paper that broke it!
 
 I'm a Tor supporter personally, but those things should be
 clarified!
 
 
 Read my email more carefully next time. I specifically encouraged
 experimentation in a way that seems reasonably safe:

There's no need to be so patronizing — I'm aware that you recommended TAILS 
(which is also a Tor project).

NK

 
 
 I'd suggest if you want to experiment with Tor and i2p, to try
 Tails:
 
 https://tails.boum.org
 
 All the best,
 Jacob
 
 ___
 cryptography mailing list
 cryptography@randombit.net
 http://lists.randombit.net/mailman/listinfo/cryptography

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography


Re: [cryptography] Potential funding for crypto-related projects

2013-06-30 Thread Jacob Appelbaum
Nadim Kobeissi:

 Read my email more carefully next time. I specifically encouraged
 experimentation in a way that seems reasonably safe:
 
 There's no need to be so patronizing — I'm aware that you recommended TAILS 
 (which is also a Tor project).
 

I'm sorry to write with more bad news - it certainly isn't meant to be
patronizing though writing to correct and update people is often viewed
that way - sadly it seems important to correct the record, again:

Tails is an independent project from the Tor Project - Tor supports the
development of Tails and we are not the only group to do so.

Just to clear it up more explicitly:

They have their own development cycles, their own funding management,
their own development teams and so on. Obviously our two communities are
very related but not so obviously, we are two different projects.

I wouldn't for example ship i2p - though part of me is glad that someone
does...

All the best,
Jacob
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography


Re: [cryptography] Potential funding for crypto-related projects

2013-06-30 Thread Ralph Holz

 I don't think they are doing this (as I said, they only bother with the
 low hanging fruit) but they could.
 
 Is there a tool that detects changes of CA?

Certificate Patrol does it for you on client-side:
https://addons.mozilla.org/de/firefox/addon/certificate-patrol/

Our own Crossbear does it for you on server-side - and will aggressively
start tracerouting to get an idea of where the MITM must be. Note that
we are currently revising Crossbear to be implemented as an OONI test -
called OONIBear. The Firefox plug-in has been broken by Mozilla's
lovingly frequent changes in API; we're fixing at the moment.

[1] https://addons.mozilla.org/de/firefox/addon/certificate-patrol/
[2]
http://www.net.in.tum.de/fileadmin/bibtex/publications/papers/holz_x509forensics_esorics2012.pdf
[3] http://www.youtube.com/watch?v=29h21n-tyfEt=46m26s

Ralph

-- 
Ralph Holz
I8 - Network Architectures and Services
Technische Universität München
http://www.net.in.tum.de/de/mitarbeiter/holz/
Phone +49.89.289.18043
PGP: A805 D19C E23E 6BBB E0C4  86DC 520E 0C83 69B0 03EF
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography


Re: [cryptography] Potential funding for crypto-related projects

2013-06-30 Thread Michael Rogers
 So who's out there developing any useful protocols for anonymization today? 
 *Anybody*? Could we try to start a new project (if needed) to create one?

I'd love to see a revitalisation of remailer research, focussing on 
unlinkability (which we know many people would benefit from) rather than sender 
anonymity (which fewer people need, and which is prone to abuse that 
discourages people from running mixes).

Cheers,
Michael
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography


Re: [cryptography] Potential funding for crypto-related projects

2013-06-30 Thread Jacob Appelbaum
Michael Rogers:
 So who's out there developing any useful protocols for
 anonymization today? *Anybody*? Could we try to start a new project
 (if needed) to create one?
 
 I'd love to see a revitalisation of remailer research, focussing on
 unlinkability (which we know many people would benefit from) rather
 than sender anonymity (which fewer people need, and which is prone to
 abuse that discourages people from running mixes).
 

I'd also like to see revitalisation of remailer research. Though
anonymity as Tor is designed is specifically about unlinkability. To
reduce it to sender anonymity is pretty ... ridiculous. What one does
with an anonymous communications channel is up to them - many people do
actually want that feature for chatting, web browsing, news, email, etc.

All the best,
Jacob
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography


Re: [cryptography] Potential funding for crypto-related projects

2013-06-30 Thread aortega
I believe Anonymity is a problem orders of magnitude bigger than privacy.
Tor seems like the only serious project aiming at solving it but I think
you should be wise by choosing your enemies and Tor in its current state
is useless against government-type surveillance for the following reasongs
(IMHO):

1) Endpoint security: Tor is a big C project, needs much more code review
until it's considered safe.
2) Network analysis: Tor is vulnerable to network analysis. FBI has made
arrests to people that were specifically using TOR to hide their
activities, and their use of network analysis to unmask them is documented
(Jeremy Hammond, Stratfor case).

Given those shortcomings I think is not wise to recommend it unless your
enemy doesn't have the resources of a country. That being said, it's the
best tool at the moment, lights year ahead of other popular software like
Cryptocat, whose end-point security should be considered not only sub-par
but dangerous. (who in their right mind will consider browser crypto?)

Some months ago I tried to fix some shortcomings of Tor by wrapping it in
a higher layer and using it for simple network-analysis resistant chat.
The result was a protocol so slow that's almost unusable, if someone want
to take a look at it it's here: https://github.com/alfred-gw/torirc

I would like to see a tor configuration flag that sacrifices speed for
anonymity.

 Michael Rogers:
 So who's out there developing any useful protocols for
 anonymization today? *Anybody*? Could we try to start a new project
 (if needed) to create one?

 I'd love to see a revitalisation of remailer research, focussing on
 unlinkability (which we know many people would benefit from) rather
 than sender anonymity (which fewer people need, and which is prone to
 abuse that discourages people from running mixes).


 I'd also like to see revitalisation of remailer research. Though
 anonymity as Tor is designed is specifically about unlinkability. To
 reduce it to sender anonymity is pretty ... ridiculous. What one does
 with an anonymous communications channel is up to them - many people do
 actually want that feature for chatting, web browsing, news, email, etc.

 All the best,
 Jacob
 ___
 cryptography mailing list
 cryptography@randombit.net
 http://lists.randombit.net/mailman/listinfo/cryptography



___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography


Re: [cryptography] Potential funding for crypto-related projects

2013-06-30 Thread Jacob Appelbaum
aort...@alu.itba.edu.ar:
 I believe Anonymity is a problem orders of magnitude bigger than privacy.

I agree - though most people think the two terms mean the same thing.
Lots of different terms are a similar set of things for different people.

 Tor seems like the only serious project aiming at solving it but I think
 you should be wise by choosing your enemies and Tor in its current state
 is useless against government-type surveillance for the following reasongs
 (IMHO):

Whenever I see the above statement, I think to myself gosh, I really
wonder what this person suggests I should do? or I wonder what they
would do in my shoes or the shoes of any of my friends who do not get to
choose if they're playing? - usually, there isn't much of a response.
The advise of don't do anything is not useful - rather - do something
but understand the limits, and understand the limits of what we know is
much more useful.

So then - what do you suggest to someone who wants to leak a document to
a press agency that has a GlobaLeaks interface? What do you suggest to
someone who wants to use a web email account that properly supports
HTTPS? What do you suggest to someone who wants location privacy from
their chat service? What do you suggest to someone who wants to buy
themselves time and not link their entire past to some event they think
might matter, thus attracting retroactive searches in the future?

 
 1) Endpoint security: Tor is a big C project, needs much more code review
 until it's considered safe.

I agree - all C programming projects need help in this area. This is why
we have multiple static analysis tools, regular code audits, multiple
people doing code review for every commit, a design process for
features, a design process for protocol changes, cryptographic review at
an academic level and at an implementation level, and so on.

It is also why we have multiple implementations as well. There is a Java
version of Tor that is nearly ready for release and it will solve a
number of the C implementation concerns and exchange them for Java
related concerns. There are a few other Tor implementations in the wild,
each serving an interesting subset of users. Diversity is important.

Still - having a bug in Tor as a client is a lot less likely than in
whatever application you'll use with Tor - web browsers come to mind
here but other chat clients, like Pidgin or Thunderbird, they also come
to mind.

 2) Network analysis: Tor is vulnerable to network analysis. FBI has made
 arrests to people that were specifically using TOR to hide their
 activities, and their use of network analysis to unmask them is documented
 (Jeremy Hammond, Stratfor case).
 

What is public about Jeremy Hammond is worth reading. It suggests the
FBI has the lamest of all Network analysis techniques - a very simple
traffic confirmation attack. They appear to disconnect a person's
internet and then they ask their snitch if the person signs off from
their chat service. There are solutions - one of them is to run a second
machine reachable by (Stealth) Tor Hidden Service with your chat client
in gnu screen - login to that system, attach to the screen and chat away
- sometimes, you'll get disconnected but no one will see it.

There are social issues that are more concerning though - if you
normally are quite chatty, only to stop chatting, they might suggest
that not speaking is confirmation, etc. So this issue issue, like any
solution, is partially a technical issue and partially a social issue.
It is not fair to blame Tor for the times that you have no internet. Tor
can't protect you from an internet blackout when you need to reach a
service on the public internet.

 Given those shortcomings I think is not wise to recommend it unless your
 enemy doesn't have the resources of a country. That being said, it's the
 best tool at the moment, lights year ahead of other popular software like

I think if you put all countries in the same category you're doing a
disservice to well, everyone. There are different behaviors - chatting
to a jabber service that is a Tor hidden service is probably fine -
especially if you also use TLS anyway. I do that on a daily basis - I
also consider that there are nation state attackers going after me -
what would be a better option? Living in the forest and writing with a
pen? Hardly.

People who are working on important work can protect themselves with Tor
and they do so. Without Tor and without a complex education, I think
they have little to no chance. Barebacking with the internet is like
barebacking with Big Brother. Don't do it.

 Cryptocat, whose end-point security should be considered not only sub-par
 but dangerous. (who in their right mind will consider browser crypto?)
 

Oh man, you just opened up a can of worms that I won't even touch. If I
even comment, an entire community of people will send me hate mail -
which I suppose is enough said already. :(

 Some months ago I tried to fix some shortcomings of Tor by 

Re: [cryptography] Potential funding for crypto-related projects

2013-06-30 Thread Peter Maxwell
On 1 July 2013 01:55, Jacob Appelbaum ja...@appelbaum.net wrote:


  I would like to see a tor configuration flag that sacrifices speed for
  anonymity.

 You're the first person, perhaps ever, to make that feature request
 without it being in a mocking tone. At least, I think you're not mocking!
 :)



I would second that, it would be a desirable feature.

As it happens, I have been pondering this very problem for a while now,
even before information came to light about GCHQ's pervasive tapping of
fibre cables.  While I doubt any government agency is at the moment running
any decent traffic analysis on the Tor network - as was alluded to in
previous posts, it's hardly worth their while at the moment - conceptually
it wouldn't take a massive leap to do so.  If you have visibility of a
large proportion of the internet with very accurate time stamps, it will
almost certainly be possible to break the anonymity protection that Tor
currently provides.

There are some naive models that can combat that type of traffic analysis
but they all introduce new problems as well.  For example, if one creates a
new mode of operation so that nodes forward entire messages instead of
packets and that those messages have a lower and upper bound delay field,
it would seem on the face of it that one could thwart traffic analysis
because the data forwarding times are almost completely disassociated from
the sender.  However, because it is a larger message instead of packets, a
new statistical bias is introduced in terms of message size and reduction
in frequency of forwarding events.  So in this naive model, it may actually
have made the situation worse.

So, yes, being able to sacrifice speed for improved anonymity is a
desirable feature but I doubt it's going to be particularly easy to design
or implement.  There's also the problem of having applications that can
utilise a mode of operation that has potentially much higher latency.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography


Re: [cryptography] Potential funding for crypto-related projects

2013-06-29 Thread Jacob Appelbaum
Natanael:
 I would like to point out that the developers of the anonymizing network
 I2P are looking for more external review of the codebase (it's in Java, by
 the way). Everybody who knows how to do security reviews of source code and
 has time to spare should take a look at it.
 

I've previously read papers like this:

  http://grothoff.org/christian/i2p.pdf

My thought is that some of the ideas behind i2p are interest but many of
them are... misguided or perhaps ignoring some of the hard won lessons
from GnuNET, Tor, FreeNet, the Freedom Network, etc.

We should be reviewing protocols, not the code for i2p, I think. I'm not
convinced that the overall architecture makes sense from what we know
about building anonymity systems.

 FYI, I also think that I2P's supernode architecture is a whole lot better
 than Tor's directory servers. It's much more decentralized, to start with.
 

Yeah, about that...

Have you seen the most recent paper by Egger et al?

The file is about two weeks old:

  Last-Modified: Fri, 14 Jun 2013 23:46:05 GMT

Abstract. Anonymity networks, such as Tor or I2P, were built to allow
users to access network resources without revealing their identity.
Newer designs, like I2P, run in a completely decentralized fashion,
while older systems, like Tor, are built around central authorities. The
decentralized approach has advantages (no trusted central party, better
scalability), but there are also security risks associated with the use
of distributed hash tables (DHTs) in this environment.
I2P was built with these security problems in mind, and the network
is considered to provide anonymity for all practical purposes. Unfortu-
nately, this is not entirely justified. In this paper, we present a
group of attacks that can be used to deanonymize I2P users.
Specifically, we show that an attacker, with relatively limited
resources, is able to deanonymize a I2P user that accesses a resource of
interest with high probability.

...

The developers of I2P have reacted to the publication of attacks, and
they have improved their network to resist the DHT-based attacks
introduced in [3] and [4], by limiting the database to a subset of
well-performing nodes. This reduces the number of nodes involved in each
individual lookup to only one for most cases. Moreover, the performance
computation techniques were up-dated to make it more difficult for an
attacker to exploit them. As a result, I2P
is considered secure in practice. Unfortunately, this is not entirely
justified.

In this paper, we describe an attack that can be used to break the
anonymity of a victim who is using anonymized resources in I2P – for
example, a user browsing eepsites (I2P’s terminology for anonymous
websites) or chatting. We are able, with high probability, to list the
services the victim accesses regularly, the time of access, and the
amount of time that is spent using the service

The full paper is here:

  http://wwwcip.informatik.uni-erlangen.de/~spjsschl/i2p.pdf

Seems rather... well, not a lot better. :(

 A link on Hidden Services:
 http://donncha.is/2013/05/trawling-tor-hidden-services/
 

Yeah, Ralf's paper is worth reading:

  http://www.ieee-security.org/TC/SP2013/papers/4977a080.pdf

Discussion about this paper starts here - read the thread for tickets,
fixes, etc:

  https://lists.torproject.org/pipermail/tor-dev/2013-May/004909.html

All the best,
Jacob
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography


Re: [cryptography] Potential funding for crypto-related projects

2013-06-29 Thread Natanael
I'm not seeing that many options though. The Phantom project died pretty
fast;
https://code.google.com/p/phantom/
https://groups.google.com/forum/#!forum/phantom-protocol
http://phantom-anon.blogspot.se/

So who's out there developing any useful protocols for anonymization today?
*Anybody*? Could we try to start a new project (if needed) to create one?
(I would like one with at least the same level of functionality as I2P,
even if it would have to have a very different architecture.)


2013/6/30 Jacob Appelbaum ja...@appelbaum.net

 Natanael:
  I would like to point out that the developers of the anonymizing network
  I2P are looking for more external review of the codebase (it's in Java,
 by
  the way). Everybody who knows how to do security reviews of source code
 and
  has time to spare should take a look at it.
 

 I've previously read papers like this:

   http://grothoff.org/christian/i2p.pdf

 My thought is that some of the ideas behind i2p are interest but many of
 them are... misguided or perhaps ignoring some of the hard won lessons
 from GnuNET, Tor, FreeNet, the Freedom Network, etc.

 We should be reviewing protocols, not the code for i2p, I think. I'm not
 convinced that the overall architecture makes sense from what we know
 about building anonymity systems.

  FYI, I also think that I2P's supernode architecture is a whole lot better
  than Tor's directory servers. It's much more decentralized, to start
 with.
 

 Yeah, about that...

 Have you seen the most recent paper by Egger et al?

 The file is about two weeks old:

   Last-Modified: Fri, 14 Jun 2013 23:46:05 GMT

 Abstract. Anonymity networks, such as Tor or I2P, were built to allow
 users to access network resources without revealing their identity.
 Newer designs, like I2P, run in a completely decentralized fashion,
 while older systems, like Tor, are built around central authorities. The
 decentralized approach has advantages (no trusted central party, better
 scalability), but there are also security risks associated with the use
 of distributed hash tables (DHTs) in this environment.
 I2P was built with these security problems in mind, and the network
 is considered to provide anonymity for all practical purposes. Unfortu-
 nately, this is not entirely justified. In this paper, we present a
 group of attacks that can be used to deanonymize I2P users.
 Specifically, we show that an attacker, with relatively limited
 resources, is able to deanonymize a I2P user that accesses a resource of
 interest with high probability.

 ...

 The developers of I2P have reacted to the publication of attacks, and
 they have improved their network to resist the DHT-based attacks
 introduced in [3] and [4], by limiting the database to a subset of
 well-performing nodes. This reduces the number of nodes involved in each
 individual lookup to only one for most cases. Moreover, the performance
 computation techniques were up-dated to make it more difficult for an
 attacker to exploit them. As a result, I2P
 is considered secure in practice. Unfortunately, this is not entirely
 justified.

 In this paper, we describe an attack that can be used to break the
 anonymity of a victim who is using anonymized resources in I2P – for
 example, a user browsing eepsites (I2P’s terminology for anonymous
 websites) or chatting. We are able, with high probability, to list the
 services the victim accesses regularly, the time of access, and the
 amount of time that is spent using the service

 The full paper is here:

   http://wwwcip.informatik.uni-erlangen.de/~spjsschl/i2p.pdf

 Seems rather... well, not a lot better. :(

  A link on Hidden Services:
  http://donncha.is/2013/05/trawling-tor-hidden-services/
 

 Yeah, Ralf's paper is worth reading:

   http://www.ieee-security.org/TC/SP2013/papers/4977a080.pdf

 Discussion about this paper starts here - read the thread for tickets,
 fixes, etc:

   https://lists.torproject.org/pipermail/tor-dev/2013-May/004909.html

 All the best,
 Jacob
 ___
 cryptography mailing list
 cryptography@randombit.net
 http://lists.randombit.net/mailman/listinfo/cryptography

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography


Re: [cryptography] Potential funding for crypto-related projects

2013-06-29 Thread Jacob Appelbaum
Natanael:
 I'm not seeing that many options though. The Phantom project died pretty
 fast;
 https://code.google.com/p/phantom/
 https://groups.google.com/forum/#!forum/phantom-protocol
 http://phantom-anon.blogspot.se/
 
 So who's out there developing any useful protocols for anonymization today?
 *Anybody*? Could we try to start a new project (if needed) to create one?
 (I would like one with at least the same level of functionality as I2P,
 even if it would have to have a very different architecture.)

I guess you might be interested in this project called Tor? A few of us
have spent a decade working on it:

  https://www.torproject.org/

I'd suggest if you want to experiment with Tor and i2p, to try Tails:

  https://tails.boum.org

All the best,
Jacob

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography


Re: [cryptography] Potential funding for crypto-related projects

2013-06-29 Thread James A. Donald

On 2013-06-30 10:21 AM, Natanael wrote:



Of course there's that whole 'almost none of our tools are usable'
problem.



That problem needs fixing first.  Only then will our enemies start 
bothering with pattern recognition and such.


Right now, the most trivial precautions result in you not being traced 
and observed.  They only bother with the low hanging fruit.


___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography


Re: [cryptography] Potential funding for crypto-related projects

2013-06-29 Thread Natanael
Yeah, I know about Tor already of course, but I also want *more options*
(at least so that any critical bugs in one of the options doesn't
automatically put *everybody* at risk), and there's also a few too many
things I don't like about Tor. I know a lot of it can be fixed, but it
would also require a lot of work and time to fix (even if just to make sure
nothing breaks). Such as relatively small keysizes for hidden services
(1024 bit RSA), those short .onion domains (just 80 bits?), some of the
details on how it handles the circuits, etc... I would prefer to see
something new written from scratch, even if it would be based on something
that already exists. At this point, if anonymity is absolutely critical for
you, I don't really trust any of the existing options for much more than
one-off usage like quickly checking something or quickly uploading some
document rather than for live chat (IM or IRC) or continous browsing.

2013/6/30 Jacob Appelbaum ja...@appelbaum.net

 Natanael:
  I'm not seeing that many options though. The Phantom project died pretty
  fast;
  https://code.google.com/p/phantom/
  https://groups.google.com/forum/#!forum/phantom-protocol
  http://phantom-anon.blogspot.se/
 
  So who's out there developing any useful protocols for anonymization
 today?
  *Anybody*? Could we try to start a new project (if needed) to create one?
  (I would like one with at least the same level of functionality as I2P,
  even if it would have to have a very different architecture.)

 I guess you might be interested in this project called Tor? A few of us
 have spent a decade working on it:

   https://www.torproject.org/

 I'd suggest if you want to experiment with Tor and i2p, to try Tails:

   https://tails.boum.org

 All the best,
 Jacob


___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography


Re: [cryptography] Potential funding for crypto-related projects

2013-06-29 Thread James A. Donald
The biggest Tor vulnerability is that governments and large criminal 
organizations (but I repeat myself) can use their influence over a CA to 
perform a man in the middle attack.


I don't think they are doing this (as I said, they only bother with the 
low hanging fruit) but they could.


Is there a tool that detects changes of CA?
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography


Re: [cryptography] Potential funding for crypto-related projects

2013-06-29 Thread Natanael
Convergence, (in-browser) certificate pinning, and a few more. You could
also use DNSSEC to serve the certificate.


2013/6/30 James A. Donald jam...@echeque.com

 The biggest Tor vulnerability is that governments and large criminal
 organizations (but I repeat myself) can use their influence over a CA to
 perform a man in the middle attack.

 I don't think they are doing this (as I said, they only bother with the
 low hanging fruit) but they could.

 Is there a tool that detects changes of CA?

 __**_
 cryptography mailing list
 cryptography@randombit.net
 http://lists.randombit.net/**mailman/listinfo/cryptographyhttp://lists.randombit.net/mailman/listinfo/cryptography

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography


Re: [cryptography] Potential funding for crypto-related projects

2013-06-29 Thread coderman
On Thu, Jun 13, 2013 at 9:27 AM, Moritz mor...@headstrong.de wrote:
 ...
 A foundation offered me money for improving, auditing, or implementing
 crypto-related software ...

wanted: SSL/TLS session ticket storage clustering support for apache2,
nginx, haproxy using memcached or suitable memory only backed storage
engine with forced session ticket expiry to ensure proper rotation and
zeroisation of tickets in large scale web deployments.

see also https://www.imperialviolet.org/2013/06/27/botchingpfs.html
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography