Cryptography-Digest Digest #65, Volume #12 Mon, 19 Jun 00 19:13:00 EDT
Contents:
Re: Extended Euclidean Algorithm (Mok-Kong Shen)
Re: Forgot ZIP File password. (Simon Johnson)
Re: Small compression/encryption problem (Rickman)
Re: Random sboxes... real info (tomstd)
Re: Forgot ZIP File password. (tomstd)
Re: Random sboxes... real info (Roger Carbol)
Re: Extended Euclidean Algorithm (Simon Johnson)
Re: Extended Euclidean Algorithm (tomstd)
Re: Forgot ZIP File password. (Simon Johnson)
Re: Encryption on missing hard-drives (Paul Rubin)
Re: Random sboxes... real info (michael)
Re: Cipher design a fading field? ("Douglas A. Gwyn")
Re: Cipher design a fading field? ("Douglas A. Gwyn")
Re: Cipher design a fading field? ("Douglas A. Gwyn")
Re: Weight of Digital Signatures ("Douglas A. Gwyn")
Re: Extending LFSR...... ("Douglas A. Gwyn")
Re: oneway encryption for password (David P Jablon)
Re: Extending LFSR...... ("Douglas A. Gwyn")
Re: quantum cryptography at nytimes.com ("Douglas A. Gwyn")
Re: small subgroups in Blum Blum Shub (Secret Squirrel)
Re: Encryption on missing hard-drives ([EMAIL PROTECTED])
Re: Extended Euclidean Algorithm (Anton Stiglic)
Re: Extending LFSR...... (Joaquim Southby)
Re: MD5 Expansion (Arthur Dardia)
Re: Extending LFSR...... (Joaquim Southby)
----------------------------------------------------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Extended Euclidean Algorithm
Date: Mon, 19 Jun 2000 22:19:51 +0200
Simon Johnson wrote:
> It would seem very logical that the Extended Euclidean Algorithm
> is an *extension* of the euclidean algorithm. What is this
> nature of this extention? - No source code please, all in
> prose. :)
>
> Also: i'm told it can solve the following problem:
>
> 6y + 7x + 14z mod n - where n is known........
>
> How do i go about this?
See Knuth, The Art of Computer Programming. Vol. 2.
M. K. Shen
------------------------------
Subject: Re: Forgot ZIP File password.
From: Simon Johnson <[EMAIL PROTECTED]>
Date: Mon, 19 Jun 2000 13:12:14 -0700
Isn't there an attack that requires less than 100 bytes of known
plain-text and has a complexity of about 2^40......
Or is that what that cracking program does?
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
From: Rickman <[EMAIL PROTECTED]>
Crossposted-To: comp.compression
Subject: Re: Small compression/encryption problem
Date: Mon, 19 Jun 2000 16:16:49 -0400
Guy Macon wrote:
>
> Rickman wrote:
> >What you suggest could do the job well. But I can give you what should
> >be a simpler approach. Take your input data (uncompressed text string of
> >any form) and compress it by any of the conventional and redily
> >available means. PKZIP will do nicely. Generate a bit pattern using a
> >LFSR or other simple pseudo random number generator. XOR the compressed
> >data with the bit pattern. This is your compressed, encrypted data. You
> >may need to group it into 6 bit characters which are mapped to 64
> >printable ascii characters. I would bet that with a little searching on
> >the web for the random bit stream generator, you could reduce your
> >programming effort to almost nothing.
> >
> >This may not provide NSA level security, but it will be more than useful
> >enough for your application and you don't need to do a lot of coding.
>
> This looks like a near ideal solution. I wouldn't go for 64 characters
> on the basis of making things easy for the typist. I would use 16,
> (specifically abcdefghjkprstuv) presented in groups of 4 characters.
That is a good point. It might also be a good idea to add one of the ECC
methods that others have mentioned before encrypting. Since the
characters will be very random, the typist will have problems
transcribing this text and an error correcting code will help with this
problem. One or two wrong characters (or missing or repeated) will still
give you the data you intended.
I am not real busy at the moment. If you are interested, I can work on
this for you. Drop me an email or call if you are interested.
--
Rick Collins
[EMAIL PROTECTED]
Ignore the reply address. To email me use the above address with the XY
removed.
Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design
Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX
Internet URL http://www.arius.com
------------------------------
Subject: Re: Random sboxes... real info
From: tomstd <[EMAIL PROTECTED]>
Date: Mon, 19 Jun 2000 13:16:31 -0700
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> The point is Mr BS and Mr Wagner have written posts attacking
my
>SCOTT19U as snake OIL and he even bragged I was incapable of
makeing
>a safe cipher. They made fun of my cash contest which lasted
much longer
>than the BS contest. They gloat how they feel no ameuter can
wrote a
>good cipher. Yet the contest I ran with SCOTT19U could not be
done with
>the ciphers they push in the NSA approved chaining modes.
THeres are not
>as safe for the type of contest I ran. Even the other so called
experts
>have followed there lead. The Example is Peter Guttman
following the
>Crap Wagner has stated about SCOTT19U has it classifed
as "snake oil"
>Yet he like many pusedo crypto gods has never broken it or
taken a honest
>look at it. Mr Wagner has even stated that 1-1 compression
can't be that
>hot since I wrote it. Even though he lackes the intelligence to
even
>understand my crypto code. He and his colleges every so often
attack
>some common weak beginner cipher and say all beginners wrote
wesk ciphers.
>Well mine has been a thron in there side for years and they
both lack
>the honesty to take a look at it. Is comes with compileable
source code.
>the only real bugs in that released version was in the arrays
and I have
>published fixes for that. He never did a full retaction anad
only weekly
>stated that he really did not take a look at it. The don't want
any
>real competition and they dodn't want people to use compression
that
>would get in the way of the NSA cracking your crypto. Our they
would
>have been honest not only about the cipher but about the use of
1-1
>compression for encryptiojn. Yet from wheat I have read they
can't
>seem to even be honest about that simple concept. Either they
are
>helping to cover it up or they lack the honesty that Tim Tyler
has.
> yes the spelling sucks so BFD.
For starters if you want people to treat you with respect then
you must do the same. His name is Bruce Schneier not Mr.BS so
please use his real name.
Second, they said you can't design a safe cipher because you are
apparently incapable of any form of cryptanalysis. Other then
the "I said so" analysis.
Third, I don't need to break it to know your method is useless.
It consumes too much resources, it's slow and has yet to be
analyzed at all.
Fourth, The cipher block modes were published by NBS not NSA.
Fifth, compression is only to make things smaller not more
secure. If your encryption method is only secure alongside
compression then you have to rethink it a bit.
Sixth, They never say beginners write crap, it's just self-
obvious that beginners make alot of mistakes. Beginners should
not field their own designs. That's just common sense. You
don't have first year med students performing open heart surgery
now do you?
Seventh, You have yet to prove *any* of your claims. Why not
wield a scientific mallet for once? You say your method is
better then the "three letter NSA ciphers" then prove it.
Eigth, Get a life. You spend all this time ranting when it's
obvious you haven't a clue what's really going on in the world.
Try breaking your cipher then we will respect you for it.
Tom
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
Subject: Re: Forgot ZIP File password.
From: tomstd <[EMAIL PROTECTED]>
Date: Mon, 19 Jun 2000 13:17:31 -0700
Simon Johnson <[EMAIL PROTECTED]> wrote:
>Isn't there an attack that requires less than 100 bytes of known
>plain-text and has a complexity of about 2^40......
>
>Or is that what that cracking program does?
The attack on Eli Bihams page works with 13 bytes of plaintext.
Tom
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
From: [EMAIL PROTECTED] (Roger Carbol)
Subject: Re: Random sboxes... real info
Date: Mon, 19 Jun 2000 20:21:01 GMT
John Myre <[EMAIL PROTECTED]> wrote:
>Roger Carbol wrote:
>> What is the meaning of "key" with reference to a one-time pad,
>> anyways?
>The pad is the key.
That's what I thought, too. Thus I think it's misleading to
describe a OTP as "having" key.
.. Roger Carbol .. [EMAIL PROTECTED]
------------------------------
Subject: Re: Extended Euclidean Algorithm
From: Simon Johnson <[EMAIL PROTECTED]>
Date: Mon, 19 Jun 2000 13:21:49 -0700
Is there an online copy of that, or do i have to buy it?
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
Subject: Re: Extended Euclidean Algorithm
From: tomstd <[EMAIL PROTECTED]>
Date: Mon, 19 Jun 2000 13:23:41 -0700
Simon Johnson <[EMAIL PROTECTED]> wrote:
>Is there an online copy of that, or do i have to buy it?
Have to buy it. The entire set is 200$ but the single volume is
about 65$ cdn and 50$ us (I think).
They are a good read, I have the entire set and find them
usefull.
Tom
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
Subject: Re: Forgot ZIP File password.
From: Simon Johnson <[EMAIL PROTECTED]>
Date: Mon, 19 Jun 2000 13:42:57 -0700
Bruce wasn't kidding when he said never use PKzips encryption
algorithm. :)
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Encryption on missing hard-drives
Date: 19 Jun 2000 20:54:59 GMT
In article <[EMAIL PROTECTED]>,
John Savard <[EMAIL PROTECTED]> wrote:
>On Fri, 16 Jun 2000 12:43:16 GMT, [EMAIL PROTECTED] wrote, in
>part:
>
>>What *do* they use? What is the current "state-of-the-art" GAO approved
>>encryption system. Please don't tell me they still you single round
>>DES! Kiss that data good-bye!
>
>Well, they might use triple-DES. Or, they might use a PCMCIA card (now
>called a PC Card) that does Skipjack. Then again, at one point a
>PGP-like product was mentioned on the NSA web site: I think it could
>use either a Capstone card or Triple-DES in software.
It really doesn't matter whether the stuff on those drives was encrypted
or not. Whoever had access to the vault to take them in the first place,
presumably also has the encryption keys if any.
------------------------------
Subject: Re: Random sboxes... real info
From: michael <[EMAIL PROTECTED]>
Date: Mon, 19 Jun 2000 13:55:09 -0700
Well those 2^128 permutations out of the entire (2^64)!
permutations are strong with respect to diff and linear
analysis. They are hardly any random permutation, the
permutations are *dictated* by the algorithm itself. Remember
that 2^128 is only a TINY fraction of (2^64)!. Even if you add
up the permutations allowed by RC5, CAST, IDEA, DES, Blowfish,
TEA and SAFER, you still only barely cover the surface of all
possible permutations.
==================================
"Oh Breath of Life, give us this day our daily food, deliver us
from the curse of the ice, save us from our forest enemies, and
with mercy receive us into the great beyond."
-Onagar
http://www.urantia.org
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Cipher design a fading field?
Date: Mon, 19 Jun 2000 20:19:10 GMT
"John A. Malley" wrote:
> So we may conclude from the posted example that the algorithmic
> ciphertext-only cryptanalysis of a substitution cipher is undecidable if
> there is no algorithm to determine a candidate plaintext string is a
> member of the language E (the English language.)
> So here's an example of a cryptanalysis that's undecideable by an
> algorithm. It's not the same as saying cryptanalysis is equivalent to
> the halting problem, but we show (ciphertext only) cryptanalysis can be
> undecideable.
When one arrives at an asburd conclusion, it is time to go back
and check the premises and argumentation.
There is something wrong with this use of terminology anyway --
the relevant criterion for cryptanalysis is whether or not it
has a substantial likelihood of succeeding (according to a
reasonable criterion under a suitable scenario). We all know
that simple-substitution cryptanalysis is nearly certain to
succeed, given a good-sized chunk of text from a known natural
language, even without word separators.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Cipher design a fading field?
Date: Mon, 19 Jun 2000 20:20:46 GMT
"John A. Malley" wrote:
> That immediately raises this question : Can we even encipher and cipher
> plaintext strings of a Turing-unrecognized language?
? Arbitrary bit strings can be enciphered and deciphered.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Cipher design a fading field?
Date: Mon, 19 Jun 2000 20:21:46 GMT
Benjamin Goldberg wrote:
> How much does the problem change, if we consider English as a
> ciphertext, and 'knowledge' or 'understanding' as it's corresponding
> plaintext?
It's a different situation -- the object of natural language is
to express and communicate, whereas the object of a cryptosystem
is to hide.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Weight of Digital Signatures
Date: Mon, 19 Jun 2000 20:25:01 GMT
Greg wrote:
> ... Kudos to all who have had any
> hand in helping the government see the light (finally)...
Unfortunately, that probably means that even when an insecure
digital signature scheme is used, you cannot refuse personal
responsibility when you're forced to use it anyway.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Extending LFSR......
Date: Mon, 19 Jun 2000 20:33:05 GMT
tomstd wrote:
> That's just it my friend. a LFSR is not a magical tap sequence
> thingy... it's MULTIPLICATION IN A GALOIS FIELD!!!!
Actual linear-feedback shift registers are implemented by XORing
taps from various stages in the register. This can be described
in terms of polynomials over GF(2), where the "x" of the polynomial
represents one delay stage of the shift register. The lowest
coefficient in the polynomial will be 1 (or else there are some
wasted delay stages that serve no mixing purpose) and the order of
the polynomial will be the number of stages minus one (or else ditto).
There is a one-to-one correspondence between polynomials of that
form and linear-feedback shift register tappings.
Golomb wrote a nice book on the subject, somewhat dated but worth
reading, reprinted by Aegean Park Press.
------------------------------
From: [EMAIL PROTECTED] (David P Jablon)
Subject: Re: oneway encryption for password
Date: Mon, 19 Jun 2000 21:26:03 GMT
In article <[EMAIL PROTECTED]>,
Sisson <[EMAIL PROTECTED]> wrote:
>i'll probably take your advice and encrypt the date or something, and
>then have the server compare. ...
I don't know what kind of advice you've looking at, but all the
discussion that I've seen on this thread about one-way hashed passwords
is only relevant to single-server *local* authentication.
For client/server authentication, the best methods are zero-knowledge
password protocols, like EKE, SRP, SPEKE and a growing family.
All of these prevent brute force attacks from the network, which
no purely symmetric or hash-based approach can do. Some are dirt
simple, and some are not. Most are as easy to use as any other
black-box crypto function, and free source is plentiful.
Better still, if you can use two or more servers, you can even prevent
the local brute-force attacks as well. This is a newly published result.
See www.IntegritySciences.com for details.
Also, in our FreeSPEKE SDK (www.IntegritySciences.com/freespek.html)
you'll find an implementation of SHA-1, which is stronger, simpler,
and potentially much smaller than DES for protecting locally stored
password verifiers, if that's all you want to do. For example, I have
an x86 version of SHA version that fits in just a few hundred bytes.
======================================================
David P. Jablon
Integrity Sciences, Inc.
[EMAIL PROTECTED]
<http://www.IntegritySciences.com>
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Extending LFSR......
Date: Mon, 19 Jun 2000 20:36:12 GMT
Simon Johnson wrote:
> I have noticed that the words: modulo & modulus have been used
> to describe the remainder on division by a number. Surely both
> of these terms don't mean the same thing do they?
The "modulus" is the base, while "modulo some_base" means using
the indicated base as a modulus.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: quantum cryptography at nytimes.com
Date: Mon, 19 Jun 2000 20:38:09 GMT
zzapzing wrote:
> <sarcasm>
> Oh, yeah, and it would be Sooo much less expensive
> to build a quantum cryptography line than it would
> be to generate and store enough OTP bits for the
> next 3 million years !
The trouble with sarcasm is that it makes your point unclear.
If you mean to imply that an OTP is more practical,
we have established before that there are severe problems
in the practical use of OTPs.
------------------------------
Date: 19 Jun 2000 22:19:07 -0000
Subject: Re: small subgroups in Blum Blum Shub
From: Secret Squirrel <[EMAIL PROTECTED]>
[Apologies if a duplicate of this message appears.]
[The discussion below references
http://x61.deja.com/[ST_rn=ps]/getdoc.xp?AN=572282072 ]
Terry Ritter writes:
> I saw that when it came out, and a short summary is:
>
> "it follows from the RSA assumption that finding short cycles is
> impossible, for moduli large enough that factorization is
> intractable."
>
> and
>
> "The advice to choose moduli with guaranteed long cycles, and to
> choose seeds that way, is completely useless."
>
> Oddly for useless advice, the last 2/3 of the BB&S published article
> concerns just this issue. The response involves forming a special
> construction for N which is guaranteed to have long cycles of a
> computable length, and then finding an algorithm to traverse those
> cycles of known length, to show that a long cycle has been selected.
> Now, did Blum, Blum and Shub simply get carried away with their own
> math abilities? Shall we assume that they were they so unaware of
> their first results that they simply did not understand that 2/3 of
> their work was "useless"?
This is not an argument. This is innuendo. This is speculation. Not one
word of what you have written here contradicts the proof referenced
above that being able to find short cycles allows you to factor.
There is no reason to speculate on what anyone's motives are. That's
not math, it's soap opera. Let us stick to mathematics here. This
is a mathematical question and we have a mathematical answer.
> >It shows a way to factor RSA moduli if you can find short BBS cycles
> >(or any cycles for that matter).
>
> The cycles in an arbitrary primes construction will have various
> lengths, but as far as I know, there are always some cycles of length
> 1 (which I call "degenerate"). I doubt they will be much help in
> factoring N. But they undoubtedly *are* the weakest possible
> "sequence" (which would be, in practice, a "constant").
If x^2 = x mod n, with n an RSA modulus, then x^2 = x mod p where p is one
of the factors. Therefore x^2 - x is a multiple of p, and equivalently
x(x-1) is a multiple of p. But by the unique factorization theorem then
either x or x-1 must be a multiple of p. The same thing is true with
respect to q, the other factor.
Therefore, such x values are extremely rare. There are only 4 of them
less than n, two of which are 0 and 1. Hence the chance of hitting one
at random is the same as the chance of factoring n by just guessing a
factor at random and seeing if you are right.
Furthermore, even if you did manage to hit one of the two non-trivial
values, it is a multiple of either p or q, and so if you do gcd(x,n)
you recover a factor of n. (But it doesn't matter because you would
never hit one, not in the lifetime of the universe.)
> It may be that some of those on the other side have not really
> understood the weakness of a short cycle. BB&S type systems probably
> would be used as the generator of the confusion sequence for stream
> ciphers. The stream cipher requires its sequence to be random-like,
> and *ALSO* to not repeat. But if the BB&S happens to be on a short
> cycle, it *will* repeat, and *that* is a weakness. Sufficiently short
> cycles *are* weak, and there simply is nothing to debate about it.
It seems that it is you who do not understand. Short cycles produce
factors! That should be the beginning and ending of the discussion.
No more is needed.
For more than five years you have been spreading misinformation on
this topic by insisting that you do not have provable security in a BBS
generator unless you use special primes and do tests so that your initial
seed does not put you on a short cycle. Again and again over the years
you have been presented with mathematical proof that you are wrong.
All you ever respond with is "but why then did the BBS paper analyze
cycle lengths?"
This is the weakest form of argument by authority, because you can't
even find a quote from the authority which justifies your position.
Instead you have to speculate: they must have analyzed cycle lengths
because they believed that unless you check for short cycles, the BBS
cipher is weak! Of course, they never say that. They do not have one
word in any of their papers which says this. It is purely an invention
which you have conjured up, an inference which you have reached on the
basis of your guess at their psychological motivations.
Such arguments have no place in a technical forum. If you cannot
respond with a mathematical argument, you should go away until you can.
You certainly should not be making unsupported technical claims purely
on the basis of what your imagination suggests is the motivation of
other researchers.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Encryption on missing hard-drives
Date: Mon, 19 Jun 2000 22:19:46 GMT
Paul Rubin <[EMAIL PROTECTED]> wrote:
> It really doesn't matter whether the stuff on those drives was encrypted
> or not. Whoever had access to the vault to take them in the first place,
> presumably also has the encryption keys if any.
Even if it was, it would be classified with a classified algorithm,
not DES. I suspect it wasn't, however, given the nature of the
disks. The burning question in my mind is the FBI's statement that
they're examining the disks to see if the information on them was
altered or accessed. Is it possible to reliably tell if the
information's been accessed in the case of a missing drive?
--
Matt Gauthier <[EMAIL PROTECTED]>
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: Extended Euclidean Algorithm
Date: Mon, 19 Jun 2000 18:42:55 -0400
Simon Johnson wrote:
>
> It would seem very logical that the Extended Euclidean Algorithm
> is an *extension* of the euclidean algorithm. What is this
> nature of this extention? - No source code please, all in
> prose. :)
yes indeed. Check out the following URL:
http://www-math.cudenver.edu/~wcherowi/courses/m5410/exeucalg.html
Anton
------------------------------
From: Joaquim Southby <[EMAIL PROTECTED]>
Subject: Re: Extending LFSR......
Date: 19 Jun 2000 22:42:34 GMT
In article <[EMAIL PROTECTED]> tomstd,
[EMAIL PROTECTED] writes:
>That's just it my friend. a LFSR is not a magical tap sequence
>thingy... it's MULTIPLICATION IN A GALOIS FIELD!!!!
>
This is like arguing with a stump on fire. What's your reason for
refusing to understand that there is more than one way to describe the
device? Do you even understand how an LFSR works?
------------------------------
From: Arthur Dardia <[EMAIL PROTECTED]>
Subject: Re: MD5 Expansion
Date: Mon, 19 Jun 2000 18:41:14 -0400
[EMAIL PROTECTED] wrote:
> In article <10839b68.9f89254c@usw-ex0104-
> 031.remarq.com>,
> tomstd <[EMAIL PROTECTED]> wrote:
> > Andrew Bortz <[EMAIL PROTECTED]> wrote:
> > >In the interest of increasing the size of a
> MD5 hash, I have
> > been
> > >thinking of a fairly simple method:
> > >
> > >1) Calculate the MD5 hash of the data
> > >2) Permute the data, preferable at the
> beginning, in some small
> > manner
> > >3) Calculate the MD5 hash of the new data, and
> append to the
> > original
> > >hash
> > >4) Lather, rinse, repeat as necessary/paranoid
> > >
> > >It seems as though it would work, and using
> the 256-bit variant
> > (one new
> > >hash) it would appear as though it yields huge
> advances in
> > protection,
> > >utilizing the apparent collision-free nature
> of MD5.
> > >
> > >Finally getting the root of my question...
> Since the hash
> > method in its
> > >entirety will/must be disclosed, it will be
> possible for
> > attackers to
> > >possibly utilize the two hashes in some attack
> to reveal the
> > data
> > >originally hashed. My question is, is MD5
> secure enough to
> > withstand
> > >giving an attacker a significant statistical
> peep at the data
> > that was
> > >hashed?
> >
> > From what I gather you want todo this
> >
> > A = H(M)
> > B = H(L(A))
> >
> > Where M is the original message, L is a linear
> transform and H
> > is the hash function.
> >
> > This is no more secure then the original
> underlying hash
> > function and I will show why.
> >
> > We know that a collision by the birthday
> paradox will take 2^64
> > effort against MD5 (since it's a 128-bit
> hash). However, a
> > collision in A is sufficient to find a
> collision in the entire
> > hash. In otherwords your 256-bit hash can be
> broken in 2^64
> > guesses which is far under the birthday paradox
> limit for a 256-
> > bit hash.
> >
> > Tom
> >
> > Got questions? Get answers over the phone at
> Keen.com.
> > Up to 100 minutes free!
> > http://www.keen.com
> >
> >
>
> Sorry, my news server sucks, so I'm using Deja.
> Anyway, Your logic evades me. Just because we can
> find 2 messages that have the same MD5 hash
> doesn't mean those two messages, run through the
> linear function, will have the same 2nd hash!
> That is where I see the security of using 2
> hashes: Even when a collision is found in MD5, it
> will rarely have a collision in the 2nd hash
> because one bit change in the message will
> (supposed to) change on average half the bits of
> the hash. The attacker is back to searching...
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
I'm a newbie, so here it goes:
Instead of doing what the original poster came up with. Why can't you
just hash the original message with MD5. Use the output as the input to
another hash algorithm (say SHA-1), and then to be safe repeat the same
thing replacing TIGER/192 for SHA-1.
A=MD5(M);
B=SHA-1(MD5(M));
C=TIGER/192(SHA-1(MD5(M)));
C would be the final output.
How does this increase security, by what percentage, if it does at all?
--
Arthur Dardia Rensselaer Polytechnic Institute [EMAIL PROTECTED]
PGP 6.5.1 Public Key http://www.webspan.net/~ahdiii/ahdiii.asc
------------------------------
From: Joaquim Southby <[EMAIL PROTECTED]>
Subject: Re: Extending LFSR......
Date: 19 Jun 2000 22:45:18 GMT
In article <[EMAIL PROTECTED]> Simon Johnson,
[EMAIL PROTECTED] writes:
>A futher question. In Applied Cryptography, it say a polynomial
>is primitive if all its powers are relatively prime.
>
You might be misreading it. A primitive polynomial will have relatively
prime exponents; the converse is not necessarily true.
------------------------------
** 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
******************************
