The german e-mail hoster web.de offers PGP encryption with Mailvelope now.

To transfer your private key to another browser, you can use a 21 characters long recover key.

How does this affect the security value of the service?


As I understand it, the user has a sensitive secret (his PGP key) in his browser. The server maintains a "recovery mode" in which a copy of the said secret can be recovered in case the browser becomes unavailable (e.g. the user switched to another kind of browser, or to another device), but subject to a "recovery key". IF I offered a service of that kind, then I would store the secret S encrypted (symmetrically) with a user-specific key K, and that key K would be the "recovery key", known to the user, but not to me.

A 21-character "recovery key" is enough to encode about 126 key bits, using Base64, and 126 key bits are largely enough to ensure security for symmetric encryption.

This does not say how the processing is implemented: if the decryption is performed on the hoster's server, or is done with Javascript code freshly obtained from the hoster's server, then the hoster can, technically, plunder keys during the recovery operation (the plundering will be a lot more discreet if the decryption occurs on the hoster's server). Whether the symmetric encryption is done properly is also an open question.

Thus, one can say that a 21-character recovery key does not necessarily imply a reduction or breach in the security model -- provided that it is used correctly.


Disclosure: Mailvelope developer. The original question speaks of a 21 character recovery key, which is not correct. Mailvelope generates client-side a 26 character long string based on cryptographically random values from window.crypto.getRandomValues(). OpenPGP's Iterated and Salted S2K is then used to derive a key for AES-256.

Encryption and decryption of the recovery packet is only done inside the Mailvelope browser extension, which is statically installed and independent of the hoster's server.

For the symmetric encryption Mailvelope relies on the implementation in OpenPGP.js. The output is compatible to what you get with the --symmetric option in GPG.


The existence of the "recovery key" is likely to be a fatal flaw in the encryption scheme. While a 21 character password is enough storage for a sufficient amount of entropy, users are unlikely to generate enough entropy to provide adequate security. This has been demonstrated time and time again through password crackers that do offline attacks on users passwords.

The vast majority of users don't understand that an offline attacker can (depending on the implementation of key stretching) guess thousands or potentially millions of guesses per second. An attack like this would need to first gain access to the recovery key, though means such as court order or a security vulnerability.

  • If the recover key is generated by the app then it may have sufficient entropy. – Neil Smithline Sep 8 '15 at 22:27
  • Actually in browsers you certainly have enough entropy and as the recovery key is chosen randomly you cannot compare this to most password crack attacks, where the user imagines a password on their own. – rugk Jan 6 '16 at 19:32
  • @rugk Be very careful about the RNG quality of javascript in a browser. It's been long understood to not provide the entropy it's designed to provide. – Steve Sether Jan 6 '16 at 21:26
  • Obviously you should use a cryptographically-secure RNG. And with the Web crypto api you also can do this. In Mailvelope e.g. RandomSource.getRandomValues is used according to the answer of the developer (@toberndo). If you implement it correctly there is enough entropy. – rugk Jan 6 '16 at 22:08
  • @rugk I don't think it's obvious to everyone that browsers don't come with crytographically secure RNGs. It's great you already know this, but a lot of people don't. – Steve Sether Jan 6 '16 at 22:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.