Cryptography-Digest Digest #989, Volume #8 Thu, 28 Jan 99 15:13:02 EST
Contents:
256-bit block cipher ([EMAIL PROTECTED])
Re: Random numbers from a sound card? ([EMAIL PROTECTED])
Any known probs with 2PKDP (KryptoKnight)? (Christian Muszynski)
Re: hardRandNumbGen (Patrick Juola)
Re: hardRandNumbGen (Patrick Juola)
(no subject) (barak)
Re: Random numbers from a sound card? (Medical Electronics Lab)
Re: Encoding for telephone over Internet (fungus)
Blowfish: Affecting strength of algorithm? ("Uta Loeckx")
Re: Who will win in AES contest ?? (David Hamilton)
Re: Foiling 56-bit export limitations: example with 70-bit DES ([EMAIL PROTECTED])
Merchants needed for software beta testing (Kent Briggs)
Re: My comments on Intel's Processor ID Number (Barry Margolius, NYC)
Re: RNG Product Feature Poll (Dan S. Camper)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: 256-bit block cipher
Date: Thu, 28 Jan 1999 17:23:32 GMT
256-bit block cipher
The size of the block is 256 bits or 32 bytes.
Inserted key is transformed to 256 bytes( effective key)
using 8-bit Alex chained encryption.
There are two interpretations of the key. One of them
is mentioned above in 8-bit chained encryption a sequence
of automorphisms of a group. The second is the sequence
of transpositions of bits in block. Each byte of the key
represents a simple transposition of bits as follows:
index of byte is the index of the first bit in block and the
context of the byte is the index of the second bit in block.
During encryption of the block the key is scanned from the
beginning to the end and during decryption reverse.
Encryption follows in two steps:
1. A block is encrypted using 8-bit Alex chained algorithm.
This approach gives suitable dispersion of 1 and 0 bits in
the block.
2. A transposition of all 256 bits in block is made using
256 byte key.
This algorithm is implemented and has performance apr.127 Kb/sec.
The full Delphi 4 source code, freeware executable, updated
algorithm description are available for download at
www.online.de/home/aernst
Please follow the link 'Alex8x256.zip'
Regards
Alex
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Random numbers from a sound card?
Date: Thu, 28 Jan 1999 18:10:41 GMT
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> >
>
> > Note that even using a highly structured signal (e.g., digitized
> > video program including your local receiver noise) you could generate
> > good bits, but you'd have to distill bushels of them.
>
> I find your experience interesting. (In another thread I suggested
> obtaining good bit sequences from such materials as natural
> language texts.)
>
> M. K. Shen
>
There is a big difference. Eve does not know the local, instantaneious
electromagnetic conditions around my receiver, nor does she know what
my local electronics are doing.
The point is that measuring something physical is nothing like
playing with text streams, unless you you get them via UDP and
have a real bad link :-)
============
"Properly done science is a sort of masochistic game where one beats
one's head against a wall until it falls down, and then goes in search
of another wall." --Steven Vogel
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: Christian Muszynski <[EMAIL PROTECTED]>
Subject: Any known probs with 2PKDP (KryptoKnight)?
Date: Thu, 28 Jan 1999 19:30:21 +0100
Hi everybody,
I have to implement an authentication and encryption system for a
wireless
data communication environment. This is an environment which has some
special characteristics as:
- small bandwith
- higher reaction times
- high transmission costs
- high error rate
- clients with reduced ressources concerning processing power and memory
What I need is a system for mutual authentication between client and one
communication server, data encryption and MAC of data packets.
I can't integrate a standard solution as IPsec because I don't have an
IP connection between communication server and the mobile client,
but a specific point to point protocol.
Two achieve these goals for this special environment I need a slim
protocol and an effective algorithm. At the moment I am thinking of
the Two Party Key Distribution Protocol (2PKDP) (also integrated in
KryptoKnight family). As algorithm I plan to take Blowfish for the
encryption part, MAC-calculating and perhaps part of the
number generator(with some realtime events as millisecondtimer, consumer
reacktions, Process data as intialisation and key).
I think Blowfish is ok for this MAC use, because the MAC is just
for a maximum of one minute valid.
I think the RSA public key procedure is no help because
- secure key sizes take a lot of calculation time on small 20 MHz
processors
- encrypted data increases message size
- you need two additional certification varification steps
in your protocol
- implementation needs more memory space
- secure implementations are hard to carry out....
Now my questions:
Are there any successful attacks or security consideration against
2PKDP known?
Are there any better authentication and key exchange protocols which
are slim in -necessary protocol steps
-message size ?
Which other risks see the experienced guys in this described
configuration?
(I already know that it is really difficult to
implement a secure system and that there a tons of pitfalls)
Are there any realistic attacks against blowfish?
I appreciate any comments! Please add some pointers ot web sites
adressing this situation...
Best regards
Christian
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: hardRandNumbGen
Date: 28 Jan 1999 11:25:33 -0500
In article <[EMAIL PROTECTED]>,
R. Knauer <[EMAIL PROTECTED]> wrote:
>On 27 Jan 1999 14:27:50 -0500, [EMAIL PROTECTED] (Patrick Juola)
>wrote:
>
>>English text contains just over one bit of randomness per character.
>>If you need a thousand bits of randomness, get a thousand characters
>>of English text from a secure source, distill them appropriately with
>>a trusted hashing function. Better yet, get 1500 characters to allow
>>for sloppy engineering -- you'd never run a wire at its rated wattage,
>>would you? Take the resulting 1000 bit string, XOR it with the plaintext,
>>and voila. A scientifically sound method of securing 1000 bit secrets.
>
>You once said that such a system was vulnerable to a Bayesian attack.
>Have you changed your mind?
No. The key point here is that the key is as large as -- larger than,
in fact -- the plaintext. Such a system *would* be vulnerable if you
were using it to secure secrets larger than 1000 bits. But as long
as the plaintext is finite *AND BOUNDED*, if you can get key material
to exceed that bound, you can get perfect secrecy.
But few of us have bounded secrets.
-kitten
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: hardRandNumbGen
Date: 28 Jan 1999 11:28:41 -0500
In article <[EMAIL PROTECTED]>,
R. Knauer <[EMAIL PROTECTED]> wrote:
>On 27 Jan 1999 15:06:39 -0500, [EMAIL PROTECTED] (Patrick Juola)
>wrote:
>
>>Um... the NSA does *NOT* have infinite resources. Far from it.
>>The GNP of the United States is only measured in the trillions,
>>so any hardware costing more than a quadrillion dollars or so is
>>probably out of reach.
>
>Not when the federal reserve can make all the fiat money it wants.
Producing that much fiat money would produce such inflation
as to drive the buying power to zero. It doesn't matter how many
dollars you printed, you'd still hit the limit of what a large
pile of dollars valued at a ten-billions of an Italian lira would
be worth.
Or to put it another way, if you create a quadrillion dollars to enable
yourself to buy that equipment, the cost just went up to a sextillion
dollars. 8-)
-kitten
------------------------------
From: barak <[EMAIL PROTECTED]>
Subject: (no subject)
Date: Thu, 28 Jan 1999 20:55:07 +0200
nhjkinhjki
------------------------------
From: Medical Electronics Lab <[EMAIL PROTECTED]>
Subject: Re: Random numbers from a sound card?
Date: Thu, 28 Jan 1999 12:47:39 -0600
R. Knauer wrote:
>
> Then you're a masochist. :-)
:-) I think you're right about that!
> Once you catch on to all this, you will see why.
It's pretty clear we have different opinions. The best I can
hope for is more descriptions so I can find out what the core
assumption is that we disagree on. Neither one of us will change
:-)
> Those things don't measure the crypto-grade randomness of finite
> numbers at all. They try to make inferences about the generator from
> finite samples, which is useless for purposes of crypto. They will
> pass the outputs of PRNGs that can be cracked.
So you need an infinite sequence of bits to prove that something
is crypto-grade random, yes?
> Just what makes a finite number produced by a TRNG "look random"?
Is a 10 megabyte block of random bits a single number? Or is it
80 million individual numbers? For the latter case, it looks
random if it can pass all the tests for randomness that
mathematicians have dreamed up. In the former case, if it isn't
printable ascii, then it will probably look random no matter
what.
> Why do you thing that characteristics that apply only to infinite
> numbers can also apply to finite ones with equal certitude?
What characteristics are you talking about? Integrals over a
finite range and binomial or poisson distributions are all based
on finite samples. All the DIEHARD tests are based on finite
samples. I am assuming that Marsaglia knows what he's doing,
but maybe you can correct him?
> What does "vanishingly small" mean to you?
Less than I can measure.
> That measure is worthless for crypto-grade random numbers.
Yes, well, expand on "crypto-grade" a bit.
> > Isn't that good enough?
>
> Nope. Not even close.
:-) See, I told you we disagree. Let's keep it that way,
makes for a nice long discussion.
Patience, persistence, truth,
Dr. mike
------------------------------
From: fungus <[EMAIL PROTECTED]>
Subject: Re: Encoding for telephone over Internet
Date: Thu, 28 Jan 1999 17:27:51 +0100
"Scott A. Berg" wrote:
>
> There are many packages for telephone, videophone, FAX, drawing board, etc.
> over the internet. Since all of them resolve at some point to a stream of
> numbers, they would seem to lend themselves well to REALLY secure
> encryption, e.g. OTP.
>
OTP wouldn't be practical for this (in fact, OTP is impractical for
just about any real-life crypto system).
eg. How would you send the OTP to the other person?
> Do any commercially available packages for this kind of communication
> actually provide such security?
They won't use OTP, but that doesn't mean they aren't secure. They
could be using any number of good crypto algorithms to encode the
data.
--
<\___/>
/ O O \
\_____/ FTB.
------------------------------
From: "Uta Loeckx" <[EMAIL PROTECTED]>
Subject: Blowfish: Affecting strength of algorithm?
Date: Thu, 28 Jan 1999 19:41:05 +0100
(Please do not reply to the apparent sender of the question, please DO
reply to the address below or to sci.crypt only)
This being the first time I have to implement an encryption algorithm, I
do not feel very confident about the things i did. Who can give me hints
about whether my implementation of Blowfish counteracts it's normal
strength or not?
1. Goal description:
==============
I have to secure some data of the Geological Survey of Hessen, Germany.
They have a database with some confidential data which one finds in
several table columns. Every column is encrypted with a different key,
but a table can contain several thousand entries. DBAs which are not
supposed to get the confidential information can read all ciphertext,
though (no way around it in ORACLE8). Is this a serious potential for
ciphertext attacks?
Algorithm must be public domain, easy to implement in C and Java, and
tested for some years (without being broken, of course).
Implementation details:
=================
1. I decided for Blowfish. Input data is aligned to the next 8 byte
border using 00H (I am not sure if this is correct, Markus Hahn's
implementation uses 20H=whitespaces, but I couldn't find anything about
padding in Blowfish paper). One more 8-byte-block is appended containing
the original data length in bytes as a 64bit-integer.
2. The table columns may contain repetitive data like names or dates or
wages. Since ECB would produce the same ciphertext for same plaintexts,
I decided to use CipherBlockChaining. Now I'm not sure if the way the
initialization vector is produced has influence on Blowfish strength. I
do it the following way in Java:
A Random object is created using the computer clock. Then every time
data is encrypted, the Random object produces a 64bit value which should
be equally distributed (see Java1.2APIdocumentation).
This value gets XORed with the 18 PBoxes of Blowfish's expanded key,
always putting two of these boxes together to produce 64bits. I actually
thought, that this might improve security because no one knows the PBox
values if he/she doesn't know the key, but one might guess the system
time. This is my main question: is this random enough for encryption???
Java code goes like this:
___________________________________________________
import java.util.Random;
public class Blowfish { //partly taken from Markus Hahn's impl.
//...
final static int PBOX_ENTRIES = 18;
Random random = new Random(System.currentTimeMillis());
//...
public Blowfish(byte[] bfkey) {
//...
pboxes = new int[PBOX_ENTRIES];
//...
}
//...
protected long getRandomNumber() {
long temp = random.nextLong();
for (int counter = 0; counter < pboxes.length - 1; counter += 2)
temp ^= ((((long) pboxes[counter]) << 32) | (long)
pboxes[counter+1]);
return temp;
}
//...
}
________________________________________________________
Now I hope that it is impossible for anyone to find out how often a
repeated entry exists in a table. The only remaining weakness, as far as
I can see, is that you get information from the length of the
ciphertext if the plaintexts align to different 8byte-borders (like a
lot of people gain 3,000$ but one person 10,000,000$). But I'm not a
cryptanalyst...
Thank you all for listening
Any hints on better ways of implementing this thing are appreciated
Andreas
======================================================================
Andreas Jaeger
Institut f�r Geoinformatik, Universit�t M�nster
Robert-Koch-Stra�e 26/28
D-48149 M�nster
Tel.: (0251) 83 - 3 00 11
Fax: (0251) 83 - 3 97 63
mailto:[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (David Hamilton)
Subject: Re: Who will win in AES contest ??
Date: Thu, 28 Jan 1999 19:19:04 GMT
=====BEGIN PGP SIGNED MESSAGE=====
[EMAIL PROTECTED] wrote:
(snip)
> If the contest was to actually be of real help then security
>would be of the very highest concern. But you miss the whole
>point of the contest. The Clipper chip failed so the NSA needs
>a way to make people use a common encryption method that they
>can break and yet appear to be not involved in its selection.
Earlier in this thread, you said:
> The winner will be one of the entries that the NSA has entered
I asked you 'Which of the entries were entered by the NSA?' but you decided
not to answer the question. Do you want to answer that question now?
Do you want to say which of the entries the USA NSA can break? Have you any
evidence (or is this just your opinion)?
(snip)
> These are just
>my thoughts but if you want better securtiy and don't care about
>time try looking at scott19u.
Don't use David A. Scott's software. There is evidence that it is almost
certainly weaker than, eg, PGP. See message-ID:
<[EMAIL PROTECTED]> in the thread 'Re: Encryption Basics'
posted in sci.crypt on 19th December for details.
David Hamilton. Only I give the right to read what I write and PGP allows me
to make that choice. Use PGP now.
I have revoked 2048 bit RSA key ID 0x40F703B9. Please do not use. Do use:-
2048bit rsa ID=0xFA412179 Fp=08DE A9CB D8D8 B282 FA14 58F6 69CE D32D
4096bit dh ID=0xA07AEA5E Fp=28BA 9E4C CA47 09C3 7B8A CE14 36F3 3560 A07A EA5E
Both keys dated 1998/04/08 with sole UserID=<[EMAIL PROTECTED]>
=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 5.5.3i for non-commercial use <http://www.pgpi.com>
Comment: Signed with RSA 2048 bit key
iQEVAwUBNrCxr8o1RmX6QSF5AQEoTwgAm8n2bi7x/FYdsXnsPYdG3U7AyfypXvDM
0cfuLwf9vzWTGjaPCpH1DiOVdvj0tBZysujdmY8bVf6ZFoxuB2xmifU/14SW+3dU
hr26gsaQzM0nU8lVRMpwbVcK92+Z7hrTiIE1A0JJuJDtHxSQZEAfcyNEAw8CUS8E
OZxBps90iwikCO35v0IAYqWhoBCrpJRNz3vHbCjlxv2vK7C+a51EbU3friSortv+
6LTqDcYHncM7wwceu3+tPYI9EI+wYWWiiuBGU0xtWt9eDzPdAFrbLfZ1+2BOltlK
GcsPzJ8wPmimIOF1s0/a+XtGsfLDPBDG1wBAJkLUdzRZSuV/T48naQ==
=GnWW
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Foiling 56-bit export limitations: example with 70-bit DES
Date: Thu, 28 Jan 1999 17:45:13 GMT
In article <78pnga$3om$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> In article <[EMAIL PROTECTED]>,
> "Peter K. Boucher" <[EMAIL PROTECTED]> wrote:
[snip]
> > A well-known stream-cipher with variable-size keys might work as well
> > (or better, for flexibility's sake) for your notion of M-DES.
>
> No, it won't ... as you say below ;-) Besides, I have the impression you did
> not have time yet to actually read the paper, so you ignored the other
> security features --- such as M key collision.
I did read your paper, and I think that if you run the stream cipher on the
DES ciphertext, it is as secure as your method, as long as the stream cipher
behaves well with short keys.
> > For
> > example, generate M bits randomly, use these as, hypothetically
> > speaking, an RC4 key. You pre-encrypt the entire message with the
> > stream cipher, then encrypt with DES. Your recipient (and any
> > attackers) must brute-force the M-bit stream-cipher key.
>
> This is well-known, with well-known problems. For example, the one you cite
> below. Further, the probability of repeating the M key for the same text
> (message headers, for example) is not zero and increases with time, for all
> messages -- however, pratically null in the M-DES scheme because the 64-bit
> ciphertext itself is random and that is what is XOR-ed with the M bit key ...
> ;-)
Grabbing one of 2^M published 64-bit blocks and XORing it with the DES
ciphertext is not more random than post-encrypting the ciphertext with a
well-behaved M-bit sttream-cipher algorithm, and may be less secure than
post-encrypting with a good M-bit block cipher. All three approaches,
however, have the weakness that you must include a known plaintext block (or
send only English text, or printable data), if you want to be sure that Alice
can successfully brute-force Bob's post-encryption step.
> >
> > One problem with this approach is that you must include known-plaintext
> > in your protocol, if your recipient wants to be sure he has correctly
> > guessed the M-bit "whitener."
>
> Which problem is just absent in the M-DES scheme, no? Perhaps, on purpose '-)
I don't understand how you can say it's not a problem with your scheme.
> And, which considerably weakens your suggestion -- perhaps too much to be
> useful and that is why this scheme is not used, though already discussed in
> the literature. Look for "cascadng ciphers".
Choosing one of 2^M 64-bit blocks and XORing it with each 64-bit block of
message is nothing more than a really weak M-bit stream cipher. I don't
understand why using a better stream cipher wouldn't be better.
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: Kent Briggs <[EMAIL PROTECTED]>
Subject: Merchants needed for software beta testing
Date: Thu, 28 Jan 1999 19:49:49 GMT
I'm looking for volunteers to help beta test a new encryption program
that will soon be released as shareware. It's targeted towards small
online merchants and software developers who do not have SSL-enabled web
sites but still need a secure method of collecting credit card orders.
This program allows you to build a stand alone order form program in a
single Win 95/98/NT EXE file and then distribute it royalty free. The
customer runs the program, fills in the order info and the result is
automatically encrypted with the built-in public key encryption option
and e-mailed back to the merchant directly.
If you are interested in helping with the beta test, please send a
private reply back to me with your name, e-mail, and basic info on your
PC (CPU type, RAM installed, Windows version, etc) and I will provide
you with a download link. Those that provide feedback will get a free
copy of the final registered version.
--
Kent Briggs, [EMAIL PROTECTED]
Briggs Softworks, http://www.briggsoft.com
------------------------------
From: [EMAIL PROTECTED] (Barry Margolius, NYC)
Subject: Re: My comments on Intel's Processor ID Number
Date: Thu, 28 Jan 1999 19:27:25 GMT
To make it cryptographically useful, and avoid replay attacks, would mean
that the signing would have to happen each time the S/N was queried, while
appending some other data to the cleartext S/N. I could see hacker
newsgroups filling up with signed S/N's to replay/substitute for your own.
-barry
[EMAIL PROTECTED] (John Savard) wrote:
>[EMAIL PROTECTED] (Bruce Schneier) wrote, in part:
>>On Wed, 27 Jan 1999 16:16:59 GMT, [EMAIL PROTECTED]
>>(John Savard) wrote:
>
>>>However, according to claims I've read about the Intel processor ID
>>>number, it will include a digital signature by Intel. So the validity
>>>of a processor ID number can be checked.
>
>>I have heard the exact opposite.
>
>You certainly could be right.
>
>At the Intel site, there is very little information about the Pentium
>III, only that its brand name is now official.
>
>News articles quoted in various Usenet groups have given some details.
>Apparently, its main feature is the long-awaited MMX 2 instruction
>set, with the ability to handle vectors with multiple floating point
>numbers in them. Also higher clock speeds.
>
>Out here, in the cryptography-related groups, the processor ID and the
>hardware random-number capability were mentioned. I couldn't find
>reference to either feature among Intel press releases.
>
>John Savard
>http://www.freenet.edmonton.ab.ca/~jsavard/index.html
--
Barry F Margolius, New York City
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Dan S. Camper)
Subject: Re: RNG Product Feature Poll
Date: Thu, 28 Jan 1999 13:52:40 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Terry Ritter) wrote:
>On Thu, 28 Jan 1999 11:09:22 -0600, in
><[EMAIL PROTECTED]>, in sci.crypt
>[EMAIL PROTECTED] (Dan S. Camper) wrote:
>
>>All:
>>
>>My company is developing a hardware random number generator, based on
>>radioactive decay, which will be a component of a larger turnkey (server)
>>product. The device is an external peripheral with a serial connection to
>>the CPU and back-end serial connections that allow you daisy-chain these
>>RNG devices to provide higher throughput.
>>
>>The device currently works. It's output is a measly 3K per second, but
>>the raw data passes Diehard and every other test we've thrown at it. Of
>>course, that doesn't prove that the output is random, but at least we know
>>it passes those tests. ;)
>
>My guess would be that the device itself produces independent unbiased
>bits which are then simply collected into 32-bit values for Diehard
>testing. Sensing randomness as single-bit results is probably why the
>data rate is low. That is not necessarily bad.
>
>But if any problems do exist, they will be bit-level problems. And it
>would seem to be difficult to pick up bit-level problems when we
>collect bits into 32-bit values with numeric interpretations.
To my knowledge, all of the tests we've run to date have dealt with the
output grouped into bytes, up to 8-byte chunks (I think). Is there a
utility or method for detecting bit-level problems?
>>We are considering the addition of a hash algorithm to the setup. There
>>have been messages posted to this newsgroup in the past regarding hashing
>>hardware RNG outputs, but I haven't been able to discern a consensus on
>>whether or not an additional hash is a Good Thing.
>
>A hash takes arbitrarily large input to a fixed-size output. This can
>buy several things:
>
>1) It can collect "entropy" over time.
>2) With sufficient "entropy," it can produce an even or flat
>distribution.
>
>But bit-level RNG devices may not need these things if the bit results
>are almost unbiased. Bit-level correlations are to some extent
>inherently confused by collecting bits into larger values. And if we
>use enough bits we can afford some amout of imperfection.
[snip]
>I suppose that since the application is "cryptography," everyone
>assumes that any hash, if used, must be a "cryptographic hash." This
>is false, although it can be dangerous for a producer to instruct
>their customers on reality.
>
>The main technical advantage of a cryptographic hash is that it breaks
>up the pattern of transformations between input and output values.
>This means that it should be very difficult to find two different
>inputs which hash to the same result. But this is not the property
>which is used for collecting entropy and flattening the distribution.
>
>In contrast, a linear CRC hash is fast and simple, and has a complete
>mathematical basis for doing what we want. Fast CRC implementations
>are table-driven and "fast" because they operate on multiple bits at
>once, typically bytes. Any good polynomial will do.
>
>The argument is sometimes made that a cryptographic hash will protect
>weakness in the original sequence. But a hash is not a cipher: Any
>hash has more input than output, so the transformation is not
>reversible for any hash, if we have enough input.
>
>It is always possible to actually encrypt the random values if we
>can't stand even the thought of weakness.
>
>There is also a systems-level tradeoff between using "perfect" random
>values of exactly the size we need, versus using larger random values
>of somewhat less quality.
You're right, the intent of the hash function would be to confuse the
output from the device, not necessarily encrypt it. Personally, I see no
problem with substituting a CRC for MD5 (for instance). But this may wind
up being a marketing decision, all other things being equal.
DSC
____________________________________________________________________
Dan S. Camper [EMAIL PROTECTED]
Borrowed Time, Inc.
------------------------------
** 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
******************************
