Cryptography-Digest Digest #83, Volume #14 Thu, 5 Apr 01 17:13:01 EDT
Contents:
How secure is AES ? ("Latyr Jean-Luc FAYE")
Re: Dickson Polynomials? (Stefan Katzenbeisser)
Re: RSA, block size, key space ("Joseph Ashwood")
Re: DES C Source Code ("Latyr Jean-Luc FAYE")
Re: Compression-encryption with a key (newbie)
Re: Compression-encryption with a key (Joe H Acker)
Re: How secure is AES ? (Mike Rosing)
Re: Beginners guide to how encryption algorythms work? (Mouse)
Re: A gift for cryptanalysts (David Wagner)
Re: Comment on SafeBoot's RC5 algorithm ("Tom St Denis")
Re: Beginners guide to how encryption algorythms work? ("Simon Johnson")
Re: Comment on SafeBoot's RC5 algorithm ("Sam Simpson")
Re: Comment on SafeBoot's RC5 algorithm ("Tom St Denis")
Re: Data dependent arcfour via sbox feedback (Terry Ritter)
Re: Dickson Polynomials? ("Tom St Denis")
----------------------------------------------------------------------------
From: "Latyr Jean-Luc FAYE" <[EMAIL PROTECTED]>
Subject: How secure is AES ?
Date: Thu, 5 Apr 2001 17:26:14 +0100
I've read stuff about linear cryptanalysis, differential cryptanalysis and
the weakness of DES with these methods.
What about AES ???
---
Latyr Jean-Luc FAYE
http://faye.cjb.net
------------------------------
Date: Thu, 05 Apr 2001 18:40:19 +0200
From: Stefan Katzenbeisser <[EMAIL PROTECTED]>
Subject: Re: Dickson Polynomials?
Tom St Denis wrote:
> What is a Dickson Polynomial? My web search has not turned up anything
> usefull...
The dickson polynomial g_k(a,x) is defined by the following expressio (TeX-Notation);
k specifies the degree of the polynomial and a is a parameter:
g_k(a,x) = \sum_{i=0}^{\lfloor k/2\rfloor} \frac{k}{k-i}{{k-i}\choose{i}}(-a)^i
x^{k-2i}
The point is now that -- under certain conditions -- Dickson polynomials
induce a permutation of Z_n.
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: RSA, block size, key space
Date: Wed, 4 Apr 2001 12:08:24 -0700
The block size and key space for RSA are actually equivalent. Given a
modulus N your block space is [0,N-1] theoretically. Generally what I do to
avoid any possible backfire, and to minimize the computations is instead of
taking a 1024-bit N and subtracting 1, I instead reduce it to being treated
as a 1024-8 - bit block and use the whole thing, this slightly reduces the
input space, by a factor of ~256, but it prevents having to do any bounds
checking at the input step (it's guarenteed to be smaller). In some cases
you may only want to force the top bit to 0. And in the most common case you
simply encrypt a relatively small value (typically using OAEP), and use that
small value to key a symmetric cipher.
Joe
"John Smith" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> How is block size determined? When one picks a public key and
> figures out the corresponding private key, he now needs to
> encrypts the plaintext. How does one decide what block size to
> use to encrypt the plaintext and how does the receiver know what
> the block size to use to decrypt the ciphertext?
>
> Can one choose a block size without affecting key space?
>
>
> -----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
> http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
> -----== Over 80,000 Newsgroups - 16 Different Servers! =-----
------------------------------
From: "Latyr Jean-Luc FAYE" <[EMAIL PROTECTED]>
Subject: Re: DES C Source Code
Date: Thu, 5 Apr 2001 17:41:09 +0100
I had done a few work on DES two weeks ago for college with an C
implementation.
You can find them at the following URL :
http://mi6.faye.cjb.net/art08/
I don't know if all the links are ok ! Let me know if any problems. I'll
fixed them
Jean-Luc
---
Latyr Jean-Luc FAYE
http://faye.cjb.net
"M.S. Bob" <[EMAIL PROTECTED]> a �crit dans le message news:
[EMAIL PROTECTED]
> Adrian Planinc wrote:
> >
> > > You are going to "analyze and modify" DES? Do you feel qualified to do
so?
> >
> > Yes. I'm doing a Cryptography course at University and essentially
> > understand how the DES works, and now have been set the task to re-write
> > intefaces in a specific way to take input thru stdin on the command line
> > or to encrypt text files on Linux.
>
> So you are not modifing the DES algorithm, just creating a program...
>
> > > http://csrc.nist.gov/publications/fips/fips46-3/fips46-3.pdf
> > > http://www.itl.nist.gov/fipspubs/fip81.htm
> >
> > I found most of these myself...but thanks anyway.....haven't found all
> > of these.....will look at them....:)
> >
> > ********
> >
> > I was merely hoping that there is someone out there who has an
> > academic-like original educational implementaion (this is what I mean by
> > simple) of DES which would be the purest and easiest to analyse and
> > modify, rather than the cumbersome ones I've been fininding which are
> > not pure DES and have particular applications.
>
> http://www.funet.fi/pub/crypt/mirrors/ftp.dsi.unimi.it/docs/des-how-to.txt
> (How to implement the DES)
> http://www.cryptopp.com/ (C++)
> http://www.cs.umbc.edu/~stephens/crypto/minides.c
> http://www.cs.umbc.edu/~stephens/crypto/daglucifer.c
------------------------------
From: newbie <[EMAIL PROTECTED]>
Subject: Re: Compression-encryption with a key
Date: Thu, 05 Apr 2001 13:34:52 -0300
It depends on wich algo you use.
I'm thinking to use another system to compress-encrypt.
New idea.
Tim Tyler wrote:
>
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> : amateur wrote:
>
> :> What I said is "simultaneously".
> :> That does not mean compression then encryption.
> :> At the same time you compress, you encrypt. [...]
> :> Does that system exist?
> :> That is my question.
>
> : Yes. You can also rather tightly combine encryption with
> : compression. [...] If you use Huffman (or adaptive Huffman)
> : compression, the labeling of the tree is at your disposal.
>
> "Huffman encryption" is a fine example of simultaneous
> compression and encryption.
>
> However, it has been argued in the past that on it's own, it's not very
> strong, and an adaptive chosen-plaintexts attack (and probably
> something much less sophisticated) will let you read the Huffman tree
> out of the start of the file.
>
> ISTM that the benefits of mixing compression and encryption together are
> rather minimal. Certainly today it telescopes your choice of compression
> algorithm and your choice of encryption algorithm down to practically
> nothing.
>
> Keying orthodox compression algorithms is unlikely to offer much strength
> - and trying to compress during most conventional types of encryption
> is plainly a dumb idea.
> --
> __________
> |im |yler Try my latest game - it rockz - http://rockz.co.uk/
------------------------------
From: [EMAIL PROTECTED] (Joe H Acker)
Subject: Re: Compression-encryption with a key
Date: Thu, 5 Apr 2001 19:46:28 +0200
amateur <[EMAIL PROTECTED]> wrote:
> What I said is "simultaneously".
> That does not mean compression then encryption.
> At the same time you compress, you encrypt.
> In the process of compression, run the process of encryption.
> Without dictionnary. I stress without dictionnary.
> Does that system exist?
> That is my question.
In OS 9 and higher, Apple seems to use an algorithm they call Apple
Secure Compression (ASC) which does that. I say "seems " because the
information I've found about it is unclear. Some think that they use
FEE, but I don't believe so. I believe they use ASC for file encryption,
RC2 for keychain encryption and FEE for signing.
Anyway, ASC claims to do exactly what you are asking for. I don't know
of any attacks against it, but I highly doubt it is secure enough to be
labelled "strong encryption".
If anyone knows better, please let me know.
Regards,
Erich (erich"at"NOSPAM.snafu.de)
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: How secure is AES ?
Date: Thu, 05 Apr 2001 12:52:09 -0500
Latyr Jean-Luc FAYE wrote:
>
> I've read stuff about linear cryptanalysis, differential cryptanalysis and
> the weakness of DES with these methods.
> What about AES ???
Worm around here and read about it:
http://csrc.nist.gov/encryption/aes/round2/r2anlsys.htm#NSA
Patience, persistence, truth,
Dr. mike
------------------------------
From: Mouse <[EMAIL PROTECTED]>
Subject: Re: Beginners guide to how encryption algorythms work?
Date: Thu, 5 Apr 2001 19:14:52 +0100
Thu, 05 Apr 2001 07:04:07 -0700, John A.
Malley([EMAIL PROTECTED]) wrote...
>
> Mouse wrote:
> >
> > I'm looking for a site with fairly easy to understand explanations of how
> > the encryption works and some of the theory behind it, if possible
> > without too much higher math (I know some is inevitable).
>
> John Savard and Terry Ritter each authored and maintain web sites on
> cryptology that may fit your needs:
>
> Mr. Savard's site is at
> http://fn2.freenet.edmonton.ab.ca/~jsavard/crypto/jscrypt.htm
>
> Mr. Ritter's site is at http://www.io.com/~ritter/
>
> There's also an excellent web site explaining classical ciphers and
> their cryptanalysis at
>
> http://www.fortunecity.com/skyscraper/coding/379/lesson1.htm
>
>
> Hope this helps,
>
> John A. Malley
> [EMAIL PROTECTED]
>
Excellent sites, thanks a lot John.
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: A gift for cryptanalysts
Date: 5 Apr 2001 18:50:39 GMT
Reply-To: [EMAIL PROTECTED] (David Wagner)
Mark Wooding wrote:
>Adding C rather than XORing would fix this good and proper. The carries
>in the addition will square the differential probabilities. This is a
>somewhat ugly patch, though. (I didn't want to use addition here,
>because it makes the cipher too +/*-linear. I still don't.)
I agree. That's pretty scary. :-)
The modified F' function (where we take z odd) is
F'_z(x) = ((x * z) + C) <<< 16
This has lots of structure. If we look mod 2^16 - 1, the rotate
becomes a no-op, and we have
F'_z(x) = z*x + C mod 2^16 - 1.
In fact, if we look mod 2^32 - 1, we have
F'_z(x) = 2^16 * (z*x + C) mod 2^32 - 1.
The modified cipher doesn't break immediately, because the output
of the F' function is mixed with the other half of the block using
XOR, but still, the above property is worrisome, as you say.
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Comment on SafeBoot's RC5 algorithm
Date: Thu, 05 Apr 2001 18:59:48 GMT
"Simon Hunt" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> All (especially Tom!)
>
> finally got around to replying on the message thread : RC5-SAFE? -
SAFEBOOT
> from 9th Sep last year. The quote re the speed was from an old document
and
> is a bit misleading.
>
> The RC5 alg we use has to work in a pre-boot (no DOS even) environment,
and
> is a nice unlooped assembler version of RC5 with cipher-block-chaining
based
> on the sectors. The raw alg works at about 400MB/s (yes, 400 megabytes of
> data per second) on a 1ghz athelon in W32. The pre-boot alg runs at about
> 40MB/s on the same machine. The 6MB/s figure was from a old 486/33
machine.
> So in our product SafeBoot, you don't see any slowdown if you run a
> performance benchmark on it - take my word for it or arrange an eval and
try
> it yourself. Yes, I am saying total hard drive encryption, at 1024 bit,
with
> no slowdown....
400mb/sec rc5? You are full of it. My copy runs at 50mb/sec with 16 rounds
on my 800 mhz athlon.
> you can use whatever key size you like with RC5! who told you otherwise?
> 1024 bits is a nice number (128 bytes) and is easy to handle. Why use
short
> keys if you don't have to?
First off the largest key you can use for RC5-32 is 4*R bytes long where R
is the number of rounds. if R=12 as in your previous case then you can only
use 48byte keys not 128 byte ones.
Second itterative attacks can break RC5 with 12 rounds faster then brute
force for virtually all key sizes.
> the last comment, well - We've been thinking about and using RC5 for about
> 10 years now - so I guess that gives us a bit more experience and
commercial
> know-how than perhaps you on this matter :-)
Well for starters RC5 is not 10 years old, it was invented in 1995. If you
do the math 2001-1995 != 10.
And second by using RC5 in a low round mode and with extra huge keys shows
you don't know what you are peddling.
Tom
------------------------------
From: "Simon Johnson" <[EMAIL PROTECTED]>
Subject: Re: Beginners guide to how encryption algorythms work?
Date: Thu, 5 Apr 2001 20:10:08 +0100
Mouse <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> I'm looking for a site with fairly easy to understand explanations of how
> the encryption works and some of the theory behind it, if possible
> without too much higher math (I know some is inevitable).
Two books... One can be downloaded the other cannot:
"Handbook of Applied Cryptography (HAC)" (downloadable)
"Applied Cryptography"
HAC is more mathematical than Applied Cryptography... both are equally as
good. Its up to you.
Simon.
Simon
------------------------------
From: "Sam Simpson" <[EMAIL PROTECTED]>
Subject: Re: Comment on SafeBoot's RC5 algorithm
Date: Thu, 5 Apr 2001 20:20:12 +0100
Tom St Denis <[EMAIL PROTECTED]> wrote in message
news:Eg3z6.28081$[EMAIL PROTECTED]...
>
> "Simon Hunt" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > All (especially Tom!)
> >
> > finally got around to replying on the message thread : RC5-SAFE? -
> SAFEBOOT
> > from 9th Sep last year. The quote re the speed was from an old document
> and
> > is a bit misleading.
> >
> > The RC5 alg we use has to work in a pre-boot (no DOS even) environment,
> and
> > is a nice unlooped assembler version of RC5 with cipher-block-chaining
> based
> > on the sectors. The raw alg works at about 400MB/s (yes, 400 megabytes
of
> > data per second) on a 1ghz athelon in W32. The pre-boot alg runs at
about
> > 40MB/s on the same machine. The 6MB/s figure was from a old 486/33
> machine.
> > So in our product SafeBoot, you don't see any slowdown if you run a
> > performance benchmark on it - take my word for it or arrange an eval and
> try
> > it yourself. Yes, I am saying total hard drive encryption, at 1024 bit,
> with
> > no slowdown....
>
> 400mb/sec rc5? You are full of it. My copy runs at 50mb/sec with 16
rounds
> on my 800 mhz athlon.
Tom,
That's a damn fast implementation - my own (naive!) implementaion managed
just 15Mb/s on a 700Mhz Ahlon :(. What language is your implementation in?
What compiler are you using? What architecture is it aimed towards? What
performance enhancing optimisations have you applied for your target
platforms?
It would be interesting to see what a optimisation guru (e.g. Dr Brian
Gladman et al) could manage with RC5, and what the RSA optimised
implementation managed. Wie Dai manages just 40Mb/s (on a Celeron 850) -
but I guess that's cross-platform and not optimised for the target
platform.....
<SNIP>
--
Regards,
Sam
http://www.scramdisk.clara.net/
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Comment on SafeBoot's RC5 algorithm
Date: Thu, 05 Apr 2001 20:12:19 GMT
"Sam Simpson" <[EMAIL PROTECTED]> wrote in message
news:SB3z6.5316$[EMAIL PROTECTED]...
> Tom St Denis <[EMAIL PROTECTED]> wrote in message
> news:Eg3z6.28081$[EMAIL PROTECTED]...
> >
> > "Simon Hunt" <[EMAIL PROTECTED]> wrote in message
> > news:[EMAIL PROTECTED]...
> > > All (especially Tom!)
> > >
> > > finally got around to replying on the message thread : RC5-SAFE? -
> > SAFEBOOT
> > > from 9th Sep last year. The quote re the speed was from an old
document
> > and
> > > is a bit misleading.
> > >
> > > The RC5 alg we use has to work in a pre-boot (no DOS even)
environment,
> > and
> > > is a nice unlooped assembler version of RC5 with cipher-block-chaining
> > based
> > > on the sectors. The raw alg works at about 400MB/s (yes, 400 megabytes
> of
> > > data per second) on a 1ghz athelon in W32. The pre-boot alg runs at
> about
> > > 40MB/s on the same machine. The 6MB/s figure was from a old 486/33
> > machine.
> > > So in our product SafeBoot, you don't see any slowdown if you run a
> > > performance benchmark on it - take my word for it or arrange an eval
and
> > try
> > > it yourself. Yes, I am saying total hard drive encryption, at 1024
bit,
> > with
> > > no slowdown....
> >
> > 400mb/sec rc5? You are full of it. My copy runs at 50mb/sec with 16
> rounds
> > on my 800 mhz athlon.
>
> Tom,
>
> That's a damn fast implementation - my own (naive!) implementaion managed
> just 15Mb/s on a 700Mhz Ahlon :(. What language is your implementation
in?
> What compiler are you using? What architecture is it aimed towards? What
> performance enhancing optimisations have you applied for your target
> platforms?
Mine is in unrolled x86 assembler where each round takes 4 instructions... I
did the key schedule too but the key schedule didn't work. The actual
cipher seems to work though.
Tom
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Data dependent arcfour via sbox feedback
Date: Thu, 05 Apr 2001 20:32:26 GMT
On Thu, 05 Apr 2001 07:23:55 GMT, in
<[EMAIL PROTECTED]>, in sci.crypt Benjamin Goldberg
<[EMAIL PROTECTED]> wrote:
>Terry Ritter wrote:
>>
>> On Wed, 04 Apr 2001 19:53:09 -0700, in
>> <[EMAIL PROTECTED]>, in sci.crypt Bryan Olson wrote:
>[snip]
>> >You also went through the claim and showed DES obviously
>> >does't match. Shouldn't this algorithm be handled the same
>> >way?
>>
>> Yes, it should and was. DES is not a substitution table.
>
>What are smoking, and can I have some? DES is most certainly a
>substitution,
Really? DES is just the same as a substitution table? You know this
mathematically? Can you prove it?
Really?
Are you sure?
Well, interesting.
Because *I* can prove that DES is *NOT* a substitution table as
expected in the Dynamic Substitution patent. In particular, the DES
"table" cannot be initialized to be non-invertible:
"The combiner can also be used to combine two pseudo-random confusion
streams into a more-complex confusion stream. In this case, extraction
may be unnecessary and so the combiner substitution tables need not be
invertible."
>though not a simple table. However, it *can* be modeled
>as a [64x64 bit] table.
Gee, I thought you were one of those guys who is amused by all the
silly patents granted by the PTO. Now you want to interpret a patent
in the context of a 2**64-element table. Can you say anti-gravity?
Faster-than-light? Perpetual motion?
Let me see it work.
>Any change in the DES key permutes the table
>which the DES algorithm models. Thus, key feedback mode can be
>considered prior art to Dynamic Substitution.
And so we have yet *another* expert in patent law, one most willing to
lend his expertise to anyone who will listen. His attitude is: "Let
the chips fall where they may." He thinks nothing of damaging the
reputation of an issued patent.
Perhaps that is because he obviously knows so much more than those who
invented, constructed, and allowed the patent in the first place, even
though that was a complex and time-consuming formal legal process.
Why should such an entity ever consider that he could be wrong, for
how could that ever happen?
Whump! [The sound of Hell freezing over.]
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Dickson Polynomials?
Date: Thu, 05 Apr 2001 20:52:30 GMT
"Stefan Katzenbeisser" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Tom St Denis wrote:
>
> > What is a Dickson Polynomial? My web search has not turned up anything
> > usefull...
>
> The dickson polynomial g_k(a,x) is defined by the following expressio
(TeX-Notation);
> k specifies the degree of the polynomial and a is a parameter:
>
> g_k(a,x) = \sum_{i=0}^{\lfloor k/2\rfloor}
\frac{k}{k-i}{{k-i}\choose{i}}(-a)^i x^{k-2i}
Can you write this just using ascii math? i.e ^ for exponents, +/*- etc..?
Tom
------------------------------
** 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
******************************
