Cryptography-Digest Digest #863, Volume #10 Fri, 7 Jan 00 15:13:01 EST
Contents:
Re: Questions about message digest functions (Tim Tyler)
Re: Blowfish (Robert Sandilands)
Re: Why the Cryptonomicon in Cryptonomicon? ("Tony T. Warnock")
Re: AES wise? (Tim Tyler)
Re: Anagram (Dan Day)
Re: Unsafe Advice in Cryptonomicon (Mok-Kong Shen)
Re: REDOC: First use: key dependent S-BOXES (Mok-Kong Shen)
Mispronounce words. (OT Re: How to pronounce "Vigenere"?) (William Rowden)
Re: Truly random bistream (Tim Tyler)
Re: frequency analysis with homophones ("r.e.s.")
Re: Interview with an ECHELON Spy (Jim)
Re: Identifier anonymization (Paul Rubin)
Re: REDOC: First use: key dependent S-BOXES (David Wagner)
Re: Identifier anonymization (Paul Rubin)
----------------------------------------------------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Questions about message digest functions
Reply-To: [EMAIL PROTECTED]
Date: Fri, 7 Jan 2000 19:06:46 GMT
[EMAIL PROTECTED] wrote:
: Tim Tyler wrote:
:> lordcow77 wrote:
:> [...]
:> a hash should approximate a pseudo-random function?
:>
:> I don't care *how* "simple" and "widely accepted"
:> it is - it's dead wrong.
: The wide-acceptors have a reason: we can't find
: functions better than random.
That's not entirely true. I could present one without
much difficulty.
Recall that I calim that each hash value should occur
with as near-equal frequency as possible given the
target distribution of message files to be hashed.
A classical pseudo-random function would produce something
more like a bell-shaped distribution.
Consequently, a function which approximates my ideal more closely
than a pseudo-random function would could be easily created by
employing some ordinary hash function where message size != hash size,
and using a one-way pseudo-random permutation when message size == hash
size.
This would perform better by my criteria of avoiding hash collisions than
a traditional hash design.
: The improvement against brute force is entirely trivial, and seems
: to come at a terrible cost.
Hang on. There *is* no "terrible cost".
I'm talking about the ideal that hash functions should approach. If few
today understand how to build algorithms that approach the ideal, that's
neither here nore there as far as the nature of the ideal system goes.
Personally I doubt that building a one-way hash function with the
characteristics I believe are desirable would be /that/ difficult.
All that would probably be required is some clear thinking on the
matter.
:> For /many/ applications hashes should make
:> finding two messages which hash to the same
:> value as difficult as possible. Alternatively
:> (and perhaps more commonly) they should make
:> finding a second message with the same
:> hash as a given message as difficult as possible.
: There's another property generally required of
: hash functions: a hash should be "preimage
: resistant", that is one-way.
Firstly, not all hashes need to be one way.
However, for cryptography, one-way hashes are important. I see this
described as for some hash h, it is hard to find a message M, such that
hash(M) = h.
I observe that literally appling this criteria appears to suggest that
a PRF as a hash (when hash size = message size) apparently offers
advantages over a bijection - since for some h there exists no
M in the set of possible messages such that hash(M) = h.
I doubt that this criteria is actually important. What I believe is
required for most practical applications is that it is hard to find a
message M, such that hash(M) = h, for some h that is the hash of a
message.
:> A hash that has the distribution of an unbiased
:> "pseudo random function" demonstrably fails to
:> get anywhere near the optimum collision resistance.
:> Consequently it fails to offer the property
:> demanded by a good hash - that of making finding
:> multiple messages with the same hash as hard as
:> possible. Most obviously, it fails against a
:> brute force search through the space of possible
:> messages for a matching hash.
: Not at all.
Yes at all ;-)
: Even for modest length messages, just
: a few bytes longer than the digest, random
: functions will map preimages to digest so evenly
: that the expected time for brute-force search will
: differ by an tiny fraction of a percent,
: compared to a hash that maps exactly the same
: number of preimages to each digest. [...]
That's probably fair enough. My objections are only really
very significant when the size of the message is small.
When the messages to be hashes are much longer than the hash, the
hashes will still follow a bell-shaped curve, rather than being a
near-flat distribution. In principle a brute force search could
check the hashes that occur most frequently first, and do better
than it would otherwise be able to manage.
Imagine an frequency table of 3-bit hashes:
3-bit message - optimum hash:
h 0 1 2 3 4 5 6 7
f 1 1 1 1 1 1 1 1
3-bit message - ordinary PRF hash:
h 0 1 2 3 4 5 6 7
f 0 0 1 1 1 1 2 2
8-bit message - optimum hash:
h 0 1 2 3 4 5 6 7
f 32 32 32 32 32 32 32 32
8-bit message - ordinary PRF hash:
h 0 1 2 3 4 5 6 7
f 31 36 35 28 34 29 33 30
As the size of the message gets bigger the deviation of the PRF hash
from the optimal hash effectively reduces.
:> For example, when the hash size is equal to the
:> message size, use of a hash that simulates a PRF
:> will introduce totally unnecessary hash collisions.
:> Generally speaking - for most applications of a
:> hash - this is not good.
: If you only need collision resistance, there's no
: reason to use a hash if the digest is as big as
: the messages; the identity function is collision
: free. If you do need preimage resistance, then it
: would seem that a pseudo-random permutation would
: be optimal by your criteria.
Yes. Though a PRP only applies when the hash size is
exactly equal to the message size.
: But here's the problem - how do you create this
: pseudo-random permutation so that's it's as strong
: as pseudo-random-function hashes such as SHA-1?
: Can you describe a permutation on 160-bit vectors
: (or even an almost-permutation) that is easy to
: compute but takes anywhere near 2^160 steps to
: invert?
You could use one /very/ big table representing the random permutation.
2^160 is big, but not so big that it's totally unmanagable. The
table is ordered by message value. Looking up the hash of a message
can be done by bisecting until the appropraite table entry is found.
Looking up the message for a hash is not "in principle" any harder -
but in practice it involves wading through the entire table until the
correct hash is found. If the table could be sorted, the function would
lose its "one-way" property. But sorting such a table is a lot harder
than searching it.
I know that there are constructions for building hashes from /asymmetric/
block cyphering schemes. I do not know if any of these retain bijectivity
of the underlying cypher.
: Using ecliptic curves, I think I can come up with
: such a function (almost-one-to-one) that takes
: about 2^80 steps (and trivial memory) to invert.
: Can you do better?
I doubt it off the top of my head. I'm not saying that building a hash
function that approaches the ideal hash will be easy. My suspicion is
that it will not be amazingly difficult - and it may already have been
done - but I have no concrete basis for thinking this.
Howver, I want to be clear about what properties an ideal hash should
have. If everybody goes around thinking that a hash should be a one-way
PRF, nobody will ever build a hash that approaches the correct frequency
distribution at small message sizes - because they are not even trying.
If engineers realise that the PRF model is /not/ the ideal which a hash
should approach, they might at least try to build one which works properly
on small messages.
A random function as a hash isn't even useful for distilling entropy from
small messages, not much larger than the hash. In fact, given a
message the size of a hash with maximal entropy, a random function will
typically *destroy* almost a whole bit of that entropy. Even increasing
the size of the message by a few bits won't help. A hash that actually
*dilutes* - rather than condenses - the entropy in some messages it is
given is not behaving as a hash ought to behave.
:> If collision resistance is why you are using
:> a hash, you should ideally avoid those that
:> simulate pseudo random functions - *especially*
:> if you can't afford to use a large hash, and
:> the information you are hashing is not gigantic
:> compared to the size of the hash.
: Is one byte larger "gigantic compared to"? Let's
: say our digest is n bytes long, and our messages
: are n+1 bytes long. We want to know the expected
: number of tries to find a collision with a given
: message, using a random function versus using one
: optimized to avoid collisions.
[snip math]
: The ratio of time to break by brute-force is about
: 255/256.
I find no fault with this math. For a message n bits bigger than the
hash, the ratio will be roughly (2^n - 1) / 2^n.
: There is no point to optimizing against brute force search.
Huh? This doesn't seem to logically follow.
I would say that for messages which are much larger than the hash,
optimising against brute-force runs into diminishing returns as the size
of the message increases. That's not to say it's a waste of time.
:> My argument is /very/ simple. I have seen no coherent criticism of it.
: Now you have [...]
I'm not sure about that. It seems to me you're /almost/ agreeing with me.
I'm claiming that in theory, an ideal hash should have a particular
distribution.
Your argument so far seems to have been that:
A) existing functions are fairly close enough to this anyway;
B) nobody knows how to build a function with the distribution I
am claiming is desirable with the same security as existing hashes;
Now I don't exactly agree with your comments - but they don't seem to
contradict my statements about what an ideal hash should look like.
Only if it is /impossible/ to build a secure, one way pseudo-random
permutation does your "engineering difficulties" objection carry any real
weight.
I can't demonstrate the viability of the project today - but fully expect
that if it has not already been done, it will not prove an insurmountable
problem.
: - and how you might refute it is clear:
: Describe a hash that distributes preimages
: to digest more evenly than would a random
: function, and is comparable to a random function
: in resistance to the best attack against it that
: we can find.
I hope I've done that - *if* you allow the existence of a secure one-way
psuedo-random permutation of the size of the hash.
My construction is not very satisfying - but it's intended only as
an existence proof.
:> If nobody can distill the wisdom of the literature
:> references given into some sort of reason why my
:> argument is wrong - and in fact collision
:> resistance in the hash should be sacrificed for
:> some currently-unspecified higher goal - I will not
:> be impressed.
: Here is the wisdom: it makes no sense to optimize
: resistance to brute force attack when doing so
: enables much more damaging attacks.
Here is the bone of contention. What reason do you have for thinking that
a better distribution would inevitably allow more damaging attacks?
Without anyone presenting such an algorithm, I would have thought the
best you can do when describing attacks against it is to remain silent.
It is clear enough to me that preventing such attacks will be an
engineering problem, not an insurmountable theoretical obstacle.
Your only argument that they would be weak seems to have been of
the form that people don't currently know how to build them.
This is the argument from ignorance - an argument I don't find very
satisfying.
I don't doubt that the first such hashes may suffer from being cracked.
However, in the long term, it seems to me that they will ultimately prove
stronger against the full range of attacks than the traditional hashes,
since the latter are /demostrably/ sub-optimal in the manner I have
described.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Save the whales. Collect the whole set.
------------------------------
Date: Fri, 07 Jan 2000 09:14:23 +0200
From: Robert Sandilands <[EMAIL PROTECTED]>
Subject: Re: Blowfish
There is a file contained in the archive called boBlowfish.dll which is a plugin
for a program called BackOrrifice 2000. Some people consider this program to be
a useful administrative utility and some like the Anti virus industry consider
it to be a trojan or back door program. In that light McAfee made the correct
identification of the file.
There can be a moral debate whether McAfee is correct or not. I personally think
they are. If you don't want the protection that your av vendor offers you,
uninstall it. But I think they have good reasons for detecting that file and
it's associated programs as something bad.
Robert Sandilands, Senior Virus Analyst, Virus Protection Systems (Pty) Ltd.
South Africa.
"r.e.s." wrote:
> Since you might browse into this out of curiosity as I did,
> I think the following is worth mentioning.
>
> My AV software (McAfee) reports that the file
> boblowfish1-1.zip
> at
> ftp://ftp.replay.com/pub/replay/pub/crypto/LIBS/blowfish/
> contains a virus called "Orifice2K.plugin".
> (Today, 1/6/00, I notified the webmaster at the ftp site.)
>
> One of the links on Counterpane's page is to that site,
> so I'm now wondering if it could be something legitimate
> causing a false alarm. Can anyone enlighten me on this?
>
> --
> r.e.s.
> [EMAIL PROTECTED]
>
> "Kyle Morani" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> : "Ben Humphreys" <[EMAIL PROTECTED]> wrote:
> :
> : >Does anyone know where I can get some decent info regarding the Blowfish
> : >cipher? I've used the search engines but couldn't find anything exciting.
> :
> : Bruce Schneier seems to know a little about it. Try his site here:
> :
> : http://www.counterpane.com/blowfish.html
> :
> : --
> : "Kyle Morani" is actually [EMAIL PROTECTED] (4903 871256).
> : 0123 456789 <- Use this key to decode my email address and name.
> : Play Five by Five Poker at http://www.5X5poker.com.
------------------------------
From: "Tony T. Warnock" <[EMAIL PROTECTED]>
Subject: Re: Why the Cryptonomicon in Cryptonomicon?
Date: Fri, 07 Jan 2000 12:15:40 -0700
Reply-To: [EMAIL PROTECTED]
Cwm fjord glyphs vext quiz?
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: AES wise?
Reply-To: [EMAIL PROTECTED]
Date: Fri, 7 Jan 2000 19:13:05 GMT
Albert Yang <[EMAIL PROTECTED]> wrote:
: I can think of at least one clear reason; and that is the fact that if
: you have purely dependent S-boxes, then you might have a biased in the
: strength of the algorithm in terms of what key is used because the
: S-boxes produced might not efficiently or optimally diffuse in a
: non-linear fashion. If that then becomes true, then you're algorithm is
: not as strong all across the keyspace. That would then mean you "might"
: have weak keys. That then would be bad.
The argument goes that for "sufficiently large" s-boxes, affine boolean
functions are fantastically rare.
Having siad this, I see /very/ little *harm* in restricting the operations
used to bent functions. It's not as though testing them is terribly
time-consuming.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
A hangover is the wrath of grapes.
------------------------------
From: [EMAIL PROTECTED] (Dan Day)
Subject: Re: Anagram
Date: Fri, 07 Jan 2000 19:21:23 GMT
On Fri, 07 Jan 2000 04:11:58 GMT, Scott Fluhrer <[EMAIL PROTECTED]> wrote:
>He got it right.
So he did...
>Nope: since the random integer is from the range [i,100],
Crap, that's where I went astray -- I read it as [1,100].
Remind me to read messages using a larger font next time...
--
"How strangely will the Tools of a Tyrant pervert the
plain Meaning of Words!"
--Samuel Adams (1722-1803), letter to John Pitts, January 21, 1776
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Unsafe Advice in Cryptonomicon
Date: Fri, 07 Jan 2000 20:32:27 +0100
Guy Macon wrote:
>
> >And one more technical quibble from Cryptonomicon, about a computer
> >room with an electromagnet in the door frame, that wipes any media
> >being carried in or out: OK fine, if the field is strong enough to
> >wipe media at the distances involved (typically 1-1/2 feet or so) and
> >through the ferrous materials in the housings & etc. And OK fine, if
> >the people carrying the stuff out through this field do not notice
> >that every piece of ferrous metal that comes close to the frame gets
> >yanked out of their hands.
Perhaps one could so adapt the device as to carry out spin-tumorgraphy
for the personals walking in and out of their working place, so that
enormous health benefits result :)
M. K. Shen
> >
> >Oops. Heh heh. OK so the first thing they tried to carry out was the
> >one thing that really did need wiped.
> >
> >Clank! "What the-- oh sh*t!"
> >
> >Plot line saved. Ta daa.
>
> Nobody would design in a DC electromagnet when an AC electromagnet
> works so much better. You typical 60 Hz electromagnet makes ferrous
> materials wibrate quite noticably, but it may be that a higher
> frequency with some spectrum spreading may erase without being noticed.
>
> BTW, unless you are using Mu metal, it takes a LOT of ferrous material
> in the housing to do mucfh in the way of shielding.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: REDOC: First use: key dependent S-BOXES
Date: Fri, 07 Jan 2000 20:32:31 +0100
karl malbrain wrote:
>
> It seems to me that BLOWFISH, and other key-dependent S-BOX authors, should
> be giving credit to Michael Wood for using his invention. Karl M
I have a little problem with terminology. If one uses a key to
construct a monoalphabetic substitution in the classical way,
doesn't that also qualify as a 'key dependent S-Box'? Thanks.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (William Rowden)
Subject: Mispronounce words. (OT Re: How to pronounce "Vigenere"?)
Date: 7 Jan 2000 19:27:26 GMT
I'm joining the topic drift.
In article <[EMAIL PROTECTED]>,
Dan Day <[EMAIL PROTECTED]> wrote:
> Hell, I have that same problem with a lot of words in English (and
> English is my first language). That's the problem with doing a lot
> of reading in my younger years -- I was first introduced to many
> words via print, not speech.
>
> I still recall the day when I first discovered that the written
> "chaos" and the spoken "kay'os" were the same word...
:-)
I, too, was a reading child. "Omnipotent" is logically "omni-potent"
/om'nee poe'tent/, right? I also remember the quizzical look I
received when I first said "annihilation," complete with two short
i's. Why is that "h" there?
--
-William
SPAM filtered; damages claimed for UCE according to RCW19.86
PGP key: http://www.eskimo.com/~rowdenw/pgp/rowdenw.asc until 2000-08-01
Fingerprint: FB4B E2CD 25AF 95E5 ADBB DA28 379D 47DB 599E 0B1A
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Truly random bistream
Reply-To: [EMAIL PROTECTED]
Date: Fri, 7 Jan 2000 19:21:06 GMT
Guy Macon <[EMAIL PROTECTED]> wrote:
: In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Tim Tyler) wrote:
:>Dave Knapp <[EMAIL PROTECTED]> wrote:
:>: (Jim) wrote:
:>:>Nothing is _absolutely_ random; no clock is _absolutely_ accurate;
:>:>nothing can go from one level to another _absolutely_ instantaneously;
:>:>etc; etc...
:>
:>: And there's no such thing as _perfect_ conductivity...
:>
:>: And there is no fluid with zero viscosity...
:>
:>: Oops.
:>
:>You may /think/ these are errors - due to phenomena such as
:>superconductivity - but I don't believe it's true.
:>
:>There's no such thing as _perfect_ conductivity.
: (Conductivity being the inverse of resistance)
: Yes there is. In fact, there are negative resistances. [...]
I believe I recognised the existence of negative viscosity, and
/still/ claimed the absolute zero viscosity was an academic dream.
There's no such thing as perfect conductivity (or zero resistance).
Even if there /were/ (as usual) nobody would ever know if it had been
realised or not.
The universe just doesn't seem to like these absolutes people keep
claiming it can exhibit.
Electrons insist on materialising and dematerialising, protons decay right
in the middle of your experiment, things from the environment get in the
way, and perfection remains elusive.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Fat people eat accumulates.
------------------------------
From: "r.e.s." <[EMAIL PROTECTED]>
Subject: Re: frequency analysis with homophones
Date: Fri, 7 Jan 2000 11:43:08 -0800
"Mok-Kong Shen" <[EMAIL PROTECTED]> wrote ...
: r.e.s. wrote:
: > I appreciate your following comments, but in the present case
: > it's not a question of how best to design a substitution table.
: > Rather, I'm trying to get a handle on why in certain cases the
: > frequency subtotals (of a cipher of unknown design), divided
: > by the total number of ciphertext letters, agree so well with
: > the ranked p(i), these coresponding to the common frequencies
: > found for English letters (I=26). The question is a statistical one
: > as to whether the agreement is merely coincidental or is actually
: > due to the substitution table being as simple as hypothesized.
:
: If I understand correctly, you assume that a set of ciphertext
: characters are homophones of A, another set are homophones of B, etc.
: and you sum the frequencies of these groups and obtain a distribution
: that fairly agrees with a certain distribution you deem to be
: representative of the plaintext and want to know whether that
: assumption is correct.
No. There is no assumption that particular symbols are the homophones
of any particular plaintext letter -- some just happen to get grouped
together when their frequencies are ranked. What is assumed is that
there are J homophones -- whatever they are -- per plaintext letter.
: I don't think you can do that. For there
: wouldn't be much practically detectable difference if, for example,
: you exchange one of the assumed homophones of A with one of E. After
: all, the particular piece of plaintext involved may have a frequency
: distribution fairly deviated from the representative distribution
: so that much reliance on any 'exact' computation is illusory.
The original statistics question I asked seeks to make your statement
precise. By obtaining the statistical properties of the frequency
subtotals, which is what I was asking for, one has a quantitative basis
for reasoning about how they might or might not have been generated.
Other posters have pointed out other (presumably better) ways to go about
that, but the statistical problem I posed is of interest in its own
right, imho.
: Note that, while the normal use of homopnone substitutions attempts to
: achieve a uniform distribution, one can also use homophones to
: deceive the analyst. Just for illustration purpose, suppose you have a
: plaintext alphabet consisting of the digits 0-9, and you have a uniform
: distribution of these (for instance the digits are fairly random),
: you could attempt to map that to A-Z (or a permutation of these) in
: such a way that the distribution more or less parallels to one of
: natural languages, thus disguising the digit origin of your plaintext.
: From this viewpoint, one once again sees that your question above
: cannot be answered in the affirmative with 'any' certainty.
It's good that you put 'any' in quotes, because that's a main issue
-- no one is asking for certainty. The question is one of statistics,
implicitly recognizing the probabilistic nature of the problem. It
doesn't ask for certainty, but for clues, in the sense of what is
or is not to be expected in ciphertext under some specific conditions.
--
r.e.s.
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Jim)
Subject: Re: Interview with an ECHELON Spy
Date: Fri, 07 Jan 2000 19:54:42 GMT
Reply-To: [EMAIL PROTECTED]
On 7 Jan 2000 15:46:47 -0000, "http://www.hyperreal.art.pl/cypher/remailer/"
<[EMAIL PROTECTED]> wrote:
>No need to be too optimistic though, as there are opposing trends within
>
>government on the subject of unreguleated unbreakable encryption.
What's the situation in Denmark at the moment regarding private use
of strong crypto?
--
Jim,
nordland at lineone.net
amadeus at netcomuk.co.uk
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Identifier anonymization
Date: 7 Jan 2000 20:03:51 GMT
Al Wang <[EMAIL PROTECTED]> wrote:
>I've been thinking more about my problem and I had a thought: would I
>be able to use some public-key algorithm as an anonymizer by promptly
>destroying (or securing) the private key? This would allow me to
>"anonymize" the identifier by encrypting it with the public key, but
>would provide no way of decrypting it.
>
>Would anyone be able to recommend an algorithm for this purpose? It
>seems that this model would have to defend well against both
>known-plaintext and chosen-plaintext attacks. Does this mean RSA
>would not be such a good solution?
That suggestion is similar to hashing, but it's like chartering a 747
to get groceries at the corner store. The amount of computation for
the public key encryption is comparatively large, and if you use RSA,
the output will be as large as the RSA modulus, typically 1024 bits.
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: REDOC: First use: key dependent S-BOXES
Date: 7 Jan 2000 12:06:26 -0800
In article <vuqd4.2$[EMAIL PROTECTED]>,
karl malbrain <[EMAIL PROTECTED]> wrote:
> The basic method for REDOC III was to [...]
> It seems to me that BLOWFISH, and other key-dependent S-BOX authors, should
> be giving credit to Michael Wood for using his invention. Karl M
As far as I can tell, REDOC III seems to post-date Khufu, which also uses
key-dependent S-boxes and which Bruce Schneier prominently credits in his
original paper on Blowfish. Am I wrong?
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Identifier anonymization
Date: 7 Jan 2000 20:09:07 GMT
Al Wang <[EMAIL PROTECTED]> wrote:
>I've been thinking more about my problem and I had a thought: would I
>be able to use some public-key algorithm as an anonymizer by promptly
>destroying (or securing) the private key? This would allow me to
>"anonymize" the identifier by encrypting it with the public key, but
>would provide no way of decrypting it.
You really do need to keep a persistent secret key around for
decrypting the data, because the space of messages you're encrypting
is so small (9 digit numbers). Using a salted hash makes it harder to
build a precomputed database, but it's still not good enough. The
attacker can decrypt any hashed key by simply trying all 10**9
possible identifiers and finding the one that hashes to the given
value. You need secret input to the hash function and I don't see
any way around that. If you're concerned about the key management
hassles this will cause, feel free to describe your application
environment a little more and I may be able to make further suggestions.
------------------------------
** 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
******************************
