Things are getting better in JS crypto since the original articles came out. The latest versions of FF have a proper PRNG available, for example.
There are still issues with timing attacks and with the fact that the JS can be overridden by other chunks of code and there is no good way to verify the security of the runtime as a whole. This is not my area of expertise but my understanding is that (for example) If I were a developer of Adblock Plus (or another popular plugin) I could insert code into MY plugin that changed openpgp.js's execution environment (since it's all running in the same browser) enough to render the implementation useless and in general, there is no good way to verify that nothing in the JS execution environment has not been tampered with. All this being said, openpgp is probably better than nothing (all caveats about a false sense of security notwithstanding). - alasdair On Tue, Jul 8, 2014 at 10:40 PM, Giorgio Maone <gior...@maone.net> wrote: > On 09/07/2014 01:41, Alasdair Young wrote: > > I'm not a fan of openpgp.js for a lot of reasons. > http://tonyarcieri.com/whats-wrong-with-webcrypto explains why in a much > better way than I ever could. > > > I'm very new to this community and its mindset, so I know I've got a lot > to learn and I'm certainly missing something essential, but I fail to > understand how those (mostly valid) objections apply to our scenario, since > they are directed either against the webcrypto standardization process or > aganst cryptography performed in the context of a web page: > > 1. OpenPGP.js does not *depend* on webcrypto, even if it supports it > 2. We wouldn't run as web content, but as privileged code, with the same > powers and the same isolation as the browser itself (much like any > platform-native program, even if written in cross-platform JavaScript). > 3. We don't need to deal with private keys > > -- G > > On Jul 8, 2014 3:47 PM, "Griffin Boyce" <grif...@cryptolab.net> wrote: > >> OpenPGP.js doesn't require the user to have GPG installed on their >> system. >> >> Ideally, in this case, the pubkey would be already packaged within the >> extension, with only signed updates being able to overwrite it. However, I >> think to some extent this still relies on a user making an effort to verify >> the key's validity via its web of trust. >> >> best, >> Griffin >> >> On July 8, 2014 6:19:07 PM EDT, sajol...@pimienta.org wrote: >>> >>> Giorgio Maone wrote: >>>> >>>> Hi everybody. >>>> >>>> The blueprint should be enough for me to start hacking a prototype >>>> together. >>>> >>>> >>>> If nobody has suggestions, I'd propose to call the extension with the >>>> catchy (!) name of "Tails Catcher". >>>> >>>> I'd just add that a future version might embed tails developer's key and >>>> >>>> perform OpenPGP authentication itself. >>> >>> >>> I didn't put that idea on the blueprint so far, for the following reasons: >>> >>> - OpenPGP for verifying our ISO image is only stronger than SHA256 if >>> >>> the WoT is used to build strong trust in the signing key. Otherwise, you >>> might as well get an HTTPS MitM while receiving the key, as much as >>> while receiving the hash. >>> - Our past experience with Firegpg [1] taught us that doing GPG inside >>> >>> of a browser is usually a >>> bad idea. The same might not apply to an ISO >>> verification but I would check this very carefully before going this way. >>> - I don't know how portable it would be to do such GPG operations from >>> inside the browser. Would the user need to have GPG installed on their >>> >>> Windows or Mac OS X? Would we ship a GPG ourselves? All those options >>> sounds scary to me :) >>> >>> Those are the reasons why I'm not convinced by that idea. We might also >>> want to further discuss the role of the OpenPGP verification in the >>> >>> broad installation process with UX people. But anyway, that discussion >>> shouldn't block in any way the first implementation... >>> >>> [1]:https://tails.boum.org/doc/encryption_and_privacy/FireGPG_susceptible_to_devastating_attacks/index.en.html >>> >>> >> -- >> Sent from my tracking device. Please excuse brevity and cat photos. >> >> _______________________________________________ >> Tails-dev mailing list >> Tails-dev@boum.org >> https://mailman.boum.org/listinfo/tails-dev >> To unsubscribe from this list, send an empty email to >> tails-dev-unsubscr...@boum.org. >> > > > _______________________________________________ > Tails-dev mailing > listTails-dev@boum.orghttps://mailman.boum.org/listinfo/tails-dev > To unsubscribe from this list, send an empty email to > tails-dev-unsubscr...@boum.org. > > > > -- > -- > Giorgio Maonehttp://maone.net > > > _______________________________________________ > Tails-dev mailing list > Tails-dev@boum.org > https://mailman.boum.org/listinfo/tails-dev > To unsubscribe from this list, send an empty email to > tails-dev-unsubscr...@boum.org. > -- - alasdair Alasdair Young
_______________________________________________ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
