Cryptography-Digest Digest #338, Volume #12 Wed, 2 Aug 00 13:13:01 EDT
Contents:
Re: Blowfish Implementation (Runu Knips)
Re: Secure key-based steganography (Mark Wooding)
Re: Small hash checksum (Mark Wooding)
Why is it necessary...? ("Sergio Arrojo")
Please somebody help me out!!!! ("Sergio Arrojo")
Security ("Sergio Arrojo")
Re: RC5 / 4 (tomstd)
Re: Just Curious. Are girls/women interested ("Dr. Yongge Wang")
Re: Blowfish Implementation (Mark Wooding)
Re: Secure key-based steganography ("Toby Sharp")
Re: Secure key-based steganography ("Toby Sharp")
Re: Small hash checksum (Terry Ritter)
Re: Why is it necessary...? (Doug Kuhlman)
Re: Small block ciphers (Terry Ritter)
Re: Small block ciphers (David A. Wagner)
Re: Skipjack (David A. Wagner)
Vote Yes/No. (None)
Re: IV for arfour (David A. Wagner)
Re: IV for arfour (David A. Wagner)
Re: Small hash checksum (Mark Wooding)
Re: IV for arfour (David A. Wagner)
Re: Small block ciphers (David A. Wagner)
Re: Psuedo-random number generation (James Felling)
Re: Small hash checksum (stanislav shalunov)
----------------------------------------------------------------------------
Date: Wed, 02 Aug 2000 16:27:53 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: Blowfish Implementation
Mark Wooding wrote:
> * There's no guarantee that there's any type which is exactly 8 bits
> long. `unsigned char' might be 9 bits, or 16 bits, or...
Interesting. In fact, I believe most ciphers would really be hard
to implement on machines which aren't 8 bit. You always have to
mask out the superflous bits in each byte all the time. And
without an 9 or 10 bit per byte machine at hand, its very hard to
check if the code is actually working correctly on this odd kind
of machines.
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Secure key-based steganography
Date: 2 Aug 2000 14:36:46 GMT
[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Alice should use a picture that alot of people would be interested in
> downloading (oh... <scratching head>... say maybe a porn picture) and
> hide her message in it ("original" porn pictures are easy to make
This is slightly asymmetric. All Alice needs to do to generate such
material is find a photographer. Bob has more of a problem here.
(Piccies of blokes don't generate as much demand.)
There's also a risk of Bob getting carried away and forgetting that
there's actually a message hidden in the piccies.
And finally, there's scope here for a simultaneous exchange of secrets
protocol...
> There are steganographic programs out there to hide information in
> various picture and sound files as well as in executables. Huge
> delivery potential.
>
> What do you guys think?
I've had the idea for some time that alt.binaries.pictures.erotica.* is
really some huge covert broadcast medium for Them to discuss whatever it
is that They discuss. I've tried quite hard to imagine other reasons
why people would be interested in some of the material in those
groups. ;-)
Anyone for alt.binaries.pictures.erotica.cryptographers.covert-channel?
-- [mdw]
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Small hash checksum
Date: 2 Aug 2000 14:39:00 GMT
Ilya O. Levin <[EMAIL PROTECTED]> wrote:
> > Just use a 32 bit CRC they have the requirements you need.
> > Table driven implementations are very fast.
>
> Definitely, it'll faster then take a piece of a big hash.
Not necessarily. I remember testing CRC32 and MD4 on large files, and
MD4 won rather convincingly. Both implementations were written in ARM
assembler, though I'd not be surprised if similar results held for other
architectures.
-- [mdw]
------------------------------
From: "Sergio Arrojo" <[EMAIL PROTECTED]>
Subject: Why is it necessary...?
Date: Wed, 2 Aug 2000 16:38:13 +0200
Reply-To: "Sergio Arrojo" <[EMAIL PROTECTED]>
Why is it necessary to know the number of points of a curve in order to find
a point with order n (n large prime)?, once we know the order of the curve,
how do we manage to find such a point?
Thanks
Sergio Arrojo
------------------------------
From: "Sergio Arrojo" <[EMAIL PROTECTED]>
Subject: Please somebody help me out!!!!
Date: Wed, 2 Aug 2000 16:43:05 +0200
Reply-To: "Sergio Arrojo" <[EMAIL PROTECTED]>
I need to implement a method to generate keys and parameters to aplly ECDSA.
Am I all set if I am able to find a program to generate a curve and a point
n (large prime) order together with a SHA-1 algorithm?
Where could I get such Software?
Thank you
Sergio Arrojo
------------------------------
From: "Sergio Arrojo" <[EMAIL PROTECTED]>
Subject: Security
Date: Wed, 2 Aug 2000 16:56:13 +0200
Reply-To: "Sergio Arrojo" <[EMAIL PROTECTED]>
When using a curve over a field 2^n with n prime (n big enough). By knowing
that the curve is not Anomalous and that the MOV condition is satisfied can
we assure that it is secure. If not what else should we do to be 100% sure?
Thanks
Sergio Arrojo
------------------------------
Subject: Re: RC5 / 4
From: tomstd <[EMAIL PROTECTED]>
Date: Wed, 02 Aug 2000 08:03:36 -0700
[EMAIL PROTECTED] (rlogin) wrote:
>This address is wrong, can you please give me the correct
address ?
Try
ftp://ftp.ox.ac.uk/pub/crypto/misc/
Note: RC5 is the holy grail of RSA so unless you want to start a
war with them I would avoid it.
Tom
===========================================================
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
From: "Dr. Yongge Wang" <[EMAIL PROTECTED]>
Subject: Re: Just Curious. Are girls/women interested
Date: 2 Aug 2000 15:14:45 GMT
[EMAIL PROTECTED] wrote:
: in cryptography? Is there any female poster on this board? Any
: prestigious woman in the field at all? Thank you for your response.
: --Sisi
All of you guys forgot Joan Feigenbaum? The
Editor-in-Chief of Journal of Cryptology:-)
: Sent via Deja.com http://www.deja.com/
: Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Blowfish Implementation
Date: 2 Aug 2000 15:19:13 GMT
Runu Knips <[EMAIL PROTECTED]> wrote:
> Interesting. In fact, I believe most ciphers would really be hard to
> implement on machines which aren't 8 bit. You always have to mask out
> the superflous bits in each byte all the time.
I disagree. I don't think it's very hard at all. I've tried to
implement all of the ciphers in Catacomb so that they'll work in such
funny environments. Indeed, if anyone discovers that this isn't the
case, that's a bug and I'll fix it. (Subject, that is, to the
assumption my code makes, that I/O is basically something done on 8-bit
octets, and you store one in each unsigned char.)
> And without an 9 or 10 bit per byte machine at hand, its very hard to
> check if the code is actually working correctly on this odd kind of
> machines.
This is true. It's hard enough coping with compiler bugs on platforms I
don't have access to (e.g., Windows).
-- [mdw]
------------------------------
From: "Toby Sharp" <[EMAIL PROTECTED]>
Subject: Re: Secure key-based steganography
Date: Wed, 2 Aug 2000 16:20:31 +0100
Sorry, I meant freeware, not public domain.
Mark Wooding <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Toby Sharp <[EMAIL PROTECTED]> wrote:
>
> > This scheme is implemented in the software Hide v2 for Win32
> > platforms, which is currently in the public domain. (Copyright Toby
> > Sharp, 1999.)
>
> Which is it: copyright, or public domain?
>
> -- [mdw]
------------------------------
From: "Toby Sharp" <[EMAIL PROTECTED]>
Subject: Re: Secure key-based steganography
Date: Wed, 2 Aug 2000 16:24:01 +0100
New pictures are easily generated from digital cameras, scanned images etc.
The pictures could be stored on image web sites such as
http://filmstills.freeservers.com/ so that Eve's suspicion is not aroused
through direct communication, since many hundreds of web images may be
downloaded to Bob's machine when he surfs.
An ActiveX control (or similar) on Bob's machine alerts him when his browser
donwloads an image which contains covert information intended for him.
Steve Weis <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Toby Sharp wrote:
> > At each visited pixel, the least significant bit of image data is
replaced
> > by the next covert message bit until all data bits have been encoded.
The
>
> Alice and Bob would have to generate an original image each
> transmission. If they use the same image over and over, Eve will notice
> the slight changes in the image. If they choose some image which is
> publicly available, Eve will be able to compare the original with their
> transmission. (Assuming Eve is a powerful adversary and has the
> resources to find the original image). There is also the question of
> traffic analysis. It will look suspicious if Alice and Bob suddenly
> start sending each other images and haven't had a history of doing it in
> the past.
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Small hash checksum
Date: Wed, 02 Aug 2000 15:32:29 GMT
On 2 Aug 2000 14:39:00 GMT, in <[EMAIL PROTECTED]>,
in sci.crypt [EMAIL PROTECTED] (Mark Wooding) wrote:
>Ilya O. Levin <[EMAIL PROTECTED]> wrote:
>> > Just use a 32 bit CRC they have the requirements you need.
>> > Table driven implementations are very fast.
>>
>> Definitely, it'll faster then take a piece of a big hash.
>
>Not necessarily. I remember testing CRC32 and MD4 on large files, and
>MD4 won rather convincingly. Both implementations were written in ARM
>assembler, though I'd not be surprised if similar results held for other
>architectures.
Well, there is CRC and then there is CRC. The fast implementation
uses a pre-computed table of 256 32-bit elements. Then for each data
byte we have a mask, an 8-bit XOR and look-up, an 8-bit shift and a
32-bit XOR. I'd be surprised if MD4 had an implementation which was
faster than that.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: Doug Kuhlman <[EMAIL PROTECTED]>
Subject: Re: Why is it necessary...?
Date: Wed, 02 Aug 2000 10:27:29 -0500
Sergio Arrojo wrote:
>
> Why is it necessary to know the number of points of a curve in order to find
> a point with order n (n large prime)?,
Well, it's not absolutely necessary...but it's easier to find the order
of the curve (SEA -- Schoof, Elkies, Atkin) than the order of a point.
The order of any point divides the order of the curve, so if the order
of the curve is smooth, we'd be wasting our time trying to find a point
with large prime order....
> once we know the order of the curve,
> how do we manage to find such a point?
>
Pretty easily. Assume the order of the curve is mp, where m is small
and p is a (very) large prime. Now, find any point on the curve (just
guess an x-value and see if it works...it will about 1/2 of the time.
If it doesn't, pick another x-value and see if it corresponds to a point
on the curve. It shouldn't take long to find one). Unless you're
highly unlucky, the order of the point you just found will be a multiple
of p (only m points aren't, if I recall correctly, so you have a 1/p
chance of getting a "bad" point). Multiply that point by m to guarantee
order p.
It looks more complicated than it realy is.
> Thanks
> Sergio Arrojo
No problem,
Doug Kuhlman
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Small block ciphers
Date: Wed, 02 Aug 2000 15:51:52 GMT
On 02 Aug 2000 08:25:10 GMT, in
<[EMAIL PROTECTED]>, in sci.crypt
[EMAIL PROTECTED] (Mack) wrote:
>[...]
>By dictionary attack I mean the accumulation of a dictionary of
>plaintext/ciphertext pairs.
I would call that a "codebook attack." That sort of attack is the
same as was used in the old days when there was a physical book
instead of a machine.
I reserve the term "dictionary attack" for an attack based upon actual
words, as often is done in attacking passwords or pass phrases.
>[...]
>I am more interested in the theoretical properties of a small block cipher.
>For example, If we change the key after every second encryption. Can an
>attacker find the key?
Surely the issue is not a time period but instead the amount of data
enciphered.
One might have a table-driven block cipher where each use of a table
entry was noted. Then, when an already-used entry was about to be
re-used, a new key would be generated and transferred and a new table
generated on both ends. Key transfer, as usual, would be under some
cipher, but that cipher has no known-plaintext (the plaintext is a
generated key) so there can be no known-plaintext attack on that.
One could certainly argue that such a cipher would prevent table
solution, prevent exposure of any key, and then rest on the essential
strength of the keys and the sequence of keys.
>Or if we change the key in some linear manner after
>every encryption can an attacker find the key for N encryptions where the
>key size is N*M?
First the opponent must know a key, or a sequence of keys, but if so,
the data cipher is already broken.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: Small block ciphers
Date: 2 Aug 2000 09:00:23 -0700
Mack <[EMAIL PROTECTED]> wrote:
> David Wagner wrote:
> >(I take it you are intending these things for use as internal components
> >of a cipher, in which case they are more properly called S-boxes.
> >The word "block cipher" is probably best reserved for the externally
> >visible functionality, not the internal invisible components.)
>
> No I am not talking about s-boxes. I am talking
> about small block ciphers. s-boxes fall into two
> categories static and dynamic (key dependent).
> The dynamic version certainly fills the bill as
> a cipher. The static version does not.
I _still_ think that you are talking about key-dependent S-boxes,
and _not_ ciphers. If your object is just part of a larger cipher
design and should not be used on its own for encrypting traffic,
then calling it a block cipher only invites confusion.
> If you could point me to some good literature on
> fast 'secure' dynamic s-box design that might prove
> useful. By secure I mean no attack better than
> brute force or dictionary attack.
You are right that much of the literature focuses on non-key-dependent
S-boxes. But you can still learn a lot from that literature. You should,
at the very least, go read the definitions of the various avalanche
properties, completeness properties, nonlinearity, correlation-freedom,
etc., and their theory. Also, read about bent functions. Those are all
relevant to design of key-dependent S-boxes, even if they are stated in
terms of non-key-dependent S-boxes in the literature.
As for specifically key-dependent S-boxes, Blowfish, Twofish, and Khufu
are good starting points.
Finally, let me state my opinion that your definition of `secure' is likely
to be too restrictive. Do you have any justification for your definition?
I think you can build secure ciphers out of S-boxes that aren't perfectly
indistinguishable from random functions; and you can build insecure ciphers
out of perfect S-boxes. You need to know what you are going to use the
S-box for, and then understand what properties are required, and then try
to design a S-box construction that meets those properties.
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: Skipjack
Date: 2 Aug 2000 09:09:53 -0700
In article <[EMAIL PROTECTED]>,
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
> "David A. Wagner" wrote:
> > Has anyone looked at the 256-element Skipjack S-box to see if it can
> > be expressed with less memory?
>
> As near as I can tell, you're essentially asking whether it is (non)
> random in Chaitin's sense.
Yeah! I'm not too familiar with Chaitin's theory, but I think
that's about right.
> > ... I wonder whether it is possible to build such a cipher.
>
> Sure, S-boxes and other components might be generated from smaller
> parameter sets. In fact they might be generated from the key.
Yes, that's obvious. What's not obvious is whether it is possible
to prevent the adversary from figuring out that this is going on.
After all, with such small parameter sizes, we could readily imagine
that any scheme to generate the S-boxes from smaller parameter sets
will be transparent to anyone who bothers to look and thus won't
really securely hide anything at all.
Maybe I'm missing something here, but it seems there is a real question
here, no?
------------------------------
Subject: Vote Yes/No.
From: None <[EMAIL PROTECTED]>
Date: Wed, 02 Aug 2000 09:10:38 -0700
http://www.aasp.net/~speechfb
I have used this crypto, and bought the source code, but think
1. These people may not be the best marketers. They want some
input.
2. They are seeking input on how they go about making the source
publicly available.
3. They now use the NDA to SELL the source code.
4. They want to know how to protect themselves AND have the
source publicly available.
5. I just figured they could put the source out with a copyright
notice...But I am not a lawyer. I wish I could put the source
code out, but it is now in NDA.
6. They would release it, according to their website and
contacts I have had with them, IF people let them know.
7. I think it is good enough system to be scrutinized by the
public encryption community. I have impression the Co. does as
well, but are a bit hesitant, as they are fearful of protecting
their work. I think we, the sci.crypt community can allay the
fears.
===========================================================
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: IV for arfour
Date: 2 Aug 2000 09:13:58 -0700
Andreas Sewe <[EMAIL PROTECTED]> wrote:
> Well, any stream-cipher needs an IV, and in most cases it is altogether
> sufficant to XOR the key K with the IV to get the session-key K_s.
I dispute this claim.
Anyhow, your proposal was to use K o IV as the session key, where the
permutations K,IV on 256 elements represent the master key and initialization
vector, respectively. But this requires a truly huge IV. Were you really
proposed to transmit a 256-byte array as your IV, for each packet?
That seems like an enormous transmission overhead, so I'm assuming that
can't be right. Did you intend to generate the IV permutation somehow
from a shorter value? If so, how? The details matter to the security
analysis.
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: IV for arfour
Date: 2 Aug 2000 09:15:34 -0700
In article <[EMAIL PROTECTED]>, Runu Knips <[EMAIL PROTECTED]> wrote:
> Andreas Sewe wrote:
> > Well, any stream-cipher needs an IV, and in most cases it is altogether
> > sufficant to XOR the key K with the IV to get the session-key K_s.
>
> Why that ??? I would concatenate the IV with the key ? Arcfour can
> handle plenty of key bits. XOR'ing the key with the IV reduces the
> space of possible keys drastically.
Actually, Andrew Roos has shown that this is insecure in some cases.
With RC4, I believe it is best to use H(K,IV) as your session key,
where K is the master key and H is some cryptographic hash (e.g., SHA1).
It is probably also prudent to discard the first few dozen bytes of output
from RC4 before using it to encrypt.
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Small hash checksum
Date: 2 Aug 2000 16:18:10 GMT
Terry Ritter <[EMAIL PROTECTED]> wrote:
>
> On 2 Aug 2000 14:39:00 GMT, in <[EMAIL PROTECTED]>,
> in sci.crypt [EMAIL PROTECTED] (Mark Wooding) wrote:
>
> >Not necessarily. I remember testing CRC32 and MD4 on large files, and
> >MD4 won rather convincingly. Both implementations were written in ARM
> >assembler, though I'd not be surprised if similar results held for other
> >architectures.
>
> Well, there is CRC and then there is CRC. The fast implementation
> uses a pre-computed table of 256 32-bit elements. Then for each data
> byte we have a mask, an 8-bit XOR and look-up, an 8-bit shift and a
> 32-bit XOR. I'd be surprised if MD4 had an implementation which was
> faster than that.
I'm not a *complete* idiot, Terry. I *did* implement the CRC like
that.
Let's think about this. For a CRC, we have:
* For each byte, a memory read (to fetch the byte), an XOR, an AND, a
load (with shifted index; let's say that's free, because it was),
and another XOR (and we'll say that the shift is free again).
* Then we see whether we've finished, and branch back if we haven't. I
count 7 cycles per byte.
Here's the code, or at least a facsimile:
crc32
stmfd r13!, {r3, r14}
mvn r0, r0
adr r3, crc_table
crc_loop
cmp r1, r2
ldrccb r14, [r1], #1
eorcc r14, r14, r0
andcc r14, r14, #&ff
ldrcc r14, [r3, r14, lsl #2]
eorcc r0, r14, r0, lsr #8
bcc crc_loop
mvn r0, r0
ldmfd r13!, {r3, pc}
For MD4, we have:
* Three rounds of processing. Each one consists of...
* Loading a magic constant. Actually, the first round's constant is
zero, so that's free. [0, 1, 1]
* Sixteen steps, each of which does the same thing to one of 16 input
words. Each step consists of...
* A word load. I don't have enough registers to avoid this. [1, 1, 1]
* A boolean function on three inputs. There are three different ones
of these, used in the different rounds. Three-way XOR costs two
cycles, selection costs three, and majority is a pain and costs
five. [3, 5, 2]
* Adding four things together and doing a rotate. [4, 4, 4]
Adding that load together, we have 16 [8, 10, 7] + [0, 1, 1] + 3 = 405
in total. (The three on the end is for the looping. I neglect the
padding at the end, because it's negligible on large files.) But that
does 64 bytes all at once. I therefore find that it does each byte in
6.33 cycles.
A win for MD4!
Do I hear an objection at the back? Something about loads not happening
in one cycle? Yes, I agree that that was cheeky for me. But I was
actually trying to favour CRC as much as I could. Note that we actually
do 3/4 as much loading of data in MD4 -- although we do three times as
many loads (one in each round), they're of chunks four times the size.
And I'm assuming that the CRC table lives in cache all the time anyway.
Next objection, please! Yes, I could have loaded words in the CRC. I
think I decided that the extra logic to do this would have made life
over-complex, but it is a possiblity. However, I still have to deal the
next byte out of an accumulator somehow, so it's not that much of an
advantage.
Next please?
-- [mdw]
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: IV for arfour
Date: 2 Aug 2000 09:19:48 -0700
I think there is some confusion here. RC4 already allows you to
use an arbitrary-length key, no modifications needed.
You seem to be considering taking away the RC4 key schedule and
replacing it with something else. Be very, very careful. The
security of RC4 depends intimately on the key schedule. If you
change its key schedule, you get an entirely different cipher, one
that -- if you're unlucky -- may no longer be secure. I don't think
changing the key schedule is wise.
Given that RC4 accepts an arbitrary-length key, I can't see any
motivation to take away the key schedule and replace it with something
else. As far as I can tell, there seems to be nothing to be gained
and a lot to be lost. What am I overlooking?
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: Small block ciphers
Date: 2 Aug 2000 09:25:03 -0700
Mack <[EMAIL PROTECTED]> wrote:
> By dictionary attack I mean the accumulation of a dictionary of
> plaintext/ciphertext pairs.
This was a really hard to parse definition, and a non-standard one at that.
Do you mean that the accumulation is a requirement of the attack?
If so, that's normally called a known- or chosen-plaintext attack.
Do you mean that, as a result of the attack, we deduce the entire
codebook? If so, that's sometimes known as a `global deduction attack',
or just `an attack'. (It's usually considered that the ability to
decrypt every ciphertext is just as good as recovering the key.)
Did you mean something else? It's really hard to see what the content
of this proposed definition is.
------------------------------
From: James Felling <[EMAIL PROTECTED]>
Subject: Re: Psuedo-random number generation
Date: Wed, 02 Aug 2000 11:34:23 -0500
Anthony Stephen Szopa wrote:
> RecilS wrote:
> >
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Well I'm looking for a bit of brief help. I'm working on a one-time
> > pad system and I'm trying at the moment to devise a method to get
> > identical sequences of completely random numbers to two different
> > people without the possibility of compromise. The only two methods
> > I've realized are particle entanglement (obviously a bit impossible
> > right now) and trading CDs. Well short of setting up a hardware,
> > random number generator in my house (which i plan on doing) I need to
> > fill a few CDs with random bits.
> >
> > Right now, for testing, I'm willing to fall back upon
> > psuedo-randomness, but I'd rather be developing my software than a
> > program I will use very briefly and never again. So...
> >
> > If anyone knows of a good program which generates numbers with a high
> > degree of randomness and can do so on the scale of 650megs within a
> > realistic ammount of time, PLEASE LET ME KNOW! Even if it takes a
> > few days or longer I'm interested as I'm still developing the
> > interface and have time to kill.
> > THANKS.
> >
> > BTW - Please post a followup and do not email me at this time.
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: PGPfreeware 6.5.3 for non-commercial use <http://www.pgp.com>
> >
> > iQA/AwUBOYUfDBJETAFqh0RgEQISUACeIcFNv5t7oJ18Jq+h1WrlS6OmHtEAoKhx
> > z7XKEmlcDHR56c18UR+pGRGH
> > =M4Gy
> > -----END PGP SIGNATURE-----
>
> OAP-L3: Original Absolute Privacy - Level3 encryption software
> package is SHAREWARE.
>
> Although this software is shareware there is NO programmed
> expiration written into the code.
>
> I claim that this encryption software is practicably unbreakable
> when used according to recommendations. Get it and prove it for
> yourself.
I do NOT dispute that if one takes the (very very large) amount of effort to
setup and implement your program in a secure manner that it CAN produce
secure data. ( and mind you, I do NOT have an hour to do key setup every
time I want to securely rekey)
Then again so is RC4. And RC4 is easier to use ( it requires a lot less
input and work for an equivalent amount of security). It would probably take
a couple of minutes to setup and start generating data, it will output data
much faster than OAP-L3( by about 1-3 orders of magnitude faster( on a
typical machine), and has had extensive analisys. I personally, would go
with RC4 or a similar algorithim. Arc4 ( a RC4 clone is available on the net
as freeware, and as a portion of any number of free/shareware encryption
products).
>
>
> This can give you what you want.
>
> Get your free shareware copy at http://www.ciphile.com
>
> Go to the Pricing and Ordering web page and click on the blue anchor
> "email" in the third paragraph.
------------------------------
From: stanislav shalunov <[EMAIL PROTECTED]>
Subject: Re: Small hash checksum
Date: 02 Aug 2000 12:36:16 -0400
[EMAIL PROTECTED] (Mark Wooding) writes:
[Comparison of MD4 vs. CRC32. Conclusion that CRC32 takes
7 cycles/byte, while MD4 takes 6.33 cycles/byte. Discussion of
possible objections to the analysis of the code.]
> Next please?
But if the input is short (say 32 bytes on average), CRC would still
be faster, correct?
I've seen a technique where people would use MD5 on Message-IDs,
and take first 64 bits of it, rather than CRC64.
--
"If my Eternal Life Device does not give immortality, then the entire
Bible is a joke." -- Alex Chiu
http://www.alexchiu.com/affiliates/clickthru.cgi?id=shalunov
------------------------------
** 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
******************************
