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 finishedenough 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 talksabout 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$$) {andkeygenerator: ObjectjwkToNative_: 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)
{andgenerateKeyPair: 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 ZimletOpenPGP 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
