[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SSL search attacks
-----BEGIN PGP SIGNED MESSAGE-----
Hello [email protected]
and [email protected]
and Scott Brickner <[email protected]>
> [email protected] writes
> >From: Scott Brickner <[email protected]>
...[only server assigns segments, client may ack only assigned segments]...
> >BEAAAT STATE! Push 'em back.. WAAAAAAY BAAAACK.
> >(relevant comments follow)
> *coordinated* attack on the key. We've established that there is a 1/e
> cost factor in removing the central server. I just threw out these
Wouldn't it be possible to reduce the cost?
Each client could pick a segment at random, check it and then broadcast
a NAK. Other clients would then know that the segment in question has
been done, and avoid picking it in the future. If you are worried about
collisions, one could also have IGRAB, which would advise others that
someone is working on a segment (you can still collide, but not so
One advantage is that it is not necessary to have a central infinitely
trusted server. (Nothing personal, but bogus server is an attack.)
NAKs and IGRABs would be weighted by the trust accorded to the entity
that originated them.
* "broadcast" is probably best done with a fairly sparse graph, otherwise
one will get too much communications.
* since there is no "server", I should replace "client" with another word.
* there is no incentive to send NAKs (they diminish your own chance
of hitting the jackpot). How could this be avoided?
* the NAKs could be sent by e-mail, thus allowing badly connected
and/or anonymous entities to participate.
Am I making any sense at all?
If you want an answer, please mail to <[email protected]>.
On sweeney, I may delete without reading!
PGP 463A14D5 (but it's at home so it'll take a day or two)
PGP EF0607F9 (but it's at uni so don't rely on it TOo much)
-----BEGIN PGP SIGNATURE-----
-----END PGP SIGNATURE-----