Cryptography-Digest Digest #606, Volume #11 Sat, 22 Apr 00 09:13:01 EDT
Contents:
Re: OAP-L3: Semester 1 / Class #1 All are invited. (Anthony Stephen Szopa)
Re: OAP-L3: Semester 1 / Class #1 All are invited. (Anthony Stephen Szopa)
Re: Number Theory Book (Michael J. Fromberger)
Re: OAP-L3: Semester 1 / Class #1 All are invited. (Tom St Denis)
Re: OAP-L3: Semester 1 / Class #1 All are invited. (Tom St Denis)
----------------------------------------------------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: Semester 1 / Class #1 All are invited.
Date: Sat, 22 Apr 2000 05:39:05 -0700
James Felling wrote:
>
> Anthony Stephen Szopa wrote:
>
> > James Felling wrote:
> > >
> > > Anthony Stephen Szopa wrote:
> > >
> > > > James Felling wrote:
> > > > >
> > > > > > <Gigantic snip of epic proportions>
> > > > > >
> > > > > > You don't know what you are talking about.
> > > > > >
> > > > > > You cannot even describe the process of how the final OTPs are
> > > > > > created from start to finish.
> > > > >
> > > > > I can post the materials from your website which I have reviewed
>extensively. This certianly
> > > > > skirts the line as to describing clearly, but if it passes for you, I guess
>it will have to
> > > > > pass for me.
> > > > >
> > > > > >
> > > > > >
> > > > > > OAP-L3 has no bias because I say so,
> > > > >
> > > > > First good reason to doubt your credibility.
> > > > >
> > > > > > AND because I have provided
> > > > > > a solid and sound argument why, in the Theory and Processes Help
> > > > >
> > > > > > Files available at http://www.ciphile.com
> > > > >
> > > > > No, you have not provided a "solid and sound argument why" what you have
>provided is a very,
> > > > > very complex algorithim that does in many steps what most algorithims do in
>a few, and still
> > > > > have not explained how with the artifact laden Mix files one may generate
>clean OTPs.
> > > > >
> > > > > >
> > > > > >
> > > > > > There is no more bias in the OTPs from OAP-L3 than there are from
> > > > > > picking true random numbers since the recommended use requires
> > > > > > that the user input true random numbers when choosing what
> > > > > > processes to run and what input parameters to use in each process.
> > > > > > True random numbers in: true random numbers out. This should be
> > > > > > a no brainer.
> > > > >
> > > > > Really? Your logic is flawed at at least two points
> > > > >
> > > > > 1) People are lousy pickers of "true random numbers" -- we tend to pick
>favorites, and to
> > > > > avoid certian patterns and select other "more random looking ones" -- hand
>generated OTPs
> > > > > were an insecure point in many early code departments.
> > > > >
> > > > > 2)A simple example of the falehood of random numbers in, random numbers out.
>- If I write a
> > > > > program and ask for a random number, and whatever I do my program outputs
>the number 4867,
> > > > > then what I have is "random numbers in, single number out" -- while I do not
>claim that your
> > > > > program is flawed in any similar manner, just because I imput some random
>numbers, and do some
> > > > > calculations based on them all it means is that my program is at MOST as
>random as its inputs,
> > > > > and in many cases it means that my program is less random than its inputs.
> > > > >
> > > > > >
> > > > > >
> > > > > > I have supported everything I have said here in this news group
> > > > > > and in the Help Files available at my web site. None of you have
> > > > > > supported anything you have said.
> > > > >
> > > > > Your RNG ( used to generate your mix files) has a definite and obvious flaw
>that should be
> > > > > visible to anyone who has ever taken a serious look at it. There are points
>where the 10
> > > > > digit permutation("scramble" may be easily masked out of the generated data,
>and given since
> > > > > that is no longer there, attacks versus the "Mix", "redistribute" and
>"scramble" are easily
> > > > > available. If you do not know of what I speak, ask, and I will gladly
>provide further more
> > > > > information. True this is a minor flaw( one of many), and as you have setup
>your code data
> > > > > under it is reasonably secure, but if 5 minutes of analisys of your mix file
>generation gives
> > > > > this, what other flaws lurk? Let me say this now "your algorithim is
>secure-- at least versus
> > > > > me", but I do not feel that the level of security it gives is close to that
>of much easier to
> > > > > use programs, nor do I feel that it provides any premium in any way versus
>existing free
> > > > > software such as PGP.
> > > > >
> > > > > >
> > > > > >
> > > > > > Mr. Huuskonen claims that the current implementation of the random
> > > > > > digit generator is not cryptologically sound.
> > > > >
> > > > > True.
> > > > >
> > > > > > Have any of you
> > > > > > asked Mr. Huuskonen if the output from the random digit generator
> > > > > > is used to encrypt messages?
> > > > >
> > > > > No it is not, at leas not directly. It is not used to encode in the same
>way that in a car
> > > > > with power steering, turning the steering wheel does not actually move the
>wheels, it moves
> > > > > something which in turn makes something else move the wheels. -- the RNG is
>used to make
> > > > > things that are processed to make other things, that are combined with other
>things, which
> > > > > eventually after many steps, produces the output.
> > > > >
> > > > > > No, none of you have. This is
> > > > > > because none of you knows what they are talking about.
> > > > >
> > > > > We aren't the only people in this discussion that don't seem to know what
>they are talking
> > > > > about.
> > > > >
> > > > > >
> > > > > >
> > > > > > The output from the random digit generator is not used to encrypt
> > > > > > messages in OAP-L3.
> > > > >
> > > > > Semi-true
> > > > >
> > > > > > And there is no way Mr. Huuskonen or anyone
> > > > > > else is going to get the extensive secret data required to attempt
> > > > > > an analysis as he has proposed.
> > > > >
> > > > > Probably true, unless OAP-L3 goes into general use.
> > > > >
> > > > > > If one could, they would also have
> > > > > > access to the key and or the OTPs themselves, and would not waste
> > > > > > the time attempting such an analysis.
> > > > >
> > > > > Umm, real breaks of real cyphers are generally done by testing and
>eliminating possible
> > > > > guesses -- this analisys is precisely the sort that would be done to aquire
>such data.
> > > > >
> > > > > > So the idea that the random
> > > > > > digit generator is not cryptologically sound is a statement with no
> > > > > > implications to the security of OAP-L3 software as currently
> > > > > > implemented.
> > > > >
> > > > > Try "minimal" unless, of course, it is actually used to encrypt real
>quantities of data.
> > > > >
> > > > > >
> > > > > >
> > > > > > I guess it is like they say in Orange County, California:
> > > > > >
> > > > > > "If you don't get it: you don't get it."
> > > > >
> > > > > And you sir, don't get it.
> > > >
> > > > You insist on knowing what you are talking about. And here I will
> > > > prove you do not: the software says explicitly that it is
> > > > recommended that all user input be true random numbers, etc.,
> > > > and two methods are suggested:
> > > >
> > > > 1) number beans and place them in a bottle and shake them up then
> > > > withdraw them one at a time and this will be your input sequence
> > > >
> > > > 2) use a deck of cards with the two jokers. Add two jokers from
> > > > another deck and label each one with one of the four suits giving
> > > > a deck of 56 cards with 14 cards in each suit with the jack, queen,
> > > > king, joker representing the 11, 12, 13, & 14. Shuffle this deck
> > > > and then peel off one card at a time from the top of the deck and
> > > > place each card in a pile according to suit. You will then have
> > > > four 14 number sequences that can be used for input, etc.
> > >
> > > Simply put, such methods were used to hand generate OTPs in the specific example
>I gave you. The
> > > problems you will run into is that people will deliberately subvert such
>processes, or not shuffle
> > > sulficiently.
> > >
> > > In addition I note that you have chosen to respond to only one of the two points
>I have raised.
> > >
> > > >
> > > >
> > > > Did you not read the Help Files?
> > > >
> > > > Obviously not.
> > > >
> > > > I think you are pathetic to present yourself as a credible poster
> > > > when you clearly do not know what you are talking about.
> >
> > Let me begin by saying you have still not indicated that you have
> > adequately read the Help Files, or led me to believe that you have
> > with any sure reference to what is contained in them. You have
> > only made your assertion that the software has some sort of flaw
> > with no factual support based upon the software or its associated
> > Help Files for this claim. In other words, you still seem to not
> > know what you are talking about.
>
> Sir, you continue to imply that my understanding of your helpfiles is impaired. It
>is no more impaired
> than any other technical readers comprehension of same would be after aproximately 5
>read throughs. Why
> is it that when I ask questions you say "You obviously don't understand the files"
>and not answer the
> questions?
>
> >
> >
> > I ask you this: Describe this supposed flaw in detail - where can
> > we see it and when does it show up. And describe your "flaw
> > artifacts" in detail and where can we see them and when do they
> > show up.
>
> (see my posting elsewhere on this NG -- it is admitedly sketchy, but you algorithim
>is quite frankly a
> mess of parts scattered in no particular manner)
>
> >
> >
> > Can't do this because you now say you don't understand the software
> > because the Theory and Processes Help Files are so poorly written
> > you cannot understand what I have written?
>
> Finally you admit that the theory and processes help files are very poorly written.
>Thank you.
>
> I do feel that I have a fairly sophisticated understanding of the Rube Goldberg
>Encryption process it is
> that you use, but I freely admit that I am not infalible and may not grasp all fine
>points of every
> aspect of your software, but I also feel that your unwillingness to answer
>questions, and to address the
> concerns of the people in the NG has been deliberately obstructionist and in fact a
>genuine impairment
> to anyone understanding your algorithim clearly and fully -- I am uncertian in fact
>that you have
> anything resembling a full understanding of your own algorithim.
>
> >
> >
> > Here is my final challenge to you:
> >
> > You have proven to me with a high degree of certainty that you are
> > either a liar, an idiot, or both, and in any case a fool.
> >
> > Now I will do you one better. I will prove it to you. I will prove
> > to you that you are either a liar, an idiot, or both, and in any
> > case, a fool.
>
> Please refrain from the name calling it neither makes arguments stronger nor
>enhances a reader's
> understanding.
>
> >
> >
> > (Hang in there, guys. Here it comes.)
>
> I'm waiting.
>
> >
> >
> > In the Theory Help File I mention the word "bias" seven times and
> > "unbiased" twice.
>
> I'll accept that -- I certianly didn't count your word usage though.
>
> >
> >
> > You say I don't?
> >
> > So, it is an agreed fact that I do talk about it.
>
> Certianly I accept that you do raise the issue.
>
> >
> >
> > I also make a logical case that the software has no introduced bias
> > when used according to recommendations.
>
> FALSE. No algorithim is bias free that is a fact of life. (Please review your
>information theory) --
> all algorithims produce output with SOME bias -- the goal is to minimise this bias.
>The fact that you
> claim "no bias" seems to me to indicate that you have a flawed understanding og the
>way that things
> work.
>
> >
> >
> > You say that I don't or that you can't understand it? Okay.
> >
> > The first word on the Theory Help File page is "Theory." So, is
> > there anything you don't understand about this word "theory?"
> > If you need to look it up in the dictionary or encyclopedia,
> > please. We will wait.
> >
> > Here is the following sentence, the first sentence on the Theory
> > Help Page:
> >
> > "The foundation of the OTP system for encrypting messages rests on
> > generating and using random numbers such that predicting any given
> > random number used to encrypt a character in an original message is
> > just as likely to be any of all the possible random numbers
> > available."
> >
> > Is there anything you don't understand about this sentence?
> >
>
> Nope. And I agree with that statement 100%. That is the ideal that all Stream
>cyphers attempt to
> achieve.
>
> >
> > Here is the following sentence:
> >
> > "So the primary goal of this encryption software is to generate
> > such random numbers."
> >
> > Is there anything you don't understand about this sentence?
>
> No.
>
> >
> >
> > Now please continue reading each sentence. When you come to a
> > sentence you do not understand post a reply to this post and we
> > will evaluate the problem you have with the sentence that is
> > incomprehensible to you. Let us know which sentence it is and the
> > nature of your confusion so I can give you a good response.
> >
> > This is how I intend to prove to you that you are either a liar, an
> > idiot, or both, and in any case, a fool.
> >
> > You wanted help, I am here to give it to you.
>
> Sir, it is not your help files that fail me, I waded my way through them a while
>ago. It is your
> methodology and your inability(seemingly) to answer my questions. Here they are for
>you again:If my
> simple questions were answered in a satisfactory manner, I would cease to be a drain
>upon your time, and
> may even be an advocate. I
>
> Your RNG is flawed. This does not sink your algorithim, however, it does raise
> issues. Can you give a good expalnation as to why the flaws in the RNG do NOT
> result in an artifacts in the resulting stream? Or if they do can you explain why
> such artifacts do not comprise a security risk? Do you understand the nature of
> the flaw in your RNG? Do you know how to fix it?
>
> I accept that a direct attack versus the RNG while not impossible is going to be
> quite challenging. I will accept even for the sake of argument that you are as
> secure as the AES.
>
> your program needs several MINUTES to setup before encryption, while equivalently
> secure algorithims take at worst seconds to setup on an equivalent machine -- Why
> should I use it? What benefit does it offer that justifies the time investment?
>
> your program generates stream data much slower than, oh say, RC4 for example, why
> should I use it in prefrence to other stream algorithims?
>
> PGP has a much cleaner and easier to use user interface and offers equivalent
> security and faster encryption, why should I use your program?
>
> Even ScottXu has had more thourough examination, and has actually had some
> sophisticated analisys performed upon it, has your program? If so why does the RNG
> have the weakness that it does( it is a fairly simple one that can be easily
> avoided by trivial modification)?
>
> >
> >
> > Do you accept my challenge?
> >
> > This goes for any of your peers out there who agree with J.
> > Felling's positions or have positions of their own they haven't
> > expressed regarding fault with OAP-L3.
> >
> > All anyone needs to do is post the exact description of their
> > position why OAP-L3 is flawed, where we can see this flaw, and when
> > this flaw will occur, etc. then we will go through the Theory and,
> > if necessary, the Processes Help Files so each of you can tell me
> > what it is you don't understand, if this is the case, that led you
> > to this (erroneous) conclusion. Point out the exact place where
> > your confusion begins and the unintelligible sentence in question.
> >
> > (Do you think I should have taken Dale Carnegy's course on How to
> > Make Friends and Influence People?)
"Why is it that when I ask questions you say "You obviously don't
understand the files" and not answer the questions?"
You have been claiming the software has flaws and you do not support
this claim with facts from the Help Files or the software. How is
this a question?
"but you algorithm is quite frankly a mess of parts scattered in
no particular manner" This is only true in your own mind because
of your own poor understanding of the software: its theory and
operation.
"Finally you admit that the theory and processes help files are very
poorly written. Thank you." Here is an obvious line of BS. I don't
say this. I merely say that you say this.
"The fact that you claim "no bias"..." Not so. I say "the SOFTWARE
has NO INTRODUCED BIAS when used according to recommendations."
"FALSE. No algorithm is bias free that is a fact of life. (Please
review your information theory) --" What is false? I said my logic
is correct. You say false? Then prove where my logic is wrong.
But you don't do this. You misapply some other notion that has no
bearing on what I said. And now I will prove that you are wrong.
Let's just look at the shuffle process. It is an algorithm in
itself. You say that it must produce bias because it is an
algorithm. All the process does is redistribute a MixFile into 14
TFiles each having 259,200 successive arrays written to them from
this MixFile.
The user enters true random input consisting of a 14 number sequence
of the numbers 1 - 14. Then the process interleaves the arrays in
these 14 TFiles according to this sequence. This process does the
same thing every time regardless of what the 14 number sequence is
that the user enters. The 14 number sequence only determines the
sequence of the interleaving.
I say it again, the process (software) does not introduce any bias
into the output. You say it does. Why and how and when and where?
You will undoubtedly try to BS like you have in your reply here.
But you cannot. You have misrepresented information theory with
your intellectually dishonest soul.
The bias occurs in the output, of course. It is due to the true
random number input and not the algorithm process. Since there is
about 87 billion possible inputs there necessarily must be some
bias because you know that the output must be one of 87 billion
possible outputs.
My statement is still true: the software does not introduce any
bias.
The power of this software is that a cracker cannot determine the
bias because by shuffling the MixFile numerous times the cracker
cannot determine what the output is: it quickly becomes
unpredictable.
As more MixFiles are generated and used in the random digit
generator the random digits output become unpredictable. The
calculated triplets become unpredictable, and the final OTPs become
even more unpredictable.
Simply put: the power of OAP-L3 is that you cannot predict the
bias which is solely due to the true random user input.
But what proves you failed my challenge is that this is true of all
encryption software: all encryption software is totally biased not
necessarily because of the algorithm, although this is possibly a
cause, but specifically, in every case, there is bias due to the
particular input or KEY.
The security comes from not being able to determine this bias
except by obtaining the key in some way.
You don't even understand information theory as you have tried
to apply it in your pathetic attempt to look knowledgeable and
intelligent in your zeal to bash OAP-L3.
By the way, OAP-L3 uses no mathematical equations in the encryption
processes. So you cannot attack any known or ever be able to attack
any unknown weakness in such an equation.
You suggest pgp is secure. No one officially has claimed and proven
to be able to crack it. It is accepted knowledge that to factor
large primes quickly would accomplish this. Quantum computers will
be able to do this quite readily. No such weakness exists in OAP-L3.
pgp may have other unrealized weaknesses as well as the other
popular public key encryption software and equation based
encryption software.
OAP-L3 can only be cracked with brute force because of the nature of
its algorithms and the fact that the user inputs true random input
(provided, of course, that it is used according to recommendations.)
The methods I suggest to produce these true random inputs can
produce such true randomness. (Seems good enough for Las Vegas.)
Another major point is that these sequences are not duplicable.
You cannot number beans and place them in a bottle and shake them
up and then draw them out one at a time and produce the same
sequences that the user produced.
OAP-L3 provides for practicably unlimited key length.
Rube Goldberg uses three mixfiles and generates random digits just
like me? Is this another one of your lies?
"Your RNG is flawed." You keep saying it but do not prove your
point. You don't even attempt to. You probably don't even know
where the random number generator begins and ends, do you?
Since you have not pointed out any sentence in the Theory and
Processes Help Files or any other help file that is unintelligible,
the Help Files must be adequately written which contradicts what
you have been saying up to now. So why are you unable to prove
directly that the software is flawed and insecure? Simply show us.
Keep it simple. Focus just on this single point and show us.
Forget everything else.
As far as your other questions are concerned: the primary issue
is the security issue of OAP-L3. You certainly have not and
apparently cannot refute anything in the Help Files with direct
proof. You only BS, lie, misapply theory, etc. to arrive at your
desired twisted conclusions.
What have you proved?
You are in my permanent kill file, knuckle head.
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: Semester 1 / Class #1 All are invited.
Date: Sat, 22 Apr 2000 05:40:50 -0700
"Trevor L. Jackson, III" wrote:
>
> Anthony Stephen Szopa wrote:
>
> > "Douglas A. Gwyn" wrote:
> > >
> > > Anthony Stephen Szopa wrote:
> > > > This is all so richly comical.
> > >
> > > That's because instead of conducting a technical dialogue,
> > > you're just insisting that you're right and everybody else
> > > is intellectually dishonest. And instead of explaining
> > > the principles in terms that would make sense to a working
> > > cryptologist, you simply direct us to figure it out
> > > ourselves from the "help files". How about treating this
> > > as a genuine technical discussion? For example, tell me
> > > why my observation (based on examining the "help files")
> > > that at least one of the three columns of generated "mix"
> > > could be recovered by chaining is flawed (as you claimed).
> > > I suspect that most cryptologists will have no real
> > > interest in your system if their concerns are not addressed
> > > in good faith.
> >
> > Real cryptologists understand my Help Files.
>
> Excellent. Now we are making progress. Please name at least two "real
> cryptologists" who understand your Help Files.
Avoiding the issue which you are incapable of discussing with solid
support: the security of OAP-L3?
------------------------------
From: Michael J. Fromberger <[EMAIL PROTECTED]>
Subject: Re: Number Theory Book
Date: 22 Apr 2000 12:47:19 GMT
In <[EMAIL PROTECTED]> Antoine Bruguier <[EMAIL PROTECTED]> writes:
>Hi,
>I'm looking for a number theory book, explaining from the
>beginning. But I konw stuff like Zn is a field when n is prime,
>Fermat's theorem etc. Any suggestions ?
A few suggestions:
Niven & Zuckerman, _Introduction to the Theory of Numbers_
Lindsay N. Childs, _A Concrete Introduction to Higher Algebra_
Kenneth H. Rosen, _Elementary Number Theory & Its Applications_
Cheers,
-M
--
Michael J. Fromberger Software Engineer, Thayer School of Engineering
sting <at> linguist.dartmouth.edu http://www.dartmouth.edu/~sting/
OfUb/Q/gvcIAtVDQ7kbZelrae4GIXJT8mmn38wXEpdUjthIOaDBPen8LcEij9zNFJzRNoe0W
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: Semester 1 / Class #1 All are invited.
Date: Sat, 22 Apr 2000 12:57:39 GMT
Anthony Stephen Szopa wrote:
>
> "Trevor L. Jackson, III" wrote:
> >
> > Anthony Stephen Szopa wrote:
> >
> > > "Douglas A. Gwyn" wrote:
> > > >
> > > > Anthony Stephen Szopa wrote:
> > > > > This is all so richly comical.
> > > >
> > > > That's because instead of conducting a technical dialogue,
> > > > you're just insisting that you're right and everybody else
> > > > is intellectually dishonest. And instead of explaining
> > > > the principles in terms that would make sense to a working
> > > > cryptologist, you simply direct us to figure it out
> > > > ourselves from the "help files". How about treating this
> > > > as a genuine technical discussion? For example, tell me
> > > > why my observation (based on examining the "help files")
> > > > that at least one of the three columns of generated "mix"
> > > > could be recovered by chaining is flawed (as you claimed).
> > > > I suspect that most cryptologists will have no real
> > > > interest in your system if their concerns are not addressed
> > > > in good faith.
> > >
> > > Real cryptologists understand my Help Files.
> >
> > Excellent. Now we are making progress. Please name at least two "real
> > cryptologists" who understand your Help Files.
>
> Avoiding the issue which you are incapable of discussing with solid
> support: the security of OAP-L3?
Ho hum, you have yet to prove that your software is any better then a
LFSR.
And btw why not answer my questions? (under "Problems with OAP-L3")
Tom
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: Semester 1 / Class #1 All are invited.
Date: Sat, 22 Apr 2000 13:05:31 GMT
> "Finally you admit that the theory and processes help files are very
> poorly written. Thank you." Here is an obvious line of BS. I don't
> say this. I merely say that you say this.
>
> "The fact that you claim "no bias"..." Not so. I say "the SOFTWARE
> has NO INTRODUCED BIAS when used according to recommendations."
What if the user doesn't follow your rules? It's really simple to screw
it up then since the entire security is conjectured to be on the seed.
And don't tell me "the user is just plain stupid" because it's human
nature to cheat lie and take the easy way.
> "FALSE. No algorithm is bias free that is a fact of life. (Please
> review your information theory) --" What is false? I said my logic
> is correct. You say false? Then prove where my logic is wrong.
> But you don't do this. You misapply some other notion that has no
> bearing on what I said. And now I will prove that you are wrong.
It's not an OTP therefore there is bias. Pretty simple fact to live
with. Even if the bias is hard to notice...
> Let's just look at the shuffle process. It is an algorithm in
> itself. You say that it must produce bias because it is an
> algorithm. All the process does is redistribute a MixFile into 14
> TFiles each having 259,200 successive arrays written to them from
> this MixFile.
>
> The user enters true random input consisting of a 14 number sequence
> of the numbers 1 - 14. Then the process interleaves the arrays in
> these 14 TFiles according to this sequence. This process does the
> same thing every time regardless of what the 14 number sequence is
> that the user enters. The 14 number sequence only determines the
> sequence of the interleaving.
>
> I say it again, the process (software) does not introduce any bias
> into the output. You say it does. Why and how and when and where?
Yes it does. Your program is a finite state machine that produces
output, therefore a bias is a *consequence*. Again it may not be easy
to notice, as in the case BBS or RC4.
> You will undoubtedly try to BS like you have in your reply here.
> But you cannot. You have misrepresented information theory with
> your intellectually dishonest soul.
What is this suppose to mean?
> The bias occurs in the output, of course. It is due to the true
> random number input and not the algorithm process. Since there is
> about 87 billion possible inputs there necessarily must be some
> bias because you know that the output must be one of 87 billion
> possible outputs.
Why do you rely on unorthodox numbers? Like it has 87 billion possible
seeds, and 259,200 arrays, and they are permutations of 0-9... Have you
taken one class in comp sci or cryptography? BTW with 87 billion
possible seeds thats about 2^70.5, so if thats your key size (I may have
misinterpreted this) it's kinda small doncha think?
> My statement is still true: the software does not introduce any
> bias.
That's false.
> The power of this software is that a cracker cannot determine the
> bias because by shuffling the MixFile numerous times the cracker
> cannot determine what the output is: it quickly becomes
> unpredictable.
This is false too. You can generate the output deterministically
therefore it is predictable for you at least.
> As more MixFiles are generated and used in the random digit
> generator the random digits output become unpredictable. The
> calculated triplets become unpredictable, and the final OTPs become
> even more unpredictable.
They are not OTP, so stop calling them that.
> Simply put: the power of OAP-L3 is that you cannot predict the
> bias which is solely due to the true random user input.
Wait I thought there was no bias?
Face it you have alot of questions to answer and you merely avoid them
1. Why are you using perms of 0-9?
2. What is the period?
3. What is the next simplest way to attack a variant of the algorithm?
4. Will it work on my 8051 with 1kb of ram?
5. What is the speed of the output (bits per second)
6. Where is a C/Ada/Java Ref source that we can test out?
Tom
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and sci.crypt) via:
Internet: [EMAIL PROTECTED]
End of Cryptography-Digest Digest
******************************
