

Shut up and ship - jgrahamc
http://blog.jgc.org/2010/08/shut-up-and-ship.html

======
emilsedgh
We are having reports of man-in-the-middle attacks on gmail on some ISP's.
However, main focus of goverment is not spying on people and decrypting stuff,
but to censor opposition websites.

Now, this is much more simple to do. They use l7 to drop https connections.
Some of us who are lucky to have a vps and the simple knowledge of ssh stuff
are able to use simple ssh tunnels.

However, the days in which we had protest, they simply dropped all encrypted
connections, which included ssh tunnels.

I hope that little information gives you a little insight about whats going on
here.

------
moxiemk1
Elliptic curve cryptography? That sounds a bit suspect - if its true, its
_way_ more than is needed, since the Iranian government isn't going to have
the capability of breaking something like 2048bit RSA, or 512bit Public Key.

Elliptic curve cryptography is a very interesting academic subject, but
implementations are slow (so not so hot at being on all of your internet
traffic). Given that its also of ludicrously unnecessary strength, either the
author is misguided or lying.

~~~
briansmith
1\. The NSA says that RSA 2048 should only be used to protect information that
need to remain secret for at most a few years. Nobody should be using RSA 2048
to protect information that could get then jailed/hurt/killed 5 or 10 years
from now.

2\. The main advantage of ECC is that it is generally faster than RSA,
especially for security levels that would require RSA keys larger than 2048
bits.

3\. It is meaningless at this time to say that ECC is unnecessarily strong
compared to RSA. It is possible to match the security of ECC using RSA at
every level. But, a linear increase in ECC key size requires the RSA key size
to increase exponentially. For example, to match the strength of AES-128 you
need a 256-bit ECC key or a 3072-bit RSA key, whereas to match the strength of
AES-256 you need a 384-bit ECC key or a 15,360-bit RSA key.

~~~
lolipop1
Nobody should store information that could get them jailed/hurt/killed 5 or 10
years from now.

------
shin_lao
There is absolutely no relation between the openness of a source code and its
security.

Debian is open source and yet this bug was introduced and nobody made any
remark:

<http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0166>

Windows is closed source and yet security researchers manage to study it and
find security holes.

The reason for that is that you don't really need to the source code to find
security holes, it's better, but it's far from being mandatory.

So what matters?

IMHO, a strong influence on the security of a solution:

\- Awareness (of security issues generally speaking)

which needs...

\- Competence (of the maker(s) and really you don't need the whole world, a
couple of outstanding engineers is enough)

which needs...

\- Solid process (e.g. auditing, tests, validation, management)

which in turns needs...

\- Time

~~~
michael_dorfman
_There is absolutely no relation between the openness of a source code and its
security_

I think that's overstating the case a tad.

Take a look again at JGC's very nice summary of the case in question:

 _Worryingly, Haystack's only 'technical' detail is the following: "We use
state-of-the-art elliptic curve cryptography to ensure that these
communications cannot be read." Fair enough, but frankly that means nothing.
They could be using AES, or RSA, or pretty much any good algorithm and I still
wouldn't care. Two reasons: their implementation might be rubbish and enable
attacks or their cryptography might be irrelevant because another technique
(traffic analysis?) might make breaking Haystack possible. After all, all the
Iranian government needs is a list of people running the software._

In this specific case, having the source open would permit cryptography
researchers (of sufficient skill and aptitude) to analyze whether or not
Haystack is actually doing what it needs to do. Put another way: how do we
know that Haystack isn't including a back door to capture all the information
passing through their system, to sell on to the Iranian government for a hefty
fee? We don't.

I'm not arguing that open source is inherently more secure than closed source;
I'm just saying that in some specific cases, there are clear benefits to
having the source available for inspection.

~~~
jerf
Elaborating on your point further: One of those "a little knowledge is a
dangerous thing" errors that a security dilettante (like me!... though I'm at
least far enough to know about this) can easily make is to assume that because
you're using encryption, you're done. You're secure! Hooray!

But of course it's not that simple. You have to consider your entire attack
surface, and when dealing with a government that doesn't care if it disappears
you for no good reason, there's one hell of an attack surface here. (Note: I
neither know nor for the purposes of this post care if Iran is that cavalier,
what matters is the existence of governments that are, somewhere, sometime,
which I consider pretty likely.) They don't have to prove you've sent
subversive stuff behind that encryption. They don't even have to prove you're
using the subversive software. They just have to _suspect_ it. Even if we
assume the encrypted stuff is perfect, what other tells are there?
Characteristic ports? Characteristic communication patterns? Characteristic
headers? And even quick solutions to those problems, "oh, we make it look like
HTTPS" can have problems of their own, ad infinitum. Are you doing HTTPS to
sites that obviously don't serve a website? Are you trying to fake a website
in a way easy to characterize? What will you do when the ISP straight-out bans
websites on your home computer, making it impossible to mask your traffic that
way? (And how suspicious is it for two home users to hit each other's
"websites" every few seconds, anyhow?)

These are all issues that a government won't have a problem answering, and
there are yet more that they won't have trouble answering. The hostiles here
have it easier because their threshold for deciding they have enough
information to act is very low. The only way anybody should feel even remotely
confident about this is if it is reviewed. (Whereupon it'll probably be
discovered to be impossible, IMHO, but that's for reviewers to figure out.)

------
wallflower
> Ship an open source version of your code and let's take a look at it. Let
> the Iranian government have a look at it.

Skype is famous for being a black box.

<http://www.secdev.org/conf/skype_BHEU06.handout.pdf>

~~~
pi3832
Skype is not promising to protect human rights.

------
dododo
many companies build up the hype before they ship. isn't that just marketing?

i call hypocrisy. jgrahamc is involved with causata: check out their website.

<http://www.causata.com/>

count the number of times you read:

"This has to change. Stay tuned for more details."

where are the products? what have they shipped?

~~~
jgrahamc
Causata shipped our software in January 2010. It's not something you can just
download, but we would be happy to sell it to you.

~~~
dododo
which machine learning algorithms is causata shipping to customers? i could
not find this (nor the fact you were shipping) from the causata website.

you wrote:

Alas, the Haystack web site has zero technical details.

the causata web site appears to be equally placed.

------
konad
On the subject of personal encryption I recently found some interesting
plausible deniability software [1] in Phrack [2] for protection against "give
us the password or you're going to jail" laws

Different passwords decrypt different plaintext from the same cyphertext

[1] <http://www.winstonsmith.info/julia/elettra/> [2]
[http://phrack.org/issues.html?issue=65&id=6#article](http://phrack.org/issues.html?issue=65&id=6#article)

