[liberationtech] Peer-review required: SwaTwt and TweedleDH

[Daniel Colascione]

On 9/29/2010 10:08 AM, Steve Weis wrote:
> I gave some constructive criticism directly

Good, but private criticism doesn't help the prospective creators of
other systems.

> In light of Haystack, I think it's important that security questions
> about live systems are raised early and loudly.

I must protest. The CRC's test program did not cause some sea change in
the proper approach to security analysis. The problem was traceability.
All circumvention systems, to various degrees, share that particular
vulnerability. While the CRC had other severe issues, but they were
social, not technical, and in any case, Haystack is not germane to this
conversation.

SwaTWT in its short life has likely seen orders of magnitude more
use than the CRC's test program ever did, and SwaTWT's problems are worse.

> There are
> non-technical readers of this list and you don't know who might start
> using that site. I encouraged Mr. Zzzzen to highlight that the site is
> for test purposes only.

Yes, and it's important to warn potential users about the problems. But
the difference between FUD and legitimate criticism is that the latter
includes claims that are specific and verifiable.

> In fairness, I have collaborated on an experimental privacy-related
> project called PseudoID where the live demo code uses client-side
> Javascript crypto. 

I've read the paper, and it seems to be an interesting project, and
disclosing less to identity providers will be helpful if shown to be
practical (users would need a robust way of breaking any links to
requests to the identify provider and token service, particularly if
they're embodied in the same organization). Thank you for the work.

> The site has a warning that says it is for demo
> purposes. 

Good.

> The corresponding paper discusses all the security issues
> why it's not ready for practice and the future work that would need to
> happen.
> 
> One of the future areas of work was to build crypto support into a
> browser plug-in or extension. There is work being done on client-side
> crypto for HTML5, similar to client-side storage, that is promising.
> Support would be built into compatible browsers and accessible via
> calls in Javascript.

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.
Conversely, if the work can't be safely done server-side (as in the
PseudoID blinding case[1]), then the client needs dedicated support. I
hope these Javascript primitives never become widely supported.

Regards,
Daniel Colascione


[1] One might think it's safe to ask the identity provider to do the
token blinding (since we obviously can't ask the token service to do
it), but in this protocol, a leak of the logs of both the identity
provider and the token service would link a user's identity. PseudoID's
unlinkability in the face of a log leak seems to hinge on the identity
provider never seeing the blinded token sent to the token service.
Though even if all this is done client side, in the real world,
correlating log timestamps provides a nice side channel --- though a
client could cache the signed token (still blinded or not) after the
first run-through, reducing that risk somewhat and introducing another.

(By the way: you meant *client*-side Javascript in Section 5.1, right?)