Cryptography-Digest Digest #412, Volume #11 Fri, 24 Mar 00 13:13:01 EST
Contents:
Re: "THE DES, An Extensive Documentation and Evaluation" - from Aegean ("John A.
Malley")
Pseudo random sequences test ([EMAIL PROTECTED])
Re: Re-seeding PRNG's in central key distribution systems (Tim Tyler)
Re: OAP-L3: Answer me these? ("Anthony Stephen Szopa")
Re: OAP-L3: Answer me these? (Tim Tyler)
Re: OAP-L3: Answer me these? (Boris Kazak)
Re: what is a 2048 bit cipher? (Tim Tyler)
Re: OAP-L3: Answer me these? ("Anthony Stephen Szopa")
Re: implementing rot13 (Robert Harley)
Re: what is a 2048 bit cipher? ("Tom St Denis")
Re: OFB, CFB, ECB and CBC ("Scott Fluhrer")
Re: Open source or not. (Was: Re: Planet Poker Claims...)
([EMAIL PROTECTED])
Re: nsa patent on new storage device (John Savard)
Re: "THE DES, An Extensive Documentation and Evaluation" - from Aegean Press.
(John Savard)
Re: Hashes! (newbie question) (Boris Kazak)
Re: ecc equation ("Tom St Denis")
Re: OAP-L3: Answer me these? (James Felling)
Re: OFB, CFB, ECB and CBC (James Felling)
Re: OAP-L3: Answer me these? (Volker Hetzer)
Re: Hashing Algorithms. (basic newbie question) (wtshaw)
----------------------------------------------------------------------------
From: "John A. Malley" <[EMAIL PROTECTED]>
Subject: Re: "THE DES, An Extensive Documentation and Evaluation" - from Aegean
Date: Fri, 24 Mar 2000 08:19:38 -0800
"Douglas A. Gwyn" wrote:
>
>
> > If you bought it and read it, would you recommend it to someone
> > interested in learning more about differential and linear
> > cryptanalysis?
>
> That depends: "more" than what? It has nice explanations as
> far as their application to DES. I think it's a pretty good
> book, overall.
>
Thank you for the info.
"learning more about differential and linear cryptanalysis" meant
learning more than the just the fact these cryptanalysis techniques
exist and a description of how the analysis is done with a single
example for each technique. I'm looking for instructional texts that
compare and contrast variations of features of a block cipher with
resulting improved strengths or greater weaknesses with respect to
cryptanalysis techniques through examples and through problems for the
student.
Given "it's a pretty good book overall" and the fact I strongly respect
your opinions on cryptology, I will order the book.
John A. Malley
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED]
Subject: Pseudo random sequences test
Date: Fri, 24 Mar 2000 16:06:14 GMT
What could be the equivalent of Maurer's Universal Test for pseudorandom
sequences ?
Thank you
O.D.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Re-seeding PRNG's in central key distribution systems
Reply-To: [EMAIL PROTECTED]
Date: Fri, 24 Mar 2000 16:16:08 GMT
Mark Currie <[EMAIL PROTECTED]> wrote:
: If the private RSA prime factors p & q are found using the output of a prng,
: it may be possible for a user (knowing his private keys p & q) to predict
: what other user's private keys are.
: Since his p or q (depending on which one was generated last) can reflect
: the last state of the prng, he can predict what the next state will be.
*Only* if a terminally broken PRNG is used.
: In general when using a central key distribution system, it should be a rule
: that if a prng is used then it MUST be re-seeded from a quality random
: source before each new key set is generated. This might seem obvious [...]
The solution need not involve reseeding the PRNG. Simply don't use an
insecure one that allows prediction of all subsequent states from a tiny
quantity of its output.
There are *plenty* of RNGs that fit this bill in the literature.
Using a genuinely random source for key generation is no doubt recommended
- but use of a PRNG does *not* necessarily fail to this sort of attack.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
666,000 - number of the kilobeast.
------------------------------
From: "Anthony Stephen Szopa" <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: Answer me these?
Date: Fri, 24 Mar 2000 08:32:56 -0800
It is quite clear that both Mr. Hetzer and Mr. Ashwood are seriously
disoriented. The theory, and specification of the procedures and
processes, have been available at the web site in the posted Help
Files for some time now and this fact has repeatedly been stated in
these news groups.
You can believe in any personal "reality" you want to fantasize. Some of
you can share your fantasies. Have fun.
Volker Hetzer <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Anthony Stephen Szopa wrote:
>
> > You are sure a great talker. I wonder how many of you are busily
> > studying OAP-L3 theory,
> Everybody who has *access* to that theory. Which is -- nobody.
>
> > It appears that you (and most others) have willfully chosen not to
> > address the theory, and specification of the procedures and
> > processes. This should be noted by all readers to this news group.
> Tell us the theory, then we'll address it.
>
> > It appears that the attack has admittedly been chosen to be an
> > attack on the implementation. No other options?
> Nobody has bothered to "choose" an attack. The goal is to point
> out weaknesses. If you want it for free, provide the source code.
>
> > I thank many of you for unintentionally giving me such credibility
> > (short-lived or not.)
> This is not a chatroom, y'know? People take their time to follow
> threads and look up references (and funny patents). So, forget it.
>
>
> > By the way, OAP-L3 Version 4.3 will be available in about a week
> > or so. Six new processes are being added to mix things up even
> > more.
> Wow! The more "processes", the more secure. I'm impressed.
>
> Volker
> --
> Hi! I'm a signature virus! Copy me into your signature file to help me
spread!
>
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: OAP-L3: Answer me these?
Reply-To: [EMAIL PROTECTED]
Date: Fri, 24 Mar 2000 16:21:46 GMT
In sci.crypt Tom St Denis <[EMAIL PROTECTED]> wrote:
: A keyspace of more then say 160 bits is a waste of resources....
So, the One-Time-Pad is dead, then? ;-)
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
I came, I saw, I deleted all your files.
------------------------------
From: Boris Kazak <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: Answer me these?
Date: Fri, 24 Mar 2000 16:48:45 GMT
Quote from your Web site:
Major software components:
1) Random Number Generator
2) XOR Routine (!?!)
3) File Management
4) Utility Programs
5) Help Files including Tutorials
Two observations:
a) XOR is just an elementary processor instruction,
somebody elevating it to the status of "Routine" and
listing it as a "Major software component"
immediately sounds illiterate to the extent of total
incomprehension. If this is so, it is a real problem.
b) Still there is no mentioning of algorithm description
or source text files. Tutorial is the documentation for
a driver, what people here are asking for is the manual
for a detailer-repairman. If you don't comprehend it,
then see (a).
Additional note: Do not expect people to analyze and to
reverse-engineer your OAP stuff - nobody in his right mind
will do it for free. They just reasonably assume that this
encryption might be weak - using it without knowing what
is happening inside is just a gamble with unknown odds.
Finally, there is an old adage - you keep your source code
secret only if you are ASHAMED of it. Sic...
Best wishes BNK
====================================
Anthony Stephen Szopa wrote:
>
> Joseph Ashwood wrote:
***
> > First we need to see your algorithms, but you don't want to
> > reveal those.
> > ***
> > Joe
> *******
> You are sure a great talker. I wonder how many of you are busily
> studying OAP-L3 theory, and procedures and processes all the while
> "dissing" OAP-L3 and evading the software publicly? I think some
> of you should be suspicious. When opportunity knocks there are
> those who know enough to answer the door. Some disperse smoke
> screens to confuse others. Bill Gates jumped on an opportunity
> while nearly everyone else remained clueless. How many of you are
> CHOOSING to remain clueless?
>
> It appears that you (and most others) have willfully chosen not to
> address the theory, and specification of the procedures and
> processes. This should be noted by all readers to this news group.
*************
> http://www.ciphile.com
>
> Original Absolute Privacy - Level3 Encryption Software Package
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: what is a 2048 bit cipher?
Reply-To: [EMAIL PROTECTED]
Date: Fri, 24 Mar 2000 16:32:49 GMT
Tom St Denis <[EMAIL PROTECTED]> wrote:
: What the heck is a 2048-bit cipher? Is that a block size of 2048 bits? or
: 2048 bit keyspace?
>From the look of existing stream cyphers, it /usually/ seems to mean a
2048-bit keyspace.
: So how do ciphers and algorithms fall? Cryptanalysis. [...]
Indeed. Pumping up your keyspace is very likely to increase the
difficulties experienced by analysts. Of course, even 2048 bit
cyphers can be broken...
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Interior decorators do it all over the house.
------------------------------
From: "Anthony Stephen Szopa" <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: Answer me these?
Date: Fri, 24 Mar 2000 08:37:18 -0800
Thanks for showing us again that you are unable to address the theory,
and specification of the procedures and processes, and have chosen to
challenge the implementation.
http://www.ciphile.com
OAP-L3 Version 4.3 to be released in about a week. Six new MixFile
processes are being added.
Trevor L. Jackson, III <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Anthony Stephen Szopa wrote:
>
> > OAP-L3: Answer me these?
> >
> > Where is the bias in any of the procedures and processes in OAP-L3?
> >
> > Where is any bias introduced into any of the procedures and processes
> > found in OAP-L3 when used according to recommendations?
> >
> > What conclusions can we draw if there are no biases in any of the
> > procedures and processes, and no biases introduced in
> > any of the procedures and processes used in OAP-L3?
>
> The more important conclusion is drawn from the fact that you refuse to
> provide sufficient information for an objective observer to determine
whether
> biases exist or not. But I'll offer an inducement that you may find
useful as
> an endorsement. I'll put up $1,000.00. You put up $10,000.00, and
publish
> all of your source code. If no one finds any flaws in your product within
60
> days you keep my money, and you get to advertise the fact that you
software is
> flawless. Otherwise I'll split your money with the people who find the
flaws
> in your software.
>
> Now if you are are right about the quality of OAP-L3 you stand to make a
quick
> grand. You _do_ believe in your software don't you?
>
------------------------------
From: Robert Harley <[EMAIL PROTECTED]>
Subject: Re: implementing rot13
Date: 24 Mar 2000 17:49:22 +0100
> >for ( char *s=string; *s; s++)
> > *s += isalpha(*s) ? (toupper(*s)<('A'+13))*26-13 : 0;
> Cute.
> Okay, the gauntlet has been thrown -- who can do it in even
> fewer (non-whitespace) characters?
Here's one I prepared earlier (about 6 years ago, actually):
main(g,h){for(;h=getchar(),h>=0;putchar(g<65||g>90?h:g<78?h+13:h-13))g=h&223;}
Bye,
Rob.
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: what is a 2048 bit cipher?
Date: Fri, 24 Mar 2000 17:00:28 GMT
Tim Tyler <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
> Tom St Denis <[EMAIL PROTECTED]> wrote:
>
> : What the heck is a 2048-bit cipher? Is that a block size of 2048 bits?
or
> : 2048 bit keyspace?
>
> From the look of existing stream cyphers, it /usually/ seems to mean a
> 2048-bit keyspace.
>
> : So how do ciphers and algorithms fall? Cryptanalysis. [...]
>
> Indeed. Pumping up your keyspace is very likely to increase the
> difficulties experienced by analysts. Of course, even 2048 bit
> cyphers can be broken...
You are so wrong. Making the keyspace large is only effective if your
algorithm is secure. So even a cipher with a 80 bit key would be secure by
todays computer standards [maybe not 20 years from now..., but for now].
Tom
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: OFB, CFB, ECB and CBC
Date: Fri, 24 Mar 2000 08:54:56 -0800
<[EMAIL PROTECTED]> wrote in message
news:8bfdr8$6im$[EMAIL PROTECTED]...
> In a previous article, Jerry Coffin <[EMAIL PROTECTED]> writes:
> >ECB encodes each block completely separately from all the others, so
> >if an attacker knows the contents of a particular block, they know
> >what they block will encrypt to with any particular key. With the
> >other modes, the blocks are chained together (with an Initialization
> >Vector as the first block) so they won't know this ahead of time. In
> >descending order of preference, I'd use CBC, CFB, OFB and finally, if
> >I had NO other choice, ECB.
>
> You may make CFB and CBC modes sound better than they are. In fact, if you
> know then key and cipher (= E_k) and only two adjactent plain text blocks
> p(n-1) and pn, then you know ahead of time what the cipher block cn will
be.
> Hence, the complexity is increased compared to ECB mode, but not that
much.
> Using a stronger cipher would probably often be a better way to increase
> security than to go from ECB mode to either CBC or CFB mode.
Actually, you're misunderstanding the problem with ECB that CBC (and CFB)
are designed to overcome. With random plaintext, there really isn't any
reason to prefer CBC. However, real plaintext is often very redundant, and
it is quite often the case that the same plaintext block occurs repeatedly.
When that occurs, ECB will encrypt those blocks identically. This means
that the attacker knows that those blocks within the plaintext are repeats.
In addition, if he knows the plaintext for one of those blocks, he then
knows the rest of them as well. With CBC, this is unlikely to happen unless
your plaintext approaches 2**(Blocksize/2) blocks in length.
--
poncho
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: rec.gambling.poker
Subject: Re: Open source or not. (Was: Re: Planet Poker Claims...)
Date: Fri, 24 Mar 2000 17:00:10 GMT
In article <8bdtgp$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (A. Prock) wrote:
> According to A. Prock <[EMAIL PROTECTED]>:
> >Going directly to the heart of the matter, Planet Poker, Paradise
Poker,
> >and all of the other online poker rooms are asking us to play with
> >cards which we haven't seen shuffled. In a live game it would be
analogous
> >to bringing out a new deck of cards each hand, which have been
"shuffled"
> >in the back room somewhere, and dealing it "cold".
>
> I may not have been clear here. What I'm trying to say is that the
> online card rooms are asking us to play *without* knowing how the
> deck was shuffled.
>
> In a real card room we get to see how the deck is shuffled. Simply
> knowing how the cards are mixed up is important. If a live dealer
> hid the cards while they were being shuffled, we would be much more
> suspicious.
>
> Hiding the shuffling algorithm is the electronic equivalent of hiding
> the cards when they are shuffled.
>
> - Andrew
>
>
It is commonplace in Bridge to play with pre-delt cards. It is also
common
knowledge that these pre-delt cards are distributed differently from
cards delt at the table. The difference being of course that the pre-
delt hands are delt randomly, while the hands shuffled 'badly' at the
table are not random.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: nsa patent on new storage device
Date: Fri, 24 Mar 2000 10:13:39 GMT
"Trevor L. Jackson, III" <[EMAIL PROTECTED]> wrote, in part:
>but appears to lack any aspect of content addressability
It's true that holographic techniques are hoped to provide some type
of content addressability, since content-addressable memories are
specialized, and most present types of memory do not provide
content-addressability, a very high density and low cost memory
device, simply because it isn't content addressable, is hardly
something to be dismissed as useless!
John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: "THE DES, An Extensive Documentation and Evaluation" - from Aegean
Press.
Date: Fri, 24 Mar 2000 10:18:31 GMT
Jack Diamond <[EMAIL PROTECTED]> wrote, in part:
>DES is filled with trap doors, so you might learn as much by doing
>simple distribution analysis and finding them.
Your posting has already recieved two incredulous responses, noting
that the consensus of current opinion that DES is pretty good except
for its awfully short key. Rather than adding to the chorus, though,
I'll just ask a simple question.
What technique are you referring to by the term "simple distribution
analysis"? Can you describe it or give references?
John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Boris Kazak <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Hashes! (newbie question)
Date: Fri, 24 Mar 2000 17:15:54 GMT
Runu Knips wrote:
>
> > In all subsequent description I shall refer to the
> > M-transformation, which is now going to be described.
> > All multiplications are assumed to be (mod 2^32+1).
>
> This doesn't look like a good algorithm.
>
> (a) a toggled input bit has to toggle 50% of the output
> bits (in average) in a good oneway hash function.
> here it only affects 32 of the output bits !!!
==============================
Did you read the description of the M-transformation?
Please take notice of the following:
The specifics of the M-transformation regards the
progression along the block. After the multiplication,
when the bytes of the product are returned to their places
and it is time to proceed with the subsequent multiplication,
the two LS bytes of the previous product become the two
MS bytes of the new number to be multiplied, and two adjacent
bytes of the plaintext are appended to them in order to make
this new 32-bit number. When the end of the block is reached,
the index wraps cyclically over the 2*HASHBLOCKSIZE.
(and so on for 3 full rounds)
This arrangement allows an ultra-rapid propagation
of all changes across the entire block - there is complete
avalanche after the 2-nd round and then after each
subsequent round.
=====================
>
> (b) you use nothing but multiplication to produce the
> hash. muliplication is both slow and bad for certain
> input values (for example, 0*anything=0).
=======================
This would be true if the multiplication used would be
(mod 2^32-1). In case of multiplication (mod 2^32+1) the rules
are as follows:
0 is assumed to be equal to 2^32, thus
0*0 = 1
0*anything = 2^32 - anything + 1
In addition, if using Assembly, the whole multiplication
(mod 2^32+1) can be implemented in 5 register instructions,
it will take longer to load and to unload the data than to
actually multiply. However, this is true only for processors
capable of producing the 64-bit intermediate product.
And finally, this is just a model, it was not designed to
hash the stream of video signals in real time, sorry...
Best wishes BNK
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: ecc equation
Date: Fri, 24 Mar 2000 17:19:51 GMT
So if I make random (a, b) for a curve in GF(p) I must simply check that
4a^3 + 27b^2 mod p != 0?
I saw a program called schoof.exe from MIRACL that calcs the order of a
point on a curve. I tried searching for it, and I found the reference, but
I can't find a copy of the description online.
Anyhelp?
Tom
------------------------------
From: James Felling <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: Answer me these?
Date: Fri, 24 Mar 2000 11:27:39 -0600
Anthony Stephen Szopa wrote:
> It is quite clear that both Mr. Hetzer and Mr. Ashwood are seriously
> disoriented. The theory, and specification of the procedures and
> processes, have been available at the web site in the posted Help
> Files for some time now and this fact has repeatedly been stated in
> these news groups.
>
> You can believe in any personal "reality" you want to fantasize. Some of
> you can share your fantasies. Have fun.
>
> Volker Hetzer <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > Anthony Stephen Szopa wrote:
> >
> > > You are sure a great talker. I wonder how many of you are busily
> > > studying OAP-L3 theory,
> > Everybody who has *access* to that theory. Which is -- nobody.
> >
> > > It appears that you (and most others) have willfully chosen not to
> > > address the theory, and specification of the procedures and
> > > processes. This should be noted by all readers to this news group.
> > Tell us the theory, then we'll address it.
> >
> > > It appears that the attack has admittedly been chosen to be an
> > > attack on the implementation. No other options?
> > Nobody has bothered to "choose" an attack. The goal is to point
> > out weaknesses. If you want it for free, provide the source code.
> >
> > > I thank many of you for unintentionally giving me such credibility
> > > (short-lived or not.)
> > This is not a chatroom, y'know? People take their time to follow
> > threads and look up references (and funny patents). So, forget it.
> >
> >
> > > By the way, OAP-L3 Version 4.3 will be available in about a week
> > > or so. Six new processes are being added to mix things up even
> > > more.
> > Wow! The more "processes", the more secure. I'm impressed.
> >
> > Volker
> > --
> > Hi! I'm a signature virus! Copy me into your signature file to help me
> spread!
> >
To quote your web site sir:
"Each of these files must
be thoroughly shuffled. That is to say, the permutation order must be
randomly rearranged in each file. There are several processes the
software uses to shuffle the permutation order in each MixFile(X)
individually, and one that shuffles the MixFile(X)s all together. "
This is useless as an algorithim description. "There are several processes"
well this could be anything from a secure PRNG stream to a simple modular
arithmetic PRNG, to picking a spot in the file and starting from there. This
paragraph is the sole source of information about this( that I could find)
and provides no useful details as to what the nature of such "processes"
are. This is the core of your algorithim -- the only part that will add
randomness to your output stream, and thus far you have not replied to our
questions.
I ask you now sir: What are the "processes" involved, and how are they
applied?
If you can not or will not answer this question, no meaningful conclusions
about your program's quality may be drawn. Until I have seen such data, I
will have no confidence in your program. Given also your claims that this is
an OTP, and other misleading statements made I am inclined to give your
program a great deal of scepticism, and doubt it's quality. If the actual
data was on the table, then an objective analisys could be made, and real
conclusions drawn.
------------------------------
From: James Felling <[EMAIL PROTECTED]>
Subject: Re: OFB, CFB, ECB and CBC
Date: Fri, 24 Mar 2000 11:30:56 -0600
They are methods of chaining encryption. The FAQ has an excelent description
of how each works.
Marc Howe wrote:
> What the heck is this?
> OFB, CFB, ECB and CBC
>
> I understand that CBC is a way to check if a file is preserved in its
> original state...is this true?
>
> What are the differences among the types and which should I use for an
> encryption routine...and why?
>
> I'm wondering this because I am attempting to use a SkipJack routine that
> has these various implementations available to me.
>
> Thank you,
>
> Marc
------------------------------
From: Volker Hetzer <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: Answer me these?
Date: Fri, 24 Mar 2000 17:40:59 +0000
Anthony Stephen Szopa wrote:
>
> Thanks for showing us again that you are unable to address the theory,
> and specification of the procedures and processes, and have chosen to
> challenge the implementation.
Hey I love that "us" part. Care to take a poll? I'd like to see how many
those "us" are that understand your "theory" to such an extend that they
could post a summary that convinces the rest of the listeners in this thread
of the security of your algorithm.
Greetings!
Volker
--
Hi! I'm a signature virus! Copy me into your signature file to help me spread!
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Hashing Algorithms. (basic newbie question)
Date: Fri, 24 Mar 2000 11:10:42 -0600
In article <[EMAIL PROTECTED]>, Runu Knips
<[EMAIL PROTECTED]> wrote:
> Yen-Choon Ching schrieb:
> > BTW, are there any different with these terms:
> > - one-way function
> > - hash function
> > - collision free hash function
>
> No, a "hash function" is just a function which maps one
> bitstream into another bitstream, where the input stream
> is typically of any size and the output stream is
> typically of a fixed size. Note that identity is also
> a hash function, for example.
>
> A "one way hash function" is a hash function which is
> useable in cryptography.
>
> * You cannot tell from the output what the input was,
> i.e. you cannot construct an input which creates an
> given output with anything better but brute force.
> * You cannot construct a second input which creates
> the same output like a given first input with anything
> better but brute force.
> * You cannot find two inputs which create the same
> output with anything better but brute force.
>
> Brute force means, for a fixed output of n bits, you
> have to test (2^n/2) tests (on average) to find an
> input for a given output, or a second input for a
> given output, and you need (2^(n/2)/2) tests to find
> a pair of inputs which result in the same output.
>
> This means, if you use SHA-1 or RIPE MD160 (both 160
> bit outputs), you have to check (2^160/2) for the
> first two cases, and (2^80/2) for the third.
Hash functions can have trivial uses. Such can be even cryptographically
useful. But, when the hash is a major player, with its results displayed
for the whole world to see, it seems good to up the ante.
A hash function can be designed to act as those mentioned, but I have no
use for them at all since I don't usually work with bit-twiddling as the
core of information scrambling. Try to have a more inclusive
understanding of hash functions, as they have many and varied uses.
--
To see the results of GW Bush's shaddow, visit the Valley;
notice the miserable conditions he allows to fester.
------------------------------
** 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
******************************
