TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Ask HN: Does wasm or web crypto api help web app crypto?

10 点作者 giantahead大约 8 年前
Web assembly is a very promising idea and has a chance to provide better means for building security into web apps than SJCL/etc by enforcing same origin policy, sandboxing execution, being able to limit side-channel attacks, etc. Similarly promising is Web Crypto API: better primitives, consistent across browsers. My question is: will it even help, given that end-user interaction is still in DOM, attackers can still inject the code that overrides calls to better implementations of ciphers? Or I'm missing something in the threat model of both?

1 comment

dsacco大约 8 年前
I think I don&#x27;t fully understand your challenge as stated, so I&#x27;m perhaps not able to give the response you&#x27;re looking for.<p>With that said, let&#x27;s take the way that Netflix implemented DRM via web crypto and encrypted media extensions. Assuming that an attacker is in a position to inject arbitrary code in the browser&#x27;s execution, the attacker still cannot bypass the server-side implementation (otherwise it wouldn&#x27;t be DRM). Unless there is an exploitable weakness in the cryptosystem on the client-side that can be meaningfully chained to the server-side, you need to control both areas of execution to break the crypto involved.<p>When you say &quot;override calls to better ciphers&quot;, do you mean something like a downgrade attack, such as in TLS? It&#x27;s true that you could masquerade the client as a device that is only capable of using a vulnerable type of encryption, but in that scenario the server-side can simply choose to not support it. In fact (again using Netflix as an example), it is more or less a requirement of these cryptosystems that the algorithm&#x27;s work be distributed between a client and a server for exactly this reason.<p>If what you&#x27;re talking about is more of a situation where a rogue software gains access to the DOM while you&#x27;re using web crypto to have an OTR-encrypted, browser-based conversation with someone else, and they use your secret key in execution to decrypt the other parties&#x27; messages: sure. But I&#x27;m not sure what&#x27;s special about that versus client-side takeover of any other cryptosystem. You could just as easily take over Signal on a jailbroken iPhone.