Cryptography-Digest Digest #595, Volume #11 Fri, 21 Apr 00 13:13:01 EDT
Contents:
Re: OAP-L3: Semester 1 / Class #1 All are invited. (James Felling)
Re: Very Large S-Boxes VLSB's (Tim Tyler)
Number Theory Book (Antoine Bruguier)
Re: The Illusion of Security (Terry Ritter)
Re: OAP-L3: Semester 1 / Class #1 All are invited. (Tom St Denis)
Re: Can a password be to long? (Paul Koning)
Re: OAP-L3: Semester 1 / Class #1 All are invited. (James Felling)
----------------------------------------------------------------------------
From: James Felling <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: Semester 1 / Class #1 All are invited.
Date: Fri, 21 Apr 2000 11:43:22 -0500
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.
>
> An automobile will crash if the operator does not drive according
> to instructions and safety procedures.
>
> A secretary will not be able to type the bosses correspondence on
> her word processor if the word processor instructions are not
> followed.
>
> OAP-L3 is not secure if you do not follow recommended usage. Yes,
> that is correct.
>
> What have you offered here of any value?
First off, the bad OTP's given were generated by people attempting to use random
picking/shuffling as a
RNG, just as you suggest people do to generate seeds for your code. The data thus
generated had flaws
sulficient to allow partial compromise of OTP data used thereby. What I am saying is
that even if
people attempt to "follow the instructions" this method is still flawed as a means of
generating true
RNGs -- just as flawed as any other generational method.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Very Large S-Boxes VLSB's
Reply-To: [EMAIL PROTECTED]
Date: Fri, 21 Apr 2000 16:11:05 GMT
Diet NSA <[EMAIL PROTECTED]> wrote:
: FAPKC was invented by Tao Renjii in 1985. Tim Tyler [...]
: has a bibliography of Renjii's work. [...]
Exact URL: http://alife.co.uk/ca/publickey/biblio/
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Legalise IT.
------------------------------
From: Antoine Bruguier <[EMAIL PROTECTED]>
Subject: Number Theory Book
Date: Fri, 21 Apr 2000 18:54:18 +0200
Reply-To: [EMAIL PROTECTED]
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 ?
Thanks,
Antoine
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: The Illusion of Security
Date: Fri, 21 Apr 2000 16:57:30 GMT
On Fri, 21 Apr 2000 16:41:57 GMT, in <[EMAIL PROTECTED]>,
in sci.crypt Tom St Denis <[EMAIL PROTECTED]> wrote:
>Mike Kent wrote:
>>
>> Tom St Denis wrote:
>>
>> > UBCHI2 wrote:
>> ...
>> > > Intractable math problem are only in the eye of the beholder. How many of you
>> > > would have thought that the enigma could be broken?
>> >
>> > This is amazingly false.
>>
>> Hmmm, it's _very probably_ amazingly false.
>
>I would like to think all the math-wizards know what they are doing.
>Ciphers along the same idea as DES (i.e feistel) have been around for a
>while.
>
>Of course it's entirely possible that all AES ciphers and pre-aes
>ciphers get broken tommorow. However, that is as likely as monkeys
>learning speech and taking over the world while we are asleep.
True, the original claims were over the top, but this is way beyond
what we know in the other direction. We do not know the strength of
these ciphers. The designers and reviewers do not know the strength
of these ciphers. None of us *can* know strength with respect to
opponents we do not know and whose knowledge and resources we also do
not know.
There exists no basis for asserting that breaking these ciphers is
"unlikely." We have no testable probability distribution for the
breaking of ciphers. If the only thing we have to go on is the
limited published experience, we might well say that every algorithmic
cipher is likely to be broken eventually. And that is precisely the
opposite of your unproven assertion that breaking AES is unlikely.
>Both could happend, but neither will. Of course having a monkey as a
>master isn't a big change for alot of people... hehehe
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: Semester 1 / Class #1 All are invited.
Date: Fri, 21 Apr 2000 17:04:26 GMT
Anthony Stephen Szopa wrote:
>
> Tom St Denis wrote:
> >
> > Anthony Stephen Szopa wrote:
> > > You still don't know what you are talking about.
> >
> > I am going on what I read in the ng.
> >
> > > You are not drawing random digits / numbers from the bottle of
> > > numbered beans, you are drawing random number sequences of the
> > > numbers 1 - 14.
> > >
> > > You say you are in high school?
> > >
> > > Is it a high school for morons?
> >
> > Why yes it is. I saw you graduated from here in 88'. Impressive.
> >
> > > You apparently still have not read the Help Files and certainly
> > > not retained the most basic facts given in them, you think you know
> > > something yet consistently prove you know nothing.
> >
> > Present your ideas in the ng, where you appear to be flaming everyone.
> >
> > > Then you have the nerve to critique my Help Files as being
> > > inadequate, and you have the ridiculous audacity to tell me to
> > > make them more presentable and mature while you are a blithering
> > > knuckle head.
> >
> > replace help file with technically correct paper. Present your ideas
> > properly. Have you ever even read a technical paper?
> >
> > > You have never offered any factual support for even one of your
> > > positions. You can't even write a coherent paragraph. You might
> > > as well forget about going to a university.
> > 7
> > It does require alot of memory.
> >
> > > You are now in the permanent kill file.
> >
> > Along with common sense I will jump in your kill file.
> >
> > > You couldn't give any positive feed back if your life depended on it.
> > >
> > > Who in their right mind would waste anymore of their time with such
> > > a jerk?
> >
> > Because I asked questions about your method and you don't respond.
> >
> > Tom
>
> Wait until I sink my teeth into you later today.
>
> Then hopefully you will leave this news group with your tail / tale
> between your legs.
Answer our questions. If you can't why not just stop posting about your
software?
Tom
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: Can a password be to long?
Date: Fri, 21 Apr 2000 12:35:07 -0400
John wrote:
>
> I know passwords can be to shrot, but I recall reading
> somewhere, a long time ago, about being to long. Is this true.
Depends on how it is used. If you run the password through
a one way hash or something like that, then no, it is not
true.
paul
------------------------------
From: James Felling <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: Semester 1 / Class #1 All are invited.
Date: Fri, 21 Apr 2000 12:04:45 -0500
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?)
------------------------------
** 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
******************************
