Boston Linux & UNIX was originally founded in 1994 as part of The Boston Computer Society. We meet on the third Wednesday of each month at the Massachusetts Institute of Technology, in Building E51.

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] Secure Email



> From: Discuss [mailto:discuss-bounces+blu=nedharvey.com at blu.org] On
> Behalf Of Greg Rundlett (freephile)
> 
> I'm considering email service* for my domain and wonder if anyone has
> experience with Hushmail, S-Mail or Kolab Now?
> 
>    - http://www.s-mail.com/inf/1/users.shtml.en
>    - https://www.hushmail.com/hushmail-business/
>    - https://kolabnow.com/moving
> 
> *Of course Lavabit is defunct.  Because government spies.
> http://lavabit.com/

So ... This is what I do for a living, except we do file sharing service instead of email. https://conceptblossom.com So we compete against dropbox, not against gmail. End result: I do a lot of analysis on cryptographic soundness of design of tools and services.

The problem with lavabit was, user information existed temporarily decrypted in server memory. This means Ladar *could* access that data, although he didn't - but it also meant that he was *obligated* upon request. He counts as a 3rd party under 3rd party doctrine, and that's what killed lavabit.

The *only* way to have security/privacy is to *never* under any circumstance disclose the data, password, or encryption keys to *any* 3rd party, and that includes the service providers themselves.

If you read Concept Blossom's tech details, we're using CBCrypt, which allows authentication, and encryption, to both be done using the same password, while neither the password nor encryption keys are exposed to the server.

Lastpass uses pbkdf2 to derive an encryption key client-side. They use a hash of the key for authentication to their servers. So again, the password and encryption keys are not exposed to the servers.

Point being, YES it's possible to get this right. And NO, most of the time it's not.

You may be familiar with spideroak's "zero knowledge" catch phrase, but if you read their Engineering page, they say "Important Note: When accessing your data via the SpiderOak website or a mobile device, you must enter your password which will then exist in the SpiderOak server memory for the duration of your browsing session. [...] The moment your browsing session ends your password is destroyed and no further trace is left." This means they are actively advertising themselves as being absolutely private, and it's an absolute crock. In reality, they suffer the same flaw as lavabit. But that's just a tangential example, because they're about file sharing rather than email.

Getting back to email: hushmail says "When one Hushmail user sends an email to another Hushmail user, the body and attachments of that email are kept on our server in encrypted form, and under normal circumstances, we would have no access to that data. We can't just pick an arbitrary encrypted email message off the server and read it. An encrypted email message cannot be decrypted without the passphrase, and in the normal course of operations, we do not store passphrases. However, we may be required to store a passphrase for an account identified in an order enforceable in British Columbia, Canada."

This means they're in the same category with lavabit and spideroak.

If you want to find a secure private service, you have to be *absolutely* sure that all the encryption is done client-side, using keys or a password that are never exposed to the SSL/TLS channel, or the server.

s-mail says they're using key sizes *up* *to* 1024 bits, which is not considered strong enough for present day usage. Realistically, however, that cryptographic strength *might* be strong enough to keep people out. It definitely *won't* keep out a government agency, but might be good enough for common purposes. But I can't find anything on their site that says if your password or private key is ever exposed to their server. So I would have to assume it is. The base assumption is that s-mail is in the same category with lavabit, spideroak, hushmail, and now s-mail.

Kolab's security page basically says "We're in Switzerland!"  Hooray! Doesn't seem to give us any clues about encryption or anything. Base assumption then, is that they're the same as the others. Because if they *weren't* you can bet your sweet buns they'd make noise about it and tell us how they're differentiated. As conceptblossom and lastpass do.

I'll add one more to your list:  Protonmail.

I haven't had the opportunity to dig into details yet myself, but they say everything is encrypted client-side in your browser, using keys that are never exposed to the server. I read a review somewhere that said you need two different passwords - one to login, and one to encrypt/decrypt. So it seems your login password is probably exposed to their servers, but the second password should provide security.



BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org