Cryptography-Digest Digest #729, Volume #10 Mon, 13 Dec 99 02:13:01 EST
Contents:
Re: Questions about message digest functions (Tim Tyler)
An attack on the WTLS SHA_XOR_40 MAC algorithm (David Hopwood)
Re: If you're in Australia, the government has the ability to modify your files. >>
4.Dec.1999 (Tim Tyler)
Better encryption? PGP or Blowfish? (molypoly)
Re: Better encryption? PGP or Blowfish? (Tom St Denis)
Re: Are thermal diodes as RNG's secure (Tom St Denis)
Re: Better encryption? PGP or Blowfish? (Y. Karmenoil)
Re: Please help this newbie crack a potentially simple encryption (Jim Gillogly)
Re: old Microsoft Mail 3.0b encryption? (Keith A Monahan)
Re: Please help this newbie crack a potentially simple encryption ("r.e.s.")
Re: Please help this newbie crack a potentially simple encryption (Jim Gillogly)
Re: Digitally signing an article in a paper journal (Lincoln Yeoh)
Re: Are thermal diodes as RNG's secure (Lincoln Yeoh)
Re: Please help this newbie crack a potentially simple encryption (Jim Gillogly)
Re: Scott's Screaming Security Method (wtshaw)
Re: Questions about message digest functions (wtshaw)
The future of telecommunication? ("Melinda Harris")
----------------------------------------------------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Questions about message digest functions
Reply-To: [EMAIL PROTECTED]
Date: Mon, 13 Dec 1999 02:03:10 GMT
Lasse Reichstein Nielsen <[EMAIL PROTECTED]> wrote:
: IF there exist collision intractable hashfunctions (afaik. still not
: decided) [...]
Surely this may be answered in the affirmative, in that such functions
definitely *exist*. Whether any human can ever find one is much more
questionable, of course.
The construction is much the same as the demonstration that a "perfect"
block cypher exists. Fill an infinitely big book with random numbers the
length of the hash, one for each message. As the hash size increases,
the chance of a hash collision becomes miniscule, and the chances of
finding one dwindle. Since the hashes are allocated on a completely
random basis, no attack is better than brute force.
The hash may be effectively made one-way if required by listing the hashes
in size order (and then in alphabetical order), of the messages.
Such a collision-intractable hash function exists only in mathematical
never-never land, of course - but I /presume/ this was the sense in
which you asked about existence.
Can such a hash be found in the form of a finite function? Not IMO.
: This doesn't require the hashfunction to be a permutation on messages
: of the appropriate size.
In this sort of context, "intractability" is sometimes taken as a
statement about how the work factor scales with the size of the hash.
You don't need a hash that is a bijection when the message size is equal
to the size of the hash in order to get security - if you have a big
enough hash.
The bijection property minimises the chance of hash collisions (when
choosing messages at random). Whatever size hash you use, a bijection
will make collisions as unlikely as possible. This seems a desirable
property - especially when there are other reasons for not wanting to
transmit a monster-sized hash.
Part of the point of a hash is to make it hard to find two messages that
hash to the same value. A bijection makes it not just hard, but
/impossible/ (for messages of the right length).
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
It is easier to get forgiveness than permission.
------------------------------
Date: Mon, 13 Dec 1999 01:25:45 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: An attack on the WTLS SHA_XOR_40 MAC algorithm
=====BEGIN PGP SIGNED MESSAGE=====
WTLS, "Wireless Transport Layer Security", is the security layer of the
WAP protocol suite (www.wapforum.org). It is loosely based on TLS, with
modifications to allow running on datagram transports, removing
dependencies on ASN.1, support for elliptic curve key exchange, and
various other tweaks.
The latest proposed spec (for version 1.2) is in PROP-WTLS-19991105.pdf
in the technical docs section of the WAP forum site. For the MAC
algorithms (which have not changed from the previous version, 1.1),
it lists
- a null algorithm that provides no authentication (not a good idea
IMHO, but at least it's documented as such),
- four algorithms based on HMAC-MD5 and HMAC-SHA1 truncated to 40
and 80 bits,
- and the following algorithm, which I've just broken:
# SHA_XOR_40 (4)
#
# A 5-byte XOR checksum. The input data is first divided into the
# multiple blocks of 5 bytes. Then all blocks are XOR'ed one after
# another. If the last block is less than 5 bytes, it is padded with
# 0x00. SHA is much stronger than XOR for generating MAC's,
# although there were no significant attacks reported on XOR MAC's,
[Note that this is *not* the XOR MAC described in "XOR MACs: New Methods
for Message Authentication Using Finite Pseudorandom Functions," by
Mihir Bellare, Roch Gue'rin and Phillip Rogaway; it is an ad-hoc
construction that I haven't seen used anywhere else.]
# which must be encrypted and is [sic] only used for CBC mode block
# ciphers. XOR is only intended for some devices with very limited
# CPU resources.
# Warning: XOR can not provide as strong message integrity
# protection as SHA can. It is recommended that the security
# consequence should be carefully evaluated before XOR
# MAC is adopted. In other than MAC operations for message
# integrity (eg., PRF) the full-length SHA-1 is used.
In fact there is an easy attack on SHA_XOR_40 (when used with a block
cipher in CBC mode). First note that if the MAC size were equal to the
block size, then rearranging the order of the ciphertext blocks would
not affect the XOR of the decrypted plaintexts:
Let P[0..n-1] be the plaintext, of length n blocks.
Encryption:
C[-1] := IV
P[n] := XOR[j = 0..n-1](P[i])
C[i] := E[K](C[i-1] XOR P[i]), for i = 0..n
Decryption:
C[-1] := IV
P[i] := D[K](C[i]) XOR C[i-1], for i = 0..n
X := XOR[j = 0..n](P[j])
:= IV XOR C[0] XOR ... XOR C[n-1] XOR D[K](C[0]) XOR ... XOR D[K](C[n])
Accept iff X = 0.
X does not depend on the order of the blocks C[0..n-1]. If an attacker
swaps two regions of ciphertext blocks, for example, the effect will
be to swap the corresponding regions of plaintext (apart from errors
at the beginning and just after the end of each region).
The fact that the checksum is calculated in 5-byte chunks that do not
match the cipher block boundaries, might appear to prevent this attack,
but in fact it just means that we are only able to reorder chunks of
size LCM(cipher block size, 5 bytes). For the currently-defined WTLS
ciphersuites, this is always LCM(8, 5) = 40 bytes.
To demonstrate this, let Z(a, b, c, d, e) be the exclusive-or of the
eight 5-byte blocks that result from splitting cipher blocks a..e. Then
the first few terms of the X calculation are:
X = XOR[j = 0,5,..)](Z(P[j], P[j+1], P[j+2], P[j+3], P[j+4])
= Z(IV , C[0], C[1], C[2], C[3]) XOR
Z(D[K](C[0]), D[K](C[1]), D[K](C[2]), D[K](C[3]), D[K](C[4])) XOR
Z(C[4], C[5], C[6], C[7], C[8]) XOR
Z(D[K](C[5]), D[K](C[6]), D[K](C[7]), D[K](C[8]), D[K](C[9])) XOR
Z(C[9], C[10], C[11], C[12], C[13]) XOR
...
= Z(IV , 0, 0, 0, 0) XOR Z(0, C[0], C[1], C[2], C[3]) XOR
Z(D[K](C[0]), D[K](C[1]), D[K](C[2]), D[K](C[3]), D[K](C[4])) XOR
Z(C[4], 0, 0, 0, 0) XOR Z(0, C[5], C[ 6], C[ 7], C[ 8]) XOR
Z(D[K](C[5]), D[K](C[6]), D[K](C[7]), D[K](C[8]), D[K](C[9])) XOR
Z(C[9], 0, 0, 0, 0) XOR Z(0, C[10], C[11], C[12], C[13]) XOR
...
which is also independent of the ordering of the 40-byte chunks,
excluding the last chunk containing the encrypted MAC.
So, SHA_XOR_40 is insecure for plaintexts exceeding 80 bytes (so
that there are at least two chunks to reorder), with an attack
requiring negligable work.
My recommendation is that SHA_XOR_40 be dropped from WTLS 1.2.
The argument for including it was based on processing speed
limitations, but IMHO that doesn't stand up very well to closer
examination. Although the processing speed of many wireless devices
may be fairly limited, so is the available bandwidth (the maximum
bandwidth currently available on any WDP-supporting network is
64 kbit/sec). As bandwidth increases, so will processing speed.
[Note that a device's HMAC implementation only has to be able to
keep up with its own maximum bandwidth, taking into account any
other work being done at the same time. It doesn't have to be able
to keep up with the maximum bandwidth of its peer or of the network,
if that is greater.]
If SHA_XOR_40 is dropped, then to prevent any confusion and to
simplify security analysis, the number that was allocated to
it should not be re-used for any future algorithms. For example:
# DO_NOT_USE (4)
#
# This number was previously allocated to a 5-byte XOR-based
# checksum [WTLS 1.1]. However, that algorithm was found to be
# insecure [Hopwood99].
# New implementations of WTLS MUST NOT suggest (for clients)
# or accept (for servers) this algorithm.
#
# [Hopwood99] - this post, submitted as a formal comment if necessary.
- --
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
"Attempts to control the use of encryption technology are wrong in principle,
unworkable in practice, and damaging to the long-term economic value of the
information networks." -- UK Labour Party pre-election policy document
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOFRJ8jkCAxeYt5gVAQGoDQf/dDuiONMcnE943kNM+GG+RRVePg/ucogR
SlbcFcAJjjiFTVu930reK5CDMf05eRR0OveZbJMk7q0GSQiNIfjrGu9IAC+4wB3f
eaOGN05R53MhpuBkIahh2sscU1kCWEoB9lIWkA1gUUglu090tMWT7ATWl51OsJvQ
Lacne7WP6SfUTpXbpCYcI5vUZ8/lp4NbJZ3xiN3LZarydWgnzMgRBik4lh47ch7/
ISh/P5UkH6bvY6+lXhpzqUICmF+X0sLjTOltKrTcUKcU4mgOePbQN+iXAcoYN8zd
RxMFdJSajnBHDtLZYx24cP1nl0wxGqVvRaSQP4ygDdUsEyeE3G+Xyw==
=kuQz
=====END PGP SIGNATURE=====
------------------------------
Crossposted-To: alt.privacy
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: If you're in Australia, the government has the ability to modify your
files. >> 4.Dec.1999
Reply-To: [EMAIL PROTECTED]
Date: Mon, 13 Dec 1999 03:14:26 GMT
In sci.crypt wtshaw <[EMAIL PROTECTED]> wrote:
: "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
:> Greg wrote:
:> > News flash: [...]
:> > If you have Microsoft Windows and Internet Explorer, your
:> > government has the ability to modify your files. The bugs
:> > that are in these fine pieces of software allow the governments
:> > of the world to do lots of shit with the files on your hard disk.
:> > Don't worry about the law- they certainly don't.
:>
:> It would be nice if you could get your facts straight.
:> Presumably you're talking about the so-called "NSAkey".
:> If so, you've completely mischaracterized it.
: No, he is right on, even without that.
: The game is afoot, but the mission is compromised.
Indeed. The irony is no conspiracy theory or involvement of the
government appears to have been required:
The software companies shot themselves (and all their users) in the
foot, without any external assistance :-(
You'd think that after the macro virus fiascos, people would have learned
that putting native executable content into user documents was a recipe
for security disasters.
Yet today there are email viruses that propagate themselves when the
user looks at the text of the email in certain newsreaders. It's sad.
It seems the more "advanced" systems get, the more security holes they
have.
I doubt the governments of the world have ever had such ability to look
into the lives of the citizens as they have today.
Cryptography is of little protection if it is running on a system with
more holes in it than a pair of fish-net tights.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Press ESC once to quit, twice to continue.
------------------------------
From: molypoly <[EMAIL PROTECTED]>
Subject: Better encryption? PGP or Blowfish?
Date: Mon, 13 Dec 1999 03:21:55 GMT
Which is a harder encryption to break? The encryption in PGP program
or McAfee's PcCrypto program which has the 128 bit Blowfish encryption.
Thanks. You can reply to me at (remove the "nospam")
[EMAIL PROTECTED]
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Better encryption? PGP or Blowfish?
Date: Mon, 13 Dec 1999 03:30:38 GMT
In article <831oof$c6g$[EMAIL PROTECTED]>,
molypoly <[EMAIL PROTECTED]> wrote:
> Which is a harder encryption to break? The encryption in PGP program
> or McAfee's PcCrypto program which has the 128 bit Blowfish
encryption.
> Thanks. You can reply to me at (remove the "nospam")
> [EMAIL PROTECTED]
>
You have sucessfully compared apples to oranges and if you don't know
why, you wouldn't fully understand a proper response anyways.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Are thermal diodes as RNG's secure
Date: Mon, 13 Dec 1999 03:35:17 GMT
In article <[EMAIL PROTECTED]>,
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
> Tom St Denis wrote:
> > [EMAIL PROTECTED] wrote:
> > > Is it possible to manipulate the electronics to make the output
of the
> > > [thermal] diode not-so-random?
> > Change the voltage? As I understand it diodes work by letting
current
> > go thru only when it passes a voltage, but when it equals the
voltage
> > it let's it pass at 'random'.
>
> "Better to remain silent and be thought a fool than to speak and
> remove all doubt."
>
> Really, when you don't understand something (like the operation
> of a semiconductor junction), posting guesses about it is
> counterproductive.
As was explained by a friend to me.
A diode lets current pass thru a circuit [or line] in a certain
direction only. They have a 'cutoff' voltage where it will not let
current passing, acting as a open circuit [ if the voltage is below ].
If the voltage is above it will let it pass, and if it's at the voltage
they can behave randomly.
If I interpred this properly a 'noisy' diode circuit is a diode which
is fed 'just' enough voltage to maintain the noisy open/close state.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Y. Karmenoil)
Subject: Re: Better encryption? PGP or Blowfish?
Date: Mon, 13 Dec 1999 03:59:01 GMT
molypoly <[EMAIL PROTECTED]> wrote:
> Which is a harder encryption to break? The encryption in PGP program
>or McAfee's PcCrypto program which has the 128 bit Blowfish encryption.
>Thanks.
McAfee's PcCrypto has secret source code, doesn't it? In that case what you
really mean is the encryption that we strongly believe is implemented
properly in PGP because the source code is public, vs. the encryption that
is claimed to be implemented properly in McAfee's PcCrypto. It's an easy
choice.
--
"Y. Karmenoil" is actually [EMAIL PROTECTED] (4815 620973).
0 123456789 <- Use this key to decode my email address and name.
Play Five by Five Poker at http://www.5X5poker.com.
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: Please help this newbie crack a potentially simple encryption
Date: Mon, 13 Dec 1999 04:15:20 +0000
"Douglas A. Gwyn" wrote:
> I personally would try to categorize the CT values into the
> classes "consonant" and "vowel", or rather into a slightly
> greater number of analogous classes, by fitting a Hidden
> Markov Model to it (using the Baum/Welch/Eagon algorithm for
> Maximum-Likelihood Estimation).
It's possible that the key structure will also be coherent --
for example, if it is like a Grandpre cipher the key matrix
may be a list of 9 9-letter words, perhaps with a keyword
running down the first letters. If you can identify some letters
or even vowels versus consonants with Doug's procedure, a "grep"
may help identify the keywords, if any.
Besides the obvious exact string matches, you might look for long
near matches with a different character in the middle -- the
corresponding numbers may be homophones.
Interestingly, this very cipher has been posted to
http://www.codasaurus.com/ubb/Forum4
as an unknown cipher, with the same paucity of provenance. My
curiosity's now up -- where did this cipher come from?
--
Jim Gillogly
Mersday, 23 Foreyule S.R. 1999, 04:06
12.19.6.14.1, 3 Imix 9 Mac, Second Lord of Night
------------------------------
From: [EMAIL PROTECTED] (Keith A Monahan)
Subject: Re: old Microsoft Mail 3.0b encryption?
Date: 13 Dec 1999 05:16:08 GMT
Joe,
JPeschel ([EMAIL PROTECTED]) wrote:
: I guess I don't have one. If this is one of those stored passwords
: and all you want to do is see behind the asterisks, try
: Snadboy's Revelation.
Well, it's not a 'stored' password AFAIK. I mean, I would hope not. Perhaps
they are just storing the hash. In any event, I did find a work around for
the initial problem. Perhaps with the semester ending this week I'll have
somewhat more time(still have to work 50+hrs/week) to probe into it
a little further. Thanks for the response.
: Joe
Keith
P.S. I'm still working on my HD passphrase. :) I'm planning on buying a
500mhz machine running NT workstation as a dedicated hack machine, hopefully
a little after xmas time. So all I need now is an effective PLAN to
attack it. I have to figure out ways to execute a dictionary attack, prune
out clearly incorrect passphrases, and then limit my exhaustive search
based on my knowledge of the passphrase. Big job.
------------------------------
From: "r.e.s." <[EMAIL PROTECTED]>
Subject: Re: Please help this newbie crack a potentially simple encryption
Date: Sun, 12 Dec 1999 21:56:52 -0800
"Jim Gillogly" <[EMAIL PROTECTED]> wrote ...
[...]
: Interestingly, this very cipher has been posted to
: http://www.codasaurus.com/ubb/Forum4
[...]
That site seems not to allow access. (?)
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: Please help this newbie crack a potentially simple encryption
Date: Mon, 13 Dec 1999 06:19:45 +0000
"r.e.s." wrote:
>
> "Jim Gillogly" <[EMAIL PROTECTED]> wrote ...
> [...]
> : Interestingly, this very cipher has been posted to
> : http://www.codasaurus.com/ubb/Forum4
> [...]
>
> That site seems not to allow access. (?)
Sorry, I guess it's in transition. Try:
http://www.codebuster.home.mindspring.com/FREDROOM.HTM
and go to "Chat With Other Crypto Enthusiasts". This cipher
is discussed in the "Puzzle Forum" under the title "numerical puzzle".
--
Jim Gillogly
Mersday, 23 Foreyule S.R. 1999, 06:17
12.19.6.14.1, 3 Imix 9 Mac, Second Lord of Night
------------------------------
From: [EMAIL PROTECTED] (Lincoln Yeoh)
Subject: Re: Digitally signing an article in a paper journal
Date: Mon, 13 Dec 1999 06:39:03 GMT
Reply-To: [EMAIL PROTECTED]
On Thu, 09 Dec 1999 10:06:38 +0100, KloroX <[EMAIL PROTECTED]> wrote:
>I have the following problem. I shall publish one or more articles in
>scientific journals which are printed on paper (i.e. no digital
>storage is used for the medium). For reasons which I am not discussing
>here, I cannot use my real name as author at present, but I wish to
>use a pseudonym and be able to demonstrate publicly my (real) identity
>as the author of the article(s) at a later date.
>
>It is not possible to sign the entire article, because the contents of
>the text may be changed slightly by editors (but enough to invalidate
>a digital signature) without consulting me. The most that an editor
Why not?
Just sign the whole article with PGP with an ASCII signature. So what if
the editors invalidate the signature. You can also mention that due to
editing the signature may not be valid, but the original will be available
somewhere at sometime.
Look at it this way, if you can produce something that matches the
signature even at a later date, it means that either:
1) You are the author of that paper.
or:
2) You know how to crack the PGP SHA1/MD5 hash in such a way that the
content is minimally changed with no obvious weird stuff stuck in the
content- it looks just like minor editing..
Which are people going to believe?
If it's 2), nobody will care about the paper itself, unless it's like "high
efficiency low cost mass-energy conversion" ;).
Cheerio,
Link.
****************************
Reply to: @Spam to
lyeoh at @[EMAIL PROTECTED]
pop.jaring.my @
*******************************
------------------------------
From: [EMAIL PROTECTED] (Lincoln Yeoh)
Subject: Re: Are thermal diodes as RNG's secure
Date: Mon, 13 Dec 1999 06:43:49 GMT
Reply-To: [EMAIL PROTECTED]
On 13 Dec 1999 01:34:18 GMT, [EMAIL PROTECTED] (Bill Unruh) wrote:
>In <831142$s6l$[EMAIL PROTECTED]> [EMAIL PROTECTED] writes:
>
>>Is a termal diode being used as a RNG secure?
>
>If it is used properly. The big problem with hardware random number
>generators is bias. You must cook theoutput to get rid of any effects of
>the biases.
How can we cook such output?
Do we just flip the output(s) according to another stream?
Link.
****************************
Reply to: @Spam to
lyeoh at @[EMAIL PROTECTED]
pop.jaring.my @
*******************************
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: Please help this newbie crack a potentially simple encryption
Date: Mon, 13 Dec 1999 06:47:54 +0000
Jim Gillogly wrote:
> Sorry, I guess it's in transition. Try:
> http://www.codebuster.home.mindspring.com/FREDROOM.HTM
> and go to "Chat With Other Crypto Enthusiasts". This cipher
> is discussed in the "Puzzle Forum" under the title "numerical puzzle".
One more try, and I give up if I screw it up yet again.
http://codebuster.home.mindspring.com/FREDROOM.HTM
(without the www. in front.). Sorry again.
--
Jim Gillogly
Mersday, 23 Foreyule S.R. 1999, 06:46
12.19.6.14.1, 3 Imix 9 Mac, Second Lord of Night
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Crossposted-To: comp.compression,alt.security
Subject: Re: Scott's Screaming Security Method
Date: Mon, 13 Dec 1999 01:06:37 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(Okra Meinly) wrote:
> [EMAIL PROTECTED] (wtshaw) wrote:
>
> The name reminds me of a failed snack food called "Screaming Yellow
> Zonkers". Remember those?
I bet you could wash them down with Ripple, which is code for a drink that
could never be called a wave.
--
There are those who are neither constrained by in belief of
their power over time and space.
All will have found too late when their time has run out,
and others find for them, a little space to be forgotten in.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Questions about message digest functions
Date: Mon, 13 Dec 1999 01:03:46 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>
> Surely collision resistance and security are generally positively
> connected - rather than negatively.
Much depends on the size of the hashspace, the output, as are there too
many keys to look at in the first place. If the hashspace is too small,
then you compare different possible inputs to see which are reasonable.
If there is not collision, then one input and one output can be paired,
decrypted through the process of searching.
>
> There seems to be a weak sense in which an attacker has advance
> information when the hash-size and the message size are equal and he
> knows in advance that the hash is a bijection:
It all depends if you want or have to throw something away.
>
> If he wants to find a message that has a particular hash, he knows that a
> message that has that hash exists.
We agree here.
>
> This sense seems rather irrelevant in practice - as an attacker is
> /usually/ trying to find a second message that matches an existing hash -
> not trying to find a message that corresponds to a hash which has no
> corresponding message in the first place.
It depends what is the purpose of the attack. One string might be used as
an input to different hashes; solve one to solve the other.
>
> I have difficulty in seeing any practical problem in this area -
> is this property what you are referring to? Or is there some other
> way in which security and hash collision exclude one another?
Practical experience demonstrates that solving hashes is undesirable.
>
> I beleieve it is possible to have both - and indeed maximum security
> should generally be accompanied by minimal hash collisions - in order
> to best resist brute force.
In an immense hashspace, you can have more collisions than can be handled,
and still have them fairly rarely occuring. Immense, huge, bewildering,
equal to thousands of bits.
>
> : As for block ciphers being so simple and symmetric as to be reversable, I
> : know of at least one that is not, depending on whether you call it a block
> : cipher. [...]
>
> Hmm. Block cyphers are certainly usually reversible. They are rarely
> simple. Sometimes, their inverse function may be computationally
> difficult to determine.
I'm sitting on my hands not to post an example.
>
> : Surely there is a war of data to have just sufficient collisions
> : to maximize a function as a hash and insufficient reversability to allow
> : its solution.
>
> War? Way? I was not saying that you /should/ build hashes (or one
> hashes) from block cyphers - just that there exist methods of
> doing so.
I have fought such wars on a desk top, a figure of speech, like two handed
solitare chess. I found a good compromise that seems to work...example
deleted.
>
> Hashes need not be easy to reverse - indeed one-way hashes should be
> difficult to invert. The very idea of reversing a hash makes little sense
> anyway in the common case where the message size exceeds the hash size.
> --
You need not actually reverse it, just use in a manner that produces an
output population paired with input values. If this is simple to do, the
hash is bad....guess I need another scale. Now is a good enough excuse to
pull out one scale for general amusement:
It is in terms of keys. the KP%, Key Purity Percentile Scale, where 100%
means all keys are useful and distinct. Penalities for being able to
derive values from partial keys should apply, as well as for having
duplicate and ineffective keys, but don't have a good method to quantize
them, just that they tend to pull the rating toward 0%. I've been messing
with this idea for some time, with others.
--
There are those who are neither constrained by in belief of
their power over time and space.
All will have found too late when their time has run out,
and others find for them, a little space to be forgotten in.
------------------------------
From: "Melinda Harris" <[EMAIL PROTECTED]>
Subject: The future of telecommunication?
Date: Mon, 13 Dec 1999 01:58:35 -0500
Is it possible?? A virus that encrypts your entire hardrive upon logon?
------------------------------
** 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
******************************
