Security Researcher Vetting?

[NetOpWibby]

Will this be evaluated by security researchers? I'm interested in using this for some projects, but I don't know how to test for effectiveness.

[arlolra]

Sorry for the late reply.

I have no immediate plans to engage an audit. There are a lot of things I'd like to see refactored before I feel that would be productive. However, the code was tangentially reviewed as part of Cryptocat and the library's dependencies were found wanting. Crypto.js is subject to cache-access leaks, bigint.js's powmod isn't constant time and its rng was biased. That doesn't instill a lot of confidence. Moreover, bigint.js isn't maintained upstream and probably wasn't ever intended for production.

A rewrite on sjcl (which also hasn't had commits in a few months) or with the webcrypto api (though that doesn't have any plans to implement DSA last I checked) may be prudent. There is an emscripten compiled version of libotr, though that doesn't lend itself very well to auditability. If xul is your thing, there're js-ctypes bindings to libotr. For node, native bindings might be good. However, the most promising looks like Google's end-to-end, when it's ready. That exhausts the ecosystem of which I'm aware.

[NetOpWibby]

👍

[jcbrand]

There is an emscripten compiled version of libotr, though that doesn't lend itself very well to auditability

Pardon my ignorance, but why would that be the case?

[mnaamani]

The emscripten version depends on bigint.js for the following functions:
powMod,mult,mod,inverseMod. However It doesn't however depend on bigint.js's RNG. (it can be recompiled without the bigint.js dependancy but in my tests I found it to be slower when doing public key crypto (DSA) and SMP authentication)

I'm inclined to agree with @arlolra with respect to auditability of the emscripten compiled version of libotr, since the library is a combination of pure javascript + asm.js compiled code of the native C library. So an audit would have to cover the javascript code, native C library, and the emscripten/asm.js compilers.

Can you think of any other reasons?

[arlolra]

The emscripten version depends on bigint.js for the following functions:
powMod,mult,mod,inverseMod. However It doesn't however depend on bigint.js's RNG. (it can be recompiled without the bigint.js dependancy but in my tests I found it to be slower when doing public key crypto (DSA) and SMP authentication)

How bad is the slowdown? I think it'd be preferable to pay the penalty and remove that dependency.

I'm inclined to agree with @arlolra with respect to auditability of the emscripten compiled version of libotr, since the library is a combination of pure javascript + asm.js compiled code of the native C library. So an audit would have to cover the javascript code, native C library, and the emscripten/asm.js compilers.

Can you think of any other reasons?

I wrote that sentence because at face value it seemed adding another layer of indirection would increase the audit surface. Particularly, I was worried about subtle timing leaks from the compiler. However, a little digging leads me to believe that asm compiled code may be less likely to introduce side channels.

It may be worth spending some time producing deterministic builds of the compiled libotr to increase trust in the obfuscated code.

[mnaamani]

Last time I checked the slowdown was significant. Which made SMP and DSA key generation slow.
Running libgcrypt tests in https://github.com/mnaamani/crypto-emscripten without overriding with bigint.js I still notice that the pubkey test takes a long time in generating DSA keys

But I tried rebuilding libotr4.js in otr4-em without the bigint dependancy, and strangely I don't see much slow down in SMP and key generation. Performance in browsers is very good (better than in node) probably because of the asm.js optimisation in the browsers?

So I think I will take your advice an remove bigint.js from otr4-em

Deterministic builds sounds very important. It should be easy todo. I would have to skip the closure compiler and minifying steps in emscripten to remove obfuscation and produce more deterministic javascript. Will definitely look into that.

Thanks Arlo for your insight and helpful feedback as always :)

[arlolra]

I still notice that the pubkey test takes a long time in generating DSA keys

Is it the FIPS test?

[mnaamani]

Yes it seems the FIPS test is the slow one. I timed the tests:

With bigint override:
basic 1m27.654s
pubkey 4m19.982s
keygen 5m6.093s
fips186-dsa 4m58.342s

Without bigint:
basic 1m37.181s
pubkey 8m11.649s
keygen 5m8.979s
fips186-dsa 7m36.197s

Is the FIPS DSA version used in libotr ?

[arlolra]

Is the FIPS DSA version used in libotr ?

Nope. The difference being the extra work to generate a seed which is never used.