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" <griffin@???
> <mailto:griffin@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, sajolida@???
> <mailto:sajolida@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@??? <mailto:Tails-dev@boum.org>
> https://mailman.boum.org/listinfo/tails-dev
> To unsubscribe from this list, send an empty email to
> Tails-dev-unsubscribe@???
> <mailto:Tails-dev-unsubscribe@boum.org>.
>
>
>
> _______________________________________________
> Tails-dev mailing list
> Tails-dev@???
> https://mailman.boum.org/listinfo/tails-dev
> To unsubscribe from this list, send an empty email to Tails-dev-unsubscribe@???.
--
--
Giorgio Maone
http://maone.net
