[liberationtech] Mailvelope: OpenPGP Encryption for Webmail

[Robbie MacKay]

"1. Mailvelope appears to use its own keystore (at least on Windows), and
not the
   GPG keystore.  Specifically, it doesn't use the GPG4Win keystore, which
is
   the one I'd expect it to use."

In some ways this is great: it means novice users don't have to worry about
getting GPG4Win or any other keystore installed first. Simplifying
encryption for end users is definitely better, though I can't speak to the
quality of their implementation. For those of us who already have a GPG
keystore set up (and existing keys) I'd definitely rather it used those.

On Tue, Dec 11, 2012 at 9:16 AM, Nick Daly <nick.m.daly at gmail.com> wrote:

> On Mon, Dec 10, 2012 at 1:42 PM, Fabio Pietrosanti (naif)
> <lists at infosecurity.ch> wrote:
> > Hi all,
> >
> > for whose who has still not see that project, i wanted to send a notice
> > about MailVelope, OpenPGP encryption for webmail:
> http://www.mailvelope.com
> >
> > It's a client-side, plug-in based (similar to CryptoCat), OpenPGP email
> > encryption plugin available for Chrome and Firefox.
> >
> > Source code is available under AGPL on
> > https://github.com/toberndo/mailvelope .
> >
> > Does anyone ever security reviewed it?
> > --
> > Unsubscribe, change to digest, or change password at:
> https://mailman.stanford.edu/mailman/listinfo/liberationtech
>
> This (could finally be) email encryption done right: encryption is
> performed on the user's browser, so that the server storing the
> communication never sees the contents of the message.
>
> However, after installing it on Chrome, I have a few concerns:
>
> 1. Mailvelope appears to use its own keystore (at least on Windows), and
> not the
>    GPG keystore.  Specifically, it doesn't use the GPG4Win keystore, which
> is
>    the one I'd expect it to use.
>
> 2. When creating a new PGP key in Mailvelope, it has some pretty poor
> defaults.
>
>    A. Keys are set to 1024 bits, instead of 2048 (or 4096).  Anything
>       under 2048 is probably insufficient.
>
>    B. Keys are set to never expire, and that can't be configured.
>       Different keys should be used for different purposes and should
>       expire differently.  It's not a bad idea to cause email-signing
>       keys to expire after 3 - 5 years.
>
> Both 2.A and 2.B can be fixed through GPA or another frontend, but
> that's still bad key-creation practice.
>
> However, it *does* show the long-form key ID (the last 8 bytes of the
> fingerprint), which is probably the minimum necessary to avoid most
> collision attacks.
>
> Nick
> --
> Unsubscribe, change to digest, or change password at:
> https://mailman.stanford.edu/mailman/listinfo/liberationtech
>



-- 
Robbie Mackay

Software Developer, External Projects
Ushahidi Inc
m: +64 27 576 2243
e: robbie at ushahidi.com
skype: robbie.mackay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.stanford.edu/pipermail/liberationtech/attachments/20121211/905cfbb9/attachment.html>