<i>There are very specific concerns I have about implementing secure cryptography in a browser runtime. ...</i><p>What are your thoughts on our strict uses of asm.js for the actual encryption (libsodium) and static typing for the rest of the code via TypeScript?<p>I&#x27;m aware that asm.js isn&#x27;t literally native code, but we and, (without putting words into their mouths) I believe, the Cure53 team felt that these were both very effective mitigations to the risks you point out. Combined with a strong CSP and an entirely Angular-based UI (so no silly mistakes like untrusted user input in jQuery selectors, and to date no known XSS), I would say that Cyph is <i>vastly</i> different from a project like Cryptocat.<p><i>As it stands, the team that audited you found devastating crypto flaws; for instance, you repeated nonces!</i><p>It was an accident, in pre-production code. (And hardly &quot;nightmare&quot;-level; it was one nonce reuse that only occurred during the initial handshake, and notably wasn&#x27;t obviously exploitable.) That was also <i>the only</i> bug found by 5 experts over 12 days in the entire protocol implementation[1], which I would say is more impressive than not.<p>The whole point of that audit was to catch those sorts of silly mistakes before we switched away from OTR in prod.<p>This also has nothing to do with WebSign or the impact the browser has on our attack surface; we could very easily switch back to the asm.js libotr cross-compilation we&#x27;d been using if Castle turned out to be unfit for production.<p>---<p>1: There were three Castle-related findings, but only one was in the Castle implementation. One was an outdated&#x2F;no-longer-correct statement in a document and one was a configuration weakness elsewhere in the code.