Search Mailing List Archives


Limit search to: Subject & Body Subject Author
Sort by: Reverse Sort
Limit to: All This Week Last Week This Month Last Month
Select Date Range     through    

[liberationtech] Mailvelope: OpenPGP Encryption for Webmail

Ali-Reza Anghaie ali at packetknife.com
Tue Dec 11 07:23:35 PST 2012


I'm not finding a lot of information since the end of ~last year~ on the
status of OpenPGP.js checks. Perhaps an inquiry on their mailing list is in
order - I didn't see archives. I would guess Mailvelope uses whatever
keystore options OpenPGP.js offers which as of now (as near as I can tell)
doesn't include GnuPG compatibility (with already noted limitations as good
reasons).

Will be interested to see how both evolve. -Ali



On Tue, Dec 11, 2012 at 9:31 AM, Petter Ericson <pettter at acc.umu.se> wrote:

> I would claim that the expected behaviour would be to use any available
> keystore by default, or alternatively (if none is found) to install its
> own in a "default" location. On *nix, this is usually ~/.gnupg, and if
> GPG4Win is "widely" used on windows, I would expect one such keystore to
> be implemented.
>
> However, I am unsure how much of this can be done from browser plugins.
>
> Still, with the caveats mentioned further down the thread, I have to
> say this is a great thing, at first glance. More (and better) encryption
> tools make more (and better) encryption!
>
> Cheers
>
> /P
>
> On 11 December, 2012 - Robbie MacKay wrote:
>
> > "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
>
> > --
> > Unsubscribe, change to digest, or change password at:
> https://mailman.stanford.edu/mailman/listinfo/liberationtech
>
>
>
> --
> Petter Ericson (pettter at acc.umu.se)
>
> Telecomix Sleeper Jellyfish
> --
> Unsubscribe, change to digest, or change password at:
> https://mailman.stanford.edu/mailman/listinfo/liberationtech
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.stanford.edu/pipermail/liberationtech/attachments/20121211/55ddda30/attachment.html>


More information about the liberationtech mailing list