Cryptography-Digest Digest #584, Volume #11 Thu, 20 Apr 00 06:13:00 EDT
Contents:
Re: OAP-L3: Semester 1 / Class #1 All are invited. (Anthony Stephen Szopa)
Re: OAP-L3: Answer me these? (Anthony Stephen Szopa)
Re: OAP-L3: Semester 1 / Class #1 All are invited. (Anthony Stephen Szopa)
----------------------------------------------------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: Semester 1 / Class #1 All are invited.
Date: Wed, 19 Apr 2000 22:06:48 -0700
James Felling wrote:
>
> Anthony Stephen Szopa wrote:
>
> > James Felling wrote:
> > >
> > > >
> > >
> > > <Big snip>
> > >
> > > >
> > > > You want me to believe that there is a useful attack of the random digit
> > > > generator?
> > > >
> > > > You want to talk reality? Then consider this:
> > > >
> > > > If there is why do I have to give anyone the raw random digit
> > > > output directly from the random digit generator before they
> > > > can make such an attack?
> > >
> > > You don't. However, most peole are willing to spend a few days worth of computer
> > > time to proove a point, more than that and its not worth the effort. Since the
> > > dificulty of attack increases greatly without such, it becomes impractical and
> > > expensive for anyone to do so merely to allow you to see the light. Your cypher
> > > on the whole is (given the attacks against it) probably as strong as the AES
> > > candidates( but not significantly stronger). What we are discussing is
>equivalent
> > > to saying that there is a weakness in the round key generator for such a cypher.
> > > This will NOT compromise a cypher(directly), but it provides a point of attack,
> > > and can remove an algorithim from contention for serious practical usage.
> > >
> > > >
> > > >
> > > > Keep in mind that there is no way this data is going to be
> > > > available in a real life situation.
> > >
> > > Agreed to a point. It certianly is not directly exposed, but the weaknesses it
> > > posesses will result in artifacts in the stream generated that CAN be used to
>make
> > > an (admitedly academic -- it needs truly ridiculous quantities of stream data)
> > > attack against it.
> > >
> > > >
> > > >
> > > > Your questions / points of contention indicate clearly that you
> > > > do not have the software, you have not thoroughly read the Help
> > > > Files, you have not run the examples, you have not done the
> > > > tutorials.
> > >
> > > Really now? I have read your tutorials, examined the software, read what
> > > helpfiles exist, and messed with it enough to familiarize my self with its
> > > function as far as that goes.
> > >
> > > >
> > > >
> > > > You have refused to do your homework.
> > >
> > > You sir, have refused to answer my direct questions, you have accused me of
> > > neglecting to familiarize myself with the topic, and have been generally
> > > uncooperative in nearly all respects. If you are atempting to educate people
> > > about your software, you are sadly deficient in teaching skills.
> > >
> > > >
> > > >
> > > > I do not have any more time to spend with such an unmotivated
> > > > pupil.
> > >
> > > 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. Is it possible, sir, that
> > > you cannot do so?
> > > Here they are again:
> > >
> > > 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)?
> >
> > "time to proove a point"? Prove what point? That there is a flaw
> > in the random digit generator? No flaw exists except in your own
> > imagination. The random digit generator serves a purpose. To
> > this end it has no flaw. You choose to perceive a flaw. But this
> > is because you do not comprehend the purpose of the random digit
> > generator.
>
> Your RNG has a severe flaw in that it leaks key data. Yes, your later steps in which
>the
> raw RNG data is mangled into the actual code stream will to some degree mask this,
>and
> make attack more difficult. I accept that your RNG's flaw is thereby masked.
>However,
> this still leaves your encryption weaker than it is claimed to be. Correct the flaw,
> and your algorihim's strength will increase greatly.Why not do so?
>
> >
> >
> > "without such, it becomes impractical and expensive" (To put it
> > mildly.) When the software is used according to recommended use
> > it becomes practicably impossible, is more like it.
>
> It become very dificult to nearly impossible. If I had serious money at stake then
>the
> cost in time and resources to break your code might be worth it. But I don't, and so
>I
> cannot break your code. OTOH, if I were to have something very valuable that I
>wished
> to protect your code would likely be insulficient as as with such resources a break
>may
> be achieved.
>
> >
> >
> > "This will NOT compromise a cypher(directly), but it provides a
> > point of attack" Oh? Regarding OAP-L3 this claim is completely
> > irrelevant. Again, when used according to recommended use,
> > specifically, when the original random number stream output
> > (0 - 255) is completely and irretrievably lost with subsequent
> > processing, there will be no attacks according to your pointless
> > generalization.
>
> Really? irretrivably lost, huh? I will admit the truncation adds some security, but
>the
> data leaked by the RNG is not "irretrivably gone". Given a byte B is generated as
> output after truncation then we know the following. Treat the digits as seperate
> substreams -- that is how they are generated isn't it? Then given an output value
> B=100*B1+10*B2+B3 we can conclude the following.
>
> then the actual output of the 3 streams call it S=100*S1 +10*S2+ S3 was either B,
>B+256,
> or B+512. this allows us to conclude the following
> S3= either B3, (B3 -6) Mod 10, or (B3-2) mod 10
> S2= either B2, (B2-5) mod 10, or (B2-1) mod 10
> and S1 = either B1, (B1-2) mod 10, or (B1-5) mod 10. in addition 0<=S1<=7 so we can
> always eliminate at least 1 possible form the valuse of S1, in addition since S1
> determines which values get droped any ability we get to guess at S1 also means that
>we
> get closer to guessing where the droped values fall.
>
> True, as I said with all the fiddling you do we cannot exactly predict what the input
> streams are, but we can make predictive guesses, and thus the RNG is somewhat
>exposed.
>
> >
> >
> > "will result in artifacts in the stream generated" Totally
> > ridiculous. I will give you any amount of the final OTP data
> > you think you will need and you will never ever ever deduce the
> > random digit output from the random digit generator or the original
> > MixFiles used as the random digit generator input. You cannot
> > even justify your statement other than to say that you read it
> > somewhere.
>
> Excuse me. If you are going to respond to selected quotes please do not put words
>in my
> mouth. Where in my positng did I say anything about "having read it somewhere"? You
>are
> lying here. This is a DELIBERATE UNTRUTH. Given your output stream, it is possible
>to
> build a statistical model of your Mix Files, and from that statistical model you can
>in
> turn build a model of your keying data. Yes this requires alot of data, time and
> effort, but it can be done. You have shown me nothing in your process that will
>result
> in the RNG artifacts remaining hidden or that compensates for such in even a simple
> manner, other than the truncation, which merely complicates attack, and most
>definitely
> does not render such impossible. You are correct in saying given that data I will not
> generates such -- I do not have that kind of spare time available. If I felt that
>the
> stakes were high enough to justify such an expenditure of time and effort however,
>your
> code would be comprimised.
>
> >
> >
> > You know I am correct if you have read and understand the OAP-L3
> > software, specifically regarding the processing done to the RandOut
> > files and the final generation of the OTP files.
>
> I regret to say that I spent several hours going over that morras of print data you
> claim sulfices as documentation
>
> >
> >
> > "messed with it enough" Clearly not enough.
>
> Perhaps, perhaps not.
>
> >
> >
> > Can any one of you imagine when you were in the university, a
> > student telling his professor that he "messed around" with his
> > homework "enough"? "Yeah, teach. I messed around with your
> > homework enough..."
> >
>
> Yep, and here are the solutions to the exercises that I could solve. You know as
>well
> as I that in higher level courses, you are expected to not always be able to fully
> answer all questions on the homework. What you are doing here is attacking my
>choice of
> words, not responding to my questions. I am still waiting for your reply to any
>serious
> questions that I have presented.
>
> >
> > Then how do you explain your obvious lack of understanding about
> > OAP-L3? What kind of credibility do you bring to this discussion
> > when you admittedly (implicitly) have not done your homework
> > adequately?
>
> By the logic in that paragraph, and the fact that you have not responded to the
> questions that I have asked you have (implicitly) admitted that you are unable to
> respond to my questions in a satisfactory manner, and thereby admited that your code
>is
> inadequate to the job. Come on, be reasonable now. We both know that resorting to
>such
> debator's tricks serves only to obscure the topic at hand. Stop attacking my
>language,
> and answer my questions. Are they so difficult to respond to?
>
> >
> >
> > "Your RNG is flawed" I thought we were talking about the random
> > digit generator.
>
> We were. Sorry that my terminology is confusing. I consider the RNG to be the
>portion
> of the code used to generate the Mix files. Any time that I have refered to such
>that
> is what I have meant. (What you have meant I can only guess, but I have been assuming
> that we were talking about the same thing.) Your documentation regretably lacks
>useful
> labels for the various subsections of the code.
>
> > If you insist: the random number generator
> > outputs the random numbers found in the OTPs. Are you now talking
> > about the OTP random numbers or are you fantasizing about some other
> > numbers. You really must decide what you want to discuss. You
> > are ridiculous if you think there is a flaw in the OTP random
> > numbers. You still have given us no proof of this: not even a
> > plausible glimmer.
>
> The flaw in the generated output stream which you persist in calling "OTP random
> numbers" exists. Follow the data back through the cycle, you can and will see its
> origins.
>
> >
> >
> > Your insistence borders on the insane, and we can be sure of this.
>
> Can we now? I have asked you a set of simple questions that you have yet to respond
> to. All I want is an answer to my questions. If that makes me insane then so be it,
>but
> I think you cannot reply to my questions in a way that makes you look good, so you
> refuse to do so. Here they are again:
>
> 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)?
>
> >
> > The only flaw is in your illogical thoughtless position.
>
> Name calling -- always the sign of a man who is in possession of all the facts, and
>with
> superior logic on his side.
>
> > There is
> > absolutely no flaw in the theory, processes, and procedures of
> > OAP-L3.
>
> Bullshit. The mix file generation has huge flaws in it.
>
> > Show us how you intend to break the OTPs.
>
> Analisys of stream data will yeild good models of the mix files, and from those the
>10
> digit user permutation may be attacked directly, and the other permutes, etc. will
> fallout thereafter.
>
> >
> >
> > Consider the probabilities inherent in the recommended use of
> > OAP-L3 software. Then give up.
>
> Why shoud I quake in my boots in fear of a broken piece of software?
>
> >
>
> >
>
> >
>
> >
> >
> > FACE IT: YOU HAVE BEEN BEATEN BY AN ALGORITHM!
> >
>
> Yep, I have --hundreds of times. There are many algo's that I cannot hope to attack.
> OAP-L3 is NOT one of them however.
>
> >
> > And consider this: you and your phony cronies in this news group
> > are just about out of time.
>
> I have no "cronies" as you claim. I am merely one man voicing one man's opinions. I
>am
> NOT selling anything -- you are, and I'm growing increasingly less likely to buy your
> story.
>
> >
> >
> > Version 4.3 is about to be released. And version 5.0 has been
> > spec'ed out.
>
> >
> >
> > In fact, I have had a working prototype of version 5.0 running for,
> > let me look... over three months now.
> >
> > Version 5.0 will blow everyone away with its variability and power.
> >
> > Isn't this really why you and your phony cronies in this news group
> > are so unnaturally concerned about OAP-L3?
> >
>
> All I asked were some simple questions, and you accuse me of being part of some sort
>of
> "crypto cabal"? Get a clue man, all I want are answers. Give them to me and I will
> either go away, or I will become an ally, is that so hard to understand?
>
> >
> > I think so.
> >
> > You asked me to write a paper. Guess what? There are probably
> > a dozen papers already written on OAP-L3. One is at NSA, another
> > at MI 6, one is in Moscow, another in Tokyo, ... But don't hold
> > your breath waiting for one of these to be published.
>
> You are delusional. What you have done is neither revolutionary nor terribly
>original,
> I strongly doubt the existence of any real analisys of your algoritim -- even by you.
>
> >
> >
> > Perhaps someone else will get around to publishing one. They
> > would certainly get much attention from the experts in the field.
>
> >
> > It would be great publicity for someone. But I recommend they wait
> > until Version 5.0 is released.
> >
> > Here is a suggestion: why don't you write one and highlight your
> > supposed flaws in OAP-L3. Now that would take some guts on your
> > part. Are you not sure enough of your position? I don't think
> > you are. The experts will slaughter you (and your phony cronies as
> > well.) Be sure of it.
>
> Perhaps if I get a few spare hours in the next few days I will.
I will prove you do not know what you are talking about by you
simply answering this question:
The OAP-L3 encryption software uses a random number generator.
Now which of the following is the most correct and most
comprehensive description of this random number generator that
it uses: which is the description that results in the random
numbers used in the encryption process?
1) The process that outputs the random digits from the MixFiles, or
2) the process that results in the OTP files?
Now define precisely what your supposed flaws are and what is the
exact nature of these "artifacts" you allege?
Let me end with this:
The accepted test of the security of an encryption process is not
what Mr. Huuskonen has asked for. The accepted test is that it is
assumed that the cracker knows every thing there is to know about
the algorithm, and that the cracker has a substantial amount of
plain text and the corresponding encrypted text. From this
it is demanded that the cracker use this information and knowledge
to crack the software. This is hardly what Mr. Huuskonen is asking
for: he is essentially asking for the key once removed.
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: Answer me these?
Date: Wed, 19 Apr 2000 22:23:28 -0700
Bo Johnson wrote:
>
> A. Stephoa wrote:
> >Food for thought: What is interesting is that with the hundreds of
> >people who have either OAP-L3 or OAR-L3, not one has come to the
> >aid of any of the detractors of OAP-L3 theory.
>
> What is more interesting is that not one has come to your defense.
Someone did: Dr. Jeff.
But you all ran him out with your ridicule.
No one but I have a substantial interest in presenting this
software in the face of such abuse.
Those who know better don't need any of you to tell them what
to think. They can think for themselves, and I claim they know
your unsupported position is the result of ignorance and intellectual
laziness.
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: Semester 1 / Class #1 All are invited.
Date: Wed, 19 Apr 2000 22:17:29 -0700
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.
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.
------------------------------
** 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
******************************
