Cryptography-Digest Digest #739, Volume #10 Tue, 14 Dec 99 16:13:01 EST
Contents:
Re: How to implement different modes using the twofish algorithm? (Medical
Electronics Lab)
security of 3des ?= des ([EMAIL PROTECTED])
Re: security of 3des ?= des (James Felling)
Conditional (keyed) bidirectional hash function ? (Niall Parker)
Re: Why no 3des for AES candidacy ("karl malbrain")
Re: security of 3des ?= des (DJohn37050)
Re: security of 3des ?= des ("karl malbrain")
Re: Conditional (keyed) bidirectional hash function ? (Anton Stiglic)
Re: Are thermal diodes as RNG's secure (Scott Nelson)
Re: Why no 3des for AES candidacy (Anton Stiglic)
Re: Why no 3des for AES candidacy (Anton Stiglic)
Re: Better encryption? PGP or Blowfish? ("Trevor Jackson, III")
Re: Why no 3des for AES candidacy ("Trevor Jackson, III")
Re: Why no 3des for AES candidacy (Anton Stiglic)
How easy would this encryption be to crack? - revised (Christoffer
=?iso-8859-1?Q?Lern=F6?=)
Re: Why no 3des for AES candidacy (Anton Stiglic)
----------------------------------------------------------------------------
From: Medical Electronics Lab <[EMAIL PROTECTED]>
Subject: Re: How to implement different modes using the twofish algorithm?
Date: Tue, 14 Dec 1999 12:09:42 -0600
Martin Bädeker wrote:
> I'm a newbie to this and have problems to implement following modes of
> Twofish: CFB1,CBC,ECB. I already verified - using given testvectors -
> that my implementations of makeKey, BlockEncrypt and BlockDecrypt are
> delivering the valid outputs, but I can't get proper results in CBC
> mode.
> For CBC I XORed the plaintext (PT) and the IV and at then encrypted it
> using my function. But the resulting ciphertext (CT) differs from the
> CBC testvectors.
> CT = Encrypt(PT xor IV)
> Any suggestions?
First set the IV = 0 and see if you get the same result as you'd
get for ECB. If so, your xor works.
Second, set PT xor IV = ECB PT. Try again and make sure that works.
If you get past those 2 steps, then it should be right, check that
you're feeding the ciphertext back to the right place for CBC.
Patience, persistence, truth,
Dr. mike
------------------------------
From: [EMAIL PROTECTED]
Subject: security of 3des ?= des
Date: Tue, 14 Dec 1999 19:02:53 GMT
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.
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.
------------------------------
From: James Felling <[EMAIL PROTECTED]>
Subject: Re: security of 3des ?= des
Date: Tue, 14 Dec 1999 13:28:45 -0600
[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.
------------------------------
Date: Tue, 14 Dec 1999 11:37:05 -0800
From: Niall Parker <[EMAIL PROTECTED]>
Subject: Conditional (keyed) bidirectional hash function ?
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.
... Niall
------------------------------
Reply-To: "karl malbrain" <[EMAIL PROTECTED]>
From: "karl malbrain" <[EMAIL PROTECTED]>
Subject: Re: Why no 3des for AES candidacy
Date: Tue, 14 Dec 1999 11:58:23 -0800
SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]> wrote in message
news:834ko3$1110$[EMAIL PROTECTED]...
> In article <fhh54.648$[EMAIL PROTECTED]>, "karl
malbrain" <[EMAIL PROTECTED]> wrote:
(...)
> >This is an example of VULGAR MATERIALISM. Yes, it's true, that ANY
> >measurable operations-effect means that the law is not being ignored, per
> >se. That's hardly the point, however. Karl M
> >
>
> No I meant the NSA. The FBI does not contain the high caliber of
> quality people to break simple codes. That is what the NSA does.
> But they don't give a FUCK about the law and your being foolish to
> think otherwise. However they don't go out of there way to give evidence
> of there law breaking to just every one or people might get pissed and
> the government might cut there budget. And just what is
> VULGAR MATERIALISM I may be vulgar but I'm not to
> materialistic.
MATERIALISM is a world outlook that evaluates OBJECTS by enumerating
SUBJECTS. This is contrasted with IDEALISM that pretends to evaluate
SUBJECTS as things-in-themselves. VULGAR MATERIALISM pretends to evaluate
OBJECTS as things-in-themselves, outside the SUBJECTS' relationships or
status.
Thus, the statement that the NSA must be governed by law because the law has
had some EFFECT on their operations is a VULGAR evaluation, as if the NSA
has no SUBJECTIVE status or role in the outcome of the evaluation itself.
It's a cheap trick of logic that was first POLITICALLY used in the final
collapse of the Roman Empire, and lives on today under the rubric `question
authority' Karl M
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: security of 3des ?= des
Date: 14 Dec 1999 20:03:10 GMT
The group that DES generates is huge.
This has been shown by looking at the orders of some elements, each prime
factor of each order must be a factor of the group order. Some think it is the
alternating group on 2**64 elements.
Don Johnson
------------------------------
Reply-To: "karl malbrain" <[EMAIL PROTECTED]>
From: "karl malbrain" <[EMAIL PROTECTED]>
Subject: Re: security of 3des ?= des
Date: Tue, 14 Dec 1999 12:12:32 -0800
<[EMAIL PROTECTED]> wrote in message
news:83648o$gmt$[EMAIL PROTECTED]...
> 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,
In the sense that DES is a 64 bit block function that MAPS one input to one
output, yes, you can combine DES operations as a single MAPPING, and there
is no security gain. This seems to be the direction that cryptanalysis is
going in general, gaining an ability to attack the MAPPING independently of
the notion of `KEY'. Karl M
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: Conditional (keyed) bidirectional hash function ?
Date: Tue, 14 Dec 1999 15:16:07 -0500
==============55C5DC630BB9715CD9865C32
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
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)
>
> 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.
>
> ... Niall
--
___________________________________________
Anton Stiglic
Jr. developer & specialist in cryptology.
Zero-Knowledge Systems Inc.
___________________________________________
==============55C5DC630BB9715CD9865C32
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<br>This seems like an odd question..
<p>Can you elaborate on why you want this? This looks like
a variation
<br>on a signature scheme...
<p>Do you need fcn_2 to be difficult to compute if you don't know the
<br>set of keys? (if not, just define fcn_1(A, key) = A, and fcn_2(B)
= B).
<br>If the person must not be able to compute fcn_2 easily without knowing
<br>the possible keys, you have to make fcn_2 take a set of keys as input.
<br>
<p>Anton
<br>
<br>
<p>Niall Parker wrote:
<blockquote TYPE=CITE>Hello,
<p>I'm looking to find some information about defining a function which
<br>can be computed initially in one direction using a key, then checked
<br>in the reverse direction without the key, ie:
<p> B = fcn_1(A,key)
<br> A = fcn_2(B)
<p>but fcn_2 is not invertible (can't compute B from A without key)
<p>I've perusing the FAQs and web pages but haven't seen anything yet,
<br>perhaps someone is aware of relevant places to look ? (hopefully this
<br>is a trivial problem I'm too thick to notice the solution for ;)
<p>Thanks.
<p>
... Niall</blockquote>
<pre>--
___________________________________________
Anton Stiglic <[EMAIL PROTECTED]>
Jr. developer & specialist in cryptology.
Zero-Knowledge Systems Inc.
___________________________________________</pre>
</html>
==============55C5DC630BB9715CD9865C32==
------------------------------
From: [EMAIL PROTECTED] (Scott Nelson)
Subject: Re: Are thermal diodes as RNG's secure
Reply-To: [EMAIL PROTECTED]
Date: Tue, 14 Dec 1999 20:20:33 GMT
On Tue, 14 Dec 1999 17:09:31 GMT, Tim Tyler <[EMAIL PROTECTED]> wrote:
>Scott Nelson <[EMAIL PROTECTED]> wrote:
>: On Mon, 13 Dec 1999 16:58:56 GMT, Tim Tyler <[EMAIL PROTECTED]> wrote:
>:>Bill Unruh <[EMAIL PROTECTED]> wrote:
>:>: [EMAIL PROTECTED] (Lincoln Yeoh) writes:
>
>:>[removing biases from hardware sources of randomness]
>:>
>:>: ]How can we cook such output?
>:>
>:>: Eg, if you suspect that the output is not really random, but is
>:>: "partially" random, so that say a fraction f of the information really
>:>: is random,then you could feed say 128/f bits into a hash function like
>:>: MD5 and use the 128 bits of output. That output should be "fully"
>:>: random.
>
>[hash functions for distilling randomness]
>
>:>If any practical hash were as good at distilling entropy as this,
>:>it would be a miracle.
>
>: If the hash produced a random (rather than evenly distributed)
>: 128 bits based on the input 128/f bits, then the number of states
>: would only be 1/e*2^128. That sounds bad, but it's less than
>: 2 bits off of perfect, or under 2% error. Secure hash
>: functions aren't perfect, but they are very good.
>
>My problem with what you write here is that I doubt your premise.
>
>***IF*** the hash produces a random 128 bits based on the input
>(i.e. from a huge lookup table of high quality, hardware-generated
>random numbers) - it would no doubt be as good as you say.
>
>However, hash functions can't /possibly/ employ such huge tables -
>they have to simulate them using mathematical techniques.
>
>I'd be happy to imagine a uniformly distributed hash function - and
>it would still be likely to fail to create fully random output - even
>from a mountain of biased input.
>
>The comparison with pseudo-random number generators still seems
>appropriate to me:
>
>PRNG output has a lower entropy than a real random stream. The entropy of
>the stream is only that of the original seed.
>
>Similarly, hashes based on pseudo-random functions - rather than genuinely
>random ones - will not do as good a job of concentrating the entropy as
>they could do.
>
>The original data is patterned (that's why we're using a hash in the
>first place - to introduce more randomness).
>
>The hash itself is also patterened (as it's made up of a relatively small
>function, rather than a huge random LUT). If the types of pattern happen
>to be anything other than completely orthogonal, that might cause
>problems for the ability of the hash to concentrate the entropy from the
>message.
>
Consider a small, analyzable case, the 1 bit hash XOR.
Further assume a source which produces a 1 with
probability .12 and a zero with probability .88,
but is otherwise unbiased and independent.
(No it's not realistic, but it's analyzable.)
The entropy in the biased-bit is slight over .5,
(f=.5) so we need two (1/.5) biased-bits to get
one good bit. Two bits have the following probabilities:
00 .7744
11 .0144
01 .1056
10 .1056
So the output is a 1 .2112 and a 0 .7888, for a total
entropy of about .74 That's not 1.00, but it's really
not bad all things considered.
It's possible to do a similar analysis for 4 bit CRC
with 8 biased bits (.82 bits per bit) and for a 16 bit
CRC (about .9) From this we can make a generalization;
"larger hashes work better."
MD5 is a lot harder to analyze, but it's clear
that it's larger than a 16 bit CRC, which is better
than 90%
Secure hash functions aren't perfect.
But they're very good.
More to the point, they're a lot better than our
estimations of f.
Scott Nelson <[EMAIL PROTECTED]>
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: Why no 3des for AES candidacy
Date: Tue, 14 Dec 1999 15:20:59 -0500
==============DD145211EF7AF9F652CC45C8
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
The trivial point is that if you change DES key expansion function, or
anything
about DES, it's no longer DES. DES is a standard, to follow the standard
you
have to implement exactly what the standard defines. So to the question can
3DES be made into a 128bit key algo, or a 198 bit algo, the answer is yes
if
you modify it (but it would longer be called 3DES). And the answer to the
question
can 3DES be a candidate for AES, the answer is no because, for one thing, it
does
not have the proper key size.
Any refutation of the above statements is simply nonsens and confuses
people...
Anton
Pelle Evensen wrote:
> Anton Stiglic wrote:
> > Uri Blumenthal wrote:
> > > > >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.
> >
> > Hunn??? 3DES uses DES, 3 times, with 3 different keys. The result
> > is a cipher that has a key of size 3*(size of key for DES) = 168 bits.
> > If we proove that the security given by this method is just 2 bits, the
> > cipher still remains a cipher that needs uses a 168-bit key.
> > I would realy be interested in seeing you come up with a 72 bit key
> > 3-DES. Do you have any idea of what you are talking about?
>
> I would assume he has;
> http://www.research.att.com/~smb/papers/ides.ps
>
> (You can replace the usual DES key schedule and make up your own
> round keys.)
>
> Cheers,
> Pell
--
___________________________________________
Anton Stiglic
Jr. developer & specialist in cryptology.
Zero-Knowledge Systems Inc.
___________________________________________
==============DD145211EF7AF9F652CC45C8
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
The trivial point is that if you change DES key expansion function, or
anything
<br>about DES, it's no longer DES. DES is a standard, to follow the
standard you
<br>have to implement exactly what the standard defines. So to the
question can
<br>3DES be made into a 128bit key algo, or a 198 bit algo, the answer
is yes if
<br>you modify it (but it would longer be called 3DES). And the answer
to the question
<br>can 3DES be a candidate for AES, the answer is no because, for one
thing, it does
<br>not have the proper key size.
<br>Any refutation of the above statements is simply nonsens and confuses
people...
<p>Anton
<br>
<br>
<p>Pelle Evensen wrote:
<blockquote TYPE=CITE>Anton Stiglic wrote:
<br>> Uri Blumenthal wrote:
<br>> > > >One good reason:
<br>> > > >The AES is supposed to support the following different key sizes:
<br>> > > > 128, 192, 256
<br>> > > >
<br>> > > >You can see why 3-DES, with it's single sized 168 bit key,
<br>> > > >does not fit in this categorie.
<br>> >
<br>> > No I can't - there are ways to securely make key of any length
<br>> > (from 64 bis to 768*3 bits) for 3DES.
<br>>
<br>> Hunn??? 3DES uses DES, 3 times, with 3 different keys.
The result
<br>> is a cipher that has a key of size 3*(size of key for DES) = 168
bits.
<br>> If we proove that the security given by this method is just 2 bits,
the
<br>> cipher still remains a cipher that needs uses a 168-bit key.
<br>> I would realy be interested in seeing you come up with a 72 bit key
<br>> 3-DES. Do you have any idea of what you are talking about?
<p>I would assume he has;
<br><a
href="http://www.research.att.com/~smb/papers/ides.ps">http://www.research.att.com/~smb/papers/ides.ps</a>
<p>(You can replace the usual DES key schedule and make up your own
<br> round keys.)
<p>Cheers,
<br> Pell</blockquote>
<pre>--
___________________________________________
Anton Stiglic <[EMAIL PROTECTED]>
Jr. developer & specialist in cryptology.
Zero-Knowledge Systems Inc.
___________________________________________</pre>
</html>
==============DD145211EF7AF9F652CC45C8==
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: Why no 3des for AES candidacy
Date: Tue, 14 Dec 1999 15:24:05 -0500
==============EC35C53E4048F7EB4C98ED5A
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
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...
Anton
==============EC35C53E4048F7EB4C98ED5A
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Uri Blumenthal wrote:
<blockquote TYPE=CITE>
<p>> Do you have any idea of what you are talking about?
<p>Do you have any brains to comprehend what I'm talking about?
<br>--
<br>Regards,
<br>Uri
<br>-=-=-==-=-=-
<br><Disclaimer></blockquote>
Gee, you are a smart ass Uri Blumenthal, very polite person as
<br>well! Do you have any matters at all? You got a paper written
and
<br>you think you are a genius. Read my other reply to see why your
<br>objection was nonsens and just confuses people...
<br>
<p>Anton
<pre></pre>
</html>
==============EC35C53E4048F7EB4C98ED5A==
------------------------------
Date: Tue, 14 Dec 1999 15:31:05 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Better encryption? PGP or Blowfish?
Tom St Denis wrote:
> In article <[EMAIL PROTECTED]>,
> "Trevor Jackson, III" <[EMAIL PROTECTED]> wrote:
> >
> > Not always. Depends on the message space.
> >
> > Consider the reponse to a proposed contract. It can be encoded in a
> bit.
> > Any boolean message has this property. Some messages have even less
> > information.
> >
> > Consider the case of a "Go!" command. The message itself contains
> zero
> > information. The recipient is waiting for exactly this message and no
> > other. So the message consists of zero bits of plaintext plus
> whatever
> > authentication is necessary.
> >
> > Now consider the data rate of a channel used to transmit the Go!
> message.
> > Normally it has no data flowing through it, but there's a tacit
> streams of
> > "Not Yet!" messages that match the sampling rate of the receiver.
> This data
> > stream has no bits in it at all. Perhaps it has a stream of noise to
> > reassure the receiver that a mesage hasn't been missed. But there's
> no
> > information in the noise. It's just noise.
> >
> > Tough to crack such virtual messages.
>
> Ok true, I would not attack a message with 'Go!' in it. I would attack
> the messages that described what they should go do.
Of course. I'm sure you meant "real" messages with some meaty text on which
to chew. Still, inspecting the extrema is always a good way to test general
propositions.
------------------------------
Date: Tue, 14 Dec 1999 15:33:30 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Why no 3des for AES candidacy
Anton Stiglic wrote:
> The trivial point is that if you change DES key expansion function,
> or anything
> about DES, it's no longer DES. DES is a standard, to follow the
> standard you
> have to implement exactly what the standard defines. So to the
> question can
> 3DES be made into a 128bit key algo, or a 198 bit algo, the answer is
> yes if
> you modify it (but it would longer be called 3DES). And the answer to
> the question
> can 3DES be a candidate for AES, the answer is no because, for one
> thing, it does
> not have the proper key size.
> Any refutation of the above statements is simply nonsens and confuses
> people...
OIC. It wasn't obvious to me that you were speaking Ex Cathedra.
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: Why no 3des for AES candidacy
Date: Tue, 14 Dec 1999 15:29:40 -0500
==============782AE59D8FB47E366E52CE4F
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
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.
It's not misleading, because to get 112 bits of entropy,
you must provide it with a 168 bit key.
For example, give it a key with 112 bits of randomnes,
with 56 bits of 0's let's say. You think that 3DES
is gonna be as strong as if you would have gave it 168 bits
of randomness for a key? It won't....
If you say to a programmer, use this 3DES protocole, it uses
a 112 bit key, what do you thing the programmer will do,
he will gatter 112 bits of randomness and give it that, the
protocole won't be secure at all!
So 3DES is a 168 bit key block cipher, because you have to
provide 168 bit of randomness for a key for the protocole to be
secure. The security of 3DES is beleived to be 112 bits,
that's a different thing...
Anton
==============782AE59D8FB47E366E52CE4F
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Tim Wood wrote:
<blockquote TYPE=CITE>Uri Blumenthal wrote in message
<[EMAIL PROTECTED]>...
<br>>> >> Why isn't 3des being considered for the AES?
<p><snip>
<p>>> >One good reason:
<br>>> >The AES is supposed to support the following different key sizes:
<br>>> > 128, 192, 256
<br>>> >
<br>>> >You can see why 3-DES, with it's single sized 168 bit key,
<br>>> >does not fit in this categorie.
<br>>
<br>>No I can't - there are ways to securely make key of any length
<br>>(from 64 bis to 768*3 bits) for 3DES.
<br>>
<br>>> of course it's effective key length (strength) is 112bit not 168bit...
<br>>
<br>>In general - this is incorrect. In particular, it HIGHLY depends
<br>>on the key schedule and how the DES engine is employed.
<br>>
<br>>See "A Better Key Schedule for DES-like Ciphers" paper on
<br>><<a
href="http://www.research.att.com/~smb/papers/index.html">http://www.research.att.com/~smb/papers/index.html</a>>
<p>Why Is it incorrect in general? There are lower strength attacks, but
even
<br>then I think it would be incorrect to quote 3DES as 168bits ? It is
<br>missleading.</blockquote>
<pre>It's not misleading, because to get 112 bits of entropy,</pre>
<pre>you must provide it with a 168 bit key.</pre>
<pre>For example, give it a key with 112 bits of randomnes,</pre>
<pre>with 56 bits of 0's let's say. You think that 3DES</pre>
<pre>is gonna be as strong as if you would have gave it 168 bits</pre>
<pre>of randomness for a key? It won't....</pre>
<pre>If you say to a programmer, use this 3DES protocole, it uses</pre>
<pre>a 112 bit key, what do you thing the programmer will do,</pre>
<pre>he will gatter 112 bits of randomness and give it that, the</pre>
<pre>protocole won't be secure at all!</pre>
<pre>So 3DES is a 168 bit key block cipher, because you have to</pre>
<pre>provide 168 bit of randomness for a key for the protocole to be</pre>
<pre>secure. The security of 3DES is beleived to be 112 bits,</pre>
<pre>that's a different thing...</pre>
<pre></pre>
<pre>Anton</pre>
</html>
==============782AE59D8FB47E366E52CE4F==
------------------------------
From: Christoffer =?iso-8859-1?Q?Lern=F6?= <[EMAIL PROTECTED]>
Subject: How easy would this encryption be to crack? - revised
Date: Tue, 14 Dec 1999 21:24:51 +0100
> keya & keyb would have different length, for example keya would be 1
> byte longer than keyb
>
> Too easy to crack?
Oops.. saw the flaws myself.
What about this:
(the class itself holds the two key arrays (byte[]) meKeyA and meKeyB,
there are also
two looking variables, meSpin (getting its starting value from meKeyA &
meKeyB)
and meSpin2 with starting value 0)
To decode a byte b:
--
byte currenta=meKeyA[mePosA++];
int rot=currenta%8;
if (rot<0)
{
rot=-rot;
}
if (mePosA>=meKeyA.length)
{
mePosA=0;
}
currenta+=meSpin;
byte currentb=meKeyB[mePosB++];
if (mePosB>=meKeyB.length)
{
mePosB=0;
}
meSpin+=currentb+meSpin2;
meSpin2++;
while (meSpin>1973)
{
meSpin-=1973;
}
if (meSpin2>666)
{
meSpin2=currenta;
}
int torot=(byte)((b^currentb)^currenta);
if (torot<0)
{
torot=256+torot;
}
torot=(((torot<<rot)&0xff) | (torot>>(8-rot)));
return (byte)torot;
--
Inputing zeros I checked the distribution of numbers
outputed and it seemed pretty evenly distributed..
/Christoffer
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: Why no 3des for AES candidacy
Date: Tue, 14 Dec 1999 15:34:58 -0500
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
------------------------------
** 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
******************************
