In this and two following articles I'd like to take a look at three different areas of personal data storage, how I see a majority of people handling these three issues and what my personal theoretical approaches regarding them is. This is going to be purely about data storage and security, not transport security, which is another topic on its own.
The questions mainly are:
First of all, the three distinctions of data storage I'd like to make, and also how I'm splitting the articles, are the following:
Let's start with email storage. Where are your emails stored? The vast majority of Internet users have an email account with one of the big free email providers or they might have an account that is provided by their Internet Service Provider (ISP). Maybe you even use some shared web hosting somewhere which comes with shared email servers. Whichever of these is the case: your emails are effectively stored with a third party, an ISP that is not you.
Let me ask you this: where is your mail stored? And by mail I actually refer to physical mail: letters. Where are they received? Surely you have a mailbox at your home, or you might have a post-office (PO) box. Most likely you'll be receiving your mail at your mailbox in front of your house and then store it safely inside your home. Would you want your letters to be sent to a third-party that is sending you a copy but also storing all your letters within their own house? Probably not.
I believe we have a major misunderstanding how we are treating Email currently. We are giving away our email data to big companies that make a living with it (among with other services). Always keep in mind that you're most likely not the customer when using a free service, you might be the actual product. If events in the last years regarding the NSA and Edward Snowden have shown us anything, it's that our data stored at big ISPs is most likely easily accessible by governments.
Instead of using such a centralized infrastructure, we should be decentralizing Email in the same way our usual mail system works. When you go back looking at the development of email, it actually was meant to be exactly like that.
My suggestion for email therefore is this:
This just a very brief overview of why I suggest hosting your own email server. There are lots of other things to consider and running an email server is by no means an easy task, I understand that.
As a concluding suggestion, I'd like to introduce the website PRISM Break which lists free and open alternatives for all kinds of proprietary and closed solutions. Specifically for mail servers: PRISM Break Mail Servers
In my next article I'll be taking a look at preference storage, where to save application preferences, what to do with browser syncing and phone syncing.
Since the illegal closure and take-down of Megaupload in January, 2012 people were anxious what might happen with the case and whether a new Megaupload will follow. Kim Dotcom has already announced the relaunch of Megaupload in November, 2012 and an exact year after the raid the new Megaupload now simply called MEGA (MEGA Encrypted Global Access) has launched.
What MEGA supposedly makes different from every other file hosting service such as Dropbox, Google Drive and more is the built in and mandatory end-to-end encryption. A reason for them to implement this is of course so they can have plausible deniability and claim that they have no idea what kind of content is hosted on their service. A side product of that is also privacy for their users hence MEGA also calls itself "The privacy company". Is it really, though?
A quick look at the Security & Privacy page of their Help center shows this:
"All encryption is end-to-end. Data uploaded is encrypted on the uploading device before it is sent out to the Internet, and data downloaded is decrypted only after it has arrived on the downloading device. The client machines are responsible for generating, exchanging and managing the encryption keys. No usable encryption keys ever leave the client computers (with the exception of RSA public keys)." - MEGA Help center
That sounds pretty awesome. Real end-to-end encryption, that seems pretty safe to me. Let's take a closer look. They are kind enough to lay out their exact process with their MEGA API on the developers page. There it reads:
"Each user account uses a symmetric master key to ECB-encrypt all keys of the nodes it keeps in its own trees. This master key is stored on MEGA's servers, encrypted with a hash derived from the user's login password." - MEGA API
Eh? So, the master key is after all stored on MEGA's servers? I'm confused.
"In addition to the symmetric key, each user account has a 2048 bit RSA key pair to securely receive data. Its private component is stored encrypted with the user's symmetric master key." - MEGA API
What? So... the symmetric master key is stored on MEGA's servers albeit "encrypted with a hash derived from the user's login password". Well, they can grab my password every time I log on or simply save it in plain text in the first place. The private component of my RSA key pair is also stored on their servers albeit "encrypted with the user's symmetric master key", where we just stated why that is broken. But wait a minute. Didn't it clearly state "No usable encryption keys ever leave the client computers" in their Help center? Oh, I see. They are encrypted, hence they are obviously not "usable". Yes. That makes sense.
Now to be honest with you, I'm by no means an expert in cryptography nor have I checked any of their source code and what it actually does. But you can all get down to it with a simple assumption and raising one single question.
Let's assume all the encryption and decryption is in fact done on the client side only. How is it possible to simply switch browsers and/or computers and use all of the encryption and decryption functions without transferring any keys between them whatsoever? Because all of your keys are stored on their servers whether they are stored "encrypted with a hash derived from the user's login password" doesn't matter. They are stored there.
That concludes that in theory it is totally possible for them to decrypt all your files, whether they do that or not is up to your belief and imagination, the ability stands.
How does the upcoming case against MEGA look like? Judge: "Is it true that you actually were able to decrypt and read all the files hosted?" - Kim: "Yes, but we never did."
Real end-to-end encryption does not require you to trust the file hosting service. MEGA does.
"The privacy company"
This article is a follow up to Germany's E-Pestbeef. I suggest reading that in case you haven't already.
I found a flyer for Deutsche Post AG's E-Postbrief in my mailbox the other day. I've found some of those there before but always tossed them immediately (with the rest of the advertisement crap I don't need). This time I actually went through it however. The idea was to have a laugh. Instead I ended up raging.
It is just ridiculous what claims they make in there. What upsets me the most is how they try to deceive normal people who have no clue about the matter into registering and using their "secure" system. I will comment on some quotes taken from the flyer. The original quotes are in German and I will include them in brackets after the translated quote. Let's take a look:
"Conventional emails are too insecure - you never know who else might be reading. Michael's solution: the E-Postbrief." ("Einfache E-Mails sind zu unsicher - da weiß man nie, wer alles mitliest. Michaels Lösung: der E-Postbrief.") - Aktuelles zum E-Postbrief 12/2011 page 8
So conventional emails are not as secure as the E-Postbrief. I beg to differ. First of all it depends on how you define "conventional email".
Let's say "conventional email" means unencrypted emails then I'd say conventional emails
and E-Postbrief are pretty much on the same level. Yes, E-Postbrief uses encryption. But what encryption? We
Who encrypted it? Not you.
Update: Actually this wasn't quite correct to prove my point. It's more like: Who decrypts it? Not you, they decrypt it for you on their system.
Meaning: a third party being not you nor the recipient knows how to decrypt the message. Insecure crap.
Let's say "conventional email" means an encrypted email with GPG/PGP. You created your key, the recipient created their key, there is no third party involved. The message has been encrypted with well known and proven security standards.
Which would you choose now? Of course they're not telling you that, though. This is exactly what makes me rage: they're telling people their system is secure and some who don't really know a lot about the matter will believe and trust them. However in reality their system is NOT secure at all. It's a freaking lie.
"Your documents are stored permanently and securely like in a giant safe at www.epost.de." ("Ihre Unterlagen sind bei www.epost.de wie in einem riesigen Safe dauerhaft und sicher abgelegt.") - Aktuelles zum E-Postbrief 12/2011 page 5
Yes, permanently alright. Since once you delete something it actually is not deleted. Securely, huh? Let's see...
"The high quality and security standard of the E-Postbrief platform is even approved and certified by TÜV." ("Der hohe Qualitäts- und Sicherheitsstandard der E-Postbrief-Plattform ist sogar vom TÜV bestätigt und zertifiziert.") - Aktuelles zum E-Postbrief 12/2011 page 5
This one actually makes me laugh and die a bit inside. Security certified by TÜV. Want to know
software that has also been certified by TÜV?
Internet Explorer 8 and Internet Explorer 9 (OMFG, are those spaces in the URL?)
What a guarantee for security and quality! Trollolololol.
DON'T USE THIS SERVICE. I can't say it often enough. It is NOT secure, it is NOT private, it's all a big freaking lie.
Also have a look at this nice list of companies who apparently seem to be as incompetent as Deutsche Post AG (since they are all already using and supporting E-Postbrief).
At least they're maintaining a handy blacklist. Vote with your wallet.
Note: Due to copyright I'm not publishing the whole flyer on here. I have a copy however, in case you want to have a look at it, simply contact me.