Cryptography-Digest Digest #60, Volume #14 Mon, 2 Apr 01 06:13:00 EDT
Contents:
Re: AES VS. DES (Benjamin Goldberg)
Re: AES VS. DES (Pascal Junod)
Re: Data dependent arcfour via sbox feedback (Benjamin Goldberg)
Re: Malicious Javascript in Brent Kohler post (was: Re: Who is Brent K (Benjamin
Goldberg)
Re: Estimation of the keygen time (Bob Deblier)
Re: AES VS. DES ("Douglas A. Gwyn")
__(Preliminary Program) EuroCrypt 2001, May 6 - 10 (kctang)
Favor needed from intl IE 5.0 user, please test this SSL site (Paul Rubin)
Re: conferences? (Paul Rubin)
Re: AES VS. DES (Pascal Junod)
Re: AES VS. DES (Volker Hetzer)
Re: AES VS. DES ("Brian Gladman")
Re: Data dependent arcfour via sbox feedback ("Bryan Olson")
Re: Data dependent arcfour via sbox feedback ("Bryan Olson")
Re: DES key replacement. (Paul Schlyter)
----------------------------------------------------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: AES VS. DES
Date: Mon, 02 Apr 2001 05:59:45 GMT
Latyr Jean-Luc FAYE wrote:
>
> Hello,
> It's the 2nd time I post this message.
> I would like to know what are the difference between AES and its
> precursor DES.
DES uses a Feistel structure, AES uses a ... I dunno what it's called,
precisely, it's wierd :)
DES has 56 bits of security, AES is believed to have 128, 192, or 256
bits of security.
DES uses 64 bit blocks, AES uses 128 bit blocks. Rijndael can use
larger blocks if desired.
DES is pretty fast in hardware, but godawful slow in software. AES is
reasonably fast in both.
> What are the advantage of AES vs DES.
AES has bigger blocksize, bigger keysizes, and is faster.
> The first time, I got a nice answer of someone on the NG with a link
> to his page about AES and I learnt lot of stuff.
Perhaps John Savard's crypto site?
http://home.ecn.ab.ca/~jsavard/crypto.htm
To go directly to his rijndael page, use this url
http://home.ecn.ab.ca/~jsavard/crypto/co040801.htm
For stuff about AES, I would recommend
http://www.nist.gov/aes
> But I lost the link. In fact I ma just hoping that anybody having a
> website on AES or knowing a personnal website on AES will give me
> links. May be I will find the one I lost.
If it isn't one of the ones I gave, then try using a search engine.
--
Sometimes the journey *is* its own reward--but not when you're trying to
get to the bathroom in time.
------------------------------
Date: Mon, 2 Apr 2001 08:21:26 +0200
From: Pascal Junod <[EMAIL PROTECTED]>
Subject: Re: AES VS. DES
On Sun, 1 Apr 2001, Brian Gladman wrote:
[snip]
> DES is still a very good cipher that has not been broken but increases
> in ... [snip]
Do you ever read about linear cryptanalysis, differential cryptanalysis ?
I'm not quite sure one can claim that DES is "unbroken"...
A+
Pascal
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
* Pascal Junod, [EMAIL PROTECTED] *
* Laboratoire de Sécurité et de Cryptographie (LASEC) *
* INF 240, EPFL, CH-1015 Lausanne, Switzerland ++41 (0)21 693 76 17 *
* Place de la Gare 12, CH-1020 Renens ++41 (0)79 617 28 57 *
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Data dependent arcfour via sbox feedback
Date: Mon, 02 Apr 2001 06:34:44 GMT
The patent does not apply to the proposed cipher, but for an entirely
different reason than the one Bryan Olson claimed.
The proposed variant combines one single input stream of data with the
internal state of a cryptographic object, and produces as output one
single stream of data (and modifies the object's state).
The Dynamic Substitution patent covers combining two input streams with
each other and with the state of a cryptographic object, and producing
one single output stream (and modifying the object's state).
The difference between the proposal and the patent is the number of
input streams, one versus two.
Here's the proposed modified RC4:
byte x, y, z, sbox[256];
encipher(byte data) {
x = (x + 1) & 255;
y = (y + sbox[x]) & 255;
swap( sbox[x], sbox[y] );
data ^= sbox[(sbox[x] + sbox[y]) & 255] ^ z;
z ^= sbox[data];
return data;
}
decipher(byte data) {
x = (x + 1) & 255;
y = (y + sbox[x]) & 255;
swap( sbox[x], sbox[y] );
data ^= sbox[(sbox[x] + sbox[y]) & 255];
z ^= sbox[data];
data ^= z;
return data;
}
If persons A and B both start with a particular sbox, x, y, z, then A
sends r=encipher(q), then B can calculate q=decipher(r).
Here's an example of Dynamic Substitution:
byte sbox[256], sibox[256];
encipher(byte data1, byte data2) {
byte dataout = sbox[sbox[data1]];
swap( sbox[sbox[data1]], sbox[data2] );
return dataout;
}
decipher(byte data1, byte data2) {
byte temp = sibox[data1];
byte dataout = sibox[temp];
swap( sibox[data1], sibox[sbox[data2]] );
swap( sbox[temp], sbox[data2] );
return dataout;
}
If persons A and B both start with a particular sbox, and B calculates
sibox = sbox^-1, then A sends s=encipher(q,r), then B can calculate
q=decipher(s,r).
Carefully note the number of inputs to each enciphering method.
--
Sometimes the journey *is* its own reward--but not when you're trying to
get to the bathroom in time.
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Crossposted-To: alt.drugs.pot,rec.radio.swap,rec.running,rec.sport.skating.ice.figure
Subject: Re: Malicious Javascript in Brent Kohler post (was: Re: Who is Brent K
Date: Mon, 02 Apr 2001 06:48:21 GMT
Mok-Kong Shen wrote:
>
> those who know me have no need of my name wrote:
> >
> > <[EMAIL PROTECTED]> wrote:
> >
> > >How often would you use scripted mathematical formulae in news
> > >group postings? Creating a web page and linking to it would
> > >probably be a more useful solution.
> >
> > in sci.crypt it might happen quite often, though it's usual for
> > latex to be used. since mathml is nearly unreadable i don't see why
> > anyone would want it, especially since it would mean that html (and
> > other shite) would have to be processed as well.
> >
> > i would _much_ rather see latex than mathml -- you tell me:
> >
> > latex ... x = \frac{-b\pm\sqrt{b^2 - 4ac}}{2a}
> > mathml ...
>
> [snip]
>
> I would also prefer Latex syntax. However, the standard
> group has chosen another approach. Now, one is likely
> to have a browser to process mathml. But not everyone
> is likely to take the trouble to install a Latex system.
Especially since it might be possible to create for one's mail/news
reader some sort of plugin which will do search and replace of latex
math stuff with mathml; it would be disabled by default, but turnonable
at the user's discretion (and be a last step just before sending).
Why suggest this rather than a latex parser? Well, 1, as you say, the
standard group's approach is towards mathml and the like, and 2, it's
much too easy for a parser to interpret something as latex that
shouldn't be, especially if it's inline with normal text. Also it
allows for messages which are multipart/alternative, with the first part
being purely text, with latex for formulae, and the second part html,
with everything except the mathml enclosed in <pre> tags so it looks
like the plaintext part (except for showing formulae instead of
symbols).
--
Sometimes the journey *is* its own reward--but not when you're trying to
get to the bathroom in time.
------------------------------
From: Bob Deblier <[EMAIL PROTECTED]>
Subject: Re: Estimation of the keygen time
Date: Mon, 2 Apr 2001 09:16:02 +0200
<posted & mailed>
Benjamin Goldberg wrote:
> Bob Deblier wrote:
>
>> Try the technique I use in the BeeCrypt crypto library: take a number
>> which is the product of the first N small primes (up to your
>> preference - I use a number which is equal in bitsize to the
>> candidates), and compute the gcd of this number and your prime
>> candidate. If the gcd is one, your candidate has passed all tests in
>> one operation. That should speed up your test.
>
> What is the break even point between your method and trial division?
>
> Surely if we are only testing, eg, small primes 2, 3, and 5, trial
> division will be faster. For what value of N is your method better than
> trial division?
>
I'll have to get back to you later with the result of some more accurate
timings - my best estimate for now is that the break-even occurs after the
first 60 primes for a 1024 bit candidate. The single gcd operation is still
over 100 times faster than a modular exponentiation on the same platform.
I'm in the process of redesigning my gcd operation to make it faster still
- I think I should be able to shave off about 30%.
Sincerely,
Bob Deblier
Virtual Unlimited
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: AES VS. DES
Date: Mon, 02 Apr 2001 07:18:48 GMT
Pascal Junod wrote:
> Do you ever read about linear cryptanalysis, differential
> cryptanalysis ?
> I'm not quite sure one can claim that DES is "unbroken"...
In its intended application, those published attacks are not
effective. However, DES is breakable via exhaustive key
search using current technology. Therefore, except for
compatibility considerations, DES is usually used only in
triple-DES form (3DES), with a key either double or triple
the original size. Probably AES will be retrofitted into
existing applications as a replacement for DES and some
instances of 3DES.
------------------------------
From: kctang <[EMAIL PROTECTED]>
Crossposted-To: sci.math.symbolic,alt.algebra.help
Subject: __(Preliminary Program) EuroCrypt 2001, May 6 - 10
Date: Mon, 02 Apr 2001 15:34:12 +0800
EuroCrypt 2001, May 6 - 10, Innsbruck, Austria
Preliminary Program
===================
http://www.iacr.org/conferences/ec2001/program.html
Official Web site
=================
http://www.ec2001.ocg.at/
--
Communicated by kctang
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Favor needed from intl IE 5.0 user, please test this SSL site
Date: 02 Apr 2001 00:46:21 -0700
If someone out there has an MSIE 5.0 or 5.01 web browser with **40
bit** cryptography (you can check the cryptography strength by looking
at the Help | About screen), or if you have MSIE 5.5 under Windows
2000 with 40 bit cryptography, could you please look at the website:
https://www.maryland.com and then put your mouse over the little
padlock icon and see whether you have a 40 bit or 128 bit connection.
(Note, that says https, not http, since it is an SSL server).
Please either email me the result or post here if you want.
The reason I'm asking this is the cert on that site is being marketed
as an SGC cert, but I don't think the vendor really understands what
that's about. See http://commercelock.register.com for info.
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: conferences?
Date: 02 Apr 2001 01:30:18 -0700
"Tom St Denis" <[EMAIL PROTECTED]> writes:
> How about provably secure against linear and differential attacks? Because
> of the use of multipermutations I know that diffusion is optimal and since I
> use really swell sboxes I have very low dp/lp maxes. This obviously doesn't
> shut the door on other attacks. My cipher can be implemented in about 350
> bytes on an 8-bit mcu (give or take) considering it has 280 byte tables (8x8
> sbox and a 24-byte lut). The idea is to make a cool fast cipher
> specifically for embedded platforms.
How many bytes of ram are needed? How does the speed compare to Skipjack?
Working well on very small processors is one of the few reasons I can
think of to bother designing yet another 64 bit block cipher. There
aren't very many good ones out there.
------------------------------
Date: Mon, 2 Apr 2001 10:31:21 +0200
From: Pascal Junod <[EMAIL PROTECTED]>
Subject: Re: AES VS. DES
On Mon, 2 Apr 2001, Douglas A. Gwyn wrote:
> In its intended application, those published attacks are not
> effective. However, DES is breakable via exhaustive key
> search using current technology.
One can break DES using current technology, one can break DES in labs
using published attacks, I can't sincerely consider that single DES is an
"unbroken" cipher.
A+
Pascal
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
* Pascal Junod, [EMAIL PROTECTED] *
* Laboratoire de Sécurité et de Cryptographie (LASEC) *
* INF 240, EPFL, CH-1015 Lausanne, Switzerland ++41 (0)21 693 76 17 *
* Place de la Gare 12, CH-1020 Renens ++41 (0)79 617 28 57 *
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
------------------------------
From: Volker Hetzer <[EMAIL PROTECTED]>
Subject: Re: AES VS. DES
Date: Mon, 02 Apr 2001 11:35:15 +0200
"Douglas A. Gwyn" wrote:
>
> Pascal Junod wrote:
> > Do you ever read about linear cryptanalysis, differential
> > cryptanalysis ?
> > I'm not quite sure one can claim that DES is "unbroken"...
>
> In its intended application, those published attacks are not
> effective.
What's your definition of "broken"?
There are methods better than exhaustive key search.
Do they not constitute "break"s in the accepted sense?
Greetings!
Volker
--
They laughed at Galileo. They laughed at Copernicus. They laughed at
Columbus. But remember, they also laughed at Bozo the Clown.
------------------------------
From: "Brian Gladman" <[EMAIL PROTECTED]>
Subject: Re: AES VS. DES
Date: Mon, 2 Apr 2001 10:38:01 +0100
"Pascal Junod" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> On Sun, 1 Apr 2001, Brian Gladman wrote:
>
> [snip]
> > DES is still a very good cipher that has not been broken but increases
> > in ... [snip]
>
> Do you ever read about linear cryptanalysis, differential cryptanalysis ?
> I'm not quite sure one can claim that DES is "unbroken"...
The issue here is one of definition.
In principle all keyed block ciphers can be attacked by undertaking an
exhaustive search of their key space so it makes limited sense to claim that
an algorithm is broken if it is vulnerable to this form of attack.
But I agree that you can choose to use this as your definition of 'broken'
if you so wish.
But I choose a different definition - namely that an algorithm is broken if
it is possible, on average, to recover the plaintext without the key with
significantly less effort than would be expected in a brute force key
search.
And it in this sense that I claim that DES is unbroken.
Brian Gladman
------------------------------
From: "nospam"@"nonsuch.org" ("Bryan Olson")
Subject: Re: Data dependent arcfour via sbox feedback
Date: Mon, 02 Apr 2001 09:38:19 GMT
Terry Ritter wrote:
>
>Bryan Olson wrote:
>
>>In article <[EMAIL PROTECTED]>, Terry Ritter wrote:
>>>
>>>Bryan Olson wrote:
>>>>RC4 and the proposed
>>>>modification do not encrypt by substitution of the data
>>>>characters; that's what makes Ritter's patent inapplicable.
>>>
>>>I can only discuss the issue theoretically: I can't speak to either
>>>RC4 or the current proposal.
>>
>>Well, you could if you looked at them.
>
>No, I could not. The coverage of an issued patent is a legal matter,
>not a technical matter, and I would be one of the contesting parties.
Infringement is a legal matter. Whether a technique is the
same as described in a claim is technical and legal matter.
>However, this particular issue seems clear enough for almost anyone to
>investigate quickly, and then form an opinion about what the courts
>are likely to uphold.
Exactly.
>>>However, the Dynamic Substitution claims do not require encryption by
>>>substitution.
>>
>>All the claims on encryption methods require two data
>>sources, the first of which is transformed by substitution
>>to form the output or substitute values.
>
>OK, that's it. I can't make you read; or having read, understand; or
>having understood, accurately represent the facts.
And yet I have.
>The Dynamic Substitution Combiner and Extractor patent covers
>mechanisms which can be useful in cryptography, not necessarily "an
>encryption method."
The technique under discussion is an encryption method and
the question is whether this patent would cover it. On the
subject of reading and understanding consider what "All the
claims on encryption methods" means. Is it,
A) those claims that apply to encryption methods,
or,
B) an assertion that there are no claims on anything
other than encryption methods?
[...]
>I just don't know what could be clearer than an explicit statement in
>the issued patent that combining confusion streams is a reasonable use
>for the patented mechanism.
Which is not what we are discussing here.
>So the claim that: "RC4 and the proposed modification do not encrypt
>by substitution of the data characters; that's what makes Ritter's
>patent inapplicable," is laughably ridiculous and clearly false to
>anyone willing to actually read and understand the patent. We can be
>sure that a court would be so willing.
You also have to read and understand RC4 and the proposed
modification. They fit the model of a stream cipher in which
the plaintext data source is transformed by another data
source. The transformation is not substitution.
--Bryan
------------------------------
From: "nospam"@"nonsuch.org" ("Bryan Olson")
Subject: Re: Data dependent arcfour via sbox feedback
Date: Mon, 02 Apr 2001 09:53:43 GMT
Benjamin Goldberg wrote:
>The patent does not apply to the proposed cipher, but for an entirely
>different reason than the one Bryan Olson claimed.
>
>The proposed variant combines one single input stream of data with the
>internal state of a cryptographic object, and produces as output one
>single stream of data (and modifies the object's state).
The method of combining is to generate a byte from the state
and XOR it in. I took the view that the bytes XOR'ed in
form a data stream.
--Bryan
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: DES key replacement.
Date: 30 Mar 2001 07:02:19 +0200
The original text is a more definite source -- then there won't be
quotes which are both truncated and taken out of context.....
FIPS 46-3 *also* says that 8 of these 64 bits are parity bits, i.e.
they don't contribute to the keyspace, but for somce reason you
failed to quote that.
Many DES implementations don't bother to check the parity bits but
just ignore them.
In article <tNNw6.1914$[EMAIL PROTECTED]>,
Sam Simpson <[EMAIL PROTECTED]> wrote:
> Hey, I'm quoting from NIST....What can be a more definitve source? ;)
>
> --
> Regards,
>
> Sam
> http://www.scramdisk.clara.net/
>
> Frank Gerlach <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
>> Both are right DES uses a 64 bit key, of which 8 are parity. This means
>> that effective length is 56bit.
>>
>> Sam Simpson wrote:
>>
>>> Terry Ritter <[EMAIL PROTECTED]> wrote in message
>>> news:[EMAIL PROTECTED]...
>>>>
>>>> On Wed, 28 Mar 2001 17:06:56 GMT, in <[EMAIL PROTECTED]>,
>>>> in sci.crypt "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
>>>>
>>>>>Yaniv Sapir wrote:
>>>>>> When using DES for encryption of long messages, is it a common
>>>>>> practice to replace the 64-bit key once in a while? If so, how
>>>>>> frequent?
>>>>>
>>>>>No. Standard practice is to use the same key for the entire session.
>>>>
>>>> First, a DES key is 56 bits, not 64.
>>>
>>> To be a fussy bastard (hey, everyone else is here) this statement is
>>> incorrect.
>>>
>>> According to NIST FIPS46-3 for example: "A DES key consists of 64
>>> binary digits......"
>>>
>>> --
>>> Regards,
>>>
>>> Sam
>>> http://www.scramdisk.clara.net/
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: pausch at saaf dot se or paul.schlyter at ausys dot se
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
** 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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
