Re: [Enigmail] openpgpjs vs GnuPG [was: Re: XUL and Enigmail]

[Mike Acker]

PGP/GnuPG is a very critical and highly detailed, feature rich program.   _javascript_ is not an appropriate tools for such work; it should be done in C. the real issue that is, and has been missing in the whole private authentication area is: how best can ordinary users generate public/private keys and then get their public keys authenticated and uploaded. i think a dedicated device for carrying they keys might be needed.   the authentication and uploading should be a service at any DMV, Credit Union, County Clerk or Notary Public . as properly noted in this message key management is the issue that is not well understood and certainly not well implemented.   we will need more than a _javascript_ to fix this .     and it needs fixing : failure to authenticate is one of the main faults that facilitates fraud -- at every level . On 11/10/2015 03:55 PM, Daniel Kahn Gillmor wrote: Thanks for raising the issue, Robert. I think the move off of xul to pure _javascript_ is a good and healthy one regardless of any other related (or unrelated) outcomes -- _javascript_ is actually maintained, and xul is on life support. Having a single simple codebase will be a good thing. That said, i think the specific question you raise below is worth more consideration: On Tue 2015-11-10 13:31:42 -0500, Robert J. Hansen wrote: To start things off, here's my contribution: what would people think about abandoning GnuPG in favor of moving to OpenPGP.js, a _javascript_ implementation of OpenPGP? This would make installing Enigmail vastly simpler, as we'd no longer have a dependency on a third-party application. Also, we'd only have to support one codebase, instead of dealing with people who were using GPGTools, GPG4Win, distro-provided GnuPG, and more. I have no qualms at all about using OpenPGP.js for symmetric message encryption and decryption. Indeed, it should be significantly faster and less error-prone from an engineering standpoint than having to shell out to a subprocess. And since the cleartext is available to enigmail already (before encryption, after decryption), it's not clear that the security boundary is much help, modulo protection of secret key material. So my two main concerns are around access to secret key material and key management. Access to secret key material: Access to secret key material is something that could potentially be solved by talking to a smartcard or a PKCS#11 module or to gpg-agent, or all of the above, if necessary. Can Mozilla extension _javascript_ talk to a local agent socket? if OpenPGP.js were used to access secret key material, are there any steps that could be done to make it resistant to secret key leakage? I'm talking about things as blatant as whether any other extension can just extract the raw secret key by knowing the name of the variable. I'm also talking about more subtly questions, like whether OpenPGP.js is free of side-channel leakage. Key management: Key management is the Achilles heel of pretty much every user-facing end-to-end public-key cryptosystem. Currently, enigmail aims to integrate with GnuPG's key management; it uses the GnuPG trust model, surfaces UI to expose its choices, relies on it for key storage, and relies on its calculations for determining whether a given key should be used or not. An enigmail that doesn't attempt this sort of integration could potentially have a much simpler interface, but it would not work well for an existing userbase that has an OpenPGP keyring that is used with GPG. If a translation tool was built to keep key management in sync, how would that work? or would enigmail just give up on interoperating with any other key management system? --dkg _______________________________________________ enigmail-users mailing list enigmail-users@enigmail.net To unsubscribe or make changes to your subscription click here: https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net -- /Mike

signature.asc
Description: OpenPGP digital signature

_______________________________________________
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net