[liberationtech] Peer-review required: SwaTwt and TweedleDH

[Uncle "The Dod" Zzzen]

Sorry for late response. I was mostly offline for a few days. eDivide in
action :)

On Wed, 2010-09-29 at 12:04 -0700, Daniel Colascione wrote:

> As you mentioned a few days ago, Javascript-callable cryptography
> primitives can only be performance optimizations: they cannot change the
> fundamental trust model between a client and server. As such, they just
> encourage what we know to be a bad idea. If a client can trust a server,
> a client can trust a server to do the cryptographic work server-side.

I totally agree, and if I ever try to have another go at "secure social
networking", it would be a desktop twitter front end like you've
suggested in a previous email.

Speaking of trust models, I'd like to explain why I chose an RC4-based
algorithm (despite the history it has with WEP). Given that there *is* a
way to implement RC4 in a way that avoids pitfalls (and I'm not saying
that my implementation was "it"), RC4 has one advantage over other other
algorithms (at least AFAIK): It's simple enough to visually inspect for
trapdoors.

Now the implementation of SwaTwt had a problem *inherent* to
server-provided JS (jscrypt too): You *can* inspect the code, but - as
Steve said - you'll fallback to trusting the site eventually (still
better than *having* to trust your remote diaspora node ;) - but not by
much).

My question is: since trapdoors are not only a known problem, but
there's even talk about enforcing them by law
https://www.eff.org/deeplinks/2010/09/government-seeks
doesn't the fact that the code is feasible-to-inspect make it safer?
(assume it's a client-side python script)

Maybe RC4 is not the only simple-to-inspect code, maybe I can make sure
the python version won't have the problems you've found in SwaTwt, or
maybe I should simply go for a standard python crypto library and hope
they're never forced to install trapdoors by law :)

What do you think?