After Lavabit Shut-Down, Dotcom's Mega Promises Secure Mail

Lavabit may no longer be an option, but recent events have driven interest in email and other ways to communicate without exposing quite so much, quite so fast, to organizations like the NSA (and DEA, and other agencies). Kim Dotcom as usual enjoys filling the spotlight, when it comes to shuttling bits around in ways that don't please the U.S. government, and Dotcom's privacy-oriented Mega has disclosed plans to serve as an email provider with an emphasis on encryption. ZDNet features an interview with Mega's CEO Vikram Kumar about the complications of keeping email relatively secure; it's not so much the encryption itself, as keeping bits encrypted while still providing the kind of features that users have come to expect from modern webmail providers like Gmail: "'The biggest tech hurdle is providing email functionality that people expect, such as searching emails, that are trivial to provide if emails are stored in plain text (or available in plain text) on the server side,' Kumar said. 'If all the server can see is encrypted text, as is the case with true end-to-end encryption, then all the functionality has to be built client side. [That’s] not quite impossible but very, very hard. That’s why even Silent Circle didn’t go there.'"

Comments

We require a new encryption scheme

[Anonymous Coward]

The problem is that private key, in server solution, are available on the server. Even in Mega, the private key is located server side and the password/passphrase is supplied by the end user over SSL. So, the weakpoints are SSL and the domestic machine, as well as an intercept placed on a server at Mega.

What we require is a private key that a person hold, on a smartcard type arrangement. From this we derive a personal certificate authority and a public key. We issue certificates through our personal CA for particular roles and upload them to our provider. This then acts as our transport encryption, digital signatures, email encryption and so forth. The private key never enters the network and everyone has a unique encrypted layer, rather than a common SSL certificate.

Decryption is performed by streaming the contents through the smartcard. We can add additional factors to this authentication such as biometrics, pin, etc. In fact, the user should be able to determine the amount of factors, their order, etc. The decrypted output can either be sent back into the machine (if you feel it is secure), or forwarded to a secure offline machine.

We only need to make sure that this forwarding eliminates the possibility of an exploit and that means a limited stack that only provides certain features. Such as text and/or video.

There is no reason that a standard mobile phone could not have two physical portions, one connected to the web and another for secure comms.