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.

Emscripten and ClojureScript: Transpiling to Avoid Rolling Your Own Crypto

45 pointsby squidlogicover 9 years ago

9 comments

barkingcatover 9 years ago
I think this is counterproductive - transpiling and relying on emscripten to be cryptographically secure in not changing your code is the very definition of rolling your own crypto. How do you know that you&#x27;re compiling the right things to js?<p>The post says they&#x27;ve taken a cursory look at emscripten to make sure it doesn&#x27;t have &quot;timing attacks&quot; in one short sentence. This is exactly the kind of verification that requires an experienced and professional cryptanalyst to audit, examine, and finally confirm that emscripten -&gt; js indeed doesn&#x27;t expose the cryptographic algorithms to side channel attacks, or add additional weaknesses to the cryptography.<p>If the authors of the original post are not cryptographically confident enough to &quot;roll their own crypto&quot; how can they verify that their tool chain is secure?<p>Don&#x27;t roll your own crypto, especially in using tools that haven&#x27;t been verified to be used in crypto by cryptanalysis.
评论 #10591652 未加载
tptacekover 9 years ago
It is super weird to see new code using Skein; doing that almost by definition implies you&#x27;re rolling your own crypto (which has more to do with how you connect crypto primitives than which primitives you choose), but it&#x27;s never made clear in this post exactly what they&#x27;re doing with it.
评论 #10590727 未加载
评论 #10590682 未加载
评论 #10590637 未加载
评论 #10591075 未加载
ff_over 9 years ago
Any reason for not to use the WebCryptoAPIs?<p><a href="https:&#x2F;&#x2F;developer.mozilla.org&#x2F;en-US&#x2F;docs&#x2F;Web&#x2F;API&#x2F;Web_Crypto_API" rel="nofollow">https:&#x2F;&#x2F;developer.mozilla.org&#x2F;en-US&#x2F;docs&#x2F;Web&#x2F;API&#x2F;Web_Crypto_...</a>
picardoover 9 years ago
Whoever made this website has never heard of &quot;Never break the back button&quot; rule. They literally rewrite my history with every click.
评论 #10591740 未加载
jandreseover 9 years ago
I had to double check to make sure this article wasn&#x27;t some Markov chain troll article.
lordofmoriaover 9 years ago
For reference, an open source library using a similar approach (crytpo + asm.js): <a href="https:&#x2F;&#x2F;github.com&#x2F;vibornoff&#x2F;asmcrypto.js&#x2F;" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;vibornoff&#x2F;asmcrypto.js&#x2F;</a><p>Looks like the asmcrypto&#x27;s speed boosts are pretty high relative to SJCL and CryptoJS. Granted, this article&#x27;s approach is transpiles C-&gt;JS, not sure what the implications are there in terms of performance.
zubairqover 9 years ago
Interesting to see that other projects also consider client side Crypto possible by calling server side macros. Well done!<p>This is my project where I do it too : <a href="https:&#x2F;&#x2F;github.com&#x2F;zubairq&#x2F;coils" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;zubairq&#x2F;coils</a>
huntaubover 9 years ago
A reminder that one of the large issues with running crypto on the client is that you lose important timing information (due to the JS VM).
norswapover 9 years ago
I wonder if many of our security issues are not due to poorly written software, and a big part of that is accumulating layers of cruft in exactly this sort of way.<p>I would certainly write my own crypto (but not design my own encryption scheme!) before using such a heavyweight solution. Implementing crypto might be hard, but common, not harder than building a compiler.