Re: Notes... The case for an open client

Elektron <elektron_rc5-FFYn/[email protected]> writes:
> "Some very significant parts of the key space may have very very low 
> probablities" is completely unfounded. Each key has an equal 
> probability, which I shall prove below. Choosing a search order other 
> than completely random does not decrease the effort of finding the 
> correct key. Also, what do you mean by "several choices in key sequence 
> generation can impact inner loop performance/work"? Checking each key 
> requires a fixed amount of effort.
>
> If each bit is random (P(bit n is set) = 1/2) and independent of other 
> bits (P(n|m) = 1/2), then we can multiply the probabilities together, 
> so P(key is x) = 1/2^72 for x in [0,2^72). That is, ALL KEYS ARE 
> EQUALLY LIKELY.

And therein lies the problem, the bits are not random, but the results
of a deterministic function, so when I said "may" I ment exactly that..
I'm not a math head, and I'm not ready to prove or disprove that one
should simplify the problem with the assumption that the bits are
effectively random, and use random probabilities to declare that keys
are all equal in probability. Since you assert that, with "If each bit
is random" as your proof my choice is wrong and that I'm clueless here,
I'm very interested in your studied proof that they should be.

> Please don't talk about "probabilistic number theory" without any
> knowledge; this is A-level statistics, which I learned at 15.

There is significant grey area between without "ANY" and having it your
choosen field of primary interest to the point that you just "KNOW"
without question the relationship between numbers in most systems that
have been extensively studied and are instantly able to recognize
non-intuitive relationships.

I believe with 100 years or so of search time, there is a certain degree
of luck or intuition in finding the next keys. Why is using a sequential
key search sequence any more valid than a function which is non-sequential,
has identical 100% coverage, same work, but has a strong preference to
order the search by run density?

Everybody is quick to prefer saving the last couple tests using partial
matches since that saves a few instructions. A different key ordering
does exactly the same thing on the front end of the problem, which
also makes doing sequential searches slightly more expensive over
a search order specifically designed to avoid the first few tests.
_______________________________________________
Hardware mailing list
Hardware-Ra3b/QYEcJ3d140v2zMXi0fjHoOT/h/[email protected]
http://lists.distributed.net/mailman/listinfo/hardware