Rainloop-webmail: PGP Keys gone after restart

[hermann88]

Hello,
when i restart my server all PGP Keys what have been saved before are gone, private as well as public, i need to copy the key each time again to be able to decrypt/encrypt/sign messages.

Please fix, its annoying!
Thanks!

[RainLoop]

PGP Keys are not stored in the server. They are stored in your browser local storage.

[hermann88]

How can i store them in the server, browser local storage get cleared every day.
Server is in private network, doesnt make sense to me to store it in unsafe browser.
Need to copy it than always in clipboard (whats also not safe) to be able to encrypt/decrypt/sign messages.

[programacion-web]

I think the same thing should be an option that let you store it on the server, and allows you to use more of a private key in the event that someone has different identities with the same e-mail account.

[ConnorMcF]

Bump. I think this should be added too!

[cluelessperson]

Yup, I'm running into this too. My personal server is meant to be trusted with the keys. Honestly, I'd be very happy with server side key management and not Javascript.

[ConnorMcF]

So you're not adding it then..

[cluelessperson]

Rainloop PGP is unusable then.

[hermann88]

true!

[janxb]

Very unpolite behavior, just closing all requests while not giving an definite answer..

[hermann88]

true true

[My1]

lol just closing without appropriate reason...

[e-alfred]

This feature is really missing. Currently as it is implemented it is not in any way better than Mailvelope that does it in your browser as an addon, but Mailvelope at least has some good options to manage my keys at least. And it supports encrypted HTML mails as well, something Rainloop misses as well.

Anyway, if the key is password protected, then storing the keys on my own server would be in some way safe. That way I could use Rainloop for PGP encryption on different devices without screwing around with addons on every machine (maybe not even available) and copying around keys.

[sumptum]

Bump!
As others have said, I trust my own server with the keys (far more than another PC's clipboard). As it stands, I'm encrypting my public / private key pairs and carrying them round on a USB, or SSH-ing back to my home PC to check mail - server-side keys would give us a solution for easily sending / opening PGP email via any web browser or mobile device on the fly which would be very useful indeed

[My1]

I agree with @sumptum on a self-managed server, server-side keys are a nice Idea, but the user needs to know whether the key is stored server or client side.

also a benefit of serverside keys is that you dont need some stupid javascript for encryption making this work better with bad connections, because if CSS breaks, it's ugly but it works, but if js breaks, it usually doesnt work and the user cannot even realize that beforehand (you dont even want to know how often I got a broken submit button in forums on my phone just because the js didnt load properly).

[maderluc]

im running a puplic mailserver with rainloop and im not sure if its a good solution to put the privat PGP key of every user onto the server ! what if the server gets hacked! well the private keys are encrypted but stil..... BUT there must be a better way ! i just lost my pgp key because (forgot to backup ) my PC crached!

[e-alfred]

Roundcube in its newest version has exactly this feature. Here is a link to it: https://kolabian.wordpress.com/2015/10/13/enigma-plugin-pgp-encryption/

[esroyo]

I think server side encryption needs a lot of work and is very far from the client-side-js current take in RainLoop. However there could be a third way using remoteStorage.js (they already have a module for pgp).

In that way, the client side javascript would connect to the remote storage server and retrieve the keys to use in the front-end. If you only trust your own server, then you still could install a remoteStorage service in it alongside with RainLoop. It might seem a lot of overhead, but the truth is that it would require minimal changes in the current RainLoop source.

@RainLoop what do you think about this possibility? I'd be interested in coding it for myself.

[e-alfred]

I am running it inside Owncloud as a plugin and it already integrates some things, maybe this could be an approach?

Link here:

https://apps.owncloud.com/content/show.php/RainLoop+Webmail?content=165254

Anyway, the Roundcube plugin relies on GnuPG to do the encryption stuff, which is proven and reliable. If you trust a server to store your keys, you probably can install stuff on it as well. If somebody else manages it, client side encryption using Openpgp.js/Mailvelope is probably a better choice.

[esroyo]

@e-alfred Seems ownCloud doesn't provide support for remoteStorage anymore. Installing as separate service is recommended instead. So it wouldn't make any diff to a regular RainLoop install.

I don't see any excitement around the remoteStorage idea, but still considering it for myself :stuck_out_tongue_closed_eyes:

[dnut]

This is the one big downside in my mind of rainloop compared to roundcube. I don't understand why this would be implemented client side. Private keys can be protected with symmetric encryption. Have all encryption and decryption happen on the client side and save encrypted private keys on the server. The server can never know your private key if it is only decrypted by the client. This is hardly a security risk and would make this feature actually useable, which it currently is not.

[goregrish]

@dnut has hit the nail on the head here, rather than store these keys on the browser there is absolutley no reason these keys can't be encrypted and stored on the server. As it stands, Roundcube now has a better PGP implementation and I'm almost tempted to go back - but its user interface is still stuck in 2006.

[zeigerpuppy]

I agree that for most users storing keys (password protected) on the server will be better than in the browser storage. The expected behaviour when you "import keys" is that they will persist between browsers. Also, it should be explicit that the current mechanism is a risk on a public computer (eg. internet cafe).

[jcgruenhage]

This is really important, although the issue should be renamed ^^

[PoGo606]

The keys should be stored on server side while keeping the operations on client side.
I don't wan't to keep importing them as I delete my cache or switch to a new computer/device.

[zeigerpuppy]

There are trade-offs here. If you store the keys server-side then you need to trust that the server is secure and that they won't hand over your keys to a third party. Really, I wouldn't call that end-to-end encryption any more (more like server-to-end encryption!).
But I agree that for a lot of users having the option of "trust the server" may make workflows easier and perhaps even more secure (is local key storage more secure for most users?). So I think the default behaviour is good but needs to be documented better and an option should be allowed for server-side storage too.
By the way, the main devs have been very quiet lately, do you think this project may be dead?

[dnut]

@zeigerpuppy If keys are encrypted client side before being sent to the server, you don't have to trust the server any more than with the current behavior. Sure, you have to trust that the javascript being run locally doesn't expose your unencrypted key, but that's equally true for any key managing web app, including the current version of RainLoop.

[zeigerpuppy]

I see your point, I guess whenever keys cross the browser divide and are decrypted they could be exfiltrated by rogue javascript.
I agree storing the keys encrypted server-side would be a reasonable compromise as long as decryption happens client side.

[madpsy]

Server side keys are essential for this feature to be of any use at all. Other webmail clients do it and from a security point of view I fail to see any reason why Rainloop shouldn't either.

[jcgruenhage]

@madpsy I'm sure you mean RainLoop and not Roundcube, right? ^^
I totally agree, it is a must have, firefox frequently deletes cookies and then I need to reimport everything, that is not user friendly at all.

[madpsy]

Indeed (corrected). The private key is encrypted by a passphrase so I don't see any implication of storing it server side except of course the chunk of time needed to write the code.

[unic0rn]

security implications. people are unaware of the technicalities. it's basically impossible to generate private key knowing only the public key, and with 4096bit keys it won't be possible anytime soon.

private key password though... if your password has 20-30 characters and some special chars, or is - ideally - entirely random, then yeah, you can consider it safe... to a degree. still, it's called PRIVATE for a reason. you shouldn't share it.

and that rises the question, isn't local storage shared across browsers via sync?

[jcgruenhage]

@unic0rn I use 64 character alphanumeric passwords. That is 64^64 possible passwords. Even an adversary that is able to try out a billion of them per second would take up to a googol years, to try out all of those. Because of them probably finding it after half of the passwords or so, let's say half a googol years. that is still a 5 with 99 zeros after it, longer than the universe existed and probably longer than it will exist. Even for people with less secure passwords, if they are nerdy enough to use gpg, their passwords are probably safe enough, so that they are not cracked faster than the rsa keys they rely on will be by quantum computing.

[unic0rn]

people are lazy, and if you haven't noticed - RainLoop makes it possible for people to start using PGP without knowing a single bit of technicalities, other than "others need my public key, i need theirs". they may be unaware of the existence of key signing, revokation and tons of other things, and you expect them to know the risk of attack on their private key depending on their password complexity?

for the average user the change you're proposing would be dangerous, because the average user of RainLoop probably knows far less about PGP than we do. do you want to sacrifice their security for your own convenience? if so, there's a fork button somewhere around here.

[jcgruenhage]

Well, then tell the average user that using a weak password makes the encryption less efficient and be done with it. The average user won't go through the trouble of externally saving their pgp key and importing it, should firefox screw up the local storage again or something (has happened a few times to me, with different browsers) either, so saving it on the server is still more convenient for them ;)

To be honest though, I couldn't care less, since I only use RainLoop for sieve anymore, since I've moved to using my yubikey for signing/decrypting mails, since RainLoop doesn't support that (yet), see #1257.

[sumptum]

@unic0rn I'd not really considered it from that perspective, and it's definitely good to think of general security for something like this since as you say security shouldn't be sacrificed for the majority for the convenience of a few of us.

The way I see it, a toggleable option in the PGP settings would mitigate any accidental or unwitting reduction in security as 'lazy users' wouldn't be poking around and it could be off by default. In fact that raises an interesting question - how does the average Rainloop user transfer their keys at the moment? They probably put them on a USB or cloud storage or... Something. I guess some people use encrypted containers and volatile browser sessions but for most, especially those who don't know as much about PGP but are starting to use it, I would expect there's already several vulnerabilities where private key management is concerned. I think that server side key storage would aid in reducing the number of points at which keys can be intercepted, especially if the keys are encrypted at rest and in transit, and the feature only available over SSL (like key generation is, if I remember correctly). Perhaps a password manager like LastPass is a good solution, but then it would need to be installed on every computer and mobile device, which sort of defeats the purpose of an available-anywhere webmail client.

You're right saying a password is easier to brute force, but a feature like this isn't intended to make private keys publicly accessible and brute force-able, quite the opposite. Unless the server hosts were evil... in which case fair enough, but maybe hide the switch behind a lot of warnings and advice on choosing a secure hosting solution :)

[unic0rn]

from what i've noticed, devs here are against adding new options in general, unless unavoidable, probably to avoid confusion for end users. it's supposed to be simple.

so the most likely assumption is that end user won't understand a word from the explanation about server security, secret key security and so on. they may copy them to a text file - i suppose that's the most likely scenario. i'm not sure about things like chrome sync - if chrome syncs that local storage (depends on RainLoop, or at least it should), then that's a possible issue - depending how much you trust google and their sync data encryption, assuming you've used that.

also, i'm not saying storing keys on a RainLoop server is a bad idea - but it should be done in the most secure way possible. so the question should be, what's the best way to encrypt those keys so they'll be basically untouchable, without complicating things for the end user. some custom encryption linked to the 2FA and keys stored on the server with a timestamp? should be possible.

[jcgruenhage]

Also, just to be clear, if you don't trust the server, you can't trust rainloop anyway, since they could just send you malicious javascript that sends them the decrypted pgp key ;)

[unic0rn]

if the admin screws up permissions, someone could get the keys without having write access to the RainLoop folder. not in the same ballpark.

secret keys are secret, period.

[jcgruenhage]

They could get read access to encrypted keys ;)
The secret keys are still secret, period.

[unic0rn]

instead of trolling, focus on finding a reasonable solution to the problem - how should those keys be encrypted. you were the one talking about trusting the server, so i've pointed out it's not all black and white when it comes to server-side security. it's obvious that when you can't trust the admin, using the server is pointless - but there are other scenarios as the one i've shown.

in the end, it's a matter of "how secure are my keys" - you're not supposed to put them in places that aren't under your own control, so to do so, they have to be encrypted.

[jcgruenhage]

Damn, I was sure it was you who is trolling :rofl:

The thing is, as long as you use reasonably secure password, storing the key on the server is perfectly fine. And the question, how the keys should be encrypted, is already solved by pgp, because the keys already are encrypted when putting a passphrase on them. Preventing people from using weak passwords would be possible by analyzing the password they entered before sending the key to the server, and requiring them to enter a stronger password.

Just as a question, do you now keybase.io? Their model for easy crypto using pgp involves storing the private key on their server ;)

[sumptum]

It couldn't hurt to encrypt them again, although they are already encrypted. Two strong unique passwords would help protect everything. I think ultimately a password is the best kind of security you can have in this scenario, but increasing the number of them (one for a key container, one on the private key already) and the cost for the function (I don't mind waiting 20s or so to decrypt it) would keep things secure. Even considering Moore's Law and the top500 computers working together, a 30+ character alphanumeric password with symbols and both cases would take over a century to crack. Tag on a second equally strong password and you're looking at nearly three centuries

[madpsy]

Another option is to use something like Mailvelope (https://www.mailvelope.com/en/) therefore keeping the key on the client but in a more persistent state than browser cache.

For server side, as has been discussed over and over again, a passphrase should suffice. If a user is choosing to use PGP they should have the common sense to realise a strong passphrase is important. If they don't then unlucky for them.

[jcgruenhage]

About keeping it client side, but persistent, using the installed gpg binary, if available not only enables yubikeys and such, but also protects the user from rogue javascript and keeps the keys more persistent than in the browser cache.

[jeaye]

I'd put my vote in for passphrase-protected server-side keys, please! I had just setup RainLoop up, for my wife (who uses it on mobile and desktop), and I'm awfully bummed that I can't have her easily use PGP in a portable manner.

[e-alfred]

To make it more secure access to the keys on the server could be secured with 2FA, for example. That would make it harder for if an attacker only knows the password.

Additionally, a notification could be shown if somebody tried to access the keys from a previously unknown location with detailed information like IP, country, browser UA and so on.

[soxhi8]

Anything new to this? I have got a server with not many users and would like to use it as a portable pgp-solution, to not store my secret keys on my vulnerable minor devices. Storing them in one, well secured place is much safer than spreading the keys across all my devices.

[jcgruenhage]

Well, they will need to be cached on your devices..

[soxhi8]

Well, you name the problem right there.

[Jaxom99]

Have you guys seen this plugin ? https://github.com/chtixof/pgpback_ynh
It might be a working solution for this use-case, so I reference it just in case.

[janemba]

Hi,

Well, I'm using multiple browsers on multiple machines so PGP is a problem. The fact is developers are right. Private keys should be private and not stored at server-side. But, that functionality exists and it is named HSM. But that's not what we want.

I think the main issue is the use of a webmail with a component that can't be shared. You can use a webmail anywhere at any time with any devices connected to internet. So to make it easy to use PGP, people tend to think to online stuff. Solution like Enigmail plugin for Thunderbird is ideal as usually that mail client is installed on your main workstations/laptops so you can store your keys at client-side.

So, what kind of solution respect the usage of PGP (private storage for private key) and allow an easy use of it with all connected devices ?

• For people owning a private cloud, we can easily think of a storage using HTTP(S) protocol (so it can be used with a web server) so the private key is accessible through a link. I'm thinking of this setting as per-user only. I mean each user as its own link.
• Using an external device like a USB key. However, we can say bye bye to mobile.
• Reading the private keys through a QR-Code. This means you have to copy that QR-code in all your devices. Well, a file is a file so why not copy the private key directly ? Well, ...

That's the only idea I got and maybe they are all wrong but finding a solution for storing stuff at client-side and make it accessible for multiple devices is not an easy task.

Jaxom99
Have you guys seen this plugin ? https://github.com/chtixof/pgpback_ynh
It might be a working solution for this use-case, so I reference it just in case.

There is no explanation about how it works. And it seems we need to install their YunoHost stuff.

Cheers

[qirtaiba]

You don't need to say bye bye to mobile if you use a Yubikey to store the key. Besides its USB interface Yubikey has RFC and works with mobile. This is supported by OpenKeychain on Android.

[soxhi8]

As much as I would like to, most of my users don't even know the term Yubikey.
​​​​​​​They need a simple, yet encrypted, better than nothing solution, not an industrial standard. Would use different software, if that standard was needed.

[goregrish]

yubikey is totally irrelevant to this script , the solution is not another
service on top of a service.

On 17 Oct. 2017 3:15 am, "Keksdose" [e-mail] wrote:

As much as I would like to, most of my users don't even know the term
Yubikey.
​​​​​​​They need a simple, yet encrypted, better than nothing solution,
not an industrial standard. Would use different software, if that standard
was needed.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/RainLoop/rainloop-webmail/issues/349#issuecomment-336938116,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAL0FByu3P94MI1DVOnygxI6eJRmgk3uks5ss4EygaJpZM4Ctan6
.

[e-alfred]

Yubikey has its issues with PGP as well:

https://www.yubico.com/2017/10/infineon-rsa-key-generation-issue/

[Luticus]

Why don't we just use encrypted private keys with a password unlock? This way the key can be stored on the server and cannot be used until the password is entered by the user. I think that's a better idea than people using unencrypted email because it is way too aggravating to have different email messages only able to be opened on certain devices! Or worse, users start emailing their private keys to themselves to try and get their keys installed on all their devices. This is literally why I don't use PGP in my email, which is completely frustrating because I absolutely want to. The whole idea behind a web client is that it can be used no matter what device you're on! Why then would we limit that by making it frustratingly difficult to use it on more than one device? This is the single "must fix" feature in Rainloop. Also it would be super nice if the client finally supported S/MIME and MIME attachment style PGP.

[Leopere]

@RainLoop You can use PBKDF2 to store the keys encrypted by the user's password at login. It's what most cloud-based password managers use to save your passwords in the cloud so why not use it to store your GPG keys. This way RainLoop can assert that only the person who owns that account has rights to the GPG keys.

You might have to do some fan-dangling if the endpoint account associated with the RainLoop account has changed its password upstream but you could just add a function to log into the PBKDF2 container and update the password.

Part of the only reason I was interested in RainLoop was the fact that I could have a webmail that I didn't have to worry about having to carry my GPG keys everywhere. If I'd have known this isn't something supported by RainLoop I probably wouldn't have gone into this whole endeavor. This thing basically being completely incompatible with Incognito mode is kind of a pain.

Hell even with PBKDF2 you could technically mimic the functionality of ProtonMail wherein you could encrypt emails that are outgoing to other people in a way where they could grab the email's contents from RainLoop maybe somehow using a pre-shared password.

[Rudi9719]

Just found out about this (I'm gonna call it a bug) bug today. My job was trying to implement Rainloop as our webmail, and we use PGP. Public PGP keys are just that, public. They should be safe to store server-side. Private PGP keys, I understand. However as they're armoured I no longer understand why they shouldn't/aren't stored server side. Has there been any updates on this bug now, in 2019?

[Leopere]

@Rudi9719

The last time I brought this up with anyone they said, GPG keys shouldn't be stored serverside. However, Protonmail does this just fine they just use zero-knowledge encrypted containers. The place this gets complex is when the user wants to change their GPG passwords you'd have to create a client-side method for changing not only the GPG key security but also change the PBKDF2 container to reflect the password changes.

https://en.wikipedia.org/wiki/List_of_PBKDF2_implementations

[Rudi9719]

@Leopere is Protonmail available within nextcloud? We use a Univention Domain, and chose Rainloop as we are able to install it right inside of our NextCloud container.

[Leopere]

Sorry @Rudi9719 I wasn't suggesting Protonmail is something you can self host unfortunately its entirely a closed source gmail alternative where they host everything however they do support GPG etc.