🚀 go-pugleaf

Let's me try one last time to get through & then I am
going to give up.

I don't think Erik Lindano understands the kind of box being built.

Here's an analog.

  I have built a box.  It has a red button on top.  If I press it,
  it jumps a foot in the air.

The "challenge" being posed basically assumes such a box is being
built and asks us to test it by pressing the button in the various
expert ways we know how and seeing if it doesn't jump.  If it does
not, the experiment is a failure.  One box that fails is probably
enough to decide it is no good.  If we fail, the box is good.

However, cryptography is more like this:

  I have built a box.  It has a red button on top.  If I press it,
  it will never, ever jump a foot in the air.

Well, I claim I "know" that is so because the box is nothing more 
than a box and
a button.  On the other hand, I may be in ignorance of quantum
mechanics, which may provide that the box will someday jump a foot
in the air.  I may also be unaware that someone with just the right
kind of compressed air gadget can make the box jump.  I may have
defeated the obvious kinds of compressed air gadgets, but I don't
know, for sure, that there _is_ no such compressed air gadget that
works.  (Why else did I post on sci.boxjump asking for help?).

If I put the box out for test and no one knows quantum mechanics, or
fluidics well enough, we will all assume the box works; at some
point, this is what one does with an encryption system.  One hopes
the box never jumps a foot in the air.

But, it might be that, unknown to the inventor, a spring was
accidentally slipped under the box.  It wasn't _supposed_ to be there,
but it is.  The inventor goofed, unknowingly.

Now, if the testers are not allowed to look under the box, they may
or may not come up with test techniques that uncover the flaw.  It
may also be that the test box's spring just so happens not to be
strong enough to pop the box up, but that when released for general
use, the manufacturer puts the spring in, thinking it belongs, and
the production spring _is_ sprung by the actual opponent.  The box
jumps and the customer sues.

Or, maybe because the testers don't get to see the underside of the
box, they fail to design a compressed air gadget that makes the box
jump.  The opponent, however, has no such scruples and does look 
under the box and is thereby able to design a workable device.

Note the difference between this and the first example; a sample size
of one or even a couple is irrelevant.  I have to be sure, before I
bet my livelihood on it, that _every_ box coming off the assembly line
does not jump a foot in the air.  That includes boxes that don't do
quite what the design document says they are supposed to do.  Note, too,
that I can't be sure that the opponent will play by the exact same
rules as my testers.  Those are key, counter-intutitive differences
between the first and second examples.

Remember, we are not the advesaries; we are on _your_ team (or,
could be if we were asked properly :-) ).

The question is "proving a negative", not proving a positive.  Even
if we participate whole-heartedly, and fail, all it proves is that
your method defeated us.  The opponent is under no obligation to
less talented than we.  Or, to play under the same rules, for that 
matter, and that make make a great difference.

Now, I can understand patentability concerns.  The only alternative is
to save your nickels and hire some number of people that append here.
Or, get some folks to look at it off-line.

However, you would be very well advised to let some of us under some
set of rules look under your box.  We may devise totally different,
and much more effective tests in far less time.  Remember, cryptography
is always a war of specifics.  It may be that your test message happens
to be much more resistant to analysis than your customers' messages.  It
may be that your system is very resistant along the terms you cite, but
totally vulnerable after (say) a billion bytes have been encrypted.
Well, banks do encrypt billions of bytes and they will not take your
word for it that it is just as secure at the billionth byte as the first.

I have seen real messages in real, well-broken systems put out for
puzzle solving that vary in difficulty by a factor of a thousand.  If
your system is any good, a particular message can easily be millions
of times harder to solve for even a single added word than a different
message in the same system.  There is a huge variability and that 
matters; that's why we want to control the experiment a little
more; it is easy to develop a false sense of security, especially on
a sample size of a single, inventor-selected message.  Or, even a
thousand messages if they all happen to share the same lucky properties.

In short, there are literally thousands of experiments that might be
relevant to how well your system works and what makes it strong.  You have
not shown that you understand this; indeed, your asking us for help
makes it clear that you _do_ know that you don't understand, quite,
how to set up the test bed.

What we have been trying, futilely, to say to you, is that it all may
hang on triffles.  Things that are unobvious to you and even unobvious
to us, initially.  It may hang on unlucky properties that only show up
after thousands or even millions of bytes.  Or on an unlucky kind of
plain text that you may not have happened to include, but will come
up in your customers' text with some regularity.  Cryptography is a war
of specifics; of things that may hold "almost" every time, but fall
apart uttlerly when the one unlucky case comes up.  And, it may be that
the first order of business is to dream up the right unlucky case and 
look for it.

Put another way; you have to allow for the possibility that we _failed_
when we _should have_ succeeded.  If we can't get the box to jump,
someone else may, because they think of the unlucky case we don't.

You can say all you like that these things do not happen.  Had you read
"The Codebreakers", I think you would be much less certain of this.  You
can't predict what a real opponent may be able to bring to bear.  And,
you can't be sure a real opponent would not do things that we would never
do -- such as burglarize your friend's desk to get the source code for
the program.  Remember, we are in it for peanuts -- the real opponent is
in it to grab a few billion bucks from your customer.  Real opponents are
by definition immoral.  We are simulating the behavior of immoral people,
but we have limits.  They don't, but we may be able to predict what they
will do that we can't.  If you help us help you.  Don't ask us to simulate
the behavior of crooks with one hand tied behind our backs, especially
for such little money :-) .

If you want to defeat us, then go ahead and pose the challenge as you have.
We give up.  We can't solve your system under those terms.  That doesn't
mean a damn thing to you, unfortunately.  What you want to know is whether
the system will really secure data.  If you won't let us help you in the
only way we know how, you are on your own.  Go ahead and patent it.  Get
your customers, and hope for the best.  It's a free country.  I truly
wish you well.  But, history is against you.

And, all of us who have been refusing the challenge have been trying to
make the point to you; it isn't important to you whether you defeat us.
It is helpful, a little; but not necessarily _disposative_, which is what
you want.  It never can be, but at least give us a fighting chance to be
useful to you instead of our potentially wasting thousands of hours to give
you a false sense of security.

You have to defeat your real opponent under rules that are not entirely
under your own control.  In the end, even if we do someday help, you will
have to take your chances.  But, odds are very good that your system is
very vulnerable in a relevant sense that will become obvious to us once
we see how the algorithm works.  And, it really is the cheapest way for
you to find out.

-- 
   Larry W. Loen        |  My Opinions are decidedly my own, so please
                        |  do not attribute them to my employer