Cryptography-Digest Digest #688, Volume #11 Tue, 2 May 00 17:13:02 EDT
Contents:
Re: Any good attorneys? (Mok-Kong Shen)
Re: sci.crypt think will be AES? (Richard Heathfield)
Re: the security of scramdisk ([EMAIL PROTECTED])
Cascading Crypto Attack (Richard Heathfield)
Re: factor large composite (Diet NSA)
Re: quantum computation FAQ? (John A. Sidles)
Re: Karatsuba threshold ("Michael Scott")
Re: factor large composite (Diet NSA)
Re: GPS encryption turned off (Jerry Maple)
Re: AEES Advanced (Tom St Denis)
Re: Any good attorneys? (Tom St Denis)
Re: Any good attorneys? (Terry Ritter)
Re: Any good attorneys? (Terry Ritter)
Exporting public keys using VSC++ CryptoAPI ([EMAIL PROTECTED])
Re: new Echelon article (Diet NSA)
Re: GPS encryption turned off (Paul Rubin)
Re: Any good attorneys? (Paul Rubin)
Re: AEES Advanced (James Felling)
Re: Cascading Crypto Attack (James Felling)
I am actually currently in a security tradeshow and conference in this week ... good
security, crypto and biometrics people .. - I actually like many smartcard
applications ... (Markku J. Saarelainen)
Re: Cascading Crypto Attack (David A. Wagner)
----------------------------------------------------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Any good attorneys?
Date: Tue, 02 May 2000 21:16:21 +0200
Eric Lee Green wrote:
>
> Err, what he was saying is that even if you write the code from scratch from a
> description of the algorithm, you must still pay royalties, because the
> algorithm itself, not the code, is what is patented.
Thanks. I have really made a blunder in reading sentences.
An essential question, I think, is by how much a variant of a patented
algorithm must deviate from the patented algorithm before it is no longer
considered to be an imfringement of the patent? Does there exist any
precedence cases so that one could at least get an appropriate feeling
of that certainly quite difficult issue. Just for an hypothetical example:
Suppose DES is patented. Can another algorithm use S-boxes that
have 6 input bits and 4 output bits, though the contents of the boxes
are not identical? Can another algorithm do what is characteristic
of Feistel ciphers, i.e. alternatively process the left and right part of
the block? Is use of IP and inverse IP allowed? etc. etc. etc.
I should very much appreciate being able to learn something about
that issue.
M. K. Shen
------------------------------
Date: Tue, 02 May 2000 20:31:45 +0100
From: Richard Heathfield <[EMAIL PROTECTED]>
Subject: Re: sci.crypt think will be AES?
"Trevor L. Jackson, III" wrote:
>
> But [patent issue is] a subjective standard everywhere. One of my favorite
> non-obvious-due-to-stupidity patents is the grapefruit shield. It's a 1/4
> sphere of sheet metal with one edge sharpened. Prior to eating a grapefruit
> half one sticks the sharpened edge of the shield into the exposed rind, thus
> protecting neighboring diners from inadvertent squirts of juice. It was
> issued in the late 1890's. Nothing has changed in the last century. ;-)
At about that time, a patents clerk famously resigned, saying
"Everything has been invented".
If he reached this conclusion after exasperatedly issuing a patent for
the grapefruit shield, then I think he should be exonerated in the eyes
of history.
--
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
34 K&R Answers: http://users.powernet.co.uk/eton/kandr2/index.html (63
to go)
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: the security of scramdisk
Date: Tue, 02 May 2000 19:33:30 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (EP847) wrote:
> From what i have read, scramdisk is secure if a strong algorithm and
password,
> etc. are used. Can anyone tell me if there are any flaws in it that
weaken
> security? i am talking about version 2.02h
> thanks
>
The source is available. You can look at it yourself.
--
=====
"There are no ifdefs in hardware."
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Tue, 02 May 2000 20:47:29 +0100
From: Richard Heathfield <[EMAIL PROTECTED]>
Subject: Cascading Crypto Attack
[Disclaimer #1 - I'm not a cryptographer]
[Disclaimer #2 - I'm not sure whether this article is intended to be
light-hearted or not - make up your own mind :-)]
A recent thread (which I can't now find, hence this new thread)
discussed the possibility of using more than one encryption technique:
C = E2(E1(P))
or even
C = E9(E8(E7(E6(E5(E4(E3(E2(E1(P)))))))))
It was later suggested that this could actually /weaken/ the encryption.
If this is so, I have a suggested attack for any crypto system ever.
Given any ciphertext, progressively weaken it by applying more and more
encryptions of different kinds to it, until eventually the plaintext is
revealed.
Like the well-loved 1 == 2 proofs, this is (a) counter-intuitive and (b)
surely wrong. Yet it proceeds logically from the proposal that
successive encryptions weaken security.
Where is the flaw?
--
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
34 K&R Answers: http://users.powernet.co.uk/eton/kandr2/index.html (63
to go)
------------------------------
Subject: Re: factor large composite
From: Diet NSA <[EMAIL PROTECTED]>
Date: Tue, 02 May 2000 12:49:10 -0700
You wrote "a giant table look-up is faster (in Rubic's
cube literature, this is refered to as God's Algorithm)". I
thought you were implying that the "giant table look-up" would be
the same as "God's Algorithm" (ala the Rubik's cube context). In
this context, there are a few solutions (such as for the 2x2x2
Pocket Cube) but the "algorithm" is not known in general. To see
this & the requirement (in terms of Cayley graphs) which needs to
be satisfied for a realization of God's algorithm scroll to the
bottom of this webpage :
http://web.usna.navy.mil/~wdj/sm485_7.txt
I don't know of any quantum algorithm that will compute in time
complexity O(1) in a meaningful way. Nor do I know of any actual
QC that has factored multi-bit numbers (let alone a 3 bit
number).
Your silly ten year performance guarantee (made relative to the
potential of QC) is baseless. This implication that you do not
know what you are talking about does not speak well for the
quality of your corporation, Cloakware, given that you are the VP
of engineering!
" V hfdt afogx nfvw ufo axb (o)(o) " - Gtnjv
====================================================
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: [EMAIL PROTECTED] (John A. Sidles)
Subject: Re: quantum computation FAQ?
Date: 2 May 2000 19:34:33 GMT
See also Peter Schor's review article, released today,
on the xxx.lanl.gov preprint server:
http://xxx.lanl.gov/abs/quant-phys/0005003
------------------------------
From: "Michael Scott" <[EMAIL PROTECTED]>
Subject: Re: Karatsuba threshold
Date: Tue, 2 May 2000 20:52:54 +0100
Of course we are digressing like fury here, but thats very close to the way
I do it, except I use a 4 element look-up table instead of your 8 element
look-up table.
Anyone else got a quicker way??
Mike Scott
"Robert Harley" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
> "Michael Scott" <[EMAIL PROTECTED]> writes:
> > On a Pentium Pro my best effort for a 32x32 GF(2) multiplication
requires
> > 144 instructions.
>
> Do you really mean instructions or cycles? The following code, taken
> from the program used for solving Certicom's ECC2K-108 recently,
> appears to take about 75 cycles when compiled with gcc.
>
> Bye,
> Rob.
> .-. .-.
> / \ .-. .-. /
\
> / \ / \ .-. _ .-. / \ /
\
> / \ / \ / \ / \ / \ / \ /
\
> / \ / \ / `-' `-' \ / \ /
\
> \ / `-' `-' \ /
> `-' [EMAIL PROTECTED] `-'
>
>
> /* > ecdl2K-108.32bit.c
> * Purpose: Fast arithmetic for computing discrete logs on elliptic
curves.
> * Copyright: Robert J. Harley, 1997-1999.
> * Contact: [EMAIL PROTECTED]
> * Legalese: This source code is subject to the GNU General Public Licence
v2.
> */
>
> typedef unsigned int u32;
>
> /*--
GF2Product32x32 -------------------------------------------------------*/
>
> /* Compute 63-bit product of polynomials over Z/2Z with degree < 32.
> * Returns low 32 bits of result, and leaves top 31 bits in *ph.
> */
> u32 GF2Product32x32(u32 a, u32 b, u32 *ph) {
> u32 a1,a2,a4, h, l;
>
> a4 = a<<2; a2 = a4>>1; a1 = a4>>2;
>
> { u32 s, t, tab[8];
>
> tab[0] = 0; tab[1] = a1; tab[2] = a2; tab[3] = a1 ^ a2;
> tab[4] = a4; tab[5] = a1 ^ a4; tab[6] = a2 ^ a4; tab[7] = a1 ^ a2 ^
a4;
>
> s = tab[b & 7];
> t = tab[b>> 3 & 7]; l = s;
> s = tab[b>> 6 & 7]; l ^= t<< 3; h = t>>29;
> t = tab[b>> 9 & 7]; l ^= s<< 6; h ^= s>>26;
> s = tab[b>>12 & 7]; l ^= t<< 9; h ^= t>>23;
> t = tab[b>>15 & 7]; l ^= s<<12; h ^= s>>20;
> s = tab[b>>18 & 7]; l ^= t<<15; h ^= t>>17;
> t = tab[b>>21 & 7]; l ^= s<<18; h ^= s>>14;
> s = tab[b>>24 & 7]; l ^= t<<21; h ^= t>>11;
> t = tab[b>>27 & 7]; l ^= s<<24; h ^= s>> 8;
> s = tab[b>>30 ]; l ^= t<<27; h ^= t>> 5;
> l ^= s<<30; h ^= s>> 2;
>
> if (a>>31 & 1) { l ^= b<<31; h ^= b>>1; }
> if (a>>30 & 1) { l ^= b<<30; h ^= b>>2; }
> } /* end block */
>
> *ph = h;
> return l;
> } /* end function GF2Product32x32 */
------------------------------
Subject: Re: factor large composite
From: Diet NSA <[EMAIL PROTECTED]>
Date: Tue, 02 May 2000 13:11:50 -0700
In article <AKsP4.3045$d63.2572@client>, "Dann Corbit"
<[EMAIL PROTECTED]> wrote:
>No one includes yourself, obviously.
Yes, Sherlock. The set of "no one" (i.e., no humans) would also
include myself as a member.
>What useful results have been created as far as factoring large
numbers with
>QC? [none] If there are none, then it is "pie-in-the-sky"
Try telling this to the governments who provide the funding and
to the researchers in the field. (Of course, the researchers have
a vested interest in keeping the field alive, and do review each
other's grant proposals). To gauge more about the potential
feasibility of QC check out, especially, the journal "Nature" vol
404, page 368, or contact various other experts (or look at their
papers) to see what their *guesses* are.
>You obviously don't know what hyperbole means either.
"Hyperbole" usually means intentional exaggeration, but I still
don't know what "FCOL" means.
" V hfdt afogx nfvw ufo axb (o)(o) " - Gtnjv
====================================================
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: [EMAIL PROTECTED] (Jerry Maple)
Subject: Re: GPS encryption turned off
Date: Tue, 02 May 2000 20:06:00 GMT
It's called GLONASS. A Google search will turn up quite a few hits.
Jerry
On Tue, 02 May 2000 18:32:49 GMT, [EMAIL PROTECTED] (Doug Stell)
wrote:
>On Tue, 2 May 2000 10:44:44 -0700, "Stou Sandalski" <tangui
>[EMAIL PROTECTED]> wrote:
>
>> Isn't anyone company
>>from europe working on a GPS system alternative to the one used by the US
>>mil?
>
>I have been told that Russia has a GPS system.
>
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: AEES Advanced
Date: Tue, 02 May 2000 20:29:02 GMT
[EMAIL PROTECTED] wrote:
>
> AEES is symmetric encryption algorithm, which is developed from the
> DES architecture.
>
> New feature of advanced AEES:
> all permutations used in a round are derived from
> correspondent sub-key.
> This feature provides more entropy and therefor more security.
>
> Features inherited from previous version
>
> 256-bit block
Cool.
> 16 rounds
Why 16 rounds? Why not 20 or 4?
> 256 byte key length
Useless. Keys from 80-192 bits is all you really need and maybe 256
bits at the max.
> S-box is multiplication table of a group of the order 256
Explain? Are you doing something like F(a, b) = ab mod 257 ?
> 16 S-boxes
Static, per round ??? what?
> 16 sub-keys 256 bytes length
Why so big?
> All S-boxes are derived from sub-keys
Are the s-boxes functions?
> All others come from DES architecture.
>
> The Avalanche Effect of advanced AEES.
Which is?
> A desirable property of any encryption algorithm is that a small
> change in either the plaintext or the key should produce a
> significant change in the ciphertext. For 64-bit block DES change
> only one bit gives 34 bit change in ciphertext. This makes 53%.
> To be able to compare current AEES implementation (256-bit) with
> DES (64-bit) we should change the same amount of information namely
> 4 bits. Two ciphertexts encrypted with AEES Advanced differ in 105
> bits, which makes 41%.
>
> With two keys that differ in only one bit position in DES
> we have about 50% of the bits in the ciphertext differ.
> In AEES we are using 2048 bits key. To be able to compare
> key avalanche effect with DES we should change 37 bits.
> Again, the results show that about half of the bits in the
> cipher text differ.
How about differential characteristics? Linear traits?
Tom
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Any good attorneys?
Date: Tue, 02 May 2000 20:31:14 GMT
Eric Lee Green wrote:
>
> Mike Rosing wrote:
> > It's an official "cease and desist" order, or they *can* take you to
> > court.
>
> Hmm, I think you're right, U.S. courts think that all other countries in the
> world are part the United States. I mean, we had no problem kidnapping Manuel
> Noriega and putting him on trial in Miami for crimes that occurred in Panama,
> so why worry about these little things called "international boundaries"?
>
> Canada, hmm, isn't that the 51st state? Why, let's sue this Canadian citizen
> in a U.S. court!
>
> [Note: Not saying that Tom should not follow your advice, which obviously he
> IS doing... just commenting on the sheer ludicrousness of quoting a U.S.
> patent number to a Canadian citizen living in Canada].
I think it's funny too, but I will just avoid all RSA (tm) products
(hehehe) from CB in the future.
I already have other block ciphers (Blowfish, Twofish, Serpent,
CAST-128, Skip-jack, XTEA, GOST), and am adding DH to it now.
Tom
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Any good attorneys?
Date: Tue, 02 May 2000 20:35:50 GMT
On Tue, 02 May 2000 18:56:30 +0200, in
<[EMAIL PROTECTED]>, in sci.crypt Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] write:
>
>>
>> As far as writing your own code, patents in general cover a
>> means of doing something, not the details. So it would be the algorithm
>> itself that is patented, not the code.
>
>I hope that someone of our group who has competent knowledge about
>patents would check and verify your statement. My reason of doubt is
>this: If anyone can write code according to a patented algorithm without
>having to pay anything, how can the patent holder ever get money from
>his patent?
I am not a patent attorney; this is not legal advice:
Everything depends upon the specific claims made in each specific
patent. Not all patents are equal. Just saying that something is
"patented" is not enough.
To find what a patent means, and to find whether or not something
infringes, we must *read* *the* *claims* of that patent. Unusual
words used in the claims should be explicitly or implicitly defined
somewhere in the body. If some approach meets the listed limitations,
even if it has vastly more things, it "reads on" the claim and thus
infringes.
Often, things are not quite that clear, of course.
>And one should also be VERY careful to examine whether a claimed
>patent-free algorithm uses features from someone else than its author
>and whether these features are patented but (knowingly or unknowingly)
>not explicitly stated by the author in the documentation of the algorithm.
Right. That is the problem with saying that the AES ciphers are "not
patented." Just because someone makes something does not allow them
to give up rights which others have begun to establish. All we can
know is that the authors did (that is, were forced to) give up *their*
rights; we do not know that the designs are unpatented by someone
else.
>Otherwise one could get into troubles, I suppose.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Any good attorneys?
Date: Tue, 02 May 2000 20:36:30 GMT
On Tue, 02 May 2000 21:16:21 +0200, in
<[EMAIL PROTECTED]>, in sci.crypt Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
I am not a patent attorney; this is not legal advice:
>[...]
>An essential question, I think, is by how much a variant of a patented
>algorithm must deviate from the patented algorithm before it is no longer
>considered to be an imfringement of the patent?
To know that one must read the specific claims in the specific patent.
>Does there exist any
>precedence cases so that one could at least get an appropriate feeling
>of that certainly quite difficult issue. Just for an hypothetical example:
>Suppose DES is patented. Can another algorithm use S-boxes that
>have 6 input bits and 4 output bits, though the contents of the boxes
>are not identical?
Almost everything depends upon what the particular patent claims say.
>Can another algorithm do what is characteristic
>of Feistel ciphers, i.e. alternatively process the left and right part of
>the block? Is use of IP and inverse IP allowed? etc. etc. etc.
Surely everything in DES has been out of patent for almost a decade.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED]
Subject: Exporting public keys using VSC++ CryptoAPI
Date: Tue, 02 May 2000 20:25:46 GMT
Where can I find an example of exporting a public key using
CryptExportKey? For some reason I don't know the RSAPUBKEY structure
that my function writes does not contain the RSA1 header. On import
(CryptImportKey) of this (wrong?) key using the same crypto provider
and application software on the same computer I get a "Bad version of
Provider"
Thanks!
Eric
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Subject: Re: new Echelon article
From: Diet NSA <[EMAIL PROTECTED]>
Date: Tue, 02 May 2000 13:39:13 -0700
In article <[EMAIL PROTECTED]>, "Douglas A. Gwyn"
<[EMAIL PROTECTED]> wrote:
>Godwin's Law prov.
>
>[Usenet] "As a Usenet discussion grows longer, the probability
>of a comparison involving Nazis or Hitler approaches one."
So should the probability of the emergence of what B. Silverman
dubbed YACs (Yet Another Crank).
>There is a tradition in many groups that, once this occurs,
>that thread is over, and whoever mentioned the Nazis has
>automatically lost whatever argument was in progress.
Then, I guess T. Jackson lost.
" V hfdt afogx nfvw ufo axb (o)(o) " - Gtnjv
====================================================
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: GPS encryption turned off
Date: 2 May 2000 20:45:07 GMT
This is being discussed to death on sci.geo.satellite-nav.
Quick summary: there are *two* GPS signals (separate frequencies),
the C/A (course acquisition) signal, and the P/Y (precision) signal.
The C/A signal's inherent accuracy is about 15-20 meters, but until
yesterday it had been intentionally fuzzed ("Selective Availability"
or SA) to 50 meter accuracy or so, to impede accurate targeting of
homemade cruise missiles and other nasty uses. The C/A signal was
never encrypted in the usual sense; it was simply made slightly
inaccurate. Yesterday the inaccuracy was removed, almost certainly
permanently. The amount of SA fuzzing is adjustable up to 100 meters
but for the past year or so it's been set to around 50 meters. Now it
is zero. While walking to work today I turned on my Garmin GPS-12XL
and with a fairly lousy satellite view got a 38 foot estimated
position error, or just over 10 meters. This is amazing for a <$200,
pocket sized instrument.
The P/Y signal's accuracy is classified but is probably about 5-7
meters. The signal is for military use only, and is encrypted, and is
still encrypted and (mostly) unuseable by civilians and this is not
intended to change. Since this is sci.crypt, I'll mention that I've
heard that the encryption is some 1960's-vintage shift-register-based
stream cipher; and what's worse, the keystream runs at 1/5th the
symbol rate of the data stream, kind of like re-using a one-time pad.
If that's true, decrypting the P code would make a fun cryptanalysis
project for someone.
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Any good attorneys?
Date: 2 May 2000 20:47:46 GMT
In article <[EMAIL PROTECTED]>,
Tom St Denis <[EMAIL PROTECTED]> wrote:
>I think it's funny too, but I will just avoid all RSA (tm) products
>(hehehe) from CB in the future.
>
>I already have other block ciphers (Blowfish, Twofish, Serpent,
>CAST-128, Skip-jack, XTEA, GOST), and am adding DH to it now.
I'd say bag RC5 for sure. There's not much reason to care about it.
However, the RSA public key algorithm is important and your product
suffers if you don't include it. Even though you're in Canada and
it's unpatented there, you might want to avoid hassles by leaving it
out for now. But on September 20 when the US patent expires, please
put it back.
------------------------------
From: James Felling <[EMAIL PROTECTED]>
Subject: Re: AEES Advanced
Date: Tue, 02 May 2000 15:45:54 -0500
Tom St Denis wrote:
> [EMAIL PROTECTED] wrote:
> >
> > AEES is symmetric encryption algorithm, which is developed from the
> > DES architecture.
> >
> > New feature of advanced AEES:
> > all permutations used in a round are derived from
> > correspondent sub-key.
> > This feature provides more entropy and therefor more security.
> >
> > Features inherited from previous version
> >
> > 256-bit block
>
> Cool.
>
> > 16 rounds
>
> Why 16 rounds? Why not 20 or 4?
>
> > 256 byte key length
>
> Useless. Keys from 80-192 bits is all you really need and maybe 256
> bits at the max.
>
> > S-box is multiplication table of a group of the order 256
>
> Explain? Are you doing something like F(a, b) = ab mod 257 ?
Nope He is doing F(a,b)= a+b+K mod 256 with specific K's -- linear Sboxes
tend to be severe weaknesses versus serious analisys.
>
>
> > 16 S-boxes
>
> Static, per round ??? what?
>
> > 16 sub-keys 256 bytes length
>
> Why so big?
>
> > All S-boxes are derived from sub-keys
>
> Are the s-boxes functions?
>
> > All others come from DES architecture.
> >
> > The Avalanche Effect of advanced AEES.
>
> Which is?
>
> > A desirable property of any encryption algorithm is that a small
> > change in either the plaintext or the key should produce a
> > significant change in the ciphertext. For 64-bit block DES change
> > only one bit gives 34 bit change in ciphertext. This makes 53%.
> > To be able to compare current AEES implementation (256-bit) with
> > DES (64-bit) we should change the same amount of information namely
> > 4 bits. Two ciphertexts encrypted with AEES Advanced differ in 105
> > bits, which makes 41%.
> >
> > With two keys that differ in only one bit position in DES
> > we have about 50% of the bits in the ciphertext differ.
> > In AEES we are using 2048 bits key. To be able to compare
> > key avalanche effect with DES we should change 37 bits.
> > Again, the results show that about half of the bits in the
> > cipher text differ.
>
> How about differential characteristics? Linear traits?
>
> Tom
This algorithim is a toy cypher in many ways -- not bad for a beginner,
but poor vs. the big boy's work.
------------------------------
From: James Felling <[EMAIL PROTECTED]>
Subject: Re: Cascading Crypto Attack
Date: Tue, 02 May 2000 15:51:30 -0500
Richard Heathfield wrote:
> [Disclaimer #1 - I'm not a cryptographer]
>
> [Disclaimer #2 - I'm not sure whether this article is intended to be
> light-hearted or not - make up your own mind :-)]
>
> A recent thread (which I can't now find, hence this new thread)
> discussed the possibility of using more than one encryption technique:
>
> C = E2(E1(P))
>
> or even
>
> C = E9(E8(E7(E6(E5(E4(E3(E2(E1(P)))))))))
>
> It was later suggested that this could actually /weaken/ the encryption.
>
There is a difference between COULD and will. In some cases (where
algorithims use similar primitive operations, it is possible for one
algorithim to partially undo the good work of annother. In addition if the
E's are part of a group it is possible to do alot of work and arive at
something where the final product is equivalent to a single encryption with
a different key.) In general superencryption will increase security, but
this is not always the case.
>
> If this is so, I have a suggested attack for any crypto system ever.
>
> Given any ciphertext, progressively weaken it by applying more and more
> encryptions of different kinds to it, until eventually the plaintext is
> revealed.
>
> Like the well-loved 1 == 2 proofs, this is (a) counter-intuitive and (b)
> surely wrong. Yet it proceeds logically from the proposal that
> successive encryptions weaken security.
>
> Where is the flaw?
>
> --
>
> Richard Heathfield
>
> "Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
>
> C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
> 34 K&R Answers: http://users.powernet.co.uk/eton/kandr2/index.html (63
> to go)
------------------------------
From: Markku J. Saarelainen <[EMAIL PROTECTED]>
Crossposted-To: alt.politics.org.cia,soc.culture.russian,soc.culture.nordic
Subject: I am actually currently in a security tradeshow and conference in this week
... good security, crypto and biometrics people .. - I actually like many smartcard
applications ...
Date: Tue, 02 May 2000 20:45:30 GMT
You can access my web site at
http://homestead.virtualjerusalem.com/waeg/
Cheers !
Markku
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: Cascading Crypto Attack
Date: 2 May 2000 13:23:25 -0700
In article <[EMAIL PROTECTED]>,
Richard Heathfield <[EMAIL PROTECTED]> wrote:
> It was later suggested that this could actually /weaken/ the encryption.
Only if the keys used in the cascade aren't independent.
(Or if you care about probable-plaintext attacks.)
> If this is so, I have a suggested attack for any crypto system ever.
>
> Given any ciphertext, progressively weaken it by applying more and more
> encryptions of different kinds to it, until eventually the plaintext is
> revealed.
Yup. That gedanken-"attack" actually proves that cascading can't
weaken the cipher, when you use independent keys. Do you see why?
(This needs to be made precise, and there is a small tweak
or two needed to the result when you do that, but roughly speaking,
it is accurate, and gives a nice intuitive feel for the formal proof.)
------------------------------
** 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
******************************
