Cryptography-Digest Digest #669, Volume #11 Sun, 30 Apr 00 09:13:00 EDT
Contents:
Re: OAP-L3: Semester 1 / Class #1 All are invited. (Tom St Denis)
Re: OAP-L3: Secure, but WAY more dificult to use than other equally
secure programs (Anthony Stephen Szopa)
Re: OAP-L3: Secure, but WAY more dificult to use than other (Tom St Denis)
Re: Janet and John learn about bits (was Re: Problems with OAP-L3) (Anthony Stephen
Szopa)
Re: Janet and John learn about bits (was Re: Problems with OAP-L3) (Anthony Stephen
Szopa)
Re: Janet and John learn about bits (was Re: Problems with OAP-L3) (Anthony Stephen
Szopa)
Re: Janet and John learn about bits (was Re: Problems with OAP-L3) (Anthony Stephen
Szopa)
Re: Janet and John learn about bits (was Re: Problems with OAP-L3) (Mark Wooding)
Re: OAP-L3: Semester 1 / Class #1 All are invited. (Anthony Stephen Szopa)
----------------------------------------------------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: Semester 1 / Class #1 All are invited.
Date: Sun, 30 Apr 2000 12:11:25 GMT
Anthony Stephen Szopa wrote:
> We are talking about encryption.
>
> We ARE talking about secure encryption.
Gotcha so far.
> If a random number generator is used for a purpose that does
> not require security are you saying that it may somehow be
> insecure for that use?
We are not talking about random number generators though.
> Crazy thinking.
I'll bet.
> It may be unsuitable for some reason but not insecure.
>
> T.H. is talking about the random digit generator from which he will
> never obtain any useful input in practice for his supposed method of
> determining the MixFile sequences.
>
> T.H. is making up his own problem and ignoring the OAP-L3
> implementation as it currently exists in an attempt to cast some
> sort of doubt over OAP-L3.
I already posted my problems, which you have yet to answer to.
> He cannot answer a question by changing the question or imagining
> another question.
By "he" you are referring to yourself?
> The question is whether or not OAP-L3 is secure. I say it is
> secure: it is unbreakable when used according to
> recommendations with a sufficiently long key. The Theory and
> Processes Help Files support my position.
>
> I have yet to hear or see any evidence to the contrary after three
> years. I am still waiting.
Ok I will use your program and enter completely biased seeds... How
secure is it now?
Why not answer some of *MY* questions instead of changing the topic
yourself.
Tom
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: Secure, but WAY more dificult to use than other equally
secure programs
Date: Sun, 30 Apr 2000 05:13:28 -0700
Richard Heathfield wrote:
>
> Tom St Denis wrote:
> >
> > Anthony Stephen Szopa wrote:
> > >
> > > Tom St Denis wrote:
> > > >
> > > > > So you should not waste anymore of your time conversing with me.
> > > > > There are plenty of other suckers out there for your delectation.
> > > >
> > > > You see, you didn't respond to my questions. You just targteted *me*.
> > > > How about you focus on your 'theory' and less the posters.
> > > >
> > > > Face it, your a troll.
> > > >
> > > > Tom
> > >
> > > Take my advice:
> > >
> > > Don't waste your breath.
> >
> > ARrg.. why don't you answer a real question?
> >
>
> I am reminded of Saruman, arguing with hobbits. It (such banter) was a
> clear sign that, whatever mastery of his art he had once had, he had
> lost it. Whatever majesty he might have commanded, he was now nothing
> but an itinerant beggar.
>
> The hobbits came out of it far better than Saruman, if I recall
> correctly.
>
> I'm not sure why anyone is wasting time arguing with this guy. He's
> clearly bright but, equally clearly, he's either an idiot or an idiot. I
> don't know much about cryptography, but I do know this: no source code,
> no trust. No algorithm, no trust. Mr Szopa's security should be placed
> in his key - not in his algorithm, his source code, or his incendiary
> rhetoric. And his algorithm does not place all the security in the key.
> If it did, he'd be falling over himself trying to prove it by showing
> the algorithm and the source. Instead, he's doing his best to convince
> us that he's an idiot and, on the whole, he's succeeding. Anyone who
> hurls abuse at teenagers and flames Doug Gwyn in the /same thread/ is
> clearly a few bits short of a byte.
>
> A thread plonk is tempting, but on the other hand it's mildly amusing to
> see just how deep a hole Mr Szopa can dig for himself before he finally
> sees what he's done to his reputation.
>
> --
>
> Richard Heathfield
>
> "Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
>
> C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
> 34 K&R Answers: http://users.powernet.co.uk/eton/kandr2/index.html (63
> to go)
You are better off ignoring the OAP-L3 encryption software package
along with its Help Files.
You need at least average intelligence to understand it.
Interesting how difficult OAP-L3 is proving for most of those in
this news group.
You would laugh your ass off if you only knew how many people in
this news group have been spending serious time contemplating the
OAP-L3 theory and its security.
It is just too intriguing to ignore for the true enthusiast or the
professional.
It is just too valuable for anyone seeking truly unbreakable
encryption to ignore as well.
My reputation? What better way to establish one's reputation than
one's work. All other considerations are secondary: and a distant
secondary at that.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: Secure, but WAY more dificult to use than other
Date: Sun, 30 Apr 2000 12:20:14 GMT
Anthony Stephen Szopa wrote:
> You are better off ignoring the OAP-L3 encryption software package
> along with its Help Files.
>
> You need at least average intelligence to understand it.
>
> Interesting how difficult OAP-L3 is proving for most of those in
> this news group.
Well I have a prng too, it works like this
1. Take a "mixfile"
2. Send it thru some processes
3. Then take several other "mixfiles" and put them thru some processes
4. Output a digit, wow.
> You would laugh your ass off if you only knew how many people in
> this news group have been spending serious time contemplating the
> OAP-L3 theory and its security.
Zero.
> It is just too intriguing to ignore for the true enthusiast or the
> professional.
>
> It is just too valuable for anyone seeking truly unbreakable
> encryption to ignore as well.
http://www.pgpi.com
????
> My reputation? What better way to establish one's reputation than
> one's work. All other considerations are secondary: and a distant
> secondary at that.
How about documenting the bloody thing. Provide some clear source code
as well so the "others" can try it out, or are you afraid you are not
upto it?
Tom
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Subject: Re: Janet and John learn about bits (was Re: Problems with OAP-L3)
Date: Sun, 30 Apr 2000 05:19:25 -0700
Richard Heathfield wrote:
>
> Anthony Stephen Szopa wrote:
> >
> > "Douglas A. Gwyn" wrote:
> > >
> > > Tom St Denis wrote:
> > > > 3) Why perms of 0-9? You waste alot of space that way, why not 0-16 or
> > > > 0-255?
> > >
> > > Yes, that is an obvious question that deserves an answer.
> > > I have my own theory as to the *real* answer to that,
> > > but let's use this question as a "litmus test" to see
> > > whether OAP-L3's author sincerely wants us to understand
> > > his system.
> >
> <snip>
> >
> > I am not sure if it is in the Help Files but it is in the patent
> > application that there is no restriction on number base. Base 16
> > could be used. The problem with Base 16 is that there would then be
> > 16! possible unique permutations of the hex digits 0 - 15 and current
> > pc computers are too slow to take advantage of the greater security
> > Base 16 would provide. Also storage requirements may pose a problem,
> > etc.
> >
>
> [Disclaimer: I'm not a cryptologist.]
>
> I find it surprising that anyone can attempt to defend their
> cryptographic technique when they don't understand about
> security-in-the-key, or killfiles (Mr Szopa's killfile seems to work
> more as a slightly-woundedfile) - but when they don't even understand
> about storage requirements, surprise is no longer adequate and, like Mr
> Adams, I am forced to resort to astonishment.
>
> Let's deal with the "storage requirements problem" first. And it looks
> like we'll have to go back to first principles to do so.
>
> Most modern computers use lots and lots of bits, each of which can store
> one of two values, 0 or 1.
>
> A combination of four bits is required, therefore, to store the digits 0
> through 9.
>
> 0000 - 0 0001 - 1
> 0010 - 2 0011 - 3
> 0100 - 4 0101 - 5
> 0110 - 6 0111 - 7
> 1000 - 8 1001 - 9
>
> The numbers 0 through 99 can thus be represented in one 8-bit byte.
> (Bytes need not be 8 bits, but I see no need to go down that road right
> now.) To store a value such as 16304791, then, we need 4 bytes. This
> encoding system (or a slight modification of it) is sometimes known as
> binary coded decimal.
>
> If we extend our numbering sequence to encompass the hexits A, B, C, D,
> E, F to represent 10 through 15 decimal, we can extend our 4-bit table
> to include
>
> 1010 - A 1011 - B
> 1100 - C 1101 - D
> 1110 - E 1111 - F
>
> We can now store values 0 through 255 in one 8-bit byte. Much more
> efficient. We can now store 16304791 in hexadecimal as F8CA97, giving a
> storage requirement of only 3 bytes.
>
> It is therefore more efficient to store values in base 16 than in base
> 10. More values can be stored in fewer bytes, because no bits are
> wasted.
>
> If your algorithm is such that you need factorial(NUMBER_BASE) bytes or
> nybbles of storage, then your claim that you can use any number base is
> clearly false. Even using base 10, are you seriously telling me that you
> need (either 1.75 or) 3.5 Megabytes of memory or disk space (10! is
> actually 3628800), just to /encrypt/ stuff? What planet are you on? In
> the real world, we like our utility applications to use less memory than
> that. A lot less. Remember that encryption provides no benefits. It only
> stops other people reading your stuff. That's not a positive benefit,
> just a (perhaps vital) prevention mechanism. Important, but not
> something that adds value to an enterprise. So it should be as
> unobtrusive as possible. 3 megabytes is not unobtrusive.
>
> Now let's address the other point, that of speed. I have several
> computers in my study. The most powerful is a Pentium II/400MHz machine.
> Admittedly, it runs Windows NT, but nevertheless it's still pretty
> quick.
>
> If we have two cryptography applications, one of which uses its memory
> efficiently, runs on my PII/400 at an acceptable speed, and offers me
> reliable security, and the other which doesn't use its memory
> efficiently, runs on my 400 MHz box at a speed which even its author
> says is far too slow, and is based on source code which has not been
> published and therefore has not had the chance to be validated by the
> cryptographic community - thus making its security untrustworthy - which
> application do you think anyone with a brain will buy?
>
> --
>
> Richard Heathfield
>
> "Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
>
> C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
> 34 K&R Answers: http://users.powernet.co.uk/eton/kandr2/index.html (63
> to go)
It is clear you do not undersand the software adequately.
If you want to use base 16 then you will have 16! possible
permutations of the digits 0 - F to work with. This is a big
number.
Modern PCs can handle perhaps base 11 using my system if they
are fast enough and have lots of storage. But I still think
it is impracticable and not necessary.
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Subject: Re: Janet and John learn about bits (was Re: Problems with OAP-L3)
Date: Sun, 30 Apr 2000 05:21:55 -0700
Tom St Denis wrote:
>
> Richard Heathfield wrote:
> >
> > Anthony Stephen Szopa wrote:
> > >
> > > "Douglas A. Gwyn" wrote:
> > > >
> > > > Tom St Denis wrote:
> > > > > 3) Why perms of 0-9? You waste alot of space that way, why not 0-16 or
> > > > > 0-255?
> > > >
> > > > Yes, that is an obvious question that deserves an answer.
> > > > I have my own theory as to the *real* answer to that,
> > > > but let's use this question as a "litmus test" to see
> > > > whether OAP-L3's author sincerely wants us to understand
> > > > his system.
> > >
> > <snip>
> > >
> > > I am not sure if it is in the Help Files but it is in the patent
> > > application that there is no restriction on number base. Base 16
> > > could be used. The problem with Base 16 is that there would then be
> > > 16! possible unique permutations of the hex digits 0 - 15 and current
> > > pc computers are too slow to take advantage of the greater security
> > > Base 16 would provide. Also storage requirements may pose a problem,
> > > etc.
> > >
> >
> > [Disclaimer: I'm not a cryptologist.]
> >
> > I find it surprising that anyone can attempt to defend their
> > cryptographic technique when they don't understand about
> > security-in-the-key, or killfiles (Mr Szopa's killfile seems to work
> > more as a slightly-woundedfile) - but when they don't even understand
> > about storage requirements, surprise is no longer adequate and, like Mr
> > Adams, I am forced to resort to astonishment.
> >
> > Let's deal with the "storage requirements problem" first. And it looks
> > like we'll have to go back to first principles to do so.
> >
> > Most modern computers use lots and lots of bits, each of which can store
> > one of two values, 0 or 1.
> >
> > A combination of four bits is required, therefore, to store the digits 0
> > through 9.
> >
> > 0000 - 0 0001 - 1
> > 0010 - 2 0011 - 3
> > 0100 - 4 0101 - 5
> > 0110 - 6 0111 - 7
> > 1000 - 8 1001 - 9
> >
> > The numbers 0 through 99 can thus be represented in one 8-bit byte.
> > (Bytes need not be 8 bits, but I see no need to go down that road right
> > now.) To store a value such as 16304791, then, we need 4 bytes. This
> > encoding system (or a slight modification of it) is sometimes known as
> > binary coded decimal.
> >
> > If we extend our numbering sequence to encompass the hexits A, B, C, D,
> > E, F to represent 10 through 15 decimal, we can extend our 4-bit table
> > to include
> >
> > 1010 - A 1011 - B
> > 1100 - C 1101 - D
> > 1110 - E 1111 - F
> >
> > We can now store values 0 through 255 in one 8-bit byte. Much more
> > efficient. We can now store 16304791 in hexadecimal as F8CA97, giving a
> > storage requirement of only 3 bytes.
>
> When you do something like
>
> long a = 16304791;
>
> You need not convert it to hex to store it. My complaint about the
> waste of space is that a permutation is normally stored as
>
> int perm[10] = { ... }
>
> and you store them serially (even as 4 bits you are wasting space).
> Also note that not all numbers between 0 and 2^24 - 1 (3 bytes) are
> possible so again you are wasting space...
>
> My point was why doesn't he use a permutation of a power of two and not
> waste space? Like 0..7 or 0..15 ?
>
> > It is therefore more efficient to store values in base 16 than in base
> > 10. More values can be stored in fewer bytes, because no bits are
> > wasted.
>
> This is not true.
>
> > If your algorithm is such that you need factorial(NUMBER_BASE) bytes or
> > nybbles of storage, then your claim that you can use any number base is
> > clearly false. Even using base 10, are you seriously telling me that you
> > need (either 1.75 or) 3.5 Megabytes of memory or disk space (10! is
> > actually 3628800), just to /encrypt/ stuff? What planet are you on? In
> > the real world, we like our utility applications to use less memory than
> > that. A lot less. Remember that encryption provides no benefits. It only
> > stops other people reading your stuff. That's not a positive benefit,
> > just a (perhaps vital) prevention mechanism. Important, but not
> > something that adds value to an enterprise. So it should be as
> > unobtrusive as possible. 3 megabytes is not unobtrusive.
>
> This is true.
>
> > Now let's address the other point, that of speed. I have several
> > computers in my study. The most powerful is a Pentium II/400MHz machine.
> > Admittedly, it runs Windows NT, but nevertheless it's still pretty
> > quick.
> >
> > If we have two cryptography applications, one of which uses its memory
> > efficiently, runs on my PII/400 at an acceptable speed, and offers me
> > reliable security, and the other which doesn't use its memory
> > efficiently, runs on my 400 MHz box at a speed which even its author
> > says is far too slow, and is based on source code which has not been
> > published and therefore has not had the chance to be validated by the
> > cryptographic community - thus making its security untrustworthy - which
> > application do you think anyone with a brain will buy?
>
> Or just use. Why do you have to buy good crypto programs? If you have
> enough time on your hands you can even write your own.
>
> Mr Szopa has some thinking todo about making his algorithm(s) not only
> public but efficient.
>
> Tom
> --
> Want your academic website listed on a free websearch engine? Then
> please check out http://tomstdenis.n3.net/search.html, it's entirely
> free
> and there are no advertisements.
It will be public in about 20 years.
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Subject: Re: Janet and John learn about bits (was Re: Problems with OAP-L3)
Date: Sun, 30 Apr 2000 05:28:40 -0700
Richard Heathfield wrote:
>
> Tom St Denis wrote:
> >
> > Richard Heathfield wrote:
> > >
> > > [Disclaimer: I'm not a cryptologist.]
> > >
> >
> > When you do something like
> >
> > long a = 16304791;
> >
> > You need not convert it to hex to store it.
>
> I agree entirely. I was not arguing that you needed to.
>
> > My complaint about the
> > waste of space is that a permutation is normally stored as
> >
> > int perm[10] = { ... }
> >
> > and you store them serially (even as 4 bits you are wasting space).
>
> I'm not exactly sure what you mean. If you're saying that a number such
> as 16304791 is being stored as
>
> int perm[10] = { 0, 0, 1, 6, 3, 0, 4, 7, 9, 1 } then I'd have to
> heartily agree that this is a blatant waste of space.
>
> >
> > My point was why doesn't he use a permutation of a power of two and not
> > waste space? Like 0..7 or 0..15 ?
>
> I thought that was my point too.
>
> > > It is therefore more efficient to store values in base 16 than in base
> > > 10. More values can be stored in fewer bytes, because no bits are
> > > wasted.
> >
> > This is not true.
>
> It very much depends how you're storing it. Consider the number
> 16304791, which is suitably random :-)
>
> If we store it like this:
>
> unsigned long num = 16304791;
>
> then base simply isn't an issue, and your objection is correct. But that
> wasn't what I thought you meant. I was under the impression that you
> were complaining about:
>
> unsigned char num[] = { 0x16, 0x30, 0x47, 0x91 }; /* binary coded
> decimal (almost!) - wastes 6 combinations per nybble */
>
> as opposed to
>
> unsigned char num[] - { 0xF8, 0xCA, 0x97 }; which is clearly more
> efficient, as it uses all the bits available to it.
>
> So perhaps we're in violent agreement?
>
> > > If we have two cryptography applications, one of which uses its memory
> > > efficiently, runs on my PII/400 at an acceptable speed, and offers me
> > > reliable security, and the other which doesn't use its memory
> > > efficiently, runs on my 400 MHz box at a speed which even its author
> > > says is far too slow, and is based on source code which has not been
> > > published and therefore has not had the chance to be validated by the
> > > cryptographic community - thus making its security untrustworthy - which
> > > application do you think anyone with a brain will buy?
> >
> > Or just use. Why do you have to buy good crypto programs?
>
> I agree entirely. Just roll your own...
>
> > If you have enough time on your hands you can even write your own.
>
> Ah, I don't have enough time on my hands. But I'm trying to write my own
> anyway <g>. Unfortunately, I'm too inexperienced in cryptanalysis to
> perform serious cryptanalytic attacks on my own code, let alone other
> people's. (I've cracked a couple of 'unbreakable' algorithms presented
> to me by other would-be cryptographers, but these were only 'kid-sister
> unbreakable', of course.)
>
> >
> > Mr Szopa has some thinking todo about making his algorithm(s) not only
> > public but efficient.
> >
>
> Possibly, but that's not his main problem. He has some really serious
> thinking to do about his ability to deal with fellow professionals in a
> professional way. It seems that anyone who dares take issue with him is
> instantly killfiled - in a mysterious and magical process which allows
> Mr Szopa to read their posts anyway, presumably so that he can killfile
> them again, and again, and again.
>
> When he learns to talk to grown-ups as if they are grown-ups, I suspect
> he can look forward to some excellent help from the heavyweight computer
> scientists in this newsgroup (Doug Gwyn and so on) in making his
> algorithm efficient.
>
> --
>
> Richard Heathfield
>
> "Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
>
> C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
> 34 K&R Answers: http://users.powernet.co.uk/eton/kandr2/index.html (63
> to go)
You are not just storing a number. You are storing a permutation array
because you need to be able to access each element of the
permutation to access any digit of the permutation stored there
when you run the processes.
Do you still think you know as much about what you are talking
about as you thought?
Maybe you need to think about the implications of what I just said.
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Subject: Re: Janet and John learn about bits (was Re: Problems with OAP-L3)
Date: Sun, 30 Apr 2000 05:35:33 -0700
Tom St Denis wrote:
>
> Richard Heathfield wrote:
> > unsigned char num[] = { 0x16, 0x30, 0x47, 0x91 }; /* binary coded
> > decimal (almost!) - wastes 6 combinations per nybble */
> >
> > as opposed to
> >
> > unsigned char num[] - { 0xF8, 0xCA, 0x97 }; which is clearly more
> > efficient, as it uses all the bits available to it.
> >
> > So perhaps we're in violent agreement?
>
> No since not all combinations of 3 byte values are possible you are
> still wasting space. That was my point.
>
> >
> > > > If we have two cryptography applications, one of which uses its memory
> > > > efficiently, runs on my PII/400 at an acceptable speed, and offers me
> > > > reliable security, and the other which doesn't use its memory
> > > > efficiently, runs on my 400 MHz box at a speed which even its author
> > > > says is far too slow, and is based on source code which has not been
> > > > published and therefore has not had the chance to be validated by the
> > > > cryptographic community - thus making its security untrustworthy - which
> > > > application do you think anyone with a brain will buy?
> > >
> > > Or just use. Why do you have to buy good crypto programs?
> >
> > I agree entirely. Just roll your own...
> >
> > > If you have enough time on your hands you can even write your own.
> >
> > Ah, I don't have enough time on my hands. But I'm trying to write my own
> > anyway <g>. Unfortunately, I'm too inexperienced in cryptanalysis to
> > perform serious cryptanalytic attacks on my own code, let alone other
> > people's. (I've cracked a couple of 'unbreakable' algorithms presented
> > to me by other would-be cryptographers, but these were only 'kid-sister
> > unbreakable', of course.)
>
> Well it's one thing to take already developed and analyzed algorithms
> and stick it together, and it's another thing *entirely* to invent your
> own ciphers at the same time. If you want a 5kb file crypto program
> just take RC4 and a hash (say md2) and write a small program (I have
> done it more then once.... :)).
>
> > >
> > > Mr Szopa has some thinking todo about making his algorithm(s) not only
> > > public but efficient.
> > >
> >
> > Possibly, but that's not his main problem. He has some really serious
> > thinking to do about his ability to deal with fellow professionals in a
> > professional way. It seems that anyone who dares take issue with him is
> > instantly killfiled - in a mysterious and magical process which allows
> > Mr Szopa to read their posts anyway, presumably so that he can killfile
> > them again, and again, and again.
> >
> > When he learns to talk to grown-ups as if they are grown-ups, I suspect
> > he can look forward to some excellent help from the heavyweight computer
> > scientists in this newsgroup (Doug Gwyn and so on) in making his
> > algorithm efficient.
>
> Well the pros are really turned off from him, so at best he will have to
> deal with the-less-than-amateurish people like You and I....
>
> Tom
> --
> Want your academic website listed on a free websearch engine? Then
> please check out http://tomstdenis.n3.net/search.html, it's entirely
> free
> and there are no advertisements.
You say writing encryption software is easy. You've done it? Just
do this and just do that?
Who wants just "adequate" or "okay" encryption software? We've got
plenty of that already.
The gold medal goes to creating unbreakable encryption... And
creating it first.
I claim to have created unbreakable encryption software. And I
can provide anyone with the software to see for themselves. The
Help Files describe OAP-L3, and the Theory and Processes Help Files
prove my claim.
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Janet and John learn about bits (was Re: Problems with OAP-L3)
Date: 30 Apr 2000 12:40:55 GMT
Tom St Denis <[EMAIL PROTECTED]> wrote:
> I am talking about using MD2 to hash the password+salt so you don't
> actually see the output ever.
Ahh. I'd still use a good hash function, though. And I'd also consider
adding a MAC, just to protect against modifications.
-- [mdw]
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Subject: Re: OAP-L3: Semester 1 / Class #1 All are invited.
Date: Sun, 30 Apr 2000 05:48:53 -0700
Tim Tyler wrote:
>
> In sci.crypt James Felling <[EMAIL PROTECTED]> wrote:
>
> : [...] 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.
>
> "Bias" is a technical term with a definition that implies that it can
> be rather easy to generate streams with *absolutely* no bias.
>
> Perhaps you should say what you mean by this term if your definition
> differs - if, say, you're using it as something like a synonym for
> "deviations from randomness".
> --
> __________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
> |im |yler The Mandala Centre http://mandala.co.uk/ Be good, do good.
Even true random processes have significant bias over relatively
short runs. The longer the run the less the bias. The bias may
never disappear but it will most certainly shift. The problem is
identifying this bias.
OAP-L3 produces the same sort of output as a true random process
once the key reaches sufficient length, this length being, in part,
the point where brute force attack becomes infeasible.
------------------------------
** 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
******************************
