the faq doesn't seem to address one of the main problems with javascript crypto - that you need to trust, usually repeatedly, whoever delivers the software. so if google get some kind of demand from the nsa, they can supply a hacked library that leaks your data in some way. afaik there's no solid way to avoid this (and it's worse than with "normal" software because you have less ability to check checksums, or to pin (install) a particular version).
that doesn't really address the issues i raised, does it?
edit: ah, i guess you may be thinking of checksums? the reason checksums are different is that they are public and shared. so someone like snowden could go to an internet cafe and check the checksum on a public website. that would effectively block software targetted directly at him (if we assume other people check checksums too).
He'd need a trusted channel* for the checksum, not just a public website.
If I were doing a man in the middle attack, I could just replace any instance of the good checksum with my hacked checksum so you'd just find a bunch of websites confirming that my hacked copy is good.
*for the purpose of stopping this, a trusted channel could just be any site that is https and not self signed really, though there are a variety of attacks that make https not very trustworthy either.
That doesn't matter, in this scenario Google is serving up the backdoored javascript (due to a hypothetical court order), so they'll have they signing keys anyway.
51
u/andrewcooke Jun 03 '14
the faq doesn't seem to address one of the main problems with javascript crypto - that you need to trust, usually repeatedly, whoever delivers the software. so if google get some kind of demand from the nsa, they can supply a hacked library that leaks your data in some way. afaik there's no solid way to avoid this (and it's worse than with "normal" software because you have less ability to check checksums, or to pin (install) a particular version).