TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

What’s wrong with in-browser cryptography?

4 pointsby mikecarltonalmost 9 years ago

1 comment

RubyPinchalmost 9 years ago
&gt; So, in fact, the W3C is not telling us what algorithms to use at all. [so they&#x27;ll all pick bottom-of-the-barrel-algos, which] in the hands of amateurs are akin to handling plutonium.<p>It isn&#x27;t up to the browser to stop people shooting themselves in the foot, &quot;Why is your web app&#x27;s download verifier so slow?&quot; &quot;Oh because some person&#x27;s blog demanded that only cryptographic functions he liked should be allowed, so I had to use a javascript-based one instead&quot; sounds like a pain in the ass, but totally possible (mega, mediafire, etc), hypothetical<p>And browsers at this point in time are getting far better at making an approximate &quot;standard&quot; for these kinds of things<p>&gt; However, this approach just doesn’t work in a browser, as illustrated by the MEGApwn utility<p>Yes, this approach doesn&#x27;t work in a system where you can&#x27;t generate a number on the other side of the sandbox. Hence, we should not try to make a system that would allow putting&#x2F;creating a number on the other side of the sandbox? That logic is a bit daft, isn&#x27;t it?