> Hi I spotted this project: https://www.own-mailbox.com/#HowWork
Looking over their FAQ, I found this entry which makes me doubt them
even further. It downright deserves a fisking, which I'll deliver inline.
"Q: Why shouldn't I trust any cloud email service with JavaScript
encryption on the client-side ?
A: These services cannot be trusted, because they still give power to
companies to spy on you.
Why is it not secure?
1-Encryption is done in JavaScript, and therefore relies on your
browser's JavaScript engines, which 80% of the time are proprietary
software coming from Google, Microsoft, Apple, and most eminent NSA
collaborators."
Nice allegation there about Google, Microsoft, and
Apple all being NSA collaborators. It's pretty
strange, though, that *all of these* companies are
currently pushing crypto in a big way, to the point
that the USG is currently pushing for legislation
requiring back-doors into crypto... why, it's almost
as if they're not collaborating at all, and are
responding to what they see as overreaching government
practices by introducing technologies to make those
overreaches more difficult.
Second, these guys are flat factually wrong about
JavaScript engines. Internet Explorer's Chakra engine
is proprietary code. Apple Safari's Nitro engine,
Mozilla Firefox's Spidermonkey engine, and Google
Chrome's V8 engine (also used in Chromium) are all
open-source. Let me repeat that: the *only* proprietary
JavaScript engine in common use today is in Internet
Explorer.
"It leaves 4% chances that both you and your correspondent don't use any
of them, (because even if you don't use them, your correspondent might,
and he would compromise your security). Using these browsers for
cryptography, even once, leaves these companies full power to forever
break your cryptography."
Cryptography is not like virginity, where once you
lose it it's gone forever. I have a hard time believing
that anyone could believe this crap -- I've had boxes
compromised before, and guess what, I wasn't "forever"
compromised. Talk about how "using these browsers for
cryptography, even once, leaves these companies full
power to forever break your cryptography" is scaremongering,
plain and simple, full stop.
Somebody really ought to write a FAQ entry about
scaremongerers.
https://www.gnupg.org/faq/gnupg-faq.html#fraudsters
"By extension any cryptography done on a proprietary operating system
like Mac or Windows can be considered as doomed, since Microsoft and
Apple can then access your keys."
"Doomed" is such a scaremongering word. It may be unwise,
but it's certainly not *doomed*. Further, where is there
any evidence that Microsoft or Apple has ever turned over
a user's encryption keys? Has this ever happened? Do they
even have that capability? Or is the author just trying to
scare you?
"2-The JavaScript code may be changed at any time by the email service
provider. So except if you check the JavaScript code sent to you each
time before entering your password (which is impracticable), you leave
the email service provider open to breaking your cryptography at any
time they want, without you even necessarily knowing it (since you don't
check it)."
Mostly true.
"3-These services don't and cannot have a strong private key encryption.
They rely on a much weaker private password that can be remembered by a
human being. Therefore, they either use a much weaker algorithm than
openPGP, or they use openPGP but store YOUR private key on THEIR
servers, in clear form or encrypted with a simple password. In the movie
citizenfour, Edward Snowden quoted saying "A 10 character password can
be broken by the NSA in few days". So in practice, using a simple
password for encryption make those services easily breakable. In
comparison GPG was initially designed to work with 2048 or 4096 bits
long private keys. GPG and SSL use this kind of strong private key
encryption, as simple passwords are too weak and can be easily broken."
This one makes my head hurt. Yes, a 10-character passphrase
can be broken in a few days. It can probably be broken in a
few *milliseconds*. Rainbow tables are awesome and there's
not enough entropy in a 10-character passphrase to really do
the trick. But that's why we recommend longer passphrases
with higher entropy. My Google login, for instance, is
literally 128 bits of random noise put into Base64.
Second, they seem to be completely missing the distinction
between the length of an asymmetric key and the entropy of
that asymmetric key. My 128-bit Google passphrase, which I've
committed to memory and have no trouble inputting by hand,
is about as hard to break as a 3072-bit RSA key.
Should you use short passphrases on sites that you care about?
Absolutely not. But it's just *flat* *wrong* to say that web
services don't and cannot use strong encryption.
"4-If you want to access your emails on computers that are not yours (at
the library, at work, at a printing store), you have to do cryptography
on their computer, and therefore you're never really sure that you don't
compromise your whole cryptographic system, you are effectively giving
the power to the computer's owner to break it."
And how is this cured, *in any way*, by using a stranger's
computer to access your email over HTTPS? That stranger could
store a local copy of your email, your keystrokes into the
terminal for your passphrase, etc...
"5- It is controversial whether JavaScript as a language, is actually
able to perform good quality encryption at all."
Dunno. I'm a pretty sharp guy but I'm not qualified to
have an opinion on this one. This puts me slightly ahead
of these guys, who appear just as unqualified but don't
know it.
I'm friends with Dr. Terri Oda, whose Ph.D. research was in
JavaScript security. I'll ask her what she thinks. If she
tells me that these guys are champs and I'm completely in
the wrong, y'all have my word I'll come clean.
"This is not only theoritical. The company hushmail, providing an email
service with java/javascript client-side encryption, has allready spied
on its users. [3]. If they could do it and did it, how do you know other
companies won't?"
Hushmail was ordered by a court to cooperate with an
investigation. In order to make things easier for users,
they allowed users to do crypto *server-side*. They advised
users this was less secure. People still did it anyway,
because convenience is more important to most people than
security. Hushmail was ordered to compromise their
*server-side* crypto for a small number of users in order
to cooperate with a legitimate Canadian investigation.
Remember what this FAQ question is about? "Why shouldn't
I trust any cloud email service with JavaScript encryption
on the client-side?"
Why would someone present an instance of a company compromising
*server-side* encryption as an argument against trusting
*client-side* encryption?
The only reason I can think of is to scare you.
"To conclude, it should be said that a broken cryptography implies not
only that your future emails can be watched, but also that all your past
emails can also retroactively be read by spies."
This is true for OpenPGP. This isn't true for any system that
employs, e.g., perfect forward secrecy. Break a message in
a system that employs PFS and you can neither read previous
traffic nor future traffic.
"Also you should not forget how aggressive the attempts are to break
cryptography. There have been several attempts from the US government in
the past to add flaws in the Linux kernel, in order to break
cryptography [4]. So it is very dangerous to leave that many security
holes opened, which are easy ways for NSA and other organizations to
break in."
All this obsession with the NSA. One wonders if they think
the Chinese Ministry of State Security is any less aggressive,
or any less of a threat. Obsessing on one three-letter agency
to the omission of all others is a sign of someone who has not
done a very good job of thinking through the problem.
Sometime, ask the kernel.org guys who they think was
responsible for the big intrusion back in 2012-2013, and what
they think the goal was. I'm not at liberty to say, since it
was told to me in a personal conversation, but I will say it
wasn't American in origin...
_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
