[RC5] DES-Test, Day 2
jcampbel at lynn.ci-n.com
Wed Jan 13 16:21:11 EST 1999
On Mon, 11 Jan 1999, Marc Sissom wrote:
> Speaking of grasping at straws! The fact of the matter is, if
> you pull a keyblock from the server and don't return it before
> the contest is over, you are hurting the effort. The reason
> why the block does not come back is irrelevant. You can deny
> it all you want, but you can't change the measurable, observable,
Actually, the odds are 1:2^28 against the non-return of an
individual 2^28 block actually hurting the effort. It's vastly more likely
that the simple checking out of the block will speed the effort towards
finding the correct key *whether the block ever gets checked or not*.
Especially since the only reason I can think of for the contest to end in
less time than it takes for a 386 to crack a block is that some other
machine found the key. If the 386 hurt the effort in that case, does that
mean that every machine that was working on a block at the moment the
contest ended hurt the effort?
> Yes, there is a chance that they could help. There is also a
> chance that they would hurt. It does not matter whether you
> say so or not. The one fact that we have is that handling
> clients costs cycles. If the key is taken and not returned,
> the box that took it hurt the effort. Period.
*Any* machine can do more work over the duration of even a short
contest than the key server could do in the fraction of a second it takes to
pass out a block. Handing out blocks increases CPU cycles, it doesn't
decrease them. That's the entire point of d.net. If it wasn't true, the key
server would keep all the blocks and crack them itself.
There is a point, admittedly, where the cost of handing out a block
exceeds the cost of cracking that block locally, but I'd guess that we need
at _least_ another hundredfold increase in keyrates, without a corresponding
increase in communications speed, before that even begins to become a
problem. (This guess is based on the fact that it takes less than a second
for one of my machines to fetch/flush a block, and the fastest
general-purpose machines I've heard of take about two minutes to do a
> about four days. Expect the real thing to take two or three at
> most. If you have a box that can turn over a block in 24 hours,
> by all means, bring it on. Just be aware that in the future, that
> box might not be a benefit to the cause.
That's why I suggested that smaller blocks be made available for
slow machines. 2^27 blocks would get the latency times on my 386es down into
a range that I'm more comfortable with for these short contests, and 2^26
blocks probably wouldn't be excessively small, so long as only slow machines
were using them. (2^26 blocks, on a 386-25, look like a block about every
4-5 hours... we wouldn't want a bunch of P-IIs ripping through a 2^26 block
every 30 seconds, though.) Also, keep in mind that "not a benefit" is a long
way from "hurting the effort".
jcampbel at lynn.ci-n.com
QotD: Things are only lost because people insist on looking where they are
not, rather than where they are.
To unsubscribe, send 'unsubscribe rc5' to majordomo at lists.distributed.net
rc5-digest subscribers replace rc5 with rc5-digest
More information about the rc5