Re: entropicdata.com ?

[Michal Zalewski <lcamtuf () coredump cx>]

> But can't we stop here? Once a solution depends on client-side, especially
> browser-based client-side encryption, aren't you dead in the water (ie:
> substancial risk) from the design itself?

There are several legitimate reasons for implementing client-side
crypto; you might be devising an algorithm that actually tries to
protect the user against compromised servers or routers; or you might
be trying to prove user's intent (think XSRF defenses) or maintain
stream identity and integrity (e.g., for hacky cross-domain
communications) without the need to waste time on obtaining single-use
crypto tokens from a server.

That said, in the first case, you generally should not rely on
server-provided data anyway, and you need a local mechanism to gather
entropy. Right now, it could be achieved in a number of hackish ways,
and in the long run, it might be beneficial to provide standard APIs
for this purpose within browsers (there is a trade-off to be made,
though: letting applications to sample, deplete, and detect
availability of data in the interrupts-driven OS entropy poll, creates
a number of interesting security problems). In the latter cases, OTOH,
it should be OK to use a seed provided by the server, either inserted
into the returned Javascript, or requested via XMLHttpRequest or so.

/mz
_______________________________________________
Dailydave mailing list
Dailydave () lists immunitysec com
http://lists.immunitysec.com/mailman/listinfo/dailydave