Cryptography-Digest Digest #722, Volume #10 Sat, 11 Dec 99 11:13:01 EST
Contents:
Re: If you're in Australia, the government has the ability to modify your files. >>
4.Dec.1999 (wtshaw)
Re: Linear Congruential Generators (wtshaw)
Re: Questions about message digest functions (wtshaw)
Re: If you're in Australia, the government has the ability to modify (fungus)
Re: Random Numbers??? (Scott Nelson)
Re: Random Numbers??? (Scott Nelson)
Re: AES cyphers leak information like sieves (Volker Hetzer)
Re: Questions about message digest functions (Paul Rubin)
Re: New RNG Technique ("Douglas A. Gwyn")
Re: If you're in Australia, the government has the ability to modify your files. >>
4.Dec.1999 ("Rick Braddam")
Re: Random Numbers??? (Anthony Stephen Szopa)
Re: Linear Congruential Generators ("Gary")
Former DDS database cracked (CLSV)
Scott's Screaming Security Method (SCOTT19U.ZIP_GUY)
Re: Random Numbers??? (Tim Tyler)
Re: Random Noise Encryption Buffs (Look Here) ("Trevor Jackson, III")
Re: Linear Congruential Generators (Tim Tyler)
Re: If you're in Australia, the government has the ability to modify ("Trevor
Jackson, III")
Re: Questions about message digest functions (Tim Tyler)
Re: Questions about message digest functions (Tim Tyler)
Re: Attacks on a PKI (DJohn37050)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: If you're in Australia, the government has the ability to modify your
files. >> 4.Dec.1999
Date: Fri, 10 Dec 1999 23:49:38 -0600
In article <[EMAIL PROTECTED]>, "Douglas A. Gwyn"
<[EMAIL PROTECTED]> wrote:
> wtshaw wrote:
> > An html format pushed a reliance on the browser, *text* being better.
> > Reminders: html is not friendly to casual use of what it considers
> > control characters, while text is. For a full descussion of character
> > sets and programming, html is a backward's move....a dumbing down.
>
> We were talking about a help system, not arbitrary text being
> incorrectly converted into HTML format. HTML supports hyperlinks,
> which are extremely useful, as Ted Nelson explained for decades.
And, Helps need to extend conveniently to ANYTHING, in the most complete
manner possible, especially in matters of programming. If you must, and
are not too lazy, copy and paste a URL. It that in attempting to be
universal, lots of reality needs to be dismissed as inconsistent for the
simple-minded, where it is the fine points that at times can count most.
--
When the horse dies, get off.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Linear Congruential Generators
Date: Sat, 11 Dec 1999 00:08:26 -0600
In article <82s5nv$b7u$[EMAIL PROTECTED]>, David A Molnar
<[EMAIL PROTECTED]> wrote about multiseeded keys, which I consider a
most useful option for algorithms not easily tapped in a simple sequence.
> Steven Alexander <[EMAIL PROTECTED]> wrote:
> Your goal is key generation? What does this gain over using the
> randomly typed values directly?
It makes a key generator possible at both ends. This means that the
runtime key can be derived from something meaningful, subject to being
remembered, not stored.
>
....
>
> I think that if you allow someone to input values and get out
> "sufficiently many" keys(*), they will be able to recover enough
> information to predict the LCG on any seed.
If the runtime key and algorithm are good, no. Most that come casually to
your mind are bad, however.
> It then seems to me that this method will give you no better protection
> than using the user's 128 bits as they are. So no real reason to use it.
>
Even a simple LCG is adequate if properly used, much to the disgust of
those that do not what simple things to work sufficiently.
--
When the horse dies, get off.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Questions about message digest functions
Date: Sat, 11 Dec 1999 00:12:42 -0600
In article <[EMAIL PROTECTED]>, Pelle Evensen <[EMAIL PROTECTED]> wrote:
> Have there been any papers published on
> 1a) Whether SHA-1 is a permutation for a message the same length as the
> digest-length (160 bits)?
> 1b) Whether this (1a) holds true for MD5?
> 1c) Is this true (or can it be true) for any other, supposedly secure,
> one-way, collision resistant, hash-functions?
>
> 2a) Whether SHA-1 in a feedback loop, d[n] = h(d[n - 1]), has any short
> periods?
> 2b) Has MD5?
> 2c) Other message digest functions regarded as secure?
>
> For any 2[abc] to hold, it seems like 1[abc] also has to hold for a majority
> of the possible values of h(m).
>
1c holds a host of sins of presumption.
--
When the horse dies, get off.
------------------------------
From: fungus <[EMAIL PROTECTED]>
Subject: Re: If you're in Australia, the government has the ability to modify
Date: Fri, 10 Dec 1999 22:45:33 +0100
"Douglas A. Gwyn" wrote:
>
> "Trevor Jackson, III" wrote:
> > I thought so too. Then I reied to install the latest Microsoft(tm) tools.
> > Visual C now refuses to install unless Internet Explorer is present. I am
> > unable to conceive of a legitimate reason for such "persuasive" market
> > positioning.
>
> That is simply the result of Visual Studio's help system having
> been changed to HTML rather than Microsoft's old proprietary
> format. Looks like progress to me.
So why can't Netscape display the help then? It does "HTML"....
--
<\___/>
/ O O \
\_____/ FTB.
------------------------------
From: [EMAIL PROTECTED] (Scott Nelson)
Subject: Re: Random Numbers???
Reply-To: [EMAIL PROTECTED]
Date: Sat, 11 Dec 1999 06:22:41 GMT
On Thu, 09 Dec 1999 John <[EMAIL PROTECTED]> wrote:
[edited]
>I have been kicking around random # generators. I have 3 sets of 1000
>random #s. Are they? How can you tell?
>
Well, it helps if you have a specific definition of
random in mind. They don't look biased, but with
such a small sample, that's not very meaningful.
If you can gather lots of numbers, you can run DiehardC
on it. ( ftp://www.
That's far from perfect, but a lot better than nothing.
But those kinds of tests won't tell you much about how
predictable the numbers are, or how repeatable.
It's garanteed that they are guessable, since you've
already posted them to the internet. To answer those
kinds of questions, it's necessary to examine the
actual construction of the generator. Of course, those
properties may not matter to you (which is why it helps
to have a specific definition of random.)
------------------------------
From: [EMAIL PROTECTED] (Scott Nelson)
Subject: Re: Random Numbers???
Reply-To: [EMAIL PROTECTED]
Date: Sat, 11 Dec 1999 06:25:44 GMT
On Sat, 11 Dec 1999 [EMAIL PROTECTED] (Scott Nelson) wrote:
> ( ftp://www.
Sorry about that. It should read;
http://www.helsbreth.org/random/diehard.html
Scott Nelson <[EMAIL PROTECTED]>
------------------------------
From: Volker Hetzer <[EMAIL PROTECTED]>
Subject: Re: AES cyphers leak information like sieves
Date: Fri, 10 Dec 1999 15:39:52 +0000
Tim Tyler wrote:
[...]
> I doubt this attack is a likely one against common modern systems - but
> it /is/ an example of a type of attack where doubling the block size
> (without changing much else) results in more than twice the work load for
> the attacker - which was, I believe, what I was asked to produce an
> example of.
Yes, the load is min(2^BlockSize,InterceptedMessageData)
Ok, you found one. :-)
Greetings!
Volker
--
Hi! I'm a signature virus! Copy me into your signature file to help me
spread!
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Questions about message digest functions
Date: 11 Dec 1999 08:00:15 GMT
In article <[EMAIL PROTECTED]>, Jim Gillogly <[EMAIL PROTECTED]> wrote:
>Pelle Evensen wrote:
>> Have there been any papers published on
>> 1a) Whether SHA-1 is a permutation for a message the same length as the
>> digest-length (160 bits)?
>
>Not in a refereed journal. It's obviously a bad flaw: if it were true,
>then the attacker seeing a hash of a 160-bit message that ended up all
>zeroes or ones would know exactly what message had been hashed.
I think Pelle is asking whether SHA-1 is a bijection, i.e. a
permutation on the 2^160 160-bit messages, not a permutation on
the bits in the message.
The answer is still, it's almost certainly not a bijection.
Why on earth would anyone expect it to be one?
>> 1b) Whether this (1a) holds true for MD5?
>
>Ditto.
Yes, ditto.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: New RNG Technique
Date: Sat, 11 Dec 1999 08:14:58 GMT
Steve Harris wrote:
> ... The output bytes themselves have no mathematical correlation to
> each other or to the seed.
Sure they do -- you produce them by a deterministic algorithm.
------------------------------
From: "Rick Braddam" <[EMAIL PROTECTED]>
Subject: Re: If you're in Australia, the government has the ability to modify your
files. >> 4.Dec.1999
Date: Sat, 11 Dec 1999 03:54:14 -0600
wtshaw <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> In article <[EMAIL PROTECTED]>, "Douglas A. Gwyn"
> <[EMAIL PROTECTED]> wrote:
>
> > wtshaw wrote:
> > > An html format pushed a reliance on the browser, *text* being
better.
> > > Reminders: html is not friendly to casual use of what it considers
> > > control characters, while text is. For a full descussion of
character
> > > sets and programming, html is a backward's move....a dumbing down.
> >
> > We were talking about a help system, not arbitrary text being
> > incorrectly converted into HTML format. HTML supports hyperlinks,
> > which are extremely useful, as Ted Nelson explained for decades.
>
> And, Helps need to extend conveniently to ANYTHING, in the most
complete
> manner possible, especially in matters of programming.
Why? Would you, for example, need to view Windows98 help files on a
machine running Linux or Mac's OS? Well, if you want to, you *can* read
Information Server, JScript, Transaction Server, Personal Web Server,
and VBScript help files with a browser... but why would you want to? If
you have those programs for another platform, you should have the html
files or the OS specific help files for them.
I don't have a man page reader. There are hundreds if not thousands of
"help" files for *nix systems that I can't read. So far, that hasn't
been a limitation. OTOH, web browsers are widely and freely available,
so there's no reason why anyone shouldn't have one.
BTW, I've used FrontPage (because it's what I've got) to generate a text
file as an html file -- a text web page. I only used two hyperlinks,
for file downloads, and nothing else specific to html. It was as easy as
using a word processor or text editor. Of the two downloads, one is a
prototype VxD device driver for allocating locked memory, the other is a
dummy for developing and testing the BTree routines which will be used
in the VxD. The page is at
http://www.aic-fl.com/rbraddam/workin.htm -- it ain't much, but it
shows how little more than a plain text file an html page can be.
Considering how much more an html page can do than a plain text file
can, it seems to me that the text file is dumber.
> If you must, and
> are not too lazy, copy and paste a URL.
If you can, and your software is capable, just click on the URL and see
the document without the manual actions which can distract you from the
problem at hand, and at least waste time. My IDE displays the help file
in the same pane I edit code in. I can switch the view of that pane from
the help file to one of several source files, and copy examples from the
help file to paste into my source file. I prefer to save copy and paste
for (code) editing operations, and use URLs for navagation.
If using an IDE makes me lazy, so be it. It is simple to use, quick, and
doesn't make typing errors on long command lines to invoke the compiler
or linker. I spend enough time troubleshooting the code I write, without
spending more to find out that I didn't get what I wanted because of a
typing error on the command line.
> It that in attempting to be
> universal, lots of reality needs to be dismissed as inconsistent for
the
> simple-minded, where it is the fine points that at times can count
most.
I'm sure you've seen Terry Ritter's pages with the embedded graphics.
Have you also checked out his newsgroup archives to see how some of them
looked as text files? I like his web pages much better. I've seen other
pages which added animation to show data flow, and I consider that
another step forward. Terry's pages *are* help files for me, and I'm
glad they aren't just text files.
--
Rick
============================
Spam bait (With credit to E. Needham):
root@localhost
postmaster@localhost
admin@localhost
abuse@localhost
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Subject: Re: Random Numbers???
Date: Sat, 11 Dec 1999 04:20:06 -0800
Reply-To: [EMAIL PROTECTED]
John wrote:
> I have been kicking around random # generators. I have 3 sets of 1000
> random #s. Are they? How can you tell? Integers range from 0 through
> 255 inclusive.
>
> Set1---Set2---Set3
> 113 126 114
> 227 80 140
> <snip>
> 200 180 210
> 70 119 218
> 91 79 152
> 40 216 61
> 0 256 1.1 ****ignore last column. 256 out of range and 1.1 is
> a non-integer. Just wanted to see if you were still with me :) :)
>
> http://www.aasp.net/~speechfb
>
> * Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
> The fastest and easiest way to search and participate in Usenet - Free!
You can be sure that there are set procedure(s) to determine
this. These procedures are surely automated.
Of course there may be certain minimum requirements. I
do not think any attempt to determine an answer to your
question would be of any value at this point.
I am not a professional cryptoanalyst.
I do find it interesting that you chose to name your
columns Set1, Set2, Set3, and that you chose random
numbers from 0 - 255.
Seems like something I would do.
------------------------------
From: "Gary" <[EMAIL PROTECTED]>
Subject: Re: Linear Congruential Generators
Date: Sat, 11 Dec 1999 12:52:47 -0000
Insecure PRNG?
Linear congruential Pseudo-Random Number Generators (PRNG) of the form
Xn+1=AXn+B are always stated to be insecure as the basis of a cipher
bit-stream.
If only the top bit is used on a PRNG of this form how do I find the
constants X0,A and B.
IE Given a large cipher bit-stream produced by the following C function
long NextBit(void)
{
static long X=X0;
X=(X*A)+B;
return (X>>31);
}
How do I determine constants X0,A,B collectively forming a key to the cipher
stream.
(The 3 constants are randomly generated but B is odd and A=1(mod 4))
More over, if two PRNGs of this form were used where the top 5 bits of the
first's output are used to select the single cipher-stream bit in the
second's output, how do I go about solving this?
IE Given a large cipher bit-stream produced by the following C function
long NextBit(void)
{
static long X=X0,Y=Y0;
X=(X*A)+B;
Y=(X*C)+D;
return ((X>>((Y>>27)&31))&1);
}
How do I determine constants X0,Y0,A,B,C,D collectively forming a key to the
cipher stream.
(The 6 constants are randomly generated but B,D odd and A,C=1(mod 4))
G.
------------------------------
From: CLSV <[EMAIL PROTECTED]>
Subject: Former DDS database cracked
Date: Sat, 11 Dec 1999 13:18:41 +0000
As I haven't seen a posting mentioning this
Source ANP [the general dutch press agency] 11-dec-1999:
[Translated from dutch]
BERLIN/HAMBURG - Computer specialists have cracked,
nine years after the dissolving of the DDR,
the database with data on foreign spies for the communist regime.
This was reported by the german magazines Der Spiegel and Focus
saturday. [...]
More info [in german]:
http://www.spiegel.de/spiegel/vorab/0,1518,56060,00.html
http://focus.de/G/GP/GPA/gpa.htm?snr=64119&streamsnr=7
Regards,
Coen Visser
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Crossposted-To: comp.compression,alt.security
Subject: Scott's Screaming Security Method
Date: Sat, 11 Dec 1999 15:46:30 GMT
I know most of you will never have access to good ciphers. The
NSA and crypto gods will see to that. But it does not mean that
you can't use some of the weak AES methods and still obtain a
far higher degree of security than what they want. Below is a
procedure that is "not all or nothing" but would allow one to
encrypt by removing the so called error recovery "feature"
that most people are stuck using.
Here it is in a nutshell You need 3 ciphers and 2 one to one
compressions to achieve the results. IF you have access to the
routines them selves it can be done in one pass since each method
works on the data previously processed but I will explain it as 5 passes.
Pass one Encrypt with AES using weak 3 letter chaining even ECB
Pass two use Compression A "explained latter"
Pass three Encrypt with different key (with different method if one wishes}
Pass four use Compression B
Pass five Encrypt with different key
For the truely insecure among you. You can make this "all or nothing" by
reversing the byte order in the file after each compression. But that requires
whole file at one time..
Know for a disccusion of how to implement the Compression.
by Compression A I mean one of my one to one compressions that
uses a "condition file" with all 256 possible characters. This makes
a starting tree that can be greatly varied. But since compression is
one to one no information is added to data stream. Also the message
will as it passes through the compression will change in length so that
it is highly unlikely that one can know where a block from the previous
encryption layer is passed to next encryption layer and it is highly unlikely
to even be the same length. For Compression B you use a different
"condition file" with all the 256 possible characters in the file.
The input file should be at least long enogh for a few blocks to be
encrypted or you can reject the file as to short. Notice also that
each compression will most likely make the file longer and that
the encryption methods should handle short blocks at the end of files.
Most methods already have a way to do this but if at least one block
is encrypted on each pass you can just pass the short block without
doing anything to it. Since the state of the adapative huffman compressor will
be such that the data in last block will be transformed by the compression.
Any thoughts on this by my nonadmirers.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Random Numbers???
Reply-To: [EMAIL PROTECTED]
Date: Sat, 11 Dec 1999 15:16:26 GMT
Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote:
: John wrote:
:> I have been kicking around random # generators. I have 3 sets of 1000
:> random #s. Are they? How can you tell? [...]
: You can be sure that there are set procedure(s) to determine
: this. These procedures are surely automated.
Well, there is no test to see if an given string is random - unless the
string is trivially small. This was formally proven by Gregory Chaitin.
Deciding whether any given string is random is undecidable.
Indeed, if you are generating our numbers using a finite deterministic
sequence from a given seed, you may be assured that they are not really
random at all.
There are various tests to see how much confusion and apparent disorder
is present in such sequences. Which tests to apply depends partly
on what you want to use the random numbers for - different criteria apply
if you want secure random numbers, from if you want numbers most suitable
for running some monte-carlo simulation.
Some of the following might help with testing:
Diehard:
http://stat.fsu.edu/~geo/diehard.html
ENT:
http://www.fourmilab.ch/random/
PLab tests:
http://random.mat.sbg.ac.at/tests/
Testing Pseudorandom Number Generators - by John-Peter Lund:
http://www.tc.cornell.edu/Edu/SPUR/SPUR95/JP/report.html
Bob Jenkins:
http://ourworld.compuserve.com/homepages/bob_jenkins/testsfor.htm
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Quantum mechanics: the dreams stuff is made of.
------------------------------
Date: Sat, 11 Dec 1999 10:30:22 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Random Noise Encryption Buffs (Look Here)
Tony T. Warnock wrote:
> "Trevor Jackson, III" wrote:
>
> > Tony T. Warnock wrote:
> >
> > > I'd like to re-phrase things to be a little clearer (and perhaps also
> > > correct.)
> > >
> > > Using a radioactive source for random number generation: the number of
> > > atoms will have to be large, around 10**20 atoms or so; finite size
> > > effects will be minimal (really small.) The probability of a decay
> > > happening in an interval is proportional to the length of the interval.
> > > This yields a Poisson distribution of counts in an interval and an
> > > exponential waiting time between counts. The difficulty comes with
> > > detecting the decays. A detector will be in a different state right
> > > after detecting a decay than it will when idle for a while. One can
> > > ignore the time right after a detected hit then start waiting; the
> > > starting time of the interval is not important, only the length. One
> > > also has to take into account what happens when the detector receives a
> > > decay while waiting; the wait has to start over.
> >
> > I don't know why, but this message triggered a small Aha! as I read it. It
> > may be possible to construct a device that produces quantum derived
> > radiation at a constant rate -- no exponential decay. I'm certain we don't
> > have the technology to build such a device today, but if modern crypto is
> > as old as practical computers, we may be able to build one in the next
> > period of similar length.
> >
> > Consider the final phase of an object emitting Hawking radiation. The
> > final blast of radiation transforms all of the rest mass of the device into
> > radiation. What's left over? A singularity. Postulate such a singularity
> > captured and mixed with a gas (say hydrogen). At intervals comtrolled by
> > the gas density the singularity will interact with (eat) an atom, and
> > immediately re-emit the energy as thermal radiation. By maintaining a
> > constant pressure in the enclosing vessel one might produce a mean emission
> > rate that was constant.
> >
> > I suppose we don't know enough about the coefficients of interaction of
> > such a singularity to determine the feasibility of the technique. But the
> > idea of putting such an object to practical use is appealing.
>
> Wouldn't there still be Brownian motion type fluxuations?
Absolutely. But the mean rate would be constant. Linear on gas
density/pressure.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Linear Congruential Generators
Reply-To: [EMAIL PROTECTED]
Date: Sat, 11 Dec 1999 15:26:05 GMT
wtshaw <[EMAIL PROTECTED]> wrote:
: In article <82s5nv$b7u$[EMAIL PROTECTED]>, David A Molnar
: <[EMAIL PROTECTED]> wrote about multiseeded keys, which I consider a
: most useful option for algorithms not easily tapped in a simple sequence.
:> Steven Alexander <[EMAIL PROTECTED]> wrote:
:> Your goal is key generation? What does this gain over using the
:> randomly typed values directly?
: It makes a key generator possible at both ends. This means that the
: runtime key can be derived from something meaningful, subject to being
: remembered, not stored.
His next question was "what does this gain over using randomly typed
values as the input to SHA-1".
The answer to this must surely be "very little".
If you need a RNG, for cryptography, it is /rarely/ wise to choose an LCG.
This is an instance where the entropy comes from the user entering
a bunch of numbers or a string of characters.
The numbers themselves (being entered by a human) will have
less-than-maximal entropy. Feeding them as a seed to an RNG will
change their entropy content not one whit.
What you need is a method of distilling randomness from a longer string
with a less-than-maximal per-character entropy.
Using a hash under circumstances like these is the conventional way to
distill entropy from such a longer (or even variable-length) source.
Using a RNG under these circumstances is like using a screwdriver to crack
a nut - it's simply the wrong tool for the job.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Suicidal twin kills sister by mistake.
------------------------------
Date: Sat, 11 Dec 1999 10:44:53 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: If you're in Australia, the government has the ability to modify
fungus wrote:
> "Douglas A. Gwyn" wrote:
> >
> > "Trevor Jackson, III" wrote:
> > > I thought so too. Then I reied to install the latest Microsoft(tm) tools.
> > > Visual C now refuses to install unless Internet Explorer is present. I am
> > > unable to conceive of a legitimate reason for such "persuasive" market
> > > positioning.
> >
> > That is simply the result of Visual Studio's help system having
> > been changed to HTML rather than Microsoft's old proprietary
> > format. Looks like progress to me.
>
> So why can't Netscape display the help then? It does "HTML"....
I think Microsoft(tm) "improved" the HTML format. They _call_ it HTML, but it
isn't.
It's funny that they started as a language company, and WHG3 understands the value
of good tools. But they keep screwing things up just enough to disqualify them
for serious work. I suppose if they are aiming Really Bad Software at the masses
of amateur developers quality doesn't matter -- most of their customers can't tell
the difference.
>
>
> --
> <\___/>
> / O O \
> \_____/ FTB.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Questions about message digest functions
Reply-To: [EMAIL PROTECTED]
Date: Sat, 11 Dec 1999 15:32:48 GMT
wtshaw <[EMAIL PROTECTED]> wrote:
: In article <[EMAIL PROTECTED]>, Pelle Evensen <[EMAIL PROTECTED]> wrote:
:> Have there been any papers published on
:> 1a) Whether SHA-1 is a permutation for a message the same length as the
:> digest-length (160 bits)? [snip]
:> 1c) Is this true (or can it be true) for any other, supposedly secure,
:> one-way, collision resistant, hash-functions?
: 1c holds a host of sins of presumption.
Another wtshaw cryptic comment ;-)
What is the answer to 1c?
Is it true? Tim does not know for certain, but thinks the answer is
"yes":
Hash functions may be made from block cyphers. Block cyphers are
reversible. Consequently, a message hash of a message with the hash
size, the block size and the message size all equal will be a bijection.
*Can* it be true? *Definitely* "yes".
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Mental backup in progress - do not disturb.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Questions about message digest functions
Reply-To: [EMAIL PROTECTED]
Date: Sat, 11 Dec 1999 15:36:02 GMT
Paul Rubin <[EMAIL PROTECTED]> wrote:
: In article <[EMAIL PROTECTED]>, Jim Gillogly <[EMAIL PROTECTED]> wrote:
:>Pelle Evensen wrote:
:>> Have there been any papers published on
:>> 1a) Whether SHA-1 is a permutation for a message the same length as the
:>> digest-length (160 bits)?
:>
:>Not in a refereed journal. It's obviously a bad flaw: if it were true,
:>then the attacker seeing a hash of a 160-bit message that ended up all
:>zeroes or ones would know exactly what message had been hashed.
: I think Pelle is asking whether SHA-1 is a bijection, i.e. a
: permutation on the 2^160 160-bit messages, not a permutation on
: the bits in the message.
Indeed.
: The answer is still, it's almost certainly not a bijection.
: Why on earth would anyone expect it to be one?
It appears to be a desirable property.
Part of the point of hashes is to avoid hash collisions. A permutation
would avoid collisions to the maximum possible extent.
Nothing else would do this for the case where message size = hash size.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Flashlight: case for holding dead batteries.
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: Attacks on a PKI
Date: 11 Dec 1999 15:49:07 GMT
I am part of a panel at RSA 2000 that is talking about public key validation
and non-repudiation. A bogus key can be a problem in many various ways.
Don Johnson
------------------------------
** 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
******************************
