Riseup moves to encrypted email in response to legal requests
riseup.net
riseup.net
[1] https://www.eff.org/deeplinks/2015/01/security-not-crime-unl...
How it works:
1. On IMAP log in, the user's cleartext password is passed to the plugin.
2. The plugin creates an argon2 digest from the password.
3. This password digest is used as a symmetric secret to decrypt a libsodium secretbox.
4. Inside the secretbox is stored a Curve25519 private key.
5. The Curve25519 private key is used to decrypt each individual message, using lidsodium sealed boxes.
6. New mail is encrypted as it arrives using the Curve25519 public key.
https://0xacab.org/riseuplabs/trees
If someone would briefly describe argon2 and libsodium to the non-crypto geeks, it would be appreciated.
Argon2 was the winner of a password hashing competition. An effective password hasher "stretches" the entropy of the password. In other words, it maps the space P of passwords to K of keys in such a way that guessing a key requires painful testing of every p. Since |P| << |K|, you need to make sure there aren't tricks whereby you can figure out subsets of K that are interesting and skip the expensive computation. You also need to make sure that hashing is expensive; that there are no shortcuts to blaze through all passwords. (Plus a myriad other concerns, including safely running the algorithm without outsiders being able to figure out the passwords based on timing and such)
So now you can take a password, make a key, and encrypt stuff. Guessing the key is hard because trying each password is expensive, and there are too many keys to check them all.
Libsodium is a crypto library that simplifies crypto down to "symmetric encryption" or "public key encryption" no mucking around with algorithm and parameter choices, constant time compares, etc.
So here your password is securely translated into a private key, whose public key pair they use to encrypt everything as it comes in. The middle step is necessary because argon2 stretches passwords into symmetric keys, but you want an assymetric key pair. So you generate a random key pair and encrypt the private key with your argon2 provided key
a "going forward" request could start capturing the incoming mail. But yeah reading the how it works section I can not see why they couldn't be compelled to decrypt on next login.
Riseup do say:-
> To be absolutely clear, this type of encryption is not end-to-end message encryption. With Riseup’s new system, you still put faith in the server while you are logged in. For full end-to-end email encryption, as before, you must use a client that supports OpenPGP (and is not web-based).
> We are working to roll out a more comprehensive end-to-end system in the coming year, but until that is ready, we are deploying personally encrypted storage in the mean time.
> NOTE: the database MUST NOT store the argon2 digest, since this value is the secret key that unlocks locked_secretbox. This is very different than how password hashing for authentication works, where the digest and parameters are stored.
So they are storing the locked secretbox on the server which contains the key to decrypt so they can send you the decrypted messages after login. Encrypting the whole message means that the contents and the meta data is secure at rest. If BringYourOwnLawEnforcement came by and imaged the storage without the argon2 digest the messages are useless.
But if Riseup were pushed to so then during the users next login the digest could be stored (Breaking the "MUST NOT" rule) when created and then handed over to BringYourOwnLawEnforcement which could then then be used to decrypt the messages as received by dovecot.
Now if the contents of those messages where also encrypted with say PGP when BYOLE wouldn't be able to read the message (unless they could break a weak PGP key, had a copy of the PGP Private key too) but they would still get the metadata that comes along with the message. (Time, Date, Sender, etc, etc).
People check their email often, so maybe this is why they are writing
> this type of encryption is not end-to-end message encryption. With Riseup’s new system, you still put faith in the server while you are logged in
The message should be "if you think you're under investigation, abandon your email and don't login anymore."
Another attack is with the received messages: I assume they are all cleartext and can be intercepted before they are encrypted at step 6, with or without the cooperation of Riseup. Messages in a conversation often integrally quote all the previous messages so there might even be no need to force Riseup decrypt anything at step 5.
They won't get access to past mail until the user next logs in but would least get access to any future mail the account receives and you are not in control of any email being received.
How does that not translate into people who are concerned about investigations simply not using Riseup (at least, for email)?
It doesn't seem particularly likely that every member of a group of people will find out about the investigation before any damage is done and then also follow through abandoning their accounts with perfect discipline.
In particular, what you are talking about is a Title III Wiretap (in transit) order with an additional element of technical assistance that requires significant re-architecture that would expose massive take, or enforced lying (endorse a false cert). This would put a huge burden on Riseup, and significantly undermine their operation. A Title III Wiretap order can only be done in very specific cases, it is much harder to obtain one of these than it is for a simple search warrant, or subponea. In fact its so difficult, that in 2015 Google received 15 wiretap orders in total and more thaan 8k search warrants. Not only that, but the government must show they can do data minimization and there is a notification requirement (unlike a search warrant) where they notify the target after 90 days. The tighter particularity requirements built into the statute make this a very good position for Riseup to be in.
> there is no case where the government has pressed the issue about modifying systems
Do we know that, or would it be more accurate to say 'there is no case that we know of'? And we do have some reason to believe that the U.S. government has pressured large telcos to modify equipment; look up Qwest's story.
Modern low-level primitives for encryption and signing.
You can build something like OpenSSL and PGP on top of it, or what's described in your post.
For anything serious it seem inadequate unless I'm missing something.
How is it even better that something like proton mal?
I'm not convinced this change alters that assessment, as the implementation seems questionable (the secret exchange seems to be on the wrong side of the connection). But maybe I just misunderstand it.
Now it turned out that the warrant was just for some malware-extortion ring, not due to a crackdown on political dissidents, so arguably a "false positive" from the perspective of what most people using riseup for its stated purpose care about. But the warrant canary didn't claim to make those kinds of fine-grained distinctions in the first place. It claimed that it would let you know when there was an unannounced warrant, and it succeeded in doing so.
Except that now that it's gone there's nothing to say that people who were previously held at bay by the canary [side note: hah] moved in right after it disappeared.
Thus I agree; a WC should be seen as nothing more than a "probably not" to a "maybe/assume so".
Riseup's response to questioning about failure to update the canary was:
listen to the hummingbird, whose wings you cannot see,
listen to the hummingbird, don't listen to me. #LeonardCohen
They were subject to a bloody gag order.
It certainly makes sense now, doesn't it?
> There was a “gag order” that prevented us from disclosing even the existence of these warrants until now. This was also the reason why we could not update our “Canary”
Seems the exact purpose it was intended for. And they discuss at length why that canary was too broad and how the new one is better.