Cryptography-Digest Digest #598, Volume #10 Sat, 20 Nov 99 15:13:03 EST
Contents:
Re: AES cyphers leak information like sieves (SCOTT19U.ZIP_GUY)
Re: AES cyphers leak information like sieves (Tim Tyler)
Re: AES cyphers leak information like sieves (SCOTT19U.ZIP_GUY)
Re: Simpson's Paradox and Quantum Entanglement ([EMAIL PROTECTED])
Re: Bracking RSA Encryption. Is it possible. (Ted Kaliszewski)
Re: Distribution of intelligence in the crypto field (Jerry Coffin)
Re: Apparently, Hushmail does work (Vernon Schryver)
One - One compression and Whitening (SCOTT19U.ZIP_GUY)
Re: Nova program on cryptanalysis -- also cipher contest (William Rowden)
Re: Distribution of intelligence in the crypto field (Troed)
Re: What part of 'You need the key to know' don't you people get? (Jerry Coffin)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: AES cyphers leak information like sieves
Date: Sat, 20 Nov 1999 16:33:41 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Jerry
Coffin) wrote:
>In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
>
>[ ... ]
>
>> You /have/ to try and make things as secure as you possibly can, within
>> the constraints laced on you. This means making things as hard as you can
>> for the analyst. Letting him know that there's an almost one to one
>> relationship between bits of text and bits of cyphertext is not a good
>> start.
>
>If there's anywhere close to a 1:1 relationship between bits of
>ciphertext and bits of plaintext, then your underlying cipher is so
>poorly designed that NOTHING you can do with the chaining mode is
>going to do any good at all.
>
>> :> Look even PGP use a weak chaing mode with compression. Most
>> :> people don't have the software to recover the real file
>> :> if a change occurred in the middle of the compressed encrypted
>> :> text. So what fuckin good does this error recovery do anyone
>> :> who depends on PGP. It does them no fucking good it can
>> :> only be of use to a dedicated attacker.
>>
>> : For those looking on, I'll translate this into understandable (and
>> : civil) English: you're just as clueless as ever...
>>
>> You disagree?!
>
>Well, at least you have a grasp of the exceptionally obvious.
>
>> You think (for example) that people do generally have the
>> software to recover from such a mess? Or perhaps you think that hardly
>> anybody uses the software in question, so it doesn't matter? Or perhaps
>> you think that there's no possible way knowledge that certain small
>> regions of cyphertext correspond with certain regions of plaintext can
>> help attackers? Perhaps you would like to clarify which, if any, of
>> these false views do you hold?
>
>Perhaps instead of trying to put words into my mouth, you should
>actually pay attention to what's being said. First of all, consider
>David's reasoning here: he says that since _most_ people lack the
>software to recover from such a situation that the fundamental
>capability "can only be of use to a dedicated attacker." This is
>nearly a textbook example of fallacious reasoning. To say it can only
>be of use to a dedicated hacker he has to prove that _nobody_ but a
>hacker can make use of the information. He hasn't, he won't and he
>can't, for the simple reason that it's dead wrong.
The chaining does little in PGP to help one if there is a byte chaange
in the file. I am sure you should have known what I meant. The chainning
at most in my opinioun helps the attacker. Also PGP does a qucik check
up front to see if the key is a likely candidate for the encrypted text. Again
I feel this only helps the attacker. Since if a user uses the wrong key he
should have to wait till the PGP process is almost over before that is
determined.
>
>Second consider that even though the discussion was of CBC, he used
>PGP as his example, and it (at least normally) seems to use CFB
>instead. Since he apparently doesn't even know the difference between
>CFB and CBC, how are we supposed to believe that he has a clue about
>what and/or how either one contributes anything to security?
Mostly I was talking about any of the letter NSA approved chainining
methods. But the discussion about PGP was brought in because that is
what most people blindly use. I know what CFB is the point is a have a long
running argument years with John Savard about this. He claims at his site
PGP uses CBC which it does not but he seems incapable of admitting that.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: AES cyphers leak information like sieves
Reply-To: [EMAIL PROTECTED]
Date: Sat, 20 Nov 1999 15:41:53 GMT
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
: David Wagner wrote:
:> (The idea of compressing before encrypting isn't new. ...
: No, but before D.Scott brought up the "one on one" idea
: (which, in the refinement I like most, guarantees that any
: incorrect bunch of bits will successfully decompress to
: statistically feasible bogus plaintext)
This is not the thread for this, so I will /try/ to be brief...
Guaranteeing that any incorrect bunch of bits decompresses
to a statistically feasible bogus plaintext is really not
the way to express the one-on-one property. One-on-one means
that there's a bijection between the input and output sets of
the compressor.
You can have compressors that always spit out statistically
valid-looking plaintexts without having the 1-1 property -
and having the 1-1 property does not mean that incorrect
inputs decompress to plausible looking outputs - that is
mainly a result of effective compression - and not all 1-1
compressors necessarily have this property.
[snip summary]
: What the one-on-one scheme (as I just described it) does is
: to render a brute-force attack *infeasible* even if one *has*
: the necessary hardware to try all possible keys in a reasonable
: amount of time.
Yes.
However, readers should note that, in many respects, the *primary*
point of the property is that it hinders any cryptanalytic attacks
based on regularities in the compressed files, *not* that it prevents
brute force attacks. Brute-force attacks are of somewhat minority
interest with a sensible-sized key - while cryptanalytic attacks are
somewhat more important to defend against, IMO.
If anyone wants a summary, perhaps try: http://www.alife.co.uk/securecompress/
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Praying for salvation at least stills the mind. This may help a little.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: AES cyphers leak information like sieves
Date: Sat, 20 Nov 1999 16:49:40 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>John Savard <[EMAIL PROTECTED]> wrote:
>: On Sat, 20 Nov 1999 00:20:07 GMT, Tim Tyler <[EMAIL PROTECTED]> wrote:
>
>:>I certainly never said the section you placed quotation marks around.
>
>: The quotation marks weren't intended to indicate a direct quote.
>
>Yes, I understood that. It pays to be cautious when playing with those
>quotation marks, though ;-)
>
>: However, if I've inaccurately characterized your views, I'm glad; I
>: much prefer it that you are not advocating such things.
>
>I'm not - that would be pretty crazy!
>
>: But David A. Scott certainly _does_ seem to hold that kind of viewpoint,
>: which is why he has few admirers on this NG.
>
>This is not the impression I have. Why don't you ask David directly if he
>believes that the NSA can brute-force 256-bit keys on some future
>occasion?
As for brute force no way. Unless quantom computers can some how test
all at once. However just because 256 bits is not reach able by brute force
I do feel that the shorter the key the more likely some sort of mathematical
attack can exist on the cipher. But 256 bits is most lilely safe. But I still
like the option of using longer if it does not add much to computaion time.
Example you can use any single cycle permutation on scott19u that makes
for a pretty long key. However if you use a fixed keyenc.key file. Then the
key variable part will be the password the users enters this will be much
smaller than the key space allowed. If after a long time due the the shorten
spaced of the possible mappings some NSA geniuos may find some
corrolation due to this reduced subset. You don't hane to change the
whole method a knew keyenc.key file would map to totally different subsets.
My ability to analyzsis a reduced subset of mappings is orders of magnitude
more limited than the NSA so why not use as basic strcutures those things
hardest to analyize. Guessing the entries to a random S-table is very hard.
But guess a function that has lower complexity is much easier as the
number of permutations decreases.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.ai.fuzzy,sci.physics,sci.math
Subject: Re: Simpson's Paradox and Quantum Entanglement
Date: Sat, 20 Nov 1999 16:00:47 GMT
In article <816bkj$lie$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (John Forkosh) wrote:
> [EMAIL PROTECTED] wrote:
> : Simpson's Paradox:
> : http://curriculum.qed.qld.gov.au/kla/eda/sim_par.htm
> : Simpson's Paradox is a statistical artifact ...<snip>
>
> There's a textbook treatment in "Quantum Probability",
> Stanley P. Gudder, Academic Press 1988, ISBN 0-12-305340-4,
> pages 102-106, which concludes it's not a problem.
> John ([EMAIL PROTECTED])
>
I wonder, since there is such a simple picture of it
in terms of vector relations in the above link;
and vectors, being so much a part of physics, one would
think that this problem would crop-up quite often in
physical contexts, and yet there isn't much mention of
"Simpson's Paradox" in physics that I can detect.
Your reference above is the first case I've seen so far
where Simpson's paradox is mentioned in physics
and quantum physics at that (other than G.G.Simpson's
fictional book involving quantum mechanics),
Maybe it's called by another name in the field of physics,
than it is in the field of statistics ?
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Ted Kaliszewski <[EMAIL PROTECTED]>
Subject: Re: Bracking RSA Encryption. Is it possible.
Date: Sat, 20 Nov 99 11:45:10 -0500
The security of RSA system does not depend ONLY on the size of the modulus
used but also on the method used to construct it. Thus, a random selection
of the factors does not guarantee "security". Moduli can readily be constructed
of any size that can be factored faster than I can type this message. It
is. therefore, a misconception to use the size of the modulus as the proof
of its security. This is not to say that safe moduli cannot be constructed.
They can and, hopefully, such moduli are used by the system providers.
Otherwise we are all in a deep trouble.
Reagrds,
Ted
------------------------------
From: [EMAIL PROTECTED] (Jerry Coffin)
Subject: Re: Distribution of intelligence in the crypto field
Date: Sat, 20 Nov 1999 09:27:06 -0700
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] says...
[ ... ]
> The best way is to plot a MURDER of the PRESIDENT (you know, the one
> in the WHITEHOUSE) - and encrypt those plans with 2048 bit RSA. If you
> get arrested - hey, that means they can decrypt it ;)
Quite the contrary: it means they can break the system as a whole.
Unless you happen to keep your computer in a Faraday cage, there's a
much better chance of them (for example) parking a black van down the
street from your house (or office) and capturing keystrokes as you
type them in, and capturing pretty much everything that's showing up
on your monitor as well.
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: [EMAIL PROTECTED] (Vernon Schryver)
Subject: Re: Apparently, Hushmail does work
Date: 20 Nov 1999 08:52:04 -0700
In article <[EMAIL PROTECTED]>,
David Hopwood <[EMAIL PROTECTED]> wrote:
> ...
>3. At http://www.hushmail.com/about_hushmail.htm:
> # Our patent-pending, state-of-the-art technology...
>
> A substantial portion of the cryptographic community (myself included)
> won't touch anything patented if they can help it, for very good reasons
> that I won't go into here. It therefore has very little chance of becoming
> a standard.
RSA hasn't been ignored for these last dozen years, despite that patent.
The compelling reason to doubt the future of this "technology" is that it
is advertised to be "state-of-the-art technology." For at least the last
10 years, almost all uses of forms of the word "technology" really want
a synonym for post process male bovine grass and grain. In practically
all cases, the intended meaning is more clear (albeit more clear than
desired) by replacing forms of the T word with the B word. Try it the
next time someone tries to sell you some technology. Given the marketing
slant of the rest that web page containing that quote, the intended meaning
of the T word in this case is likely to be the standard B word.
Vernon Schryver [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Crossposted-To: comp.compression,alt.comp.compression
Subject: One - One compression and Whitening
Date: Sat, 20 Nov 1999 18:33:53 GMT
There is been much discussion about what I call my compression
method. However it is a fact it is not adding information to a file
due to the nature of how it works any file can be treated as a
compressed file or an uncompressed file and each compresses
or uncompressed to a unique file and back without change when
the reverse process is done.
But does it protect from Plain attacks. My detractors the establishment
and new comers kissing up to the crypto gods see this as a weakness.
But if a "choosen whole file plain text attack" is possible on the encryption
method then it is possible on the system with my compression.
However if non 1-1 compression is used information will be added to
the encrypted file that an attacker could use even if nothing is known
about the nature of the file being processed.
That being true the question then araises if the attacker knows the
nature of the files being encypted can he with only a few blocks
have the information available to him to eliminate most keys from
the possiblity of a correct solution. The anwser again for my current
version of compression is yes.
The question is there a way to force the attacker to exaimine the whole
file before there is any information available to an attacker to establish
the validity of a key. And can one use a better compression in the process.
Here is my anwser YES:
I took the file ann11e.txt it is from the ACT test of compression stuff.
it is 586,960 bytes in lenght it compresses with h2com.exe to
338,366 bytes. This file when expanded would be less than a
facator of 2. And in fact if the data was a "random file" instead
of the text file it would be less than one.
Know if one encyrpts this with AES using weak NSA approved
chaining the information is not spread well through the file
and an attacker would have to look at only a few blocks.
The problem occurs because as one is decompressing a random
file you get a file that is generally about 4 times longer than the
random file. But since text or useful files that I use seem to compress
far less eifficently the attacker could determine by the current
estimes of the expansio ratio that the file is unlikely to be the
file sent.
A solution to this if one is really worred is to take the compressed
file that h2com.exe created than reverse it with reverse.exe and
run h2unc.exe on it then
reverse it and run h2com.exe this produce a file to be encrypted
that is 338,271 bytes long but when expanded it goes to 1,272,287
bytes and it looks like fluffy junk just like a random file that gets
uncompress. it has an expansion ratio of 3.76
The attacker would have to do much work on a whole decrypted file
to have enough information to see if the key may have been valid.
This rasises the question about compression eiffiency. If
one used the anne11.zip file as a start instead of the text
file it would compress 244,897 bytes to 245,178 when
this is reversed and uncompressed you get 957,988
reverse and compress this you get 245,178 so this
file has an expansion ratio of 3.907 and is within
1 percent of the oringinal zipped file.
CONCLUSION:
If one using a AES encryption and wish a higher level of security.
Guven you wish to send file A
1. either compress A with the compressor of you choice or leave it alone
2. compress it with h2com.exe
3 reverse the file with reverse.exe
4 uncompress the file with h2unc.exe
5 reverse the file
6 compress the file with h2com.exe
At this point your file should be sufficently whitten and compressed
that it would be indistinguishable form any other file that could be obtained
by a wrong key.
To even check for a possible key as a solution the attacker would have
to
A. decrypt the whole file
B. asumming the attacker can revese at same time. compress the whole
file in the reverse direction.
C. at least uncompress the first few blocks of file to see if it make sense.
to guard agaisnt known plain text attacks which are still possible assuming
the attacker can insert his "whole file" of choice at step 2. Which as some
claim can be avoided if in step 1 a non 1-1 compressor was used.
or you would have to limit the file type that is being accepted at stage 1.
or much as I don't like you would have to add a random string to file
in stage one that can be taken off during the decryption process.
But in any case with this system the information is spread through
out the whole file and one can use the weak 3 letter modes of encryption
that the NSA loves.
Nothing is perfect but as long as we say that radom data is not used
the above I think goes a long ways to insuring your message agaisnt
any ciphertext only attack and all but "complete whole file choosen
attacks"
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
------------------------------
From: William Rowden <[EMAIL PROTECTED]>
Subject: Re: Nova program on cryptanalysis -- also cipher contest
Date: Sat, 20 Nov 1999 17:51:40 GMT
For those who are interested, here are some additional comments on the
first cipher of the contest. Did anyone else from sci.crypt submit a
solution?
In article <80qs6e$bml$[EMAIL PROTECTED]>, William Rowden
<[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>, Jim Gillogly <[EMAIL PROTECTED]>
> wrote:
> > I prepared a cipher contest for them with a flavor of WW2 hand
> > ciphers
>
> I like the contest, but so far have found cryptanalysis by hand
> frustrating.
Since WWII ciphers led to advances in computing, it's fitting that I
eventually used my computer for a significant portion of the
cryptanalysis. I had imagined taking pencil, paper, and the ciphers to
a local coffee shop and returning with a solution, like I do for the
cryptograms in puzzle books. Usually the probable plaintext fits in a
limited number of locations, however. For the first cipher, inspection
only narrowed the locations to a score or so each. Attempting to
reconstruct the Playfair square for a few of these locations by hand
motivated the writing of a computer script to search the permutations.
The computer's first pass with the script produced four partial Playfair
squares for testing--a number of squares this human was willing to try.
> Is anyone else working on this? I assume teams are permitted.
Time pressures made long-distance collaboration difficult. Fortunately,
I have local friends who don't mind contributing part of a Friday
evening to an eleventh-hour solution.
> I don't think I'm going to finish in time unless I have help (or I
> quit my non-cryptological day job :-)).
If I lose my job because I was distracted and less productive at work
this week, will Jim Gillogly hire me? :-)
Look for the real email address; I don't answer my-deja.com.
--
-William
SPAM filtered; damages claimed for UCE according to RCW19.86
PGP key: http://www.eskimo.com/~rowdenw/pgp/rowdenw.asc until 2000-08-01
Fingerprint: FB4B E2CD 25AF 95E5 ADBB DA28 379D 47DB 599E 0B1A
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Troed)
Subject: Re: Distribution of intelligence in the crypto field
Reply-To: [EMAIL PROTECTED]
Date: Sat, 20 Nov 1999 17:56:50 GMT
[EMAIL PROTECTED] (Jerry Coffin) wrote:
>> The best way is to plot a MURDER of the PRESIDENT (you know, the one
>> in the WHITEHOUSE) - and encrypt those plans with 2048 bit RSA. If you
>> get arrested - hey, that means they can decrypt it ;)
>
>Quite the contrary: it means they can break the system as a whole.
>Unless you happen to keep your computer in a Faraday cage, there's a
>much better chance of them (for example) parking a black van down the
>street from your house (or office) and capturing keystrokes as you
>type them in, and capturing pretty much everything that's showing up
>on your monitor as well.
But they would only do that if they're already suspecting me. Sending
out an encrypted message on the net however will _make_ them suspect
me _if_ they can decrypt it.
See? Echelon is our friend ;) I'm in Sweden - I hardly believe the NSA
has a black van outside my apartment.
___/
_/
------------------------------
From: [EMAIL PROTECTED] (Jerry Coffin)
Subject: Re: What part of 'You need the key to know' don't you people get?
Date: Sat, 20 Nov 1999 11:00:37 -0700
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
[ ... ]
> You are saying that *nobody* has an attack on these cyphers - and that
> *nobody* will for as long as it takes for any information encrypted with
> them today to go stale?
No, I'm not saying that and I never did. Before you try to learn more
about cryptography, perhaps it would be best to learn to read. What I
said was that unless somebody DOES have such an attack, having the
known plaintext does them no good. If they do have such an attack, I
don't personally believe that the extra diffusion of treating the
entire message/file as a single block is going to slow them down to
any noticeable degree.
IOW, I believe you _need_ to depend on the underlying cipher for
strength. When/if somebody breaks the cipher, the WPCBC chaining mode
(or anything similar) is unlikely to add significant difficulty to
breaking the system as a whole -- it only does any good in a situation
where the attacker is likely intercept parts of messages, but rarely
or never intercept entire messages. According to your own
descriptions of bandwidth, dependability, etc., this is virtually
never likely to happen.
> On what do you base this amazing assertion?
When you quit trying to put words in my mouth and listen instead,
you'll realize that I've never made such an assertion, or anything
similar to it.
> : but the reality is that even with known plaintext, and even if we can
> : narrow down its effects to a small number of blocks of the file, we
> : have absolutely NO reason to believe that anybody has anything
> : approaching a practical attack on the cipher anyway.
>
> Nor do we have any good reason to believe the reverse. These cyphers may
> have already been broken behind closed doors for all we know. We are
> all ignorant of whether this is the case or not. I am not hypothesising
> some sort of monster computer, when I write this - simply some
> previously unguessed at mathematical or analytic technique - or simply an
> overlooked break.
The question isn't whether there's a possibility of the cipher itself
being broken -- there's always a chance of that. The question is
whether the modifications you're discussing make a break any less
likely and/or less useful when/if it does exist. I doubt that anybody
has (at least yet) invented a way of breaking any of the AES ciphers,
but if they have, I doubt that using the W-PCBC chaining (or something
else to diffuse information over entire files/messages/whatever will
have any significant effect on the difficulty of making use of the
method.
[ ... ]
> I'm already pretty convinced that diffusion before using a modern block
> cypher helps with security - by destroying the relationship between
> plaintext and cyphertext under discussion here.
>
> Are you arguing that this is actually generally /weaker/ - due to some
> threat from differential cryptanalysis?
I'm arguing that it's nearly impossible to compare things based on
general principles rather than specific details -- just for example,
take a look at the changes that were made to IDEA early on. The
changes were so minor that at the level of detail you're discussing
things, they wouldn't show up at all. Despite this, they improved
security a great deal. For that matter, from the level at which
you're discussing things, it would look like Lucifer would be MUCH
more difficult to attack with differential cryptanalysis than DES.
Despite this, anybody who's studied them at all realizes that exactly
the opposite is true.
I'm also saying that things that make a cipher more difficult to
attack with one method may make it a great deal weaker to attack with
a different method. Again, DES provides a classic example: the
contents of the S-boxes do a superb job of protecting against
differential cryptanalysis, but those exact same numbers make it
relatively prone to linear cryptanalysis.
To summarize: the devil is in the details. You can discuss general
principles as long as you want, and it won't get you much of anywhere.
About the only way you can really say anything useful about the
relative security of two systems is to analyze them on a concrete
basis. Sweeping generalizations are always wrong. :-)
> : IOW, if you use a form of communication reliable enough to be sure the
> : intended recipient receives the whole thing, most of those same steps
> : will also give the interceptor a higher likelihood of receiving the
> : whole thing as well, in which case you've really accomplished nothing.
>
> If a clear channel implied a clear chance at eavsdropping, your sentence
> might make sense - but it does not.
The clear channel doesn't imply the ability to eavesdrop. It implies
that if eavesdropping is possible at all, that it's likely to be
highly dependable.
[ ... ]
> You think knowing there's a relationship between bits of plaintext and
> bits of cyphertext is necessarily useless to the analyst if they have
> whole messages to work on?
>
> I'm sorry - I simply don't agree.
You can disagree all you want, but all present indicators are to the
contrary. Just for example, in 20+ years studying DES, a half dozen
or so attacks that use known plaintext have been invented, but not a
single one of them is as practical as key-exhaustion. Nobody knows
how to make use of it in a 64-bit block, and quite a few AES
candidates increase that to a 256-bit block. If there's such a huge
break found in any of the AES candidate ciphers to be able to take
advantage of it in this much larger a block, I'm hard put to believe
that increasing the effective block size a great deal more is going to
make any real difference in the security at all.
I hasten to reiterate, though, that the devil is nearly always in the
details -- it's entirely possible that in implementing the wrapped
PCBC mode (or something similar) you could do something that helped
security a great deal. It's also possible, however, that you could do
something that hurt security even more. A study has been done to
prove that CBC does NOT hurt the security of underlying cipher, but
I'm not at all sure the same can be said of W-PCBC mode. Without
defining the precise details of how it works (something David Scott is
unlikely to assist with in any way) it's virtually impossible to do
such a proof.
Other people are doing research in roughly the same direction, and
some of them are people who are far more likely to provide useful
information about it. When/if I know of something similar to the
study on CBC, it's likely that I'll have a great deal more trust in
using it.
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
** 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
******************************
