Cryptography-Digest Digest #23, Volume #10 Tue, 10 Aug 99 13:13:03 EDT
Contents:
What's up with CAST-256 ([EMAIL PROTECTED])
Quantum info? (DJohn37050)
Re: Software trojan-horse DLLs (was Re: How to keep crypto DLLs Secure?) (John
McDonald, Jr.)
Re: Construction of permutation matrix (Patrick Juola)
Re: Techweb crypto comedy... ([EMAIL PROTECTED])
Re: AES finalists to be announced ([EMAIL PROTECTED])
Re: NIST AES FInalists are.... ([EMAIL PROTECTED])
Power analysis of AES candidates ("William Whyte")
Re: NIST AES FInalists are.... ([EMAIL PROTECTED])
Re: NIST AES FInalists are.... (John Savard)
Re: Academic vs Industrial (John Savard)
Re: NIST AES FInalists are.... ([EMAIL PROTECTED])
Re: Techweb crypto comedy... (vincent)
Re: Quantum info? (David A Molnar)
Re: Techweb crypto comedy... (John Myre)
Re: What's first? (Gabriel Belingueres)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: What's up with CAST-256
Date: Tue, 10 Aug 1999 13:36:04 GMT
Has any cryptographic attacks been made against CAST-64/128 or the AES
canditate (well no more) CAST-256?
>From what I read in AC about CAST-64 that it's immune to iterative
attacks...
If CAST-256 is as strong as the paper suggests it could be the analogy
to 3DES in AES (slow but secure).
Also is it possible to generalize the structure of CAST-256 to modify
two words per round (either like RC6 or Twofish)? This could reduce
the rounds required to 16 or 20 from 48 rounds. Possibly like
for i = 0 to 15
B = B xor R[4i]
D = D xor R[4i + 1]
(B,D) = PHT(B,D)
A = A xor F(B <<< R[4i + 2])
C = C xor F(D <<< R[4i + 3])
(B,C,D,A) = (A,B,C,D)
next i
Where R is an array of 32-bit subkeys (in the 4-tupples the 3rd and 4th
subkeys are 5-bits each). It would include pre/post whitening as
well. All the operations are relative simple (xors and additions).
The slowest step would be the F() function (and rotations). This would
however be much quicker then CAST-256 (probably around 500 cycles/block
or so on a 586, just a guess). The rotation could apply to the first
two steps instead of the F() functions argument, this would be faster
(since B would already be in a register). I question the use of the
same F() function for both words though the rotation should prevent
alignment issues (characteristics going in).
Just an idea...
Tom
--
PGP 6.0.2i Key
http://mypage.goplay.com/tomstdenis/key.pgp
PGP 2.6.2 Key
http://mypage.goplay.com/tomstdenis/key_rsa.pgp
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Quantum info?
Date: 10 Aug 1999 13:53:52 GMT
Can anyone list refs to quantum computing as it relates to crypto?
Thanks,
Don Johnson
------------------------------
From: [EMAIL PROTECTED] (John McDonald, Jr.)
Subject: Re: Software trojan-horse DLLs (was Re: How to keep crypto DLLs Secure?)
Date: Tue, 10 Aug 1999 14:16:39 GMT
On Mon, 09 Aug 1999 19:49:21 -0700, "John E. Kuslich" <[EMAIL PROTECTED]>
wrote:
>Exactly right on the last paragraph.
>
>The point is, in Windows, or more precisely, on the PC there is NO
Actually, you're statement was correct the first time... (On
Windows...) Using Linux allows for security of libraries... (But
obviously not DLLs, since it does not use them per se.)
There is viable security on *nixs..
Hope this helps.
---
John K. McDonald, Jr. Alcatel, USA
[EMAIL PROTECTED]
--
"I speak for me and not this company"
TO SPAMMERS:
Please note important defininitions:
The Telephone Consumer Protection Act
of 1991, Title 47, Chapter 5,
Subchapter II, Section 227.
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: Construction of permutation matrix
Date: 10 Aug 1999 10:20:55 -0400
In article <[EMAIL PROTECTED]>,
wtshaw <[EMAIL PROTECTED]> wrote:
>In article <7ond2g$8kg$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
>(Patrick Juola) wrote:
>
>> In article <[EMAIL PROTECTED]>,
>> wtshaw <[EMAIL PROTECTED]> wrote:
>> >In article <[EMAIL PROTECTED]>, "Douglas A. Gwyn" <[EMAIL PROTECTED]>
>wrote:
>> >
>> >> wtshaw wrote:
>> >> > > it is the amount
>> >> > > of information in the simplest nontrivial discrete choice (Boolean,
>> >> > > YES/NO).
>> >> > Which is only a small part of what logic can be involved in choices.
>> >> > Trying to make everything in to yes/no is left to the uneducated and the
>> >> > legal profession.
>> >>
>> >> SIMPLEST. SIMPLEST. SIMPLEST.
>> >
>> >Wait just a dang fangle minute here pardner. If a choice is not simply
>> >yes or no, it is not a simple bit choice.
>>
>> No, but it can be modelled as a collection of simple bit choices.
>>
>Not always in choice-complete manner, as when you need five choices, you
>must allow for eight.
Not if you're doing the five-fold choice repeatedly. Suitable coding
will allow a stream of equiprobable elements from the set 1..5 to
be coded in the optimal number of bits. You simply amortize the extra
bit-fraction from this choice to the next one.
1960's technology....
-kitten
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Techweb crypto comedy...
Date: Tue, 10 Aug 1999 13:37:22 GMT
In article <[EMAIL PROTECTED]>,
fungus <[EMAIL PROTECTED]> wrote:
>
>
> Just pulled from the techweb.com news:
>
> <referring to AES>
>
> "The proposed codes are far more robust than the
> existing Federal Information Processing Standard
> Digital Encryption System (DES), which has encryption
> key sizes of 128, 192 and 256 bits. The new codes are
> virtually unbreakable with as many as 34035 possible
> keys, according to sources. "
>
> Anybody have the slightest idea where the number "34035"
> came from?
Typo? Although 34035 keys is quite a bit ... :)
Tom
--
PGP 6.0.2i Key
http://mypage.goplay.com/tomstdenis/key.pgp
PGP 2.6.2 Key
http://mypage.goplay.com/tomstdenis/key_rsa.pgp
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: AES finalists to be announced
Date: Tue, 10 Aug 1999 14:55:47 GMT
In article <7onbdb$1vg0$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
>
> You are very full of your self aren't you. As I have said before the
whole
> AES is to promote a method very similar to the clipper chip. The
winner
> will be a method that the NSA can easily break. But that is not easily
> breakable by the non spy types. I for one could have written several
methods
> but only insiders can really enter the phony contest. If they allowed
anyone
> to enter with a TEXT file listing instead of PS then I would have been
in. But
> I would not have entered with a much weaker method than scott19u since
it
> is to secure of a method and to slow to have a chance to win. Sure
they had
> a few token poor ones to make it look fair but it is not fair. I
still think
> you have a very good chance to win but not because it is really
secure.
> The above thoughts are my own. "good ciphers are designed by good
> cryptanalysts" to me the good abive means NSA breakable. The good I
would like
> to see is good in that the NSA can not break it. You of all people
should know
> that the US government would not let a standard become available
unless the
> NSA could read the messages easily.
>
> David A. Scott
David,
I'm confused. Do you have any proof that the government
can break any of the AES candiates in less than brute force?
If so, why would you hold that information back?
Marc
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: NIST AES FInalists are....
Date: Tue, 10 Aug 1999 15:25:37 GMT
In article <7op365$5ct$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (Bruce Schneier) wrote:
> > The envelope, please... The five AES finalists are Mars, RC6,
> > Rijndael, Serpent, and Twofish.
>
> eegad. How did MARS make it? It's gross complex and ugly. The rest
of
> the candidates I agree with.
MARS is far easier to code than Twofish.
>
> I think though like many have said AES should be a family of
> algorithms. One should be able to pick 'fast' but modestly less
secure
> (say work factor off by a couple factors). And 'slow' but secure for
> the keysize picked. Also good smartcard and hardware ciphers should be
> part of AES. If a cipher is not good for some of the departments why
> put it there?
Selecting multiple algorithms would diminish the trust in any
particular algorithm.
>
> Personally I think the top two ciphers should be RC6 and Twofish. My
> rational is that RC6 is simple and based on the design principles of
> RC5. Although 'fixed-points' have been found in the quadratic
function
> I don't see that as a security compromise. Twofish was just designed
> by some really smart people. I trust their ability, plus Twofish is
As opposed to MARS? I suppose that Don Coppersmith doesn't count as a
distinguished cryptanalyst.
> rather efficient and compact. Both are suitable for hardware as well
> as smartcards as well as popular x86 type computers which dominate the
> market.
>
> Good luck Twofish and RC6 teams!!!
>
> Tom
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: "William Whyte" <[EMAIL PROTECTED]>
Subject: Power analysis of AES candidates
Date: Tue, 10 Aug 1999 16:13:59 +0100
There seems to be a discrepancy between Biham and Shamir's paper on
Power Consumption Analysis from the second AES conference, and the
discussion of that paper in NIST's Round 1 report (currently available
from http://csrc.nist.gov/encryption/aes/round1/r1report.pdf).
Biham and Shamir's paper (available from, among other places,
http://csrc.nist.gov/encryption/aes/round1/conf2/papers/biham3.pdf)
seems to state that, of the five finalists, Rijndael is more
vulnerable than the others to their attack, and the other four
are about as vulnerable as each other (it even explicitly says,
of Serpent, "Thus, it is expected that (as in the case of Mars and
RC6), it will not be easy to derive useful information on the key
from the Hamming weights of the results."). But in NIST's
discussion (section 2.5.3.1), they classify Rijndael, MARS and RC6
as having "lesser implicit weaknesses" and Serpent and Twofish
as having "no weakness", with no reference given other than
Biham and Shamir's paper.
Can anyone shed any light on this?
Cheers,
WIlliam
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: NIST AES FInalists are....
Date: Tue, 10 Aug 1999 15:34:32 GMT
In article <7op74n$7vg$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> In article <7op5ke$711$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
<<Snipped some stuff>>
> > 3. This is what I like most about the cipher, the layaring of
rounds.
> > MARS has three layars, forward mixing, cryptographic core, and
> backwards
> > mixing. The mixing of structures was done to prevent certain types
of
> > analysis that bypass the first few rounds. (I hope I quoted this
> > correctly from IBM) Also, it should make any analysis harder to
break
> > it.
>
> Well that is true. but if there are weaknesses in either
> forward/backward mixing phase then it's not. Technically both RC6 and
> Twofish have three layers each as well. They both have a pre-white,
> mixing then a post-white. The pre/post white in Twofish is more
> complete though (all of the input is whiten).
Your first sentence is so flawed from a logical perspective that I
won't comment further. It's pretty much like this:
->Bob is male.
"Well that is true. but if Bob is female then it's not"
Whitening does not count, in and of itself, as a mixing phase. Read the
paper on DESX to find out why all of the input does not need to be
whitened.
>
> > As for ugly, I though it was very nice actually. IBM explained
> > everything very well in there proposal and it all seems to make very
> > good sense.
>
> Maybe but it's still rather complex as compared to RC6. Good
> algorithms don't need to be complicated. Twofish is more complicated
> then RC6 but any competent security professional should be able to >
code it. (I haven't tried so I don't know).
Your comment is frankly laughable. Twofish is significantly more
complex to code *efficiently* than MARS. Evidently, you haven't tried
coding either of them.
>
> > I think RC6 is one of the top ciphers on everybody's list. The
> ciphers
> > I was most impressed with were
> > 1. RC6
> > 2. MARS
> > 3. Rijndeal
> > 4. Twofish
> >
> > Which one will win, I don't know. If I wanted a family, those would
> be
> > the four I'd want.
>
> Well I still think if anything RC6 and Twofish should be at the top of
> the list. Not that I don't trust MARS though. Rijndael seems quite
> secure and compact. I haven't really looked at it but I would put it
> among the top 4 as well.
Without looking at all of the alternatives, you make that assumption
that what you have looked at is better than what you haven't.
>
> Tom
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: NIST AES FInalists are....
Date: Tue, 10 Aug 1999 15:53:09 GMT
[EMAIL PROTECTED] (John Savard) wrote, in part:
>I have - hopefully correctly - updated my description of MARS at
>http://www.ecn.ab.ca/~jsavard/co040806.htm
>to note these tweaks as proposed modifications.
I had made some mistakes in my description, which I believe I have now
corrected.
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Academic vs Industrial
Date: Tue, 10 Aug 1999 16:00:35 GMT
"Markku J. Saarelainen" <[EMAIL PROTECTED]> wrote, in part:
>051699
This looks like a date.
Are you referring to a news story that appeared somewhere on that date? If so,
where? Is it on a web site somewhere? If so, what is the URL?
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: NIST AES FInalists are....
Date: Tue, 10 Aug 1999 15:25:37 GMT
In article <7op365$5ct$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (Bruce Schneier) wrote:
> > The envelope, please... The five AES finalists are Mars, RC6,
> > Rijndael, Serpent, and Twofish.
>
> eegad. How did MARS make it? It's gross complex and ugly. The rest
of
> the candidates I agree with.
MARS is far easier to code than Twofish.
>
> I think though like many have said AES should be a family of
> algorithms. One should be able to pick 'fast' but modestly less
secure
> (say work factor off by a couple factors). And 'slow' but secure for
> the keysize picked. Also good smartcard and hardware ciphers should be
> part of AES. If a cipher is not good for some of the departments why
> put it there?
Selecting multiple algorithms would diminish the trust in any
particular algorithm.
>
> Personally I think the top two ciphers should be RC6 and Twofish. My
> rational is that RC6 is simple and based on the design principles of
> RC5. Although 'fixed-points' have been found in the quadratic
function
> I don't see that as a security compromise. Twofish was just designed
> by some really smart people. I trust their ability, plus Twofish is
As opposed to MARS? I suppose that Don Coppersmith doesn't count as a
distinguished cryptanalyst.
> rather efficient and compact. Both are suitable for hardware as well
> as smartcards as well as popular x86 type computers which dominate the
> market.
>
> Good luck Twofish and RC6 teams!!!
>
> Tom
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: vincent <[EMAIL PROTECTED]>
Subject: Re: Techweb crypto comedy...
Date: Tue, 10 Aug 1999 17:05:49 +0100
fungus wrote:
>
> Just pulled from the techweb.com news:
>
> <referring to AES>
>
> "The proposed codes are far more robust than the
> existing Federal Information Processing Standard
> Digital Encryption System (DES), which has encryption
> key sizes of 128, 192 and 256 bits. The new codes are
> virtually unbreakable with as many as 34035 possible
> keys, according to sources. "
>
> Anybody have the slightest idea where the number "34035"
> came from?
It's obvious, it cames from "according to sources".
--
============================
Vini boy
[EMAIL PROTECTED]
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Quantum info?
Date: 10 Aug 1999 16:08:31 GMT
DJohn37050 <[EMAIL PROTECTED]> wrote:
> Can anyone list refs to quantum computing as it relates to crypto?
> Thanks,
> Don Johnson
Check the list of references from Preskill's Cal Tech course, found
here :
http://www.theory.caltech.edu/people/preskill/ph229/references.html#algorithms
It includes Peter Shor's "Algorithms for Factoring and Discrete Log on
a Quantum Computer" and Lov K. Grover's search algoritm, plus other useful
papers. The course site itself is also a place to look at for
general quantum computing info, especially the course notes.
There are papers which give alternate presentations of Grover's algorithm,
and also those which prove that it is optimal as a quantum search
algorithm. Unfortunately, I can't seem to dig up the references at the
moment.
Also see HK Lo and HF Chau's paper on why quantum bit commitment and coin
flipping is impossible in the general case :
http://xxx.lanl.gov/abs/quant-ph/9906111
here "general case" means that both parties can measure as many quantum
bits as they like, I think.
Louis Savail presented a paper at CRYPTO '98, "Quantum Bit Commitment
>From a Physical Assumption", which tried to quantify what happens when
both parties are limited in the kinds of measurements they can make --
it turns out that some kinds of bit commitment become possible.
-David Molnar
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Techweb crypto comedy...
Date: Tue, 10 Aug 1999 10:04:29 -0600
fungus wrote:
>
> Anybody have the slightest idea where the number "34035"
> came from?
The press release from the AES home site:
http://csrc.nist.gov/encryption/aes/round2/AESpressrelease-990809.pdf
claims that 128 key gives you "...(340 followed by 36 zeroes)..."
keys (after writing it out, 340,000,000, etc.).
So it looks like a misunderstanding *and* a typo...
John M.
------------------------------
From: Gabriel Belingueres <[EMAIL PROTECTED]>
Subject: Re: What's first?
Date: Tue, 10 Aug 1999 16:19:27 GMT
In article <7op7af$88s$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> In article <7op424$5rj$[EMAIL PROTECTED]>,
> Gabriel Belingueres <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > I was wondering why is that when I send a ciphered message, I have
to
> do
> > the MAC computation from the plaintext, then the encryption of the
> > plaintext + MAC.
> >
> > If I would do this in the reverse order (ie encrypt first, then
> compute
> > the MAC from the ciphertext) I could save a decryption when the
> message
> > is modified.
> >
> > I think the two schemes provide the same security, but the
> > former provides more overhead. However, it is used in SSL.
> >
> > Does anybody knows why it is done always this way?
> >
> > Thanks,
> > Gabriel.
>
> A MAC should be a one-way keyed function of the plaintext to avoid
> giving out known plaintext. Simple as that. The CBC MAC gives out
> known plaintext with every message but is rather efficient to compute.
>
> Personally I would just hash the plaintext then encrypt the hash, also
> I would change the key with every message (possibly with a salt).
>
> Tom
I know what you mean, but this is usefull for transmition of passwords
only.
What I mean is that:
In SSL (for example), the transmition of message M is done this way:
SSL record = Cipher_SessionKey [M || HMAC_SessionMACKey(M)]
What I'm asking is why it is not done this way:
C = Cipher_SessionKey [M]
SSL record = [ C || HMAC_SessionMACKey(C) ]
where || is the concatenation.
Gabriel
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
** 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
******************************
