Hi, thanks for your feedback everyone. Looks like there is strong agreement that OpenPGP.js has many advantages over E2E.
Some other relevant comments about ECC were made here: https://github.com/openpgpjs/openpgpjs/issues/26#issuecomment-98653226 Tankred 2015-05-05 20:35 GMT+02:00 Barry de Graaff <[email protected]>: > Hello All, > > After Alex' mail, I looked into the E2E code, and it seems far from > completion, that is also more or less stated on the E2E wiki. > > I did some tests with key generation, and it seems fast in both Chrome and > Firefox, but the code is not finished > enough for good testing. > > It is unclear to me if this library is meant to be something other then a > part of a Chrome extension. The wiki talks > about Chrome extension, more than OpenPGP JS lib. > > To explain further, when I look at the e2e.openpgp object it has methods > like: > > ClearSignMessage: function $e2e$openpgp$ClearSignMessage$($body$$, > $signatureBytes$$, $opt_hash$$) { > and > keygenerator: Object > > jwkToNative_: function $e2e$openpgp$keygenerator$jwkToNative_$($jwkKey$$) { > newEcdhWithP256: function > $e2e$openpgp$keygenerator$newEcdhWithP256$($key$$117_opt_privateKey$$) { > newEcdsaWithP256: function > $e2e$openpgp$keygenerator$newEcdsaWithP256$($key$$116_opt_privateKey$$) { > newWebCryptoRsaKeys: function > $e2e$openpgp$keygenerator$newWebCryptoRsaKeys$($keyLength$$) { > > > A cryptic crypto library? As an integrator I much prefer the OpenPGP.js > approach: > > signClearMessage: function signClearMessage(privateKeys, text) { > and > generateKeyPair: function generateKeyPair(options) { > > > So while E2E may be a good alternative some day, I hope that OpenPGP.js > stays alive as a project as well. > And that development on the OpenPGP.js project continues. > > Also already stated by others, the E2E code has hard dependencies to other > Google Libraries (closure lib), > Including these libraries may be a problem (technically and legally) in the > project I am working on. > > For the rest I tend to agree woth Fabio. > > Barry > > Zimbra OpenPGP Zimlet > OpenPGP message extension for Zimbra Collaboration Suite. > http://www.barrydegraaff.tk/ > >> From: [email protected] >> Date: Sun, 3 May 2015 20:56:46 +0200 >> To: [email protected] >> Subject: [openpgpjs] Google E2E vs. OpenPGP.js >> >> Dear all, >> >> I'm moving this discussion to the complete list. In short: Do we need >> OpenPGP.js after Google released their implementation of OpenPGP in >> JavaScript ( https://github.com/google/end-to-end ). Some good arguments are >> given below. >> >> I initially established OpenPGP.js (despite not being part of the active >> development team) since there was no proper single, usable implementation >> back then. Due to the commitment of a handful gifted fellows and a great >> community this changed rapidly. This is outstanding. >> >> I see multiple technical and political reasons that argue for both, >> dropping/merging and even enhancing OpenPGP.js. I'd like to see an >> atmospheric picture here. >> For example, on a technical level it probably doesn't make sense to >> reimplement the wheel and on a political level it is questionable whether an >> implementation driven by Google would be for example an alternative for the >> GnuPG folks. >> >> Best regards, Alex >> >> >> On 03.05.2015, at 18:21, Fabio (naif) Pietrosanti >> >> <[email protected]> wrote: >> >> >> >> @tanx i think that diversity is important in the opensource ecosystem, >> >> not only in the code but also in the way specific projects get used or >> >> focus >> >> on. >> >> >> >> As you say E2E have a set of bureaucracy around it given the google >> >> internal constraints: >> >> >> >> • cannot be spitted into a lib >> >> • it's not updated immediately on github but there's a synchronization >> >> process between internal development and opensource release >> >> • there could be issues in contribution and collaboration >> >> From my point of view those are important enough constraint to let me >> >> skip using it as-it-is. >> >> >> >> A project like GnuPG or OpenPGP.js, with it's own diversity of >> >> management, diffusion and contributors, have a quite free-community >> >> oriented >> >> approach, without backing from a major multinational (that we love for >> >> it's >> >> opensource commitment, but impose rules limiting freedom a bit). >> >> >> >> I am wondering if we could not think about "re-using" some of the >> >> Google E2E components in order to cleanup / bring consistency in the >> >> crypto >> >> being used within OpenPGP.js, but keeping it's independency? >> >> >> >> From a software engineering point of view does it make sense for how >> >> OpenPGP.js is done? >> >> >> >> If i understood properly, if @tanx and @toberndo switch to e2e for >> >> whiteout and mailvelope most current code contribution to openpgp.js would >> >> go away, bringing the project to a point where there's no active >> >> development? >> >> >> >> If so, would it help defining a roadmap and make it financed? >> >> >> >> We could approach some funding (Like www.opentechfund.org) to ask for >> >> financing growth of the OpenPGP.js library itself, it would make a lot of >> >> sense given it's dependency with mailvelope and globaleaks, both funded by >> >> OTF? >> >> >> > On 03.05.2015, at 10:21, Tankred Hase <[email protected]> wrote: >> > >> > We talked about ECC alot at the OpenPGP summit in April. There were some >> > concerns about compatibility but overall everyone agreed it's an inevitable >> > step in the right direction. Especially in light of the web platform and >> > performance when compared to RSA. >> > >> > I see two options going forward... >> > >> > 1.) We all rally behind one OpenPGP JavaScript implementation like the >> > native code community does for GPG. There is no particular reason to have >> > multiple PGP JS libs which each need to be maintained and audited. >> > >> > Whiteout is thinking about adopting the End-to-End lib because of ECC, >> > its clean code and the resources Google is putting behind security audits >> > and bounty. But we still have some reservations. >> > >> > First of all the OpenPGP.js community is small but a very helpful, >> > friendly and productive one. If there something that needs to change in the >> > code I have a quick discussion with @toberndo over hangout and we make a >> > decision. This allows us to quickly add new features or clean up legacy >> > code >> > e.g. like when we migrated to ES6 promises. OpenPGP.js has been audited >> > twice by Cure53 and it's being used in production by Deutsche Telekom and >> > 1&1 in Mailvelope/DEmail which means that not only Whiteout relies on >> > stability and security. This is a great way to share the costs. >> > >> > The full E2E PGP solution is not in production yet and it's not clear >> > when it will. I talked with the Google developers quite a bit about their >> > workflow internally and their willingness to accept community >> > contributions. >> > From what I gathered it seems that the master branch that is exposed to the >> > github repository lags behind the upstream the Googlers work on internally. >> > Changes are pushed to github regularly but with some delay as their >> > internal >> > review process is quite thorough. This has the obvious upside that the code >> > quality is very very high, but it's also not obvious how outside >> > contributions would fit into this process. >> > >> > Another thing the devs also made clear is that they currently cannot >> > split the lib into it's own GitHub repo due to other internal workflow >> > constraints. >> > >> > In terms of maturity the E2E library is being used in a number of >> > production use cases internally and the team was very confident to >> > recommend >> > it for third party apps. Although as mentioned... The full PGP stack is not >> > yet in production and from my experience this is where to most maintenance >> > and interoperabilty work is. >> > >> > If we go with E2E we (Whiteout) don't want to do that alone. We would >> > probably only do it if Mailvelope is also willing to migrate. >> > >> > 2.) The second option would be to integrate the ECC modules from E2E >> > into OpenPGP.js as was discussed above. The solution is the most >> > straightforward but OpenPGP.js is already a mashup of js crypto code >> > gathered from all over the internet. This would probably reduce consistency >> > in the codebase even more. This is also not trivial and no one has raised >> > their hand to handle the actual work and pay for an audit. >> > >> > So those are the two options I see. We're going to try a proof of >> > concept for integrating E2E lib in Whiteout once we find the time. Then >> > we'll have more insight to share. Until the I'd like to get a feeling for >> > the other OpenPGP.js users... What are you in favor of? >> > >> _______________________________________________ >> >> http://openpgpjs.org >> Subscribe/unsubscribe: http://list.openpgpjs.org > > _______________________________________________ > > http://openpgpjs.org > Subscribe/unsubscribe: http://list.openpgpjs.org _______________________________________________ http://openpgpjs.org Subscribe/unsubscribe: http://list.openpgpjs.org
