nik at qnrq.se
Wed Jul 11 17:00:42 CEST 2012
The key manager uses HTML5 web storage to store keys, perhaps your
browser doesn't support it yet? I've confirmed that part to work in both
Firefox and Chrome. The plugin is heavily depending on HTML5 and things
like window.crypto, which Chrome currently supports but Firefox is
lagging (for some reason they're holding the release back because it's
not finished for the mobile app).
Decryption works as a proof of concept currently and currently it can
only decrypt using one (the first) private key in the key manager. The
decryption function is on rows 275-334 here:
I see what you mean about message parsing being a big project to get
working somehow on the client side. I can't say that I'm looking forward
to that part, but for now the most important thing imho is to get any
PGP safely into Roundcube. It might be something that requires patching
openpgp.js and that's fine by me, I've already planned doing
I think it's OK if it takes some time to get full multipart messaging
support. Browsers haven't implemented HTML5 fully yet so either what is
done with the plugin it won't function 100 % until things like that are
This is what I have in mind before releasing it as a beta (besides
what's already slightly working):
- Move key management to settings as you suggested (at this stage it's
nice to have it all in my face for easy debug)
- Create key select that spawns pre-decryption (same window as where the
user enters the passphrase) if the user has several private keys
- Easy import-export functionality of data stored in the HTML5 web
storage (I know openpgp.js was looking at cryptostick support, not sure
how that's going for them)
- Encryption function (missing entirely)
- Verification after decryption (depends on PKS support)
- Public key server connection*
* According to the specification and the implementations I've tried the
PKS sends and receives traffic through HTTPS. This creates two problems:
1) theoretically possible to alter data (MITM) and 2) an attacker with
access to the clients network traffic knows whose keys the user is
requesting or which keys are being submitted, which would decrease
anonymity even when SMTP servers use TLS between each other. My solution
communicate with for PKS activity (retrieving and adding). This way
users of Roundcube installations on HTTPS have anonymized PKS traffic
and users on HTTP are unaffected. Hopefully everybody runs Roundcube on
Once again, if this project takes very long time to develop, I wouldn't
really mind. I'd rather take long time than get in the same classical
paradox with private keys and crypto calculations on the server instead
of the client as so many others :-) I don't mess with backdoors. And
hopefully plugin users agree with the philosophy of releasing early and
releasing often and don't spam me too much about multipart support :-D
Thanks a lot for your input, I really appreciate it!
On 7/11/12 9:11 PM, Thomas Bruederli wrote:
> On Sat, Jun 30, 2012 at 5:34 PM, Niklas <nik at qnrq.se> wrote:
>> Hello :-)
> Hi Nik
>> I've been working on implementing OpenPGP.js in Roundcube for the past
>> couple of days. It's still an unfinished project in development, but
>> since there's such high demand for the result I ought I'd ask you guys
>> for some early feedback.
>> For those of you who don't know: OpenPGP.js is a fork of the previous
>> GPG4Browsers. The intent is to port all OpenPGP functionality into
>> It uses HTML5 web storage and standard PKI keyrings (private keys excluded).
> Interesting approach indeed!
>> So far the plugin, rc_openpgpjs, has a "temporary"(?) user interface for
>> key management and selection. Its consciously using a pretty rough UI at
>> the moment because the new design for Roundcube is just around the
>> corner, but just not finished enough yet to start working on. Also the
>> Enigma plugin interface looked in trouble in Larry.
>> Speaking of Enigma: I'm sure someone will ask why I extend that instead.
>> With all due respect to its authors and fans, Enigma has been stuck in
>> development for 2 years, and PGP support has been planned for Roundcube
>> for 6 years. I'm not sure whether Enigma is really relevant or not.
> It's stalled due to lack of time as well as technical and conceptual
> issues. One of the conceptual questions was whether to store the
> private keys on the server or not...
>> Anyhow! Check it out, and tell me what you think. I strongly welcome UI
>> recommendations, patches or any other tip about how I should progress.
>> It's still in early development, but most of the key management features
>> are implemented and so is the decryption of emails. Nothing about the UI
>> is finished.
> After a first run, I didn't fully understand what the plugin can do. I
> tried to import my private key but it didn't appear in the list nor
> did I get an error message or whatnot. When looking at the code, I
> don't yet see actual encryption/decryption of mail contents. Or did I
> miss something? Speaking of decryption, this is where the client side
> approach will make things pretty complicated. It might work for simple
> plain text messages but once an entire multipart message with
> attachments needs to be decrypted, we'd also need mime parsing
> be transferred from the IMAP server vis the Roundcube webserver to the
> client. We'd need a full client side implementation of message parsing
> and file handling. Not that this is entirely impossible but a huge
> amount of work and be expected.
> However, I'm willing to help you with the implementation of a
> Roundcube plugin. For now here are a few suggestions:
> * Move the key management stuff to the settings task. I'd suggest to
> add another tab/section similar to the password or filters plugin.
> * Hook into the 'message_part_structure' plugin hook to make sure
> encrypted message contents will make it to the html output. See enigma
> plugin for reference.
> * Add some UI elements to sign/encrypt outgoing messages.
> More to be added...
> Roundcube Development discussion mailing list
> dev at lists.roundcube.net
More information about the dev