> Why is there this rhetoric as if all of the bugs in JS crypto are unique to > JS crypto? These breaks happen in other platforms too, but simply occur in > different forms. However, overwhelmingly, the frequency and severity do > compare.
There are specific bugs in the JS crypto library and as a result, the rest of the software breaks, badly. > > I think that there is a lot of optimism to be had if we look at the recent > Pwn2Own results — Chrome's sandboxing prove exceptionally difficult to > break, while Chrome OS was actually unbroken. These are web technologies > and they are performing very impressively on the security front. > Actually, I was at Pwn2Own with Ralf and he owned it. Though there was small timing dispute about the contest though, so he polished it up and gave it to them after pwn2own: http://googlechromereleases.blogspot.de/2013/04/stable-channel-update-for-chrome-os.html That he sat on the bug for a while does not really suggest good things about the security of the platform. Though I like ChromeOS and Chrome - still, it was not unbroken by any means. > Nothing is perfect, but there's also a selection and confirmation bias > where we pretend that just because a class of security considerations is > new, that it must therefore be more present in severity and frequency than > other flaws. However it's largely, if of course never entirely, a matter of > perception. > Javascript web crypto has all of the problems of traditional crypto without a solid basis on which to build. As a result, the application on top has some set of unknown issues and the underlying library code does as well. This is especially true with homebaked crypto protocols and those issues are realistically compounded by say, a broken library that does some standard thing but does it badly. It is often said that "Nothing is perfect" as if this excuses known to be dangerous constructions. So rather than repeat that until I'm blue in the face, I'll offer a corollary point to move past the rhetoric: Many projects are exponentially worse through compounding failures that are almost completely avoidable in production software. The concern is not perfection, it is about repeating the mistakes of the past and compounding them with the arrogance of the future. All the best, Jacob -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at [email protected] or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
