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

[coderman]

On Thu, Jun 13, 2013 at 9:27 AM, Moritz  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

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

[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 

> 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
>
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

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

[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

[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 

> 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

[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

[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

[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 

> 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

[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

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

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.

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


2013/6/30 Tom Ritter 

> I've been waiting to reply to this until I can give it an hour to get my
> thoughts down.  Hopefully it's not too late.  This is a very important
> question: where should we spend our time, and our effort?  Because I know
> you Moritz, I'm going to stray heavily into the Liberation Tech side of
> things, as well as crypto.
>
> Of course my first thought it towards auditing, since it's my day job.
>  I've audited many open & closed source projects that were directly
> cryptographic or built on top of cryptography, and found critical flaws.
>  This is a no-brainer.  And it's valuable. But is it the *most valuable
> thing*?  For some apps, yes, for most apps, probably not.
>
> There are a host of hard problems we don't have good solutions to.
>
> For example, so many cryptographic projects are focused on content
> confidentiality: PGP Email, OTR, IPSEC, SSL, so on and so forth.  So _few_
> are focused on sender and receiver anonymity.  The techniques to achieve
> that: onion routing, mixing, anonymous(?) broadcasts, shared mailboxes,
> PIR, are so under documented in accessible forms that they're never
> considered in new censorship circumvention or anonymity tools.  Research
> into these areas, and bringing the content into more accessible forms, with
> blog posts, graphics, architecture discussions and designs would be awesome.
>
> Similarly - so many encryption applications are widely distrusted because
> they are centrally managed.  Psiphon, Wickr, Silent Circle, Cryptocat,
> RedPhone, so on and so forth.  Research and explanations into how to deploy
> a centrally managed but untrusted network would be invaluable.  A great
> example is Tor's Directory Server design.  Frankly I'm only familiar enough
> with it to know its strengths, not its weaknesses - but accessible
> explanations into how it works, and how you can design similar things,
> would be amazing.  As a very practical example: Mixminion is in desperate
> need of a directory service similar to Tor's.  NickM said today "There
> isnt' currently actually a design for the distributed directory thing you'd
> want. I wrote a draft long ago, but I was even less good at this stuff back
> then."  Nick's being quite humble - the skeleton of one is there, and the
> learning process of fleshing it out and developing it would be invaluable
> for the community.
>
> Another pervasive problem is that virtually all of our tools are
> detectable on the wire by a network admin, and classifiable.  I've thought
> about this, and broken censorship into a few buckets in my head:
>  - Source Censorship: You are censored. You're not allowed to go online.
>  (Well crap.)
>  - Destination Censorship: No one can talk to this IP, or resolve this
> domain name
>  - Content Censorship: TCP reset packets that contain the words 'Falun
> Gong' OR have a specific byte sequence (like the old Tor SSL handshake)
>  - Pattern Censorship: If someone has an SSH tunnel open, and they're
> sending significantly more data than they're receiving, they must be
> transferring an outgoing file, and kill that connection, but not other SSH
> connections.  (And similar ideas like "Well this SSL stream sure doesn't
> *seem* like HTTP...")
> Nearly all of our tools are, or can be, caught with Pattern Censorship.
>  And it's very important to recognise you can also detect without
> censoring.  "Who in my company is sending PGP emails from work?" "Who in
> the US is using Tor?".  It would be worthwhile to raise the bar for tools
> (i.e. every tool expect Tor's obfsproxies) so that adversaries have to move
> on to Pattern Censorship.  It will be possible of course - it's an arms
> race.  But when we get to pattern censorship, we'll make it harder for them.
>
>
>
> There are other ideas.
>
> Of course there's that whole 'almost none of our tools are usable' problem.
>
> And the 'oh lawd, libpurple and ZRTPCPP are horrible' issue.
>
> You could fund someone to black box reverse engineer closed apps like
> Wickr, Silent Circle, WhatsApp, GoAgent, iMessage, etc - and explain their
> architecture.
>
> Or fund someone to document that which is not-too-documented.  I recently
> read "From a Trickle to a Flood" that is a fantastic summary of Mix Network
> pooling algorithms.  Something similar to that for undocumented things.
>  Something I've been struggling with for a bit is Type I remailer
> instructions, and why they were chosen.
>
> I'm sure most people on this list have half complete

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

[Tom Ritter]

I've been waiting to reply to this until I can give it an hour to get my
thoughts down.  Hopefully it's not too late.  This is a very important
question: where should we spend our time, and our effort?  Because I know
you Moritz, I'm going to stray heavily into the Liberation Tech side of
things, as well as crypto.

Of course my first thought it towards auditing, since it's my day job.
 I've audited many open & closed source projects that were directly
cryptographic or built on top of cryptography, and found critical flaws.
 This is a no-brainer.  And it's valuable. But is it the *most valuable
thing*?  For some apps, yes, for most apps, probably not.

There are a host of hard problems we don't have good solutions to.

For example, so many cryptographic projects are focused on content
confidentiality: PGP Email, OTR, IPSEC, SSL, so on and so forth.  So _few_
are focused on sender and receiver anonymity.  The techniques to achieve
that: onion routing, mixing, anonymous(?) broadcasts, shared mailboxes,
PIR, are so under documented in accessible forms that they're never
considered in new censorship circumvention or anonymity tools.  Research
into these areas, and bringing the content into more accessible forms, with
blog posts, graphics, architecture discussions and designs would be awesome.

Similarly - so many encryption applications are widely distrusted because
they are centrally managed.  Psiphon, Wickr, Silent Circle, Cryptocat,
RedPhone, so on and so forth.  Research and explanations into how to deploy
a centrally managed but untrusted network would be invaluable.  A great
example is Tor's Directory Server design.  Frankly I'm only familiar enough
with it to know its strengths, not its weaknesses - but accessible
explanations into how it works, and how you can design similar things,
would be amazing.  As a very practical example: Mixminion is in desperate
need of a directory service similar to Tor's.  NickM said today "There
isnt' currently actually a design for the distributed directory thing you'd
want. I wrote a draft long ago, but I was even less good at this stuff back
then."  Nick's being quite humble - the skeleton of one is there, and the
learning process of fleshing it out and developing it would be invaluable
for the community.

Another pervasive problem is that virtually all of our tools are detectable
on the wire by a network admin, and classifiable.  I've thought about this,
and broken censorship into a few buckets in my head:
 - Source Censorship: You are censored. You're not allowed to go online.
 (Well crap.)
 - Destination Censorship: No one can talk to this IP, or resolve this
domain name
 - Content Censorship: TCP reset packets that contain the words 'Falun
Gong' OR have a specific byte sequence (like the old Tor SSL handshake)
 - Pattern Censorship: If someone has an SSH tunnel open, and they're
sending significantly more data than they're receiving, they must be
transferring an outgoing file, and kill that connection, but not other SSH
connections.  (And similar ideas like "Well this SSL stream sure doesn't
*seem* like HTTP...")
Nearly all of our tools are, or can be, caught with Pattern Censorship.
 And it's very important to recognise you can also detect without
censoring.  "Who in my company is sending PGP emails from work?" "Who in
the US is using Tor?".  It would be worthwhile to raise the bar for tools
(i.e. every tool expect Tor's obfsproxies) so that adversaries have to move
on to Pattern Censorship.  It will be possible of course - it's an arms
race.  But when we get to pattern censorship, we'll make it harder for them.



There are other ideas.

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

And the 'oh lawd, libpurple and ZRTPCPP are horrible' issue.

You could fund someone to black box reverse engineer closed apps like
Wickr, Silent Circle, WhatsApp, GoAgent, iMessage, etc - and explain their
architecture.

Or fund someone to document that which is not-too-documented.  I recently
read "From a Trickle to a Flood" that is a fantastic summary of Mix Network
pooling algorithms.  Something similar to that for undocumented things.
 Something I've been struggling with for a bit is Type I remailer
instructions, and why they were chosen.

I'm sure most people on this list have half completed drafts of serious
proposals that could really improve things - but need someone to finish the
draft, publish, and potentially write code.  I believe in Academia the term
for such people is 'Grad Students'.  Have people submit their half-written
proposals and fund grad students for them.  I know I'd submit ;)



In conclusion - I would recommend that besides funding individual projects,
you also consider some of the issues that we as a community are lacking
either solid architectures of; or accessible explanations of how to
integrate those architectures into projects.

-tom
___
cryptography mailing list
cryptography@ran

Re: [cryptography] Snowden: Fabricating Digital Keys?

[Jacob Appelbaum]

Cool Hand Luke:
> On 06/28, Nico Williams wrote:
 How would one fabricate a digital key?
> 
>> They probably meant something that sounds close.  E.g., minted a
>> certificate, or a ticket, or token, or whatever the thing is, by
>> subverting an issuing authority or its processes (possibly via social
>> engineering).
> 
> personally, i'm skeptical as to whether it was even necessary for
> snowden to "fabricate digital keys".
> 
>>> He used his root access to get into other people's accounts.
> 
>> Depending on how careless the others are one might not even need root.
>>  It can be very easy to escalate privilege when people are careless.
> 
> many of the documents that have been publicly released thus far have
> been classified at the top secret level. many (if not all) of those were
> also categorized under various special access programs.
> 
> if these top secret documents were being stored in an environment that
> was in compliance with security policies, snowden would not have been
> able to access them (even if he legitimately had root access).
> 
> these files should have been stored on systems with mandatory access
> controls in place and they should have been properly labeled. if they
> had been, he would not have been able to access the files and we would
> not be having this discussion.
> 
> the alternative explanation is that all of these security controls were
> in place and that snowden did, in fact, somehow "fabricate digital keys"
> in order to gain access to the files.
> 
> without serious lapses in security, however, neither should be possible.
> 

How do you suppose those documents were shared with people? Say, the
authors to the recipients? If you have a secure compartment for storing
it, how will it stay secure when you send it to a Congressperson? The
NSA obviously has access to their weakly secured communications links
and probably if they wish, to the systems themselves. I'd guess though
that if Snowden has access to them - other people who wish to have
access may also have these document - too bad none of them seem to care
to educate the public or to expose the incredibly illegal interpretation
of these laws:

  http://www.nytimes.com/2013/06/28/opinion/the-criminal-nsa.html

Snowden himself said that these controls are irrelevant - his leaks are
proof positive of such an assertion. Not only are the ones that protect
systems weak but the ones that protect us, the people, from anyone.
Especially those who would break these policies or who are not subject
to those policies:

"1) More detail on how direct NSA's accesses are is coming, but in
general, the reality is this: if an NSA, FBI, CIA, DIA, etc analyst has
access to query raw SIGINT databases, they can enter and get results for
anything they want. Phone number, email, user id, cell phone handset id
(IMEI), and so on - it's all the same. The restrictions against this are
policy based, not technically based, and can change at any time.
Additionally, audits are cursory, incomplete, and easily fooled by fake
justifications. For at least GCHQ, the number of audited queries is only
5% of those performed.

He clearly doesn't think that privacy by policy is as effective as
privacy by design - where by design, he clearly endorses the use of
cryptography with the caveat that NSA breaks into computer systems:

"Encryption works. Properly implemented strong crypto systems are one of
the few things that you can rely on. Unfortunately, endpoint security is
so terrifically weak that NSA can frequently find ways around it.

The full Q & A is here:


http://www.guardian.co.uk/world/2013/jun/17/edward-snowden-nsa-files-whistleblower

One of the most interesting things to fall out of this entire ordeal is
that we now have a new threat model that regular users will not merely
dismiss as paranoid. They may want to believe it *isn't* true or that
policy has changed to stop these things - there is a lot of wishful
thinking to be sure. Still such users will not however believe
reasonably that everyone in the world follows those policies, even if
their own government may follow those policies.

I've already met a number of people in Europe in the last month who had
a noticeable shift in their perception not only of what is possible but
what is likely happening. After more than a decade of talking with
people about these issues, it is incredible to see this shift happen and
it was nearly over night for some people!

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