Own Mail: PGP running on local server; Is it secure

[Robert J. Hansen]

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