Cryptography-Digest Digest #740, Volume #10 Tue, 14 Dec 99 17:13:01 EST
Contents:
Re: Why no 3des for AES candidacy ("Trevor Jackson, III")
Re: Why no 3des for AES candidacy ("Trevor Jackson, III")
Re: Deciphering without knowing the algorithm? (wtshaw)
Re: how easy would this encryption be to crack? (Jim Gillogly)
Re: Deciphering without knowing the algorithm? (SCOTT19U.ZIP_GUY)
Re: Why no 3des for AES candidacy (Anton Stiglic)
Re: Conditional (keyed) bidirectional hash function ? (wtshaw)
Re: how easy would this encryption be to crack? (wtshaw)
Re: How do you crack a Rotating Grille? (wtshaw)
Re: Deciphering without knowing the algorithm? (Douglas Hinton)
Re: Why no 3des for AES candidacy (SCOTT19U.ZIP_GUY)
Re: Conditional (keyed) bidirectional hash function ? (Niall Parker)
Re: Conditional (keyed) bidirectional hash function ? (John Bailey)
Re: Why no 3des for AES candidacy (Uri Blumenthal)
Non-linear PRNGs (Mok-Kong Shen)
Re: Why no 3des for AES candidacy (Uri Blumenthal)
Re: Non-linear PRNGs (Mok-Kong Shen)
Re: Why no 3des for AES candidacy ("Trevor Jackson, III")
Re: Why no 3des for AES candidacy ("Trevor Jackson, III")
Re: Conditional (keyed) bidirectional hash function ? ("Gary")
Re: security of 3des ?= des (James Felling)
----------------------------------------------------------------------------
Date: Tue, 14 Dec 1999 15:48:56 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Why no 3des for AES candidacy
Anton Stiglic wrote:
> Uri Blumenthal wrote:
>
>>
>>
>> > Do you have any idea of what you are talking about?
>>
>> Do you have any brains to comprehend what I'm talking about?
>> --
>> Regards,
>> Uri
>> -=-=-==-=-=-
>> <Disclaimer>
>
> Gee, you are a smart ass Uri Blumenthal, very polite person as
> well! Do you have any matters at all? You got a paper written and
> you think you are a genius. Read my other reply to see why your
> objection was nonsens and just confuses people...
You did not say why the objection was nonsense and confuses people, you
just asserted so. Is there some divine revelation you can share with
us?
------------------------------
Date: Tue, 14 Dec 1999 15:51:15 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Why no 3des for AES candidacy
Tim Wood wrote:
> Uri Blumenthal wrote in message <[EMAIL PROTECTED]>...
> >> >> Why isn't 3des being considered for the AES?
>
> <snip>
>
> >> >One good reason:
> >> >The AES is supposed to support the following different key sizes:
> >> > 128, 192, 256
> >> >
> >> >You can see why 3-DES, with it's single sized 168 bit key,
> >> >does not fit in this categorie.
> >
> >No I can't - there are ways to securely make key of any length
> >(from 64 bis to 768*3 bits) for 3DES.
> >
> >> of course it's effective key length (strength) is 112bit not 168bit...
> >
> >In general - this is incorrect. In particular, it HIGHLY depends
> >on the key schedule and how the DES engine is employed.
> >
> >See "A Better Key Schedule for DES-like Ciphers" paper on
> ><http://www.research.att.com/~smb/papers/index.html>
>
> Why Is it incorrect in general? There are lower strength attacks, but even
> then I think it would be incorrect to quote 3DES as 168bits ? It is
> missleading.
3DES can be used with two or three 56-bit DES keys, producing a 112-bit flavor
and a 168-bit flavor.
>
>
> Also doesn't DES include the Key schedule? a small quote from the above
> paper;
>
> <quote>
> A Feistel cipher consists of two parts:
>
> *the key schedule, which produces subkeys for each round, normally from the
> �generating� or main key;
> and
> *scrambling�the �real� encryption, which mixes the subkey bits with the
> input bits to produce the output bits.
> </quote>
>
> Not that it really matters that much, since 3DES is not a candidate.
>
> Tim
>
> --
> **<Stolen line alert>**
> From my one-bit brain with a parity error.
> **</Stolen line alert>**
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Deciphering without knowing the algorithm?
Date: Tue, 14 Dec 1999 15:22:51 -0600
In article <[EMAIL PROTECTED]>, Jim Gillogly <[EMAIL PROTECTED]> wrote:
> HKXLF wrote:
> > Is it possible
> > to decrypt some text without first knowing what algorithm is used to encrypt
> > it?
>
> Yes, depending on the class of cipher being used.
The quickest means of attack, which has a good chance of working in many
cases, is to assign a tantalizing quest to Jim in the first place. If
your object is to learn what he knows, plan to work hard and well directed
for more years than you care to count.
--
There are those who are neither constrained by in belief of
their power over time and space.
All will have found too late when their time has run out,
and others find for them, a little space to be forgotten in.
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: how easy would this encryption be to crack?
Date: Tue, 14 Dec 1999 21:04:51 +0000
Jerry Coffin wrote:
> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
> > I'm using a rather simple encryption scheme and I'm kind of wondering
> > how easy it would be to crack,
> > if anyone'd like to take a look at it I'd be very happy:
>
> [ a double substitution cipher ]
>
> > keya & keyb would have different length, for example keya would be 1
> > byte longer than keyb
> >
> > Too easy to crack?
>
> The effective key length is (at most) the GCD of the lengths of the
> two keys. Assuming they're relatively prime, that means the product
> of their lengths. E.g. if they were 5 and 7 bytes long, then the
> effective key length would be 35 bytes.
It can also typically be broken with known plaintext as long as the
sum of the two keys (12 bytes in this case) rather than the product.
We did an example of this is sci.crypt a few years ago -- with some
simple algebra you don't need to wait for the two keys to come back
into synch to make use of their individual repetitions.
--
Jim Gillogly
Highday, 24 Foreyule S.R. 1999, 21:02
12.19.6.14.2, 4 Ik 10 Mac, Third Lord of Night
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Deciphering without knowing the algorithm?
Date: Tue, 14 Dec 1999 22:04:36 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]> wrote:
>
>: Very few methods in popular use. Actually even bother with encrypting
>: files that are not multiples of various lengths so even the
>: file lengths give clues as to what system is being used.
>
>This cuts both ways. If most commonly used techniques spit out a file
>that is a multiple of 64 bits in length, it's not easy to tell such
>techniques apart.
>
>On the other hand, if you are using a rare method - that needs no padding
>and can cope with arbitrary-sized files - the length of the file will
>frequently tell the attacker that such a technique is in use.
>
>The moral of the story is probably to try to pad your messages with a
>quantity of random garbage (to disguise their real length) after
>encryption.
I still strongly feel one always needs a mod where one does not
change the lenght of a file when encrypting since it allows for more
back doors. But I do think it is wise to pad a file out so that it matches
some common lenght that the AES crap will be using. But then again
maybe the NSA can easily till it from the AES stuff. But I will someday
add options to my methods for random padding to the desired lenght
in case the NSA is as dumb as Mr BS says it is.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: Why no 3des for AES candidacy
Date: Tue, 14 Dec 1999 16:14:44 -0500
>
>
> You did not say why the objection was nonsense and confuses people, you
> just asserted so. Is there some divine revelation you can share with
> us?
Sure, I could share (don't know if it's divine do!). The initial
question,
to the post was:
Why isn't 3des being considered for the AES? Is it because it is slower
than
DES?
For which I answered:
One good reason:
The AES is supposed to support the following different key sizes: 128,
192, 256
You can see why 3-DES, with it's single sized168 bit key, does not fit
in this
categorie.
To which Mr. Uli responded:
No I can't - there are ways to securely make key of any length
(from 64 bis to 768*3 bits) for 3DES.
To which I responded negatively. 3DES, as define in the standard,
does not use 128, 192 nor 256 bit keys.
What is so complicated? A modification of 3DES, as slight as it might be,
no longer defines 3DES (the standard).
What do you not agree with?????????????
Anton
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Conditional (keyed) bidirectional hash function ?
Date: Tue, 14 Dec 1999 15:53:52 -0600
In article <[EMAIL PROTECTED]>, Niall Parker
<[EMAIL PROTECTED]> wrote:
> Hello,
>
> I'm looking to find some information about defining a function which
> can be computed initially in one direction using a key, then checked
> in the reverse direction without the key, ie:
>
> B = fcn_1(A,key)
> A = fcn_2(B)
>
> but fcn_2 is not invertible (can't compute B from A without key)
>
> I've perusing the FAQs and web pages but haven't seen anything yet,
> perhaps someone is aware of relevant places to look ? (hopefully this
> is a trivial problem I'm too thick to notice the solution for ;)
>
> Thanks.
>
To be precise, this is exactly used in one component of the Grandview
Algorithm, and I don't know of another as simple example. There are
actually three keys used in encryption of each block of the GVA, and what
you call the key is only one of them, usually different for each block.
B is computed to contain the effects of A and your designation of key,
solving for A using the other parts of the key. Simple or confusing?
--
There are those who are neither constrained by in belief of
their power over time and space.
All will have found too late when their time has run out,
and others find for them, a little space to be forgotten in.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: how easy would this encryption be to crack?
Date: Tue, 14 Dec 1999 15:42:03 -0600
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Jerry Coffin) wrote:\
>
> The effective key length is (at most) the GCD of the lengths of the
> two keys. Assuming they're relatively prime, that means the product
> of their lengths. E.g. if they were 5 and 7 bytes long, then the
> effective key length would be 35 bytes.
>
Actually, if these are the sizes of the keys for double substitution,
accumulated keylength is only 12 bytes; it's a math sort of thing. There
are no easy ways to get a large keyspace than to think big to start with.
--
There are those who are neither constrained by in belief of
their power over time and space.
All will have found too late when their time has run out,
and others find for them, a little space to be forgotten in.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: How do you crack a Rotating Grille?
Date: Tue, 14 Dec 1999 15:31:37 -0600
In article <[EMAIL PROTECTED]>, Jim Gillogly <[EMAIL PROTECTED]> wrote:
> ...With shotgun hill-climbing you stand
> back a dozen yards from the map, give it a blast, and start hill-climbing
> from each starting point you hit.
>
Most try the single BB approach, less noise, but also less effective.
--
There are those who are neither constrained by in belief of
their power over time and space.
All will have found too late when their time has run out,
and others find for them, a little space to be forgotten in.
------------------------------
From: Douglas Hinton <[EMAIL PROTECTED]>
Subject: Re: Deciphering without knowing the algorithm?
Date: Tue, 14 Dec 1999 22:31:08 +0000
Something which no one mentioned is that if you know what kind of
encryption equipment is being used, one needs only to buy a similar unit
and install the known key. The equipment could have the worlds strongest
algorithm, but a person wouldn't need to anything about it to "listen
in."
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Why no 3des for AES candidacy
Date: Tue, 14 Dec 1999 22:15:25 GMT
In article <[EMAIL PROTECTED]>, Eric
Lee Green <[EMAIL PROTECTED]> wrote:
>"Douglas A. Gwyn" wrote:
>> "SCOTT19U.ZIP_GUY" wrote:
>> > The speed thing is what most phony crypto gods would have you belive the
>> > reason is. But in fact with the bloated operating systems one uses know a
> days
>> > and as machines get faster very week this is really a lame reaon when one
>> > wants real security.
>>
>> Speed *is* important in order that encryption become as widespread as
>> it really should, e.g. on network links. We're already in the age of
>> fiber-optic communication.
>
>Today's enterprise-class tape drives can handle streams of up to 40 megabytes
I am not familar with that type of Tape Drive the last BIG DRIVES I used
was when I was the Univac Systems programer for a Navy Base our drives
had the 9600 bit densitys but I don't remember the speed. What are the
current tape densitys know a days.
>per seconds. The servers that feed these beasts may have multiple gigabit
>Ethernet cards so that they can suck down enough data to keep the pipe full. I
>looked at encrypting those streams with 3DES, since 3DES is a nice proven
>algorithm, but it was just TOO BLOODY SLOW.
I was just anwsering the Question. I would not use 3DES my self. I would
write my own in the assembly language of the machine.
>
>So this isn't a crypto god hypothesis (I'm no crypto god, I'm just an engineer
>trying to create a solution). This is real world -- 3des is secure, but there
>DO exist applications where it's too slow.
>
>
I am just an Engineer also but had to do programming all my life
since most computer people not up on engineer problems.
They lack the mathematical background one gets in Engineering.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
------------------------------
Date: Tue, 14 Dec 1999 13:29:07 -0800
From: Niall Parker <[EMAIL PROTECTED]>
Subject: Re: Conditional (keyed) bidirectional hash function ?
I'm thinking of using this as a way to provide some degree of copy
protection
to embedded code, using a fixed serial number as can be found in some
memory
and CPU devices.
The idea is to use the serial number (A) to compute a corresponding
validation
number (B) using some secret key and fcn_1. The embedded code includes
fcn_2 which can now check that B corresponds to A (ie it must be an
authorized
copy) and further execution of the code is permitted. If the code is
copied to
another device (with a different serial number A), then B must be
recomputed
using the secret key for the copy to work.
I had initially been thinking of some public key encryption scheme, but
that doesn't
work because the private key is the one needed for decryption (and that
would
not be secure in the embedded code).
... Niall
Anton Stiglic wrote:
>
> This seems like an odd question..
>
> Can you elaborate on why you want this? This looks like a variation
> on a signature scheme...
>
> Do you need fcn_2 to be difficult to compute if you don't know the
> set of keys? (if not, just define fcn_1(A, key) = A, and fcn_2(B) =
> B).
> If the person must not be able to compute fcn_2 easily without knowing
>
> the possible keys, you have to make fcn_2 take a set of keys as input.
>
>
>
> Anton
>
>
>
> Niall Parker wrote:
>
>> Hello,
>>
>> I'm looking to find some information about defining a function which
>>
>> can be computed initially in one direction using a key, then checked
>>
>> in the reverse direction without the key, ie:
>>
>> B = fcn_1(A,key)
>> A = fcn_2(B)
>>
>> but fcn_2 is not invertible (can't compute B from A without key)
>
------------------------------
From: [EMAIL PROTECTED] (John Bailey)
Subject: Re: Conditional (keyed) bidirectional hash function ?
Date: Tue, 14 Dec 1999 21:28:54 GMT
On Tue, 14 Dec 1999 11:37:05 -0800, Niall Parker <[EMAIL PROTECTED]>
wrote:
>Hello,
>
>I'm looking to find some information about defining a function which
>can be computed initially in one direction using a key, then checked
>in the reverse direction without the key, ie:
>
> B = fcn_1(A,key)
> A = fcn_2(B)
>
>but fcn_2 is not invertible (can't compute B from A without key)
>
If key= private key
and yek= public key
encrypt() and decrypt() are public key en/decryptions, eg RSA
Let "B" = "encrypt(hash(A), key)" + "yek" , where quotes denote
strings and + denotes concatenation.
now hash(A) = fcn_2(B)= decrypt(B(stripped of yek), yek)
------------------------------
From: Uri Blumenthal <[EMAIL PROTECTED]>
Subject: Re: Why no 3des for AES candidacy
Date: Tue, 14 Dec 1999 16:44:53 -0500
Reply-To: [EMAIL PROTECTED]
Tim Wood wrote:
[re: 3DES]
> >> of course it's effective key length (strength) is 112bit
> >> not 168bit...
> >
> >In general - this is incorrect. In particular, it HIGHLY depends
> >on the key schedule and how the DES engine is employed.
> >
> >See "A Better Key Schedule for DES-like Ciphers" paper on
> ><http://www.research.att.com/~smb/papers/index.html>
>
> Why Is it incorrect in general? There are lower strength attacks,
> but even then I think it would be incorrect to quote 3DES as
> 168bits ? It is misleading.
IMHO, because the key schedule you employ will determine
the "strength" of the engine. [But my definition of
standard is loose :-]
Since you read the paper - you saw the mod's to the way
DES is tripled, as well. I claim those too don't invalidate
the analysis done on "normal" DES and 3DES [see below].
> Also doesn't DES include the Key schedule?
Sure it does - and it's quite independent from the rest of
the mechanism. Biham and Shamir took the trouble to explore
what DES looks like (strength-wise) with modified key schedule,
and still called it DES (one mod was using independent subkeys).
Because they understood how loose the ties are between the crypto
engine and the key schedule engine (unlike ANY other ties
between the blocks of a crypto engine, for example).
Splitting thin hairs, if you modify the key schedule one bit,
you're not "DES" any more.
In crypto research however, the goal is not to comply with every
dot of the existing ANSI document(s), but to preserve (to keep valid
and to build upon) as much of the analysis already performed on the
existing algorithm(s) as possible. This was the purpose of the
design suggested in the above paper: to keep valid the results
of 20+ years of analysis AND at the same time increase the
strength of the algorithm, with MINIMAL invasion.
IMHO it was accomplished.
In other words, the modified algorithm is DES because all the
ANALYSIS performed on DES is still valid and applicable.
> Not that it really matters that much, since 3DES is not a candidate.
Of course (:-). A pur technical discussion on the qualities and
properties of an algorithm.
--
Regards,
Uri
-=-=-==-=-=-
<Disclaimer>
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Non-linear PRNGs
Date: Tue, 14 Dec 1999 22:54:07 +0100
There was a recent thread in this group discussing ways of
obtaining from linear congruential PRNGs bit sequences useful
for crypto applications.
This reminds one immediately of non-linear PRNGs, which by their
very nature are free from the difficulties arising from linearity
at the outset.
In a post of Feb 1988 in sci.crypt, V. S. Anashin has given a
general theorem for constructing full period (2^m) non-linear
PRNGs of arbitrarily high degree. (Literature: Mathematical Notes,
Vol. 55, 1994, p. 109-133. Plenum Pub.). This is reproduced in
essence below:
Let f(x) = a_0 + a_1*x^(1) + a_2*x^(2) + ..... + a_n*x^(n)
where x^(k) = x(x-1)(x-2)...(x-k+1).
Then the generator u(i) = f(u(i-1)) mod 2^m (m>2) has period
2^m if and only if the following congruences hold:
a_0 = 1 mod 2, a_1 = 1 mod 4, a_2 = 0 mod 2, a_3 = 0 mod 4.
It is of particular interest to note that a_k (k>3) are entirely
free of contraints.
Some experiments done by me on such PRNGs with n = 4, 5 and 6 show
that the resulting bit sequences have fairly good statistical
properties. The implementation is simple and quite efficient.
Question: Has anyone studied such PRNGs from cryptological point
of view? I surmise that they are extremely hard for analysis even
with moderate values of n.
M. K. Shen
======================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: Uri Blumenthal <[EMAIL PROTECTED]>
Subject: Re: Why no 3des for AES candidacy
Date: Tue, 14 Dec 1999 16:49:41 -0500
Reply-To: [EMAIL PROTECTED]
Tim Wood wrote:
> However Is independant sub-keys still DES?
IMHO yes it is, as far as the analysis is concerned.
> when is DES not DES, what about if you use one of the other S-box
> modes (such as making them key/plaintext-dependant)?
If memory serves me, making DES boxes plaintext-dependent would
in fact weaken the algorithm. I really don't recall the details
(it was looong time ago), so please don't quote me on this.
Regardless, touching S-boxes you do touch the "heart" of
the engine, and THEN it's questionable how much of the
existing analysis of the "old" DES still applies. Why
do you think we left the S-boxes alone? (:-)
--
Regards,
Uri
-=-=-==-=-=-
<Disclaimer>
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Non-linear PRNGs
Date: Tue, 14 Dec 1999 22:57:47 +0100
Mok-Kong Shen wrote:
>
> In a post of Feb 1988 in sci.crypt, ...
Correction: 26 Feb 1998.
------------------------------
Date: Tue, 14 Dec 1999 17:05:22 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Why no 3des for AES candidacy
Anton Stiglic wrote:
> >
> >
> > You did not say why the objection was nonsense and confuses people, you
> > just asserted so. Is there some divine revelation you can share with
> > us?
>
> Sure, I could share (don't know if it's divine do!). The initial
> question,
> to the post was:
>
> Why isn't 3des being considered for the AES? Is it because it is slower
> than
> DES?
>
> For which I answered:
> One good reason:
> The AES is supposed to support the following different key sizes: 128,
> 192, 256
> You can see why 3-DES, with it's single sized168 bit key, does not fit
> in this
> categorie.
>
> To which Mr. Uli responded:
>
> No I can't - there are ways to securely make key of any length
> (from 64 bis to 768*3 bits) for 3DES.
>
> To which I responded negatively. 3DES, as define in the standard,
> does not use 128, 192 nor 256 bit keys.
"The standard"? What standard is that?
3DES was originally proposed with a 112-bit key and E(D(E())) arrangement to
insure backward compatibility with DES. The 168-bit variant is not the only
valid usage.
>
>
> What is so complicated? A modification of 3DES, as slight as it might be,
>
> no longer defines 3DES (the standard).
>
> What do you not agree with?????????????
Your last statement. 3DES with 128/168 bits of warm key is still 3DES. It
just has a key (mis)management wrapper to match the AES requirements.
In a similar vein standard ciphers with 64 or 128-bit keys can be damaged by
restricting the key space in order to get export approval. Such a mechanism
does not invalidate the algorithm. It still operates according to the
standard. Thus the key restriction mechanism introduces no new weaknesses or
attacks except that of the reduced key space.
------------------------------
Date: Tue, 14 Dec 1999 17:08:45 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Why no 3des for AES candidacy
Anton Stiglic wrote:
> Tim Wood wrote:
>
> > >>>You can see why 3-DES, with it's single sized168 bit key, does not fit in
> > >>this
> > >>>categorie.
> > >>
> > >>of course it's effective key length (strength) is 112bit not 168bit...
> > >>
> > >
> > > it depends on how you do 3 DES
> > >
> >
> > Very true, I simpley made the same assumptions as the original poster.....
> > However Is independant sub-keys still DES? when is DES not DES, what about
> > if you use one of the other S-box modes (such as making them
> > key/plaintext-dependant)?
>
> DES stands for Data Encryption Standard. The standard defines a protocol
> called DEA, the Data Encryption Algorithm. If you modify something of it,
> it is no longer DEA, you are no longer following the standard!
> I hope everyone agrees on that, by definition of a standard alone!
> A standard is a standard, you follow it step by step or you don't followe it at
> all.
> The standard is clearly defined in FIPS-PUB report number 46-2.
>
> Take for example DESX, a variant on DES. It's name is different, and
> appropriatly!
>
> So Mr Uli might have come up with a slight variant of DES, but it's no
> longer DES, and he should never call it that!
>
> Anton
<pedantic overload alert!>
I'm ususally pretty stringent about terminology but in this case I see no issue. I
doubt you would find any reader confused by the terminology used in this thread.
------------------------------
From: "Gary" <[EMAIL PROTECTED]>
Subject: Re: Conditional (keyed) bidirectional hash function ?
Date: Tue, 14 Dec 1999 22:04:38 -0000
You can use a signature scheme using public key cryptography as follows:
You wish to authorise the unique CPU serial number A.
You sign the hash of A with your private key producing B.
When B is used in the program it is verified by using your embedded public
key on B to produce C( the hash of A). The program only runs if C is equal
to the hash of the serial number of the CPU it's running on.
Knowledge of the public key doesn't allow knowledge of the private key.
RSA is the most popular scheme for this.
------------------------------
From: James Felling <[EMAIL PROTECTED]>
Subject: Re: security of 3des ?= des
Date: Tue, 14 Dec 1999 16:05:25 -0600
I believe that it has been proven that DES is not a group relative to the
keys. It is a permutation over the plaintext however, as it bijectively
maps its input space to its output space. So given a key the space DES(K,
Space) is group.
James Felling wrote:
> [EMAIL PROTECTED] wrote:
>
> > i was wondering if it has been shown that 3des is more secure
> > than des.
> >
> > my understanding is that if des transformations form a group
> > than any composition of des transformations is equivalent to
> > a single des encryption, which is bad from a security standpoint, but
> > that currently nobody knows if des transformations form a
> > group.
>
> DES has been proven not to be a group.
>
> >
> >
> > so ... if it is still up in the air, couldn't the EFF use it's
> > super-fast des cracking machine to try to find single-des equivalent
> > keys to some 3des-encrypted known plaintexts? if it finds equivalent
> > single-des keys for even just a few 3des keys (with no obvious
> > degenerate structure) that would really convince me not to use 3des
> > for anything.
> >
> > or maybe the EFF has already tried this?
> >
> > -- p
> >
> > Sent via Deja.com http://www.deja.com/
> > Before you buy.
------------------------------
** 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
******************************
