Cryptography-Digest Digest #961, Volume #12 Thu, 19 Oct 00 18:13:00 EDT
Contents:
Re: On block encryption processing with intermediate permutations (Mok-Kong Shen)
Re: Dense feedback polynomials for LFSR (Tim Tyler)
On encryption through embedding (Mok-Kong Shen)
Re: Entropy and RC4 (Tom St Denis)
old factoring tricks (Tom St Denis)
Re: Enigma: Stolen German Code Machine Turns Up in BBC Mailroom (David Hamer)
Re: Dense feedback polynomials for LFSR ("Trevor L. Jackson, III")
Re: Which "password" is best. ([EMAIL PROTECTED])
Re: Which "password" is best. ([EMAIL PROTECTED])
Re: old factoring tricks ("Tony T. Warnock")
Re: Which "password" is best. ([EMAIL PROTECTED])
Re: On block encryption processing with intermediate permutations (Bryan Olson)
Re: old factoring tricks ("Michael Scott")
Re: How about the ERIKO-CHAN cipher? ([EMAIL PROTECTED])
Re: Looking for small implementation of an asymmetric encryption (John Myre)
Re: Enigma: Stolen German Code Machine Turns Up in BBC Mailroom (David Schwartz)
Encrypting large blocks with Rijndael (John Myre)
Re: Enigma: Stolen German Code Machine Turns Up in BBC Mailroom (Jim)
Re: Enigma: Stolen German Code Machine Turns Up in BBC Mailroom (Jim)
Re: old factoring tricks (Bryan Olson)
Re: What is desCDMF? ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: On block encryption processing with intermediate permutations
Date: Thu, 19 Oct 2000 22:30:28 +0200
Mok-Kong Shen wrote:
>
> Bryan Olson wrote:
> >
> > Mok-Kong Shen wrote:
> >
> > > I like to ask your favour to explain (excuse me, once again)
> > > but in a radically simplified case, namely on a four round
> > > DES (two cycles) with a single assumed random permutation
> > > (not used as known information) and with (u,u) as the single
> > > type of chosen plaintext.
> >
> > Why the special form (u, u)?
> >
> > If you want to do the specific exercise, you'll need to
> > understand the attack, and then study the DES round function
> > in excruciating detail. I'd suggest you look at linear
> > cryptanalysis to decide how many sample texts to work with
> > versus how much to guess-and-check.
> >
> > > Could you give the procedure in
> > > such concrete details, in particular the choice of u (if
> > > anything special) and the determination of the locations of
> > > the siblings desired for processing and the method of
> > > solutions of the equations involving these, so that one can
> > > actually write a computer program to perform exactly the
> > > attack and be able to deduce the key bits?
> >
> > I think my description is sufficiently precise to support the
> > attack up to the point where it would DES specific in your
> > example. At that point it will be up to you. Can you tell me
> > the first step that is not clear to you?
>
> Yes. You set up equations involving the 'siblings'. How
> can get these from a bunch of blocks of ciphertexts?
> Shall I try them randomly, assuming that these are the
> right ones? That's the very first stumbling stone for
> me, unfortunately.
To better illustrate my difficulty of undestanding your
stuff and hence (indirectly) my doubt of applicability of
the attack you invented, I like to formulate my point a
bit formally:
Let there be a cipher that is DES-like with a block
consiting of two words and has four rounds, i.e. two cycles,
and one intermediate permutation. Let there be four blocks
each with input (u,u).
Input of first cycle:
(u,u) (u,u) (u,u) (u,u)
Output of first cycle:
(v,w) (v,w) (v,w) (v,w)
(Assumed) permutation of words, resulting in input of
second cycle:
(v,v) (v,w) (w,v) (w,w)
Output of second cycle:
(a,b) (c,d) (e,f) (g,h)
Now, if one knows how the words a, b, ... etc. are obtained
according to the above history, then one can derive
functional relationship expressing these in terms of u and
the four round keys involved. However, the opponent, being
ignorant of the permutation, is unable to do that. How is
he then going to procede from the four blocks of the
ciphertext above to gain informations of the encryption
key of the given cipher at all (excepting perhaps through
brute force)?
M. K. Shen
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Dense feedback polynomials for LFSR
Reply-To: [EMAIL PROTECTED]
Date: Thu, 19 Oct 2000 19:56:29 GMT
Joaquim Southby <[EMAIL PROTECTED]> wrote:
: In article <8sg0h7$a1b$[EMAIL PROTECTED]> Tim Tyler, [EMAIL PROTECTED] writes:
:>The question then becomes: how do you have the faintest idea what the
:>period of the LFSR is without looking at the corresponding polynomial's
:>properties, and checking to see whether it is primitive.
:>
:>Without performing such a procedure, I don't see how you can claim that
:>99% of the state spece is covered from a given position - unless you
:>perform an exhaustive search - something which becomes impractical as
:>the size of the register grows.
: One of the most straightforward ways of checking to see if a polynomial
: is primitive is to use it as the tap sequence of an LFSR, plug in an init
: vector, and start clocking. If one were to note not only the primitive
: polynomials (i.e., those that made it to 2^n - 1 clocks before repeating
: the init vector), but also those that happened to show a large state
: space for that init vector (i.e., a large number of clocks before
: repeating the init vector), a library of such sub-maximal LFSR's could be
: built. [...]
This is an exhaustive search. You're never going to get vary large
guaranteed minimum period, nor are you going to be able to use seeds off
the path you test on without losing any guarantee of minimum period.
I expect most folks would simply choose a primitive polynomial,
if this is the alternative.
I have thought of some methods of finding LFSRs with large periods
without them being primitive, and without employing exhaustive search.
However, these methods suck ;-)
: With a maximal-length LFSR, the key is any number between zero and 2^n.
: Advantage: very easy to choose a suitable key. With a sub-maximal LFSR,
: the known init vector is seeded to the LFSR, then the LFSR is clocked a
: number of times equal to the key value before using the stream output.
: Advantage: key can be larger than 2^n since the clock count will
: effectively be the key moduloed by the size of the state space.
You call discarding much of the information in your key an "advantage"?
--
__________ http://alife.co.uk/ http://mandala.co.uk/
|im |yler [EMAIL PROTECTED] http://hex.org.uk/ http://atoms.org.uk/
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: On encryption through embedding
Date: Thu, 19 Oct 2000 22:56:55 +0200
Suppose we have a sequence of m message bits, which may
itself be encrypted, we can embed them into a sequence
of total of n (n>m) bits in the following simple manner.
Use a PRNG with a secret seed to determine the position
i (1<=i<=n) for the first message bit, then similarly
determine from the remaining places the position of the
second bit and so on and finally fill the rest positions
with random bits. This determination of the positions of
the message bits can be simply done by applying the
algorithm of Durstenfeld (see Knuth vol.2) to permute
1..n but executing only m steps, the m indices on the
righthand side being the desired positions.
In case the message bits have a strong bias in frequency,
the set of filling bits can be adapted such that no
appreciable bias is present in the result.
Analogous schemes can be employed, if one works on a base
other then 2.
M. K. Shen
==================================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Entropy and RC4
Date: Thu, 19 Oct 2000 20:41:05 GMT
In article <rOHH5.120$[EMAIL PROTECTED]>,
"George Gordon" <[EMAIL PROTECTED]> wrote:
> Other people have asked similar questions here, but let me ask a very
> specific one.
>
> Assume that you initialise RC4 using a 128-bit key. Then you output
exactly
> 16 bytes worth of the stream. (I don't care how many loops you do for
the
> initialisation)
>
> OK, how could you determine how much of the entropy in the 128-bit
key is
> preserved in the 16 byte stream if 1) you assume RC4 specifically?
2) you
> assume a perfectly uniform distribution?
I would say if the 128-bits of input is truly random then your 16 byte
output is truly random. Not that that is 100% true, but the best
analysis requires 2^30 bytes before the lsb will show off it's weakness.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: old factoring tricks
Date: Thu, 19 Oct 2000 20:42:36 GMT
Ok I am a bit behind in the times, but I am messing with pollard-rho
factoring (again). I was wondering if it was specifically designed for
smooth composites?
I am trying to factor a 79-bit RSA style modulus (ooh baby that's big)
and it's still chugging away minutes later, while I can factor smooth
1000-bit composites in a few seconds...
Oh boy.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Thu, 19 Oct 2000 16:54:01 -0400
From: David Hamer <[EMAIL PROTECTED]>
Subject: Re: Enigma: Stolen German Code Machine Turns Up in BBC Mailroom
David Schwartz wrote:
>
> Scott Craver wrote:
>
> > >Are you sure the exact specification of this version of the Enigma
> > >is public information?
Not only is "..the exact specification of this version.." known
but the details of this particular machine [G-312] are given in
a paper that I wrote in 1999 and published by Cryptologia earlier
this year.
'G-312: An Abwehr Enigma, Cryptologia XXIV(1), January 2000'.
The article contains details and a number of photographs of the
Abwehr machine including close-ups of its internal mechanism.
The wiring and notch information for the three wheels, the
Eintrittwalze and the Umkehrwalze are given together with a
detailed description of the stepping mechanism [which is totally
different from that of any of the other Enigma variants].
Comparisons between the Abwehr Enigma and the Service Enigmas
are made.
David Hamer
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
David Hamer The Crypto Simulation Group
[EMAIL PROTECTED] http://www.eclipse.net/~dhamer
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
------------------------------
Date: Thu, 19 Oct 2000 17:07:05 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Dense feedback polynomials for LFSR
Tim Tyler wrote:
> Joaquim Southby <[EMAIL PROTECTED]> wrote:
> : In article <8sg0h7$a1b$[EMAIL PROTECTED]> Tim Tyler, [EMAIL PROTECTED] writes:
>
> :>The question then becomes: how do you have the faintest idea what the
> :>period of the LFSR is without looking at the corresponding polynomial's
> :>properties, and checking to see whether it is primitive.
> :>
> :>Without performing such a procedure, I don't see how you can claim that
> :>99% of the state spece is covered from a given position - unless you
> :>perform an exhaustive search - something which becomes impractical as
> :>the size of the register grows.
>
> : One of the most straightforward ways of checking to see if a polynomial
> : is primitive is to use it as the tap sequence of an LFSR, plug in an init
> : vector, and start clocking. If one were to note not only the primitive
> : polynomials (i.e., those that made it to 2^n - 1 clocks before repeating
> : the init vector), but also those that happened to show a large state
> : space for that init vector (i.e., a large number of clocks before
> : repeating the init vector), a library of such sub-maximal LFSR's could be
> : built. [...]
>
> This is an exhaustive search. You're never going to get vary large
> guaranteed minimum period, nor are you going to be able to use seeds off
> the path you test on without losing any guarantee of minimum period.
>
> I expect most folks would simply choose a primitive polynomial,
> if this is the alternative.
>
> I have thought of some methods of finding LFSRs with large periods
> without them being primitive, and without employing exhaustive search.
> However, these methods suck ;-)
>
> : With a maximal-length LFSR, the key is any number between zero and 2^n.
> : Advantage: very easy to choose a suitable key. With a sub-maximal LFSR,
> : the known init vector is seeded to the LFSR, then the LFSR is clocked a
> : number of times equal to the key value before using the stream output.
> : Advantage: key can be larger than 2^n since the clock count will
> : effectively be the key moduloed by the size of the state space.
>
> You call discarding much of the information in your key an "advantage"?
Let's see, we load the initial (known) state and clock a number of times equal
to the 256 bit key value before using the stream output. Strange as it seems
this actually works. By the time the PRNG is ready to use the value of the
message to be encoded is guaranteed to have decayed to zero. Thus no valuable
information will ever leak, even to the intended recipient. ;-)
Even for a 64-bit key this is probably true ( ... pi seconds is a nanocentury
... so the first message takes a couple millennia if the LFSR can be clocked at
100 MHz.
For a server doing 1,000 key setups/sec we use a 10-bit key ... so it can be
cracked by hand?
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Which "password" is best.
Date: Thu, 19 Oct 2000 20:58:57 GMT
In article <[EMAIL PROTECTED]>,
"Frog2000" <[EMAIL PROTECTED]> wrote:
> Sorry for the repost, but I didn't think anyone would bother to read
the one
> where I forgot to put a subject.
>
> I have been "kicking around various ideas for encryption. I have
tried to
> get some random-passwords generated. In picking a password, which one
of
> the 2 below would you chose, and why? I am testing stream ciphers
based on
> cellular transform methods.
>
> Thanx.
>
> Password 1
>
> 0n~gv3,1=bBz&!LalIweDx(JQ$_\jN@u:O%X^t}p#SV?y]2T7GW+odYRc
>
> Password 2
>
> RrL?tJc_'A=an3V~$e(;:+vo@Tl24%yqm!\FSXKpz&DW^#5HIN
>
> --
> http://welcome.to/speechsystemsfortheblind
>
> http://www.MintMail.com/?m=18251
>
> --
> http://welcome.to/speechsystemsfortheblind
>
> http://www.MintMail.com/?m=18251
>
>
They are both too hard to type. Why not just a string of digits?
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Which "password" is best.
Date: Thu, 19 Oct 2000 21:02:02 GMT
Why not just go to the store, buy some Dungeons 'N' Dragons dice, and
get random decimal digits from them? From different dice, get random
octal digits ^_^
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Tony T. Warnock" <[EMAIL PROTECTED]>
Subject: Re: old factoring tricks
Date: Thu, 19 Oct 2000 03:16:34 -0600
Reply-To: [EMAIL PROTECTED]
Pollard rho works on the cycles of N. If N=PQ then cycles mod P and mod
Q are important. Roughly these are about Sqrt(P) or Sqrt(Q) respectively
(with some constants), or approximately N**(1/4).
For 79 bits, you should need about 2^20 cycles.
Are you sure you meant 79 bits and not 79 digits?
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Which "password" is best.
Date: Thu, 19 Oct 2000 21:13:29 GMT
Possible useful link:
http://world.std.com/~reinhold/diceware.page.html
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: On block encryption processing with intermediate permutations
Date: Thu, 19 Oct 2000 21:10:22 GMT
Mok-Kong Shen wrote:
> To better illustrate my difficulty of undestanding your
> stuff and hence (indirectly) my doubt of applicability of
> the attack you invented, I like to formulate my point a
> bit formally:
>
> Let there be a cipher that is DES-like with a block
> consiting of two words and has four rounds, i.e. two cycles,
> and one intermediate permutation. Let there be four blocks
> each with input (u,u).
Well, there's your problem. That's not the chosen plaintext
that the attack uses. First I use a single block (two word)
message, call it (u, v), and then a two-block message. As I
wrote:
| Again we use
| the same message many times, but this time the message is
| two blocks (four words) long. The two blocks are the same
| as each other, and the same as our one-block plaintext for
| which we got the 64 possible outcomes. If the one-block
| message we used was (u, v) then the two-block message is
| (u, v, u, v).
What follows explains how to find the sibling pairs.
Of course in your two-cycle case finding a sibling pair using
just the one-block plaintext is vacuously easy.
--Bryan
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Michael Scott" <[EMAIL PROTECTED]>
Subject: Re: old factoring tricks
Date: Thu, 19 Oct 2000 22:19:52 +0100
Try ftp://ftp.compapp.dcu.ie/pub/crypto/factor.exe
Mike Scott
Fastest is best.
MIRACL multiprecision C/C++ library for big number cryptography
Free implementations of Schoof's Algorithm for Elliptic Curves
http://indigo.ie/~mscott
"Tom St Denis" <[EMAIL PROTECTED]> wrote in message
news:8snmbr$kh1$[EMAIL PROTECTED]...
> Ok I am a bit behind in the times, but I am messing with pollard-rho
> factoring (again). I was wondering if it was specifically designed for
> smooth composites?
>
> I am trying to factor a 79-bit RSA style modulus (ooh baby that's big)
> and it's still chugging away minutes later, while I can factor smooth
> 1000-bit composites in a few seconds...
>
> Oh boy.
>
> Tom
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: How about the ERIKO-CHAN cipher?
Date: Thu, 19 Oct 2000 21:17:22 GMT
In article <8slihi$6te$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (David Wagner) wrote:
> >Then you take your key, a 20-digit (or longer) integer, take its
square
> >root, and starting at the decimal point, you take every digit less
than
> >6 until you have as many digits as are in your message. Then you
> >modulo-6-add this to the digits of your message.
>
> (An aside: Why do I keep seeing this suggestion? What is its
> appeal?)
>
> I don't recommend to use square roots. If you reveal every digit
> of the square root, it is very easy to recover the key with a short
> stretch of known keystream by using continued fractions. What makes
> you think that just omitting some of the digits is enough to patch
> things up to prevent generalizations of this attack from working?
=======================
Yes, but *which* digits am I omitting?
=======================
> How do you know there isn't some crazy lattice attack, for instance?
> Have you done any mathematical analysis at all? This stuff is very
> subtle, and you should spend an order of magnitude more time on
analysis
> than you do on design.
>
> This general methodology -- the original scheme is broken, so you add
> a minimal patch until you yourself can't break it, and maybe repeat
> a couple of times if the revisions get broken, too -- well, it strikes
> me as a pretty risky way to design ciphers. It's a mindset, but IMHO
> it's important.
>
--
Qwertyuiop asdfghjkl zxcvbnm!!
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Looking for small implementation of an asymmetric encryption
Date: Thu, 19 Oct 2000 15:23:01 -0600
Mike Rosing wrote:
<snip>
> But given the constraints as I've seen them here, you don't have enough
> bits in your transmission to be secure at all. Even a symmetric cipher
> at 49 bits is brute forcable in a matter of hours with a few machines.
Be careful. You can certainly use more than 49 bits for the
key even if the block size is 49 bits. Usually, brute-force
cracking means: try all the keys, you've got the right one
when the decryption "works". How many *blocks* do you need
for a "brute force" attack, supposing that the block is 49
bits and the key is, say, 128 bits? (I.e., suppose that
simply trying all the keys is hopeless).
(Granted, I have no idea if there is such a thing as a block
algorithm with a 49 bit block. Let us suppose that he decides
to use counter mode, neglecting concerns about synchronization,
errors, and spoofing.)
JM
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: Enigma: Stolen German Code Machine Turns Up in BBC Mailroom
Date: Thu, 19 Oct 2000 14:48:45 -0700
David Hamer wrote:
> The article contains details and a number of photographs of the
> Abwehr machine including close-ups of its internal mechanism.
> The wiring and notch information for the three wheels, the
> Eintrittwalze and the Umkehrwalze are given together with a
> detailed description of the stepping mechanism [which is totally
> different from that of any of the other Enigma variants].
Darn. I hate to lose a good conspiracy theory.
Perhaps the thieves were unaware of this article? <G>
DS
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Encrypting large blocks with Rijndael
Date: Thu, 19 Oct 2000 15:46:21 -0600
Rijndael is defined (almost*) to work on blocks of any
size that is a multiple of 32 bits. However, the rule
for the number of rounds based on the block size means
that encrypting a single large block is much slower than
encrypting it piecewise with one of the standard modes.
(Each round does work proportional to the block size,
which cancels out the advantage gained by encrypting
fewer blocks.)
For example, encrypting 256 bits at a time instead of
128 would require 14 rounds instead of 10, and so it
would be 40% slower.
Similarly, (if I did my arithmetic right) encrypting a
512 byte block in a single call would be 13.4 times slower
than encrypting it with 32 calls to 128-bit Rijndael.
Under what circumstances would one be willing to pay
this speed penalty? Is it at all reasonable to extend
the rule the about number of rounds this far?
JM
------------------------------
From: [EMAIL PROTECTED] (Jim)
Crossposted-To: talk.politics.crypto
Subject: Re: Enigma: Stolen German Code Machine Turns Up in BBC Mailroom
Date: Thu, 19 Oct 2000 21:58:31 GMT
Reply-To: Jim
On Wed, 18 Oct 2000 22:37:43 -0700, Anthony Stephen Szopa
<[EMAIL PROTECTED]> wrote:
>Jim wrote:
>>
>> On Wed, 18 Oct 2000 01:25:23 +0100, Mathew Hendry
>> <[EMAIL PROTECTED]> wrote:
>>
>> >On Tue, 17 Oct 2000 15:19:03 -0700, Anthony Stephen Szopa <[EMAIL PROTECTED]>
>> >wrote:
>> >
>> >>Stolen German Code Machine Turns Up in BBC Mailroom
>> >>
>> >>http://ap.tbo.com/ap/breaking/MGA5JU6YFEC.html
>> >
>> >Or from the horse's mouth
>> >
>> > http://news.bbc.co.uk/hi/english/uk/newsid_977000/977127.stm
>> >
>> >Three of the four rotors are missing. (Why steal only those?)
>>
>> Further ransom?
>Double crossing rat, is what I say.
>
>He got his money then sold the rotors to someone who had a machine
>that was missing these rotors.
>
>He got paid twice.
>
>The secret service will get this "master."
The 'secret service' couldn't catch a dying wasp.
--
______________________________
Posted by Jim Dunnett
dynastic at cwcom.net
nordland at lineone.net
------------------------------
From: [EMAIL PROTECTED] (Jim)
Crossposted-To: talk.politics.crypto
Subject: Re: Enigma: Stolen German Code Machine Turns Up in BBC Mailroom
Date: Thu, 19 Oct 2000 21:58:33 GMT
Reply-To: Jim
On Thu, 19 Oct 2000 16:22:23 +0100, Mathew Hendry <[EMAIL PROTECTED]>
wrote:
>[EMAIL PROTECTED] (Jim) wrote:
>
>: On Wed, 18 Oct 2000 01:25:23 +0100, Mathew Hendry
>: <[EMAIL PROTECTED]> wrote:
>:
>: >Three of the four rotors are missing. (Why steal only those?)
>:
>: Further ransom?
>
>Maybe, except that no ransom has yet been paid...
How do you know that for certain?
--
______________________________
Posted by Jim Dunnett
dynastic at cwcom.net
nordland at lineone.net
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: old factoring tricks
Date: Thu, 19 Oct 2000 21:49:38 GMT
Tom St Denis wrote:
> Ok I am a bit behind in the times, but I am messing with pollard-rho
> factoring (again). I was wondering if it was specifically designed
for
> smooth composites?
Kind of. The expected time to split is roughly proportional to
the square root of the smallest factor.
--Bryan
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: What is desCDMF?
Date: Thu, 19 Oct 2000 22:03:38 GMT
Tom St Denis <[EMAIL PROTECTED]> wrote:
>> > Why the heck would you use a 40-bit key? That's like asking "can
> you >> > steal my messages". Why not just not use a key at all?
>>
>> I can think of three reasons without particularly trying:
>>
And, let's not forget the obvious one. You're the worlds largest
provider of computing solutions and want to export systems
overseas. To do that, you need a way to reduce the DES key to 40 bits.
CDMF shortening allowed IBM to leverage all of the work they did in
their CCA for use in the exportable version, simply by "dialing in" a
smaller keysize.
--
Matt Gauthier <[EMAIL PROTECTED]>
------------------------------
** 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
******************************
