Cryptography-Digest Digest #582, Volume #11 Thu, 20 Apr 00 06:13:00 EDT
Contents:
Re: Requested: update on aes contest ("Adam Durana")
Re: Should there be an AES for stream ciphers? (Paul Koning)
Re: DES Key Expansion Algorithm (Paul Koning)
Re: Requested: update on aes contest ("Trevor L. Jackson, III")
Re: Q: NTRU's encryption algorithm (David Hopwood)
Re: Requested: update on aes contest ("Trevor L. Jackson, III")
Re: password generator ("Trevor L. Jackson, III")
Re: password generator (Tom St Denis)
Re: A future tenant of the dog house?? (Tom St Denis)
Re: potency of a congruetial generator (Tom St Denis)
Singh Crypto Challenge progress (Paul Rubin)
Re: diff between Symetric and Asymetric Keys (Tom St Denis)
Re: Requested: update on aes contest (Tom St Denis)
Re: password generator (Tom St Denis)
Re: Q: NTRU's encryption algorithm (John Myre)
Re: Requested: update on aes contest (John Myre)
Re: 40-Bit DES Question (Doug Stell)
Re: 40-Bit DES Question (Jim Gillogly)
Re: Observer 16/4/2000: "Jack Straw wants the keys to your office. Don't let him in
..." (Philip Baker)
----------------------------------------------------------------------------
From: "Adam Durana" <[EMAIL PROTECTED]>
Subject: Re: Requested: update on aes contest
Date: Wed, 19 Apr 2000 17:52:59 -0400
> >The greatest part of the whole conference was definitely the end, where a
> >representative of each team had a chance to explain why his cipher is
> >better than the others, it was fun.
>
> I thought so, too. The most fascinating thing, to me, is that every
> goup believed that they should be chosen as AES. On the surface, this
> is very surprising. The only explanation I can come up with is that
> ever goup knows their algorithm the best, and is most confident with
> it. Kind of like the "devil you know" as applied to block ciphers.
I do not find this very surprising. Since there are no attacks better than
brute force on any of the candidates with the full number of rounds
suggested by the authors, I would imagine that all authors of the AES
candidates still view their ciphers as secure. So to the authors it just
seems a matter of preference. I think the candidate with the least number
of attacks should be considered more secure than the rest, because attacks
are only going to improve. Whether a certain attack on a cipher can be
extended to the full round version of that cipher within the expected life
span of AES is something only time will tell. Also there is quite a bit to
be gained by the winner of AES. Although the creators of the winner will
not be profiting directly from licensing fees and etc, I suspect that
winning would increase business for them. Say Twofish is selected as AES,
I'm sure Counterpane will profit from that in some way. It would at least
mean more press for the company. The same would go for RSA if RC6 won, and
IBM if MARS won. I am not aware that the authors of Serpent or Rijndael are
affiliated with a company. Are they? It is also a competition and
admitting defeat before actually being defeated wouldn't be very sporting.
It would be interesting to see what each of the authors would choose as the
best cipher if they could not choose their own cipher. If you couldn't
choose Twofish, which cipher would you choose? And any other authors of AES
candidates that read this what cipher would you choose to win if you could
not choose your own?
- Adam
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: Should there be an AES for stream ciphers?
Date: Wed, 19 Apr 2000 17:38:23 -0400
Anton Stiglic wrote:
> ...
> I think stream cipher's are important, and often more practical.
True for some cases, not for others. For example, IPSec,
where you have to do packat at a time processing and the
packets aren't necessarily in order or free of omissions,
stream ciphers are a major hassle. Which would explain
why they aren't used with IPSec.
paul
--
!-----------------------------------------------------------------------
! Paul Koning, NI1D, D-20853
! Lucent Corporation, 50 Nagog Park, Acton, MA 01720, USA
! phone: +1 978 263 0060 ext 115, fax: +1 978 263 8386
! email: [EMAIL PROTECTED]
! Pgp: 27 81 A9 73 A6 0B B3 BE 18 A3 BF DD 1A 59 51 75
!-----------------------------------------------------------------------
! "A system of licensing and registration is the perfect device to deny
! gun ownership to the bourgeoisie."
! -- Vladimir Ilyich Lenin
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: DES Key Expansion Algorithm
Date: Wed, 19 Apr 2000 17:27:31 -0400
Anuj Seth wrote:
>
> Hi,
>
> I'm implementing the WTLS protocol which uses DES. One bulk encryption
> algorithm is DES_CBC_40 which uses 5 bytes of the key material to expand
> to 8 bytes.
>
> Could someone guide me to a source of information on the algorithm used
> for DES key expansion?
It should be in the RFCs. As I recall, it's some hack like
overwriting the high order 3 bits of the key with constant
values (not all zero, I think).
But the right answer is: don't bother. 40 bit "des" is unfit
for use, you're wasting your time and confusing your customers
implementing such a feeble "cipher".
paul
--
!-----------------------------------------------------------------------
! Paul Koning, NI1D, D-20853
! Lucent Corporation, 50 Nagog Park, Acton, MA 01720, USA
! phone: +1 978 263 0060 ext 115, fax: +1 978 263 8386
! email: [EMAIL PROTECTED]
! Pgp: 27 81 A9 73 A6 0B B3 BE 18 A3 BF DD 1A 59 51 75
!-----------------------------------------------------------------------
! "A system of licensing and registration is the perfect device to deny
! gun ownership to the bourgeoisie."
! -- Vladimir Ilyich Lenin
------------------------------
Date: Wed, 19 Apr 2000 18:16:45 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Requested: update on aes contest
Jim Gillogly wrote:
> It also makes the teams' second choice (after their own) look more
> useful as a distinguishing characteristic: Steve Bellovin said most
> of the submitting teams preferred Rijndael if their own was not chosen.
There actually some sound decision theory behind this approach. It might be an
objective assessment from people with two good credentials: expertise and interest.
Anyone who submits a cipher that makes it to the final round probably has both the
expertise to make a good choice, and the interest required to motivate their
exercise of that expertise.
A classic decision procedure the is the cake cutting "I cut, you choose" sequence.
If this process is cast as "NIST cuts, teams choose (vote)", and if NIST's cuts are
simply elimination of the respective team's submission, we be where you suggested,
looking at their second choice.
If the political process prohibits the use of this approach for the AES selection it
might still be useful as the criteria for choice of a secondary, backup cipher.
------------------------------
Date: Wed, 19 Apr 2000 22:23:32 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Q: NTRU's encryption algorithm
=====BEGIN PGP SIGNED MESSAGE=====
Runu Knips wrote:
> Mike Rosing wrote:
> > [...] The main problem is data expansion,
> > you have to transmit a lot more data than what you want to hide.
> > Since it doesn't use an Abelian group (it's just a ring) you can't
> > use any of the discrete log methods to crack it.
Although you indeed can't use discrete log algorithms to break NTRU
(AFAIK), that doesn't follow from it using a ring, since there are
other ring-based methods that can be broken by taking discrete logs.
> > It's difficulty
> > is based on finding a specific vector in a lattice, and this is
> > a very hard problem.
A little more precisely, the problem of finding "short" vectors in a
lattice, not necessarily a specific vector.
> > I don't think anybody has looked at how it
> > might fit into quantum computers either, concensus here a few
> > months ago was that quantum computers wouldn't help much.
>
> Really ? We have already a cipher which even can't be broken with
> a quantum computer ? Without having a quantum computer ? Thats
> pretty damn cool ! I want to have it !
I don't remember the discussion a few months ago, but I'm extremely
skeptical of any claim that lattice-based cryptosystems are necessarily
secure against quantum computers. (For a start, it hasn't been adequately
demonstrated yet that they are secure against conventional computers,
but even if they were, I don't think the problem of how to break them
using quantum computation has been seriously researched, so a lack of
results should not be surprising.)
- --
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOP4jlDkCAxeYt5gVAQH3ygf+INSP8ADDtzjYFh3YSOwkV1JshtyRP+oN
PNc1ptT0theceKX8FeWFofFUy6tKgwl+IuThSoPI557vL4AAx8gZdZS8KhGQ5r5Q
jdxnKEu1oH0w/j3UgMux7pl4Z8wJS6JHw4waBqrtDp9nv4FCFuEMfQCAtejb96g0
tRMNn+zHxAC4hpbZGz1Z4i9KeZeB11ttGIKYmp/LBLkaHELALi+cTtGe9RqFnA6a
QEXo0AGFEWgMsRbZLFhSJTxU0lNgWAWMVNz6ajNh+5JrumGza6/5jJVroglvlWjp
XA3Pih3N6EaHKr7P/EdKibLqSdXG131AcNROvz/ru/bpXdn0n7PQ4w==
=zj0U
=====END PGP SIGNATURE=====
------------------------------
Date: Wed, 19 Apr 2000 18:22:32 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Requested: update on aes contest
Bruce Schneier wrote:
> On Wed, 19 Apr 2000 17:31:34 +0000, Jim Gillogly <[EMAIL PROTECTED]> wrote:
> >
> >It also makes the teams' second choice (after their own) look more
> >useful as a distinguishing characteristic: Steve Bellovin said most
> >of the submitting teams preferred Rijndael if their own was not chosen.
>
> Amost. Most of the submitting teams preferred Rijndael WITH MORE
> ROUNDS if their own algorithm was not chosen. It's an important
> qualification.
This may not be a bad thing. Since performance may dominate the selection of
the primary cipher simply because it is an easily quantifiable property, it
might be interesting to consider Rijndael++ as the backup cipher.
I know that you have stated that you are opposed to multiple selections.
Would your position on this issue be influenced by a pair of selections
distinguished by performance? Say Twofish or RC6 as primary, and R++ as
secondary?
------------------------------
Date: Wed, 19 Apr 2000 18:33:12 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: password generator
Anton Stiglic wrote:
> O.k., I'm sorry for the error, I just posted a quick reflexion. No need for all
>
> that arragance, we already have Bob Silverman here for that.
Hmmm. A couple of points.
First, arrogance (sic) is partly in the eye of the beholder.
Second, everyone who submits is guilty in some degree of insufficient humility in
that they consider their writing to be worth reading (c.f., 90% of everything is ...
-- Sturgeon?).
Third, Silverman doesn't appear arrogant to me, just forceful (I'm willing to be
corrected on this point if he chooses to opine on this topic).
Fourth, had you been submitting code of your own you would probably have gotten far
more gentle treatment than you got for falsely (arrogantly ;-) criticizing someone
else's code.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: password generator
Date: Wed, 19 Apr 2000 22:29:04 GMT
John Myre wrote:
>
> Tom St Denis wrote:
> >
> > Got bored this afternoon so I wrote a password generator using the
> > windows timer rng idea.
> >
> > You can get the source at
> >
> > http://24.42.86.123/files/passwd.c
>
> Why do you generate 8 bits per byte (in trng_byte), and
> then throw two of them away (via & 63)?
I was lazy really. It's just a demo piece of code. You can modify
trng_byte to make 6 bits only if you like.
Tom
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: A future tenant of the dog house??
Date: Wed, 19 Apr 2000 22:30:25 GMT
James Muir wrote:
>
> I stumbled across "Polymorphic Cryptography" today:
>
> http://www.identification.de/crypto/index.html
> http://www.identification.de/crypto/descript.html
>
> Here's a quote from the splash page:
>
> "Common ciphers like DES and RSA are extremely slow when calculating on
> long keys. Polymorphic Cryptography is 10^1500 times as secure at
> comparable encryption speed!"
Too bad DES does not have a variable key size. I would strongly put
this guy in the clueless bag.
> Here's another one from the description page:
>
> "The widespread DES algorithm has long been supposed to be unbreakable.
> In January 1999 a test performed by RSA Data Security, Inc. (San Mateo,
> Calif., USA) proved that it takes less than 22.25 hours to crack the 56
> bit algorithm by brute-force (by trying all 256 possibilities)."
>
> Ouch... I hope they just forgot the "^" character. Is anyone
> suspicious?? I wonder if you get a free bottle of snake oil with every
> order?
I would question this guys knowledge.
Tom
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: potency of a congruetial generator
Date: Wed, 19 Apr 2000 22:32:10 GMT
Mike Rosing wrote:
>
> Tom St Denis wrote:
> >
> > p: prime
> > a: multiplier
> > b: b <- a - 1
> > c: relatively prime to p
>
> If p is prime, (p,c) = 1 for all c :-)
Yeah but you need not have p prime always... I should have not said
that. Commonly p=2^w or a large prime.
> >
> > Where 'b' is a multiple of all the prime factors of p-1.
>
> by this you mean if p-1 = p1^r1 * p2^r2 * ... then
> b = k*p1*p2*... ?
Again sorry I wored that wrong, you are right.
>
> > Xi = aXi-1 + c mod p
> >
> > Is a linear congruetial generator of period p-1.
> >
> > Therefore the potency (dependancy on previous outputs?) is the s
> > variable in, b^s = 0 mod p.
>
> Where does s come from?
's' is the potency according to Knuth.
Me thinks I should re-read that last part of the chapter.
Tom
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Singh Crypto Challenge progress
Date: 19 Apr 2000 22:35:44 GMT
A co-worker just walked by and told me that all stages up to #9
are now solved. Since I hadn't seen it mentioned here, I thought
I'd post. #9 was apparently a DES encryption, broken by the EFF using
half of the Deep Crack hardware.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: diff between Symetric and Asymetric Keys
Date: Wed, 19 Apr 2000 22:36:50 GMT
Jerry Coffin wrote:
>
> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
> > For those that get confused by the difference between asymetric and
> > symetric keys [this came up earlier]. Here is a prime example:
> >
> > This is a 256-bit RSA moduli:
> > n =
> > 64888175226511475729307106563515763635617513357155694169169668250943812167819
> >
> > I bet someone could factor it on their home computer in a bit.
>
> Well, it does take a fair amount of time, but yes a computer doesn't
> even have to be terribly fast to come up with:
>
> 213992804043672785042055563478990027397
> and
> 303225968352042123782345632613508197327
>
> in a day or so.
>
> > The same cannot be said about searching a 256-bit keyspace for a
> > symmetric key.
>
> Quite true. To try to exhaust a 256-bit keyspace, you don't take in
> days anymore, nor even in terms of weeks, years or centuries -- about
> the only reasonable unit of measure is the number of times the
> currently estimatee life of the universe, and even using that as your
> unit, you're talking about a LOT of them (even assuming you have more
> computers than there are estimated to be atoms in the universe).
Thanks for adding to my point. Now if this can be drilled into all
media press kits about crypto....
Tom
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Requested: update on aes contest
Date: Wed, 19 Apr 2000 22:37:12 GMT
James Felling wrote:
>
> Bruce Schneier wrote:
>
> > On Mon, 17 Apr 2000 18:38:38 -0400, Anton Stiglic <[EMAIL PROTECTED]>
> > wrote:
> > >I went to FSE and AES3 last week in New York. It was the first time
> > >I had been in a conference that discusses about symmetric encryption.
> > >I have a few taughts...
> > >
> > >None of them have been obviously broken. Attacks that where
> > >presented against these 5 ciphers necessitate extreme amounts
> > >of memory and/or computation, and the attacks where just slightly
> > >better than brute force, and this on a limited number of rounds.
> > >What amazed me is the slim amount of people that are actually
> > >working on breaking these ciphers, all the interesting attacks
> > >came from either the Twofish team (or extended Twofish team)
> > >or from Knudsen or Biham or Lucks. The Mars, Rijndael and RC6
> > >team seemed to have not invested much effort in cryptanalysis.
> > >Interestingly enough, the only cipher that has not been attacked
> > >is Twofish.
> >
> > People have tried, though. Sean Murphy and his group at Royal
> > Hollaway have writen about the "key separation" property, but have
> > not been able to turn that into an attack on any reduced-round
> > variants. Lars Knudsen presented an attack on Tuesday, which he
> > retracted on Thursday because it didn't work. We've tried, too.
>
> Key Seperation property? Where can I find that paper/ details? Perhaps I
> just overlooked it?
Try the counterpane website.
Tom
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: password generator
Date: Wed, 19 Apr 2000 22:41:45 GMT
"Trevor L. Jackson, III" wrote:
>
> Anton Stiglic wrote:
>
> > O.k., I'm sorry for the error, I just posted a quick reflexion. No need for all
> >
> > that arragance, we already have Bob Silverman here for that.
>
> Hmmm. A couple of points.
>
> First, arrogance (sic) is partly in the eye of the beholder.
>
> Second, everyone who submits is guilty in some degree of insufficient humility in
> that they consider their writing to be worth reading (c.f., 90% of everything is ...
> -- Sturgeon?).
>
> Third, Silverman doesn't appear arrogant to me, just forceful (I'm willing to be
> corrected on this point if he chooses to opine on this topic).
>
> Fourth, had you been submitting code of your own you would probably have gotten far
> more gentle treatment than you got for falsely (arrogantly ;-) criticizing someone
> else's code.
Not to jump in the middle, but if there are problems with my code I
would rather know. Basically all the stuff I post to my site and here
is research. So if I am wrong (98% of the time I am) I want to know.
Similarly, if they are wrong I choose to let them know.
I think some people just have to be a bit more objective and realistic
when they critic things. Also that they try something before deeming it
useless.
Cheers,
Tom
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Q: NTRU's encryption algorithm
Date: Wed, 19 Apr 2000 16:39:31 -0600
> > > Since it doesn't use an Abelian group (it's just a ring) you can't
> > > use any of the discrete log methods to crack it.
>
> Although you indeed can't use discrete log algorithms to break NTRU
> (AFAIK), that doesn't follow from it using a ring, since there are
> other ring-based methods that can be broken by taking discrete logs.
Would anyone like to explain what the first comment was meant
to mean in the first place? AFAIK, "just a ring" means in fact
an Abelian group plus a second operation. No?
John M.
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Requested: update on aes contest
Date: Wed, 19 Apr 2000 16:48:04 -0600
"Trevor L. Jackson, III" wrote:
>
> Jim Gillogly wrote:
>
> > It also makes the teams' second choice (after their own) look more
> > useful as a distinguishing characteristic: Steve Bellovin said most
> > of the submitting teams preferred Rijndael if their own was not chosen.
<snip>
> A classic decision procedure the is the cake cutting "I cut, you choose"
It doesn't have to be that peculiar looking. If you define a
"vote" as a ranking of the ciphers, a simple weighted average
gets you the same result, as the first choices cancel each other
out.
OK, I know, a weighted average isn't actually simple, unless
it is simplistic. Still, the point is that "cutting" isn't
needed because each team already distinguishes its own cipher
(as its first choice).
John M.
------------------------------
From: [EMAIL PROTECTED] (Doug Stell)
Subject: Re: 40-Bit DES Question
Date: Wed, 19 Apr 2000 22:52:41 GMT
On Wed, 19 Apr 2000 18:17:40 GMT, [EMAIL PROTECTED] wrote:
>I assume that for 40-Bit DES, known bits are set in the 56 bit DES key.
>Can someone tell me which bits are set and to what value? Also, where
>is this defined, FIPS?
It's old and probably out of date, but here is the only spec I've seen
on 40-bit DES.
Internet Draft Paul Hoffman
draft-hoffman-des40-02.txt Internet Mail Consortium
Russ Housley
SPYRUS
April 29, 1998 Expires six months later
Creating 40-Bit Keys for DES
Status of this memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."
To view the entire list of current Internet-Drafts, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
(Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
(Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu
(US West Coast).
1. Introduction
This document describes an method for shortening DES keys from 56 bits
to 40 bits. The shortened keys are generally known as "DES-40". The
motivation for this weakening is that some localities (such as the
United States) give special preference to applications that use 40-bit
keys. The weakened keys are then used with the DES encryption
algorithm in the same manner as full-strength keys.
There are many possible methods for reducing a 56-bit key to a 40-bit
key. The method in this draft was chosen because one method is needed
for interoperability. Further, this method has been known to
occasionally have been approved for export from the United States.
2. Creating 40-Bit Keys for DES
DES [DES] uses a 56-bit key. The key consists of eight 8-bit bytes;
however the last (eighth) bit of each byte is used for parity, leaving
56 bits of key.
To weaken the 8-byte, 56-bit key into a 40-bit key, you set to zero
the first four bits of every other byte in the key, starting with the
first byte. Stated a different way, you take the bitwise logical AND
of the key and the binary value:
0000111111111111 0000111111111111 0000111111111111 0000111111111111
0x0fff 0x0fff 0x0fff 0x0fff
Another way to picture this is:
Bit positions:
0000000000111111 1111222222222233 3333333344444444 4455555555556666
0123456789012345 6789012345678901 2345678901234567 8901234567890123
Use:
zzzzKKKpKKKKKKKp zzzzKKKpKKKKKKKp zzzzKKKpKKKKKKKp zzzzKKKpKKKKKKKp
Legend:
z = zero bit
K = key bit
p = parity bit
Some implementations of DES require the parity bit of each byte to be
set correctly in order for the key to be accepted. DES requires that
the last bit of each byte be a parity bit. DES uses odd parity,
meaning that the number of 1 bits in each byte should be odd.
Therefore, to complete the transformation to a 40-bit key, the
software SHOULD cause the parity in each byte to be odd, changing the
last bit if necessary.
3. Security Considerations
Current computer technology makes a brute-force attack on ciphertext
that is encrypted with a 40-bit key fairly quick. This is true for any
encryption algorithms, not just DES. Thus, 40-bit keys result in only
weak security against decryption. As computers get faster, this weak
security will become even weaker. Thus, 40-bit keys should never be
used with data that has a high value if it is decrypted by an
adversary. However, encrypting data with 40-bit keys prevents passive
snoopers from immediately reading a message without using some
significant but not onerous decryption effort.
Because of the ease of a brute-force attack on 40-bit keys, the 56-bit
key from which a 40-bit key is derived must not also be used as a
56-bit key. This is due to a simple attack that first derives the
40-bit key, then fills in the remaining 16 bits by brute force.
Systems that produce 40-bit keys from 56-bit keys must assume that the
associated 56-bit key is only slightly harder to compromise than the
40-bit key.
Note that short keys (and 40 bits is generally considered short) are
subject to a variety of brute-force attacks that are not possible with
longer keys, thus making them even more dangerous. For example, if a
40-bit algorithm is used and encrypted text includes a block of bytes
known to the attacker, then the attacker can pre-compute all possible
encryptions of that block and do a rapid comparison against the
pre-computed ciphertexts. Further, it is likely that more attacks on
short keys will appear in the future, thereby rendering them even less
suitable for protecting data.
The shortening method described in this draft causes a discernable
pattern of zero bits in the resulting key. There is no known
literature at this time that describes whether cyphertext encrypted
with a key that has this pattern of zeros is easier to decrypt than
cyphertext that has no pattern. However, because 40-bit keys are
already inherently weak, a decrease in security from the pattern is
not considered to be very important relative to the inherent weakness
due to the short key length.
There are other methods for converting longer keys to shorter ones.
For example, IBM has created a patented (and significantly more
complex) method called "Commercial Data Masking Facility", or CDMF
[CDMF]; other methods probably exist. These methods might result in
keys that produce cyphertext that is harder (or easier) to determine
through brute-force. A quick comparison of CDMF and DES-40 shows that
the brute-force attack against CDMF require one additional DES
operation. Saving one DES operation does not seem to warrant the
additional complexity.
A. References
[CDMF] "Design of the Commercial Data Masking Facility Data Privacy
Algorithm", 1st ACM Conference on Computer and Communications
Security, ACM Press, 1993.
[DES] ANSI X3.106, "American National Standard for Information
Systems-Data Link Encryption," American National Standards
Institute, 1983.
B. Authors' Addresses
Paul Hoffman
Internet Mail Consortium
127 Segre Place
Santa Cruz, CA 95060
(408) 426-9827
[EMAIL PROTECTED]
Russ Housley
SPYRUS
381 Elden Street, Suite 1120
Herndon, VA 20170
[EMAIL PROTECTED]
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: 40-Bit DES Question
Date: Wed, 19 Apr 2000 23:18:37 +0000
[EMAIL PROTECTED] wrote:
>
> SSL 3.0 has 40-bit DES as a valid algorithm for "securing" the socket.
> Only doing what is spec'ed. I assume it is for outside US to a US
> server that this is required.
No, a restriction to 40 bits is no longer required for export. Check
the BXA website for details. I'm not a lawyer, so your lawyer should
read the fine print.
No matter what the spec says, new applications should not use 40 bits.
This will require some user flexibility. Oh, well. Better that than
that they should think they're getting security when they're not.
--
Jim Gillogly
Sterday, 29 Astron S.R. 2000, 23:15
12.19.7.2.9, 1 Muluc 12 Pop, Fourth Lord of Night
------------------------------
From: Philip Baker <[EMAIL PROTECTED]>
Crossposted-To:
uk.media.newspapers,uk.legal,alt.security.pgp,alt.privacy,uk.politics.parliament,uk.politics.crime,uk.business.accountancy,talk.politics.crypto
Subject: Re: Observer 16/4/2000: "Jack Straw wants the keys to your office. Don't let
him in ..."
Date: Thu, 20 Apr 2000 00:24:48 +0100
In article <[EMAIL PROTECTED]>, NoSpam
<[EMAIL PROTECTED]> writes
>Fax your MP about RIP www.stand.org.uk
>
>www.observer.co.uk/business/story/0,6903,194001,00.html
>
>Jack Straw wants the keys to your office. Don't let him in ...
>
>John Naughton
>
>Sunday April 16, 2000
>
>The scene: an office in a high-tech start-up of the kind beloved of Iron
>Chancellor Brown. Let us call it UK-plc.com. The time: early next year; the
>Regulation of Investigatory Powers (RIP) Bill has been on the statute book
>for nearly six months. Alice, UK-plc's star programmer, has been receiving
>encrypted emails from an old flame, Bob, who (unknown to her) has a dodgy
>past.
>
>Enter Inspector Knacker, armed with a Section 46 Notice requiring Alice to
>provide the keys necessary to decrypt her correspondence. Section 50 of the
>RIP Bill requires Alice not to disclose to anyone the existence of the
>Notice, nor the actions taken pursuant to it.
>
>Being a law-abiding subject, Alice gives Knacker the keys. Under Section 50,
>she may not tell Bob, which is right and proper. But now here's the
>interesting bit - Alice may not tell her other correspondents that their
>privacy has been compromised, even though they are entirely innocent and the
>Inspector is now able to decrypt all their messages as well.
>
Except that he doesn't have them.
--
Philip Baker
http://www.thalasson.com
------------------------------
** 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
******************************
