Cryptography-Digest Digest #67, Volume #12 Tue, 20 Jun 00 03:13:00 EDT
Contents:
Updated password generator (tomstd)
Re: Equally like bit-flips in a Gray code? (M Joonas Pihlaja)
Re: Encryption on missing hard-drives ([EMAIL PROTECTED])
Is this a HOAX or RSA is REALLY broken?!? (Frank)
Re: Is this a HOAX or RSA is REALLY broken?!? (tomstd)
Re: small subgroups in Blum Blum Shub (d g)
Re: small subgroups in Blum Blum Shub (David A. Wagner)
Re: small subgroups in Blum Blum Shub (David A. Wagner)
Re: small subgroups in Blum Blum Shub (David A. Wagner)
Re: Random sboxes... real info ("Joseph Ashwood")
(somewhat OT) Non-US webhosting (Dido Sevilla)
Re: Weight of Digital Signatures ("Lyalc")
Re: Cipher design a fading field? ("John A. Malley")
Re: Is this a HOAX or RSA is REALLY broken?!? ("Adam Durana")
Re: Is this a HOAX or RSA is REALLY broken?!? (Roger Schlafly)
Re: Is this a HOAX or RSA is REALLY broken?!? (S. T. L.)
Re: LSFR, a character twist (wtshaw)
Re: Crypto Contest update (Boris Kazak)
Re: Encryption on missing hard-drives (Guy Macon)
Re: Flattening of frequency distributions (Guy Macon)
Re: MD5 Expansion ("Scott Fluhrer")
----------------------------------------------------------------------------
Subject: Updated password generator
From: tomstd <[EMAIL PROTECTED]>
Date: Mon, 19 Jun 2000 18:14:02 -0700
I updated the cute password generator to allow filters on the
output so that you can make passwords for environments that only
allow specific subsets of the chars. For example platforms that
allow only lower case letters etc...
It's all at http://tomstdenis.com/passgen.html
The source and x86 binaries are on the page.
Tom
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
From: M Joonas Pihlaja <[EMAIL PROTECTED]>
Subject: Re: Equally like bit-flips in a Gray code?
Date: Tue, 20 Jun 2000 04:22:47 +0300
On Mon, 19 Jun 2000, Mok-Kong Shen wrote:
> Question: Wouldn't the input to the cipher affect the task of
> 'finding the key bits that affect the cipher bits the least
> (or most)'? I mean you have another parameter to consider.
That's right. I should have mentioned I'm assuming known
plaintext.
Regards,
Joonas Pihlaja
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Encryption on missing hard-drives
Date: Tue, 20 Jun 2000 01:42:43 GMT
Albert P. Belle Isle <[EMAIL PROTECTED]> wrote:
> Only if whoever took them was stupid enough to boot a machine from the
> copy of Windows on one of these drives, rather than plugging the drive
> into the drive controller cable of an already-bootable machine to read
> it as a second, slave drive (as any "computer forensics" guy would to
> make a sector-by-sector copy for offline analysis with a commercial
> "forensic software" package).
Which is what I suspected, and some news agency consultants have been
pointing out. On the other hand, it _is_ an interesting question in
itself and one which surfaces now and again. I'm not sure someone
won't find a protocol to prevent it some day, perhaps requiring
connecting to some trusted server for each decryption of the data.
--
Matt Gauthier <[EMAIL PROTECTED]>
------------------------------
From: Frank <[EMAIL PROTECTED]>
Subject: Is this a HOAX or RSA is REALLY broken?!?
Date: Tue, 20 Jun 2000 01:31:25 GMT
I appended to read to this article:
http://www.sunday-times.co.uk/news/pages/tim/99/09/29/timintint02001.html?1341861
I mean... it can`t... Is this a Hoax or quantum computing is really
there? Tell me what you think.
Frank
------------------------------
Subject: Re: Is this a HOAX or RSA is REALLY broken?!?
From: tomstd <[EMAIL PROTECTED]>
Date: Mon, 19 Jun 2000 19:00:20 -0700
It's a hoax.
Tom
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
From: d g <[EMAIL PROTECTED]>
Subject: Re: small subgroups in Blum Blum Shub
Date: 19 Jun 2000 19:22:32 -0700
[EMAIL PROTECTED] (Terry Ritter) writes:
> [...] As I said in a previous posting, the issue here is nothing
> less than the meaning of "proof" itself: If you are willing to call
> something "proven secure," when the math itself says there is a
> small, but preventable probability of weakness, you are willing to
> bend more then I am.
Could you state what you mean by "provable security"? As an example,
see the definition in chapter 5 of Goldreich's "Foundations of
Cryptography":
http://www.wisdom.weizmann.ac.il/home/oded/public_html/foc-book.html
A preprint of chapter 5 is available online - semantic security is
defined in : #5.2.1, #5.2.2. Semantic security as defined by
Goldreich is essentially probabilistic. Perhaps you have a different
model of computation.
Do you agree with his construction and analysis of Blum-Goldwasser
(which is based on the same QR intractability assumption as BBS) in
section 5.3 in the monograph?
==
Dipankar
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: small subgroups in Blum Blum Shub
Date: 19 Jun 2000 19:17:49 -0700
In article <[EMAIL PROTECTED]>, Terry Ritter <[EMAIL PROTECTED]> wrote:
> As I said in a previous posting, the issue here is nothing less
> than the meaning of "proof" itself: If you are willing to call
> something "proven secure," when the math itself says there is a small,
> but preventable probability of weakness, you are willing to bend more
> then I am.
Ahh, but here's the rub: The rest of the research community is also
apparently willing to bend more than you are.
In particular, the accepted definitions of provable security say that
something is secure if the probability of weakness is acceptably small
(say, smaller than 1/poly(k) for all polynomials, where k is a security
parameter chosen by the good guys, like the length of the RSA modulus).
Go read the standard definitions in the literature! Really.
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: small subgroups in Blum Blum Shub
Date: 19 Jun 2000 19:28:47 -0700
In article <[EMAIL PROTECTED]>, Terry Ritter <[EMAIL PROTECTED]> wrote:
> If you are willing to call
> something "proven secure," when the math itself says there is a small,
> but preventable probability of weakness, you are willing to bend more
> then I am.
Here's another way to see why we are willing to bend more than you are.
Let me ask you a question. What length keys do you use?
Let's suppose for the sake of argument that you use 2048-bit RSA keys.
(The argument works for any key length.) Then we can note that there is
at least a 1/2^2048 chance that the attacker correctly guesses a prime
factor of your RSA modulus. This can be prevented by moving to a 4096-bit
RSA key, where the chance of a successful result decreases enormously.
This means that 2048-bit RSA has a small but preventable probability of
weakness which is not present in 4096-bit RSA. So you should be using
4096-bit RSA, not 2048-bit RSA.
But wait! The same argument says that 4096-bit RSA has a small but
preventable probability of weakness which is not present in 8192-bit RSA,
so you should be using 8192-bit RSA, not 4096-bit RSA. But 8192-bit
RSA is bad, you should be using 16384-bit RSA. And so on, ad infinitum.
It's a steep slope, and once you get started down this path, there's
no logical place to stop. Whatever key length you choose, it's always
illogical to use it. We're paralyzed.
This is an absurd situation, and it's all a consequence of this premise
that a small but preventable probability of weakness is unacceptable.
I submit that it's the premise that's at fault here, and that if the
probability of weakness is sufficiently small, we can go home happy.
In the computational setting, security is inherently probabilistic.
You don't get absolute security; you just get systems where breaking
it is sufficiently large to prevent compromise. Similarly, you don't
get guaranteed security; you just get systems where the probability of
compromise is sufficiently small.
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: small subgroups in Blum Blum Shub
Date: 19 Jun 2000 19:32:58 -0700
In article <[EMAIL PROTECTED]>, Terry Ritter <[EMAIL PROTECTED]> wrote:
> And you have not been able to describe *your* position at all. Do you
> imagine that short cycles do or do not exist in BB&S constructions?
> Do you imagine that using such a cycle would be weak or not? Do you
> imagine that it is actually impossible for a short cycle to be
> selected?
I think it was already clear, but I'll answer your questions.
Yes, short cycles exist in BB&S. Yes, using such a cycle would be weak.
No, it is not impossible to encounter such a cycle. Yes, BB&S is provably
secure (under appropriate assumptions and definitions). There is no
contradiction here.
> Or perhaps you simply missed the many times I have stated
> that -- as far as I know -- this is not a problem in practice. But it
> is a *theoretical* problem, and as such stands directly in the way of
> any serious claim of "proven security."
You are making an unnecessary distinction between theory and practice here.
Theory doesn't need to be different from practice just for the sake of being
different!
Under standard theoretical definitions, there is no theoretical problem.
Maybe you prefer non-standard definitions, but I haven't yet heard why
you prefer them.
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Random sboxes... real info
Date: Mon, 19 Jun 2000 19:56:54 -0700
> comes with compileable source code.
I will only bother to address this one point. I once had the
free time to download and attempt to compile your supposed
source code. I attempted to compile it with (result):
Win95/Borland (failed)
Win95/MSVC 4(failed)
WinNT x86/MSVC 5(failed)
WinNT Alpha/MSVC 4 (failed)
WinNT Alpha/MSVC 5 (failed)
Solaris SPARC/ cc (failed)
SunOS / cc (failed)
Solaris/gcc (failed)
Digital UNIX/cc (failed)
Digital UNIX/gcc (failed)
I think that list is complete enough to establish that you
simply seem incapable of writing code that will compile, or
if nothing else you didn't publish the same code you
compiled. Would you care to try again?
Joe
------------------------------
From: Dido Sevilla <[EMAIL PROTECTED]>
Subject: (somewhat OT) Non-US webhosting
Date: Tue, 20 Jun 2000 10:55:22 +0800
It's kinda off-topic, but there is something I'd like to ask... Does
anyone know of any free non-US webhosting service? I've implemented
several encryption algorithms in 80186 assembly: putting the finishing
touches on Serpent, have TEA, and an implementation of SHA-1 all ready
now, and probably I'll try doing Rjindael after Serpent is finished. I
don't want any stupid EAR or other idiotic laws to come back and bite me
because I keep strong encryption programs on my web page. My ISP
provides webhosting space, but it's pathetically small (1meg!)... As my
sig implies, I'm not a US citizen, so the law's scope is questionable,
but just to be on the safe side...
--
Rafael R. Sevilla <[EMAIL PROTECTED]> +63 (2) 4342217
ICSM-F Development Team +63 (917) 4458925
University of the Philippines Diliman
------------------------------
From: "Lyalc" <[EMAIL PROTECTED]>
Subject: Re: Weight of Digital Signatures
Date: Tue, 20 Jun 2000 13:33:23 +1000
Not wishing to appear OS biased, I suspect any software-only based digital
certificate scheme is suspect.
Reason - password grabbing/sniffing is old hat, while a number of file
grabbing exploits exist, and continue to be found, in many applications and
OS's
For mine, no bets on Visual-Basic attacks - who says they are not already
written and tested?
Even for simple Smartcard environments, where the reader is controlled from
the PC/workstation OS, generating multiple 'unauthorised but valid'
signatures is trivial today - a little tweaking on MS's VB Smartcard toolkit
is all that's needed.
Note: it's not the smartcard OS, its the PC/workstation OS and reader that's
the source of the problem.
Lyal
Lyal
Paul Koning wrote in message <[EMAIL PROTECTED]>...
>Lyalc wrote:
>>
>> In general, a lay-persons analysis of electronic signature legislation
based
>> on the UNCITRAL Model Law shows they have 5 main components; the
electronic
>> signature
>> ...
>> iv) be under the sole control of the individual identified.
>
>Ok, so that immediately excludes any digital signatures generated
>by Microsoft products from consideration, right? :-)
>
>I'd wish, but I suspect not. Any bets on how long it will take for
>the first MS Visual Basic (Outlook, Word, pick one) virus to appear
>that generates digital signatures for the benefit of the criminal?
>Surely that won't be hard.
>
> paul
------------------------------
From: "John A. Malley" <[EMAIL PROTECTED]>
Subject: Re: Cipher design a fading field?
Date: Mon, 19 Jun 2000 20:34:37 -0700
"Douglas A. Gwyn" wrote:
>
> "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.)
> When one arrives at an asburd conclusion, it is time to go back
> and check the premises and argumentation.
Agreed, Mr. Gwyn.
> 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.
What's said is literally true. Ciphertext-only cryptanalysis of the
substitution cipher is undecidable if and only if (should have been an
iff in the original sentence) there is NO algorithm to determine a
decrypted candidate plaintext string is a member of the English
language.
But there IS an algorithm to determine if a plaintext string belongs to
English.
People writing to each other use a mutual subset of the full scope of
possible English strings per a shared context. They recognize the
"proper" (error-free) written English strings. Context helps.
Cryptanalysis includes determining the shared context within which the
two parties communicate. There's a "default" general context - written
English used in everyday life. There are other more specific contexts -
military, business, political. Everyone reading English strings uses an
algorithm to decide if the strings read belong to the printed English
language per the expected context. The cryptanalyst solving the
substitution cipher uses an English-string-recognizing algorithm per
some expected context.
So it's a decidable problem.
John A. Malley
[EMAIL PROTECTED]
------------------------------
From: "Adam Durana" <[EMAIL PROTECTED]>
Subject: Re: Is this a HOAX or RSA is REALLY broken?!?
Date: Tue, 20 Jun 2000 00:05:46 -0400
Its not really a hoax. It's just another example of the media leaving out
important parts of the story. This was talked about a while ago on this
same newsgroup. If I remember correctly the Weizmann Institute said they
_could_ break RSA in a small amount of time using a quantum computer. But
what the story didn't mention is that they don't have a quantum computer
that can do this yet. They merely said that quantum computers would be able
to break RSA. This isn't anything new. Everyone knows that quantum
computers will be very fast and be able to very quickly exhaust the
keyspaces that we consider secure by today's standards. If you want more
information you should search deja.com for the previous posts concerning
this story.
- Adam
"Frank" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> I appended to read to this article:
>
>
http://www.sunday-times.co.uk/news/pages/tim/99/09/29/timintint02001.html?13
41861
>
> I mean... it can`t... Is this a Hoax or quantum computing is really
> there? Tell me what you think.
>
>
> Frank
------------------------------
From: Roger Schlafly <[EMAIL PROTECTED]>
Subject: Re: Is this a HOAX or RSA is REALLY broken?!?
Date: Mon, 19 Jun 2000 22:11:37 -0700
Adam Durana wrote:
> that can do this yet. They merely said that quantum computers would be able
> to break RSA. This isn't anything new. Everyone knows that quantum
> computers will be very fast and be able to very quickly exhaust the
> keyspaces that we consider secure by today's standards.
Actually no one knows if such computers will ever be built.
The optimists in the field believe that in 5 or 10 years
it will be possible to build a quantum computer that can
factor the number 4 as 2x2. RSA is still safe for a long time.
------------------------------
From: [EMAIL PROTECTED] (S. T. L.)
Subject: Re: Is this a HOAX or RSA is REALLY broken?!?
Date: 20 Jun 2000 05:22:59 GMT
<<The optimists in the field believe that in 5 or 10 years
it will be possible to build a quantum computer that can
factor the number 4 as 2x2.>>
I believe that 15's already been factored. Now for something big, like 77....
-*---*-------
S.T.L. My Quotes Page * http://quote.cjb.net * leads to my NEW site.
Pages up: 395 Quotes, 14 reviews of 165 science books, and a review of
the Foundation series. COMING UP: more science book reviews!
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: LSFR, a character twist
Date: Mon, 19 Jun 2000 23:36:13 -0600
In article <[EMAIL PROTECTED]>, Simon Johnson
<[EMAIL PROTECTED]> wrote:
> Before Tom kills you, be sure to use *LFSR* instead of _LSFR_.
> Don't worry, i have also comitted such a sin.
>
But, will he take the bait?
--
Some Turkeys can fly, for short distances. If you are to depend on
birds for communication, if it's with turkeys, consider the
discussions that might occur while feasting on one.
------------------------------
From: Boris Kazak <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Crypto Contest update
Date: Tue, 20 Jun 2000 06:30:05 GMT
Not very long ago I posted 2 ciphers to the site of
sci.crypt cipher contest:
<http://www.wizard.net/~echo/crypto-contest.html>
The names of the ciphers were LETSIEF-2 and MMBOOZE.
Both these ciphers were successfully attacked, and I must
freely admit it, from the mathematical point of view both
attacks were impeccable. David Wagner and Matthew Fisher
can be proud!!
The score can really be perceived as total defeat -
2 ciphers submitted, 2 ciphers successfully attacked.
However, wait a minute...
Both attacks are of "distinguishing" class, the only result
that these attacks achieve boils down to identification of
encryption algorithm. Thus with ~2^50 chosen plaintext pairs
it can be possible to pinpoint the cipher used as LETSIEF,
and with 2^32 chosen plaintext pairs it can be possible to
recognize MMBOOZE. These attacks show no obvious way of key
or plaintext recovery, in neither one of the ciphers.
And nevertheless...
The cipher is good if its output cannot be distinguished from
a totally random stream. If there are any statistical tricks
which can help in establishing the exact name and nature of
the algorithm, this could result in some serious weaknesses.
This is why I decided to accept both attacks as successful,
to admit that both ciphers deserve repair and resubmission.
I also express my utmost gratitude to David Wagner and to
Matthew Fisher, whose efforts resulted:
1) In the demolition of LETSIEF and MMBOOZE.
2) In me understanding the attacks. Believe me, this was
a much more formidable task than the first one. Dave's and
Matt's teaching abilities are beyond praise!
Now to the serious business. Attack on LETSIEF is based on
the fact that there are exactly 256 key-dependent multipliers
in the table, so in any even round there is 1/256 probability
to pick the same multiplier for both plaintexts in the pair,
preserving the difference = 0 in one half of the ciphertext.
With the total of 12 rounds this amounts to 6 even rounds and
to 1/2^48 probability of output difference = (0,b) if the input
difference is (0,a). This holds for any _a_, and all values
of _b_ are equiprobable.
As a remedy, the second table of multipliers is added to the
internal machinery of LETSIEF. These multipliers are generated
in exactly the same way, based on SEED and on randomized powers
produced by the Key Scheduler.
During an encryption round, 2 multipliers will be picked,
each one from the corresponding table. The sum of 2 MSB's will
provide the index for the 1-st table, the sum of 2 LSB's will
provide the index for the 2-nd table. The process of encryption,
including selection of the multipliers and calculation of the
F-function thus can be written as:
Start: R[0] = R^P[0] ; L[0] = L^P[1] (whitening)
1-st round: R[1] = L[0] ; L[1] = (R[0]^P[2]) MUL F(L[0])
2-nd round: R[2] = L[1] ; L[2] = (R[1]^P[3]) MUL F(L[1])
.............
N-th round: R[N] = L[N-1] ; L[N] = (R[N-1]^P[N+1]) MUL F(L[N-1])
Finish: R = R[N]^P[N+2] ; L = L[N]^P[N+3] (whitening)
MUL is modular multiplication (mod 2^32-1).
Function F[L] selects 2 multipliers from the arrays and
calculates the final multiplier; it can be written as:
F(L) = Mult1[index1] MUL Mult2[index2]
where
index1 = Sum(both MSB's in L)
index2 = Sum(both LSB's in L)
Obviously, for decryption the multipliers must be taken from
adjacent cells, where inverses were stored during key setup.
With this arrangement, there will be two modular multiplications
per round, one in F-function, one in the round itself, and the
probability of picking the multiplier pair resulting in difference
= 0 is reduced down to 1/2^15, the inverse of possible number of
combinations from 256 by 2 = 2/(256*255). With 6 even rounds, the
probability of output difference (0,b) is down to 1/2^90, difficult
to observe with 2^64 possible plaintexts.
MMBOOZE is a very different design, despite the fact that it is
also based on modular multiplication. Accordingly the perscription
for its cure was different.
First of all, due to its non-Feistel organization, the encryption
and decryption procedures are not identical. Dave Wagner ingeniously
used
this difference when planning an attack against MMBOOZE. He actually
launched the attack in reverse - from ciphertext, and called it the
"chosen ciphertext" attack. With all my reservations about practical
aspects of such an attack, mathematically it was correct, and if
it will be possible to feed about 2^32 ciphertext pairs into the
decryption engine under investigation, MMBOOZE will reveal itself
if it is the algorithm contained in the engine.
Again, this is a "distinguishing attack", it does not show
any obvious way for key or plaintext recovery (all nonzero values
in the differentials are equiprobable).
As it dawned on me, there is an elegant way to improve the
cipher security and to discourage the attacks based on different
procedures during encryption and decryption.
The remedy proposed boils down to performing encryption
during the first half of rounds, and performing decryption
during the second half of rounds. Naturally, the whitening with
round-dependent subkeys stays in place.
With this arrangement, the encryption and decryption routines
become identical, with the difference of sequencing the round
subkeys. Launching an attack from the ciphertext side becomes
exactly as difficult as launching an attack from the plaintext
side. The only loss is speed, since the number of rounds
ought to be increased to 4, and better still to 6. All other
properties of MMBOOZE stay in place, in particular its extreme
scalability, which allows to use practically unlimited block
lengths (the only limitation is available memory).
So here they are:
LETSIEF3 - 64-bit block, key accepted up to 512 bit
MMBOOZE2 - variable block, key accepted up to 512 bit
Best wishes BNK
BTW, both LETSIEF and MMBOOZE share the same Key Scheduler,
I would be grateful if anybody would cast a look at
this routine and express some opinion (derogatory OK).
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Encryption on missing hard-drives
Date: 20 Jun 2000 02:31:51 EDT
Albert P. Belle Isle wrote:
>
>On Mon, 19 Jun 2000 22:19:46 GMT, [EMAIL PROTECTED] wrote:
>
>>Paul Rubin <[EMAIL PROTECTED]> wrote:
>>
>>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?
>
>Only if whoever took them was stupid enough to boot a machine from the
>copy of Windows on one of these drives, rather than plugging the drive
>into the drive controller cable of an already-bootable machine to read
>it as a second, slave drive (as any "computer forensics" guy would to
>make a sector-by-sector copy for offline analysis with a commercial
>"forensic software" package).
Hi! Guy Macon the former hard disk drive engineer here...
There is a way, even if the slave drive method was used. I will put
in a bit of scrolling now so you can try to think of it before reading
my answer. It's clever, but a non technical person could think of it.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Examine the pins of the hard drives with a microscope. You can probably
tell if the last computer it was plugged into wasn't the one it came out
of before it went into the vault. You may be able to tell which computer,
if any, was was used to read it.
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Flattening of frequency distributions
Date: 20 Jun 2000 02:39:21 EDT
Mok-Kong Shen wrote:
>Are you assuming that the compression algorithm is secret? If not,
>and there is no secret key involved, then the opponent can decompress,
>so that he is in the same situation as if no compression has been done.
Getting down to practical matters, would using PKZIP with its
know-to-really-suck encryption before using a Real Man's Cipher
make the attackers job any harder?
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: MD5 Expansion
Date: Mon, 19 Jun 2000 23:24:13 -0700
Arthur Dardia <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
> 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?
If you're wondering how much stronger TIGER/192(SHA-1(MD5(M))) is compared
to MD5(M), the answer is: slightly weaker, actually.
After all, the main test of a hash function is the difficulty of finding
collisions. And, if we find two messages M!=M' such that
MD5(M) == MD5(M'),
then
TIGER/192(SHA-1(MD5(M))) == TIGER/192(SHA-1(MD5(M')))
That is, your concatinated cipher is no stronger against collisions. Since
the other way might not hold, that is there is no obvious reason why these
cannot hold simultaneously:
MD5(M) != MD5(M')
TIGER/192(SHA-1(MD5(M))) == TIGER/192(SHA-1(MD5(M')))
We see that your proposed scheme is likely to be (slightly) weaker than MD5.
--
poncho
------------------------------
** 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
******************************
