Cryptography-Digest Digest #51, Volume #10 Sun, 15 Aug 99 12:13:03 EDT
Contents:
Re: Compact Full-Keying Twofish Code? (SCOTT19U.ZIP_GUY)
Re: Cracking the Scott cryptosystems? (fungus)
Re: Triple DES (168bit) -- Triple DES (112bit) (fungus)
Re: Wrapped PCBC mode ([EMAIL PROTECTED])
Re: Cracking the Scott cryptosystems? (SCOTT19U.ZIP_GUY)
--- sci.crypt charter: read before you post (weekly notice) (D. J. Bernstein)
Re: Cracking the Scott cryptosystems? (SCOTT19U.ZIP_GUY)
ooops pgp trouble ([EMAIL PROTECTED])
Re: New encryption algorithm (SCOTT19U.ZIP_GUY)
Re: Clerification of Crypto Export Laws (SCOTT19U.ZIP_GUY)
Re: Do I have a problem with semantics? (SCOTT19U.ZIP_GUY)
Re: New encryption algorithm (JPeschel)
Re: Smart card generating RSA keys (Matthias Bruestle)
Re: NIST AES FInalists are.... ([EMAIL PROTECTED])
Re: NIST AES FInalists are.... ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Compact Full-Keying Twofish Code?
Date: Sun, 15 Aug 1999 15:20:28 GMT
In article <[EMAIL PROTECTED]>, *@spam.ruud.org wrote:
>[EMAIL PROTECTED] writes:
>
>> Is there any clear (less obfuscated then the Twofish Teams code)
>> implementation of a full-keying Twofish (ECB mode, cuz I can add CBC
>> later).
>>
>> I would like code to just play with. I have read the Twofish Paper and
>> well for my purposes I don't feel like coding it from scratch.
>
>lsh (free ssh2 implementation) contains a full-keying Twofish
>implementation. You can get lsh at
>ftp://ftp.lysator.liu.se/pub/security/lsh/lsh-0.1.3.tar.gz
>
>The twofish implementation is in src/symmetric/twofish.c
>
It is nice to see my governement in action. On one hand they scream that
no one should be allowed to write crypto and give it away free to someone over
seas because terrorisrs anad child porno people might use it.
At the same time they ran an more or less open contest for susposed real
strong crypto in the open. So that it gets put overseas.
Kind of like the good old days when one branch of the US government was
giving aid to Banana republics to prop them up. While the cia part of
government was using the same or more money to tear the governments
down. Oh well I guess thats the american way.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: fungus <[EMAIL PROTECTED]>
Subject: Re: Cracking the Scott cryptosystems?
Date: Sun, 15 Aug 1999 17:16:04 +0200
[EMAIL PROTECTED] wrote:
>
> Greetings.
>
> I am a relative beginner in Cryptanalysis, with a background in Computer
> Science and Math. Recently, a co-worker pointed me to cryptosystem
> designed by a regular poster to this forum, "David Scott" with an
> associated prize.
>
Being a "regular poster" here shouldn't lend credibility to anything.
> The cryptosystem in question appears to be a chained-substitution
> cipher, and I don't see many references to anything similar in the
> cryptographic texts I have access to, most noteably Applied
> Cryptography. Is there a reason why this form of cryptosystem isn't
> generally used (discounting specific weaknesses in the design of the
> system in question)?
>
It offers no specific advantages over existing systems, is badly
documented, has no theoretical basis to its methods.
--
<\___/>
/ O O \
\_____/ FTB.
------------------------------
From: fungus <[EMAIL PROTECTED]>
Subject: Re: Triple DES (168bit) -- Triple DES (112bit)
Date: Sun, 15 Aug 1999 17:11:20 +0200
In article <lkit3.81$[EMAIL PROTECTED]>,
"karl malbrain" <[EMAIL PROTECTED]> wrote:
> The key size never materially exceeds 64 bits with a 64 bit block
> cipher. Triple DES materially extends the original 56 bit key size
> to 64 bits. Karl
>
Not true.
Think of DES as a function of the key combined with the message.
You may be able to find a 64-bit key which decodes the first block
of a message, but the same key won't decode the rest of it.
--
<\___/>
/ O O \
\_____/ FTB.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Wrapped PCBC mode
Date: Sun, 15 Aug 1999 14:16:11 GMT
In article <7p5f0n$163c$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> What you say about ordinary PCBC is true you can swap 2 blocks
> in the message and they are garbled but the rest are not. This is old
> news. I think you are acting alot like Wagner saying things about
> "wrapped PCBC" with out every having looked at it. This is not a
problem
> in "wrapped PCBC" if two blocks get swaped in the output and you try
> to decrypt the WHOLE FILE is trashed. Why don't you guys check
> things out once and awhile before you make such dumb statements.
> One big advantage of "wrapped PCBC" is the all or nothing encryption
> that results from it. And you can encrypt using large blocks but yet
still
> have encrypted files the same size as input files. And yet a change
> anywhere in the file changes the whole output file front to back.
You are still missing the point. Let's use a scenario...
Alice takes a message M, a random key K (somehow they exchange it).
Alice then hashes the message to get L=H(M). Now Alice computes C=Ek
(M||L). She sends C to bob.
...meanwhile...Mallory takes C and flips a bit...
...back at the bat cave...Bob picks up C, gets the super key K, and
decrypts the message. He gets P' and M'. Since H(P') != M', he
deletes the message. Now it's upto Bob to reply if he wants ...
What does Mallory get out of this?
Tom
--
PGP 6.5.1 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] (SCOTT19U.ZIP_GUY)
Subject: Re: Cracking the Scott cryptosystems?
Date: Sun, 15 Aug 1999 15:39:08 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>SCOTT19U.ZIP_GUY wrote:
>>
>> In article <[EMAIL PROTECTED]>, "Douglas A. Gwyn" <[EMAIL PROTECTED]>
> wrote:
>> >[EMAIL PROTECTED] wrote:
>> > ...
>> Is there a reason why this form of cryptosystem isn't generally used?
>> >
>> >David seems to think it is an NSA-led conspiracy, but actually there
>> >are numerous more thoroughly understood systems that people think
>> >work well enough, so there is little motivation to work on a new one.
>> >The most serious problem, though, is the large key size, which makes
>> >key management a much bigger problem than usual.
>> Actually key management is no more a problem than it is for
>> PGP. What one would most likely have is a large keyenc.key
>> file. And then the use what you want as a pass word. You can
>> change the big keyenc.key only when you feel like it.
>>
>
>So how do you exchange the key for a message without an public-key
>method?
You excange it the way you would any secrest key cipher.
But if you want to so it using public key encryption for the key
that is between the 2 partys. I would prefer handing ny friend a
disk. Or talk to him in preson and pick a file and a pass phrase
to pass him. However since key can be long if one is using a
public key method send it in pieces with several different RSA
DIffe HIllman or what don just use a small base for the power
use different bases. Something that takes time to grind out.
>
>> >
>> >> It appears, although I don't have enough background in information
>> >> theory to prove it, that there is not enough information provided in
>> >> this system, because stages (A) and (C), given the small file size
>> >> and different starting positions this seems effectively to be a one
>> >> time pad. Is this correct?
>> >
>> >If a different key file (S-box generator input) were used for each
>> >message, then it would have similar characteristics to a one-time
>> >pad. Note that one-time pads aren't often used in practice either.
>> It seems to me that all good crypto systems should act like
>> a OTP if a different key is used for "EACH MESSAGE" since
>> it is the only provable secure method. WAKE UP
>
>I don't think this behaviour tells anything about the strength of the
>system:
Yout corrent put the presious post implied a weakness by assocaition
to the OTP
>
>1) A vernam cipher behaves like an OTP as long as the key is longer than
> the message but it can simply be broken for longer messages.
>
>2) DES doesn't show this behaviour even for a single block since it
> generates only 2^56 of the possible 2^64 permutations, but for longer
> messages it is much stronger than a vernam cipher.
Actually DES or any random generator show a likeness to a OTP
if used properly and for ONE TIME since any sequence could in theroy
have come from a OTP it is just that when the source used for the pad is
known then analysis can say that it is not a valid source for use with a
OTP.
>
>If you want to use a OTP - why not?
>But for a cipher that should be used daily I'd prefer one with the
>properties of a modern blockcipher:
By properties of a modern block I assusme mean things like
the error recovery. But I prefer the features that should be found
on future ciphers for files. Namely a one bit change in input cahnges
the whole file out. One where the entropy of message is spread
a lot better than the AES small black cipher with tiny keys.
>
>- The key should be just long enough to keep the attacker from trying
> brute-force-attacks. If I'm using passwords it is already hard
>enough to memorize a phrase that contains enough entropy and that
>isn't
> part of a book or a poem. An when using public-key-encryption long
> keys are slowing down the whole system.
>- The cipher should be small and fast. I don't want to store huge
>lookup-tables on my computer without knowing whether or not I'd be
> able to destroy them without burning my harddisk. I don't want to
> wait a long time until my cipher is ready to encrypt or decrypt a
> message, and I don't want to wait a long time until my computer
>was able to do the encryption or decryption.
>- I feel better if the cipher I've used was tested by good
>cryptographers. Since I'm not very good in cryptanalysis I have to
> hear what experts say.
> Even on the AES candidates more cryptanalysis was done than on
> SCOTTxxx, and these ones are by far too new to be used if security
> is important.
>
Actually I prefer using pass pharse that are easy to rember too
that is way the scott16u contests should be easy if my code is
weak I used very short phrases. The design methods of the AES
candidates means they can't be good for file or serious message
protection. Only an idiot would say "The key should be just long enough to
keep the attacker from trying brute-force-attacks" I think this is
the same crap that made fools think 512 but RSA was safe till
the sun burned out. Of cousre know it is known in the public that
this is not safe. But maybe the NSA people are to stupid to know
this since it wasn;t invented there.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: [EMAIL PROTECTED] (D. J. Bernstein)
Crossposted-To: talk.politics.crypto
Subject: --- sci.crypt charter: read before you post (weekly notice)
Date: 15 Aug 1999 05:00:34 GMT
sci.crypt Different methods of data en/decryption.
sci.crypt.research Cryptography, cryptanalysis, and related issues.
talk.politics.crypto The relation between cryptography and government.
The Cryptography FAQ is posted to sci.crypt and talk.politics.crypto
every three weeks. You should read it before posting to either group.
A common myth is that sci.crypt is USENET's catch-all crypto newsgroup.
It is not. It is reserved for discussion of the _science_ of cryptology,
including cryptography, cryptanalysis, and related topics such as
one-way hash functions.
Use talk.politics.crypto for the _politics_ of cryptography, including
Clipper, Digital Telephony, NSA, RSADSI, the distribution of RC4, and
export controls.
What if you want to post an article which is neither pure science nor
pure politics? Go for talk.politics.crypto. Political discussions are
naturally free-ranging, and can easily include scientific articles. But
sci.crypt is much more limited: it has no room for politics.
It's appropriate to post (or at least cross-post) Clipper discussions to
alt.privacy.clipper, which should become talk.politics.crypto.clipper at
some point.
There are now several PGP newsgroups. Try comp.security.pgp.resources if
you want to find PGP, c.s.pgp.tech if you want to set it up and use it,
and c.s.pgp.discuss for other PGP-related questions.
Questions about microfilm and smuggling and other non-cryptographic
``spy stuff'' don't belong in sci.crypt. Try alt.security.
Other relevant newsgroups: misc.legal.computing, comp.org.eff.talk,
comp.org.cpsr.talk, alt.politics.org.nsa, comp.patents, sci.math,
comp.compression, comp.security.misc.
Here's the sci.crypt.research charter: ``The discussion of cryptography,
cryptanalysis, and related issues, in a more civilised environment than
is currently provided by sci.crypt.'' If you want to submit something to
the moderators, try [EMAIL PROTECTED]
---Dan
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Cracking the Scott cryptosystems?
Date: Sun, 15 Aug 1999 15:54:35 GMT
In article <[EMAIL PROTECTED]>, fungus
<[EMAIL PROTECTED]> wrote:
>
>
>[EMAIL PROTECTED] wrote:
>>
>> Greetings.
>>
>> I am a relative beginner in Cryptanalysis, with a background in Computer
>> Science and Math. Recently, a co-worker pointed me to cryptosystem
>> designed by a regular poster to this forum, "David Scott" with an
>> associated prize.
>>
>
>Being a "regular poster" here shouldn't lend credibility to anything.
>
>
>> The cryptosystem in question appears to be a chained-substitution
>> cipher, and I don't see many references to anything similar in the
>> cryptographic texts I have access to, most noteably Applied
>> Cryptography. Is there a reason why this form of cryptosystem isn't
>> generally used (discounting specific weaknesses in the design of the
>> system in question)?
>>
>
>It offers no specific advantages over existing systems, is badly
>documented, has no theoretical basis to its methods.
>
>
Actually the major basis to it is the safety of a large random S-table
and the mixing do to "wrapped PCBC" chaining along with pre and
post whitening. Funus like most people shoot there mouth off and have
never really looked at the source code. THe totally code is supplied with
the method but I guess having people read is just to much for most.
I file that scott19u is far stronger due to 19 boudaries and 9 bit shift.
THere is a method where you can see weaknesses in all the current
ciphers. Fist I am assumong you use mode where the input file matches
the output file in legnth.
Encrypt using any of the AES or blessed candidates. Then if possible
revese file byte order encrypt again with second key. Then change one
bit in file. And decrypt the mess. There will be only a small area of change
from the original file. This is manly due to the fact the NSA wants to only
look at a small fragment of code to try to break a system so methods that
rely on this weakness are the only ones in common use. This weaknes is
not in my code. I did a lot of testing using the DIEHARD programs in various
ways, It actually is a very simple solid program that works. But the BS and
Wagner types over and over say it is weak. Wagner even said on this form
his Slide Attack would finish it. Well the asshole was wrong but that doesn't
stop them from saying it must be weak they just haven;t figures out how.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: [EMAIL PROTECTED]
Subject: ooops pgp trouble
Date: Sun, 15 Aug 1999 14:00:58 GMT
I got the new copy of PGP and my DH/DSS key (6.0.2) was erased my new
key is
=====BEGIN PGP PUBLIC KEY BLOCK=====
Version: PGPfreeware 6.5.1 for non-commercial use <http://www.pgp.com>
mQCNAze2xIgAAAEEAKLNSa2nQ32lkGz29mGGFgt+2rP2xDWZFnLDZHOL+sx7gBdK
8JslJZQBBmTInPRuseut0U92Tpw5itAsOyNHRG01+prboVWY2toFDz2Tha8LmkBq
RUGKk7x81BVspM/BwwQbCrEBv0cYHdDzVyZdZbFCCU9QgrhDgaOTFcH5uDdbAAUR
tCRUb20gU3QgRGVuaXMgPHRvbXN0ZGVuaXNAZ29wbGF5LmNvbT6JAJUDBRA3tsSI
o5MVwfm4N1sBAaukA/90Y2Wyxh4eOV1qfFPs27vtXWjCgZjFX73S/KuMDVvDbLeV
YBX6hIpUmyw9bo6uhnjDMsdyt/no4PksnBaRVARxHnoQwfQp13Y/4k9c7qx59U3j
GURhN7yel1sns7kTKbwJEkSmOq+BJUe4J9OvUpbN3fyTzKybRfbkYXNTkYuZzw==
=bLDF
=====END PGP PUBLIC KEY BLOCK=====
It's available off my website as well (if you want to compare it).
Hopefully I won't have to make a new key anytime soon.
Thanks for your time,
Tom
--
PGP 6.5.1 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] (SCOTT19U.ZIP_GUY)
Subject: Re: New encryption algorithm
Date: Sun, 15 Aug 1999 15:58:40 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(JPeschel) wrote:
>>[EMAIL PROTECTED] writes:
>
>>But lets theoretically assume that this algorithm really is
>>revolutionary and that its author would be able to make money on its
>>patent. In this case how can he insure his idea from being stolen by
>>somebody else who could simply patent it first and become the inventor
>>of
>>the algorithm in terms of law?
>
>He could present it at a crypto conference or publish it in a respected
>journal first.
>
>Joe
>
Actual this is not true. IF it really is revolutionary and out if the main
stream. You would never get it published in a journal since you are an
outsider. Oh they might do it if it is weak so they can poke fun at it,
But it would never see the light of day if it was good and not previously
blessed by a crypto god. About the only way it will get published is when
one of them highly respected people steals your method.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Clerification of Crypto Export Laws
Date: Sun, 15 Aug 1999 15:12:17 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(JPeschel) wrote:
>>[EMAIL PROTECTED] writes:
>
>>2) If someone used a half baked encryption scheme (just something that
>>they made up), does it still apply to the Laws? (Something like
>>shifting, xoring, etc, nothing big)
>
>Hardly seems worth the bother of getting a license. Many shareware
>companies and re-distributors don't bother with getting a license
>at all and haven't had any trouble.
>
>I think the ACA still has come classical ciphers on its web page.
>John Savard or Jim G. might know whether it needed a license
>to make those available. I would guess not.
>
>A while ago, I think Doug Gwyn posted some code that would XOR
>to files with each other. He didn't seem terribly worried about it.
>
>If it were me, I would post the code and not lose any sleep.
>
>Joe
>
I think the intent of the government is to make so many laws
that no matter who you are you will break some and can be put
in jail with ease. The point is you are already breaking many laws
in this country and you could go to jail. Unless you have a large
number of politically correct friends to help you.
Under out present kanagroo ( no offensive to out assie friends)
system of justice. Any police officer can just take you car and claim
that it might someday be used for drugs. You have no legal recouse
and this is happening more and more. The cop arrested your car
not you, The something happens to your money and the cop finds
money on you. If he feels it might someday be used for drugs
its gone. I am not joking our legal system really his gone
done the toilet this bad but few understand this. A few years
ago I think it was ABC that did a story about this but have
not heard much about it for years.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Do I have a problem with semantics?
Date: Sun, 15 Aug 1999 16:14:22 GMT
I
>It seems that you misunderstood definition of "unconditional secrecy".
>
>(Security is a multi-faceted notion, of which secrecy is one aspect. I
>use the term "unconditional secrecy" to emphasis the aspect of security
>we're talking about). In information theory, the intuition behind
>"information" is that information is reduction of uncertainty.
>Computational complexity is not constrained.
>
>"Unconditional secrecy" means that seeing a ciphertext does not provide
>the adversary with any information about the plaintext, regardless of
>how much computation he does.
>
>Before the adversary sees a ciphertext, he may have an a priori
>probability assigned to every possible plaintext, reflecting his
>(partial) knowledge about the source. If the cipher is such that after
>seeing the ciphertext, the conditional probability of each possible
>plaintext (conditioned on the observed ciphertext) is exactly the same
>as its a priori probability, the cipher has unconditional secrecy. In
>other words, seeing the ciphertext does not affect the adversary's
>estimate of the relative likelihood of each possible plaintext,
>regardless of how much computation he does.
>
>I can think of a loosely analogous situation in which the lack of
>information defeats any computational attempt to find the answer.
>Consider an underdetermined system of linear equations (say 5 unknowns
>but 4 equations). No matter how much computation you do, you can't
>narrow the solutions down to a unique one.
>
>> 4. Semantics density creates favorable conditions. (But this may
>> not be an issue alone)
>
>I haven't come across the term "semantic density". How is it defined?
>
>Nicol
This is why one should always try to increase the entopy of messages before
they are sent. The best way that I know of is the use h2com.exe from my web
site. It is a very agressive "adaptive huffman compressor" with out any
headers. Several example are at me site, In the list of example it is the 3rd
set of outputs, The first being the file to compress and the second being the
output of a standard adaptive huffman compressor.
There are several adavatages of a dynamic over a static huffman. One you
don't need to waste space with static table.
2 if you goal is all or nothing a static method can be easily resynched if top
part of file missing and why make it easy it should be "all or nothing"
The biggest advantage is that my compression routines contain no headers
and any file could be a compressed file ( could be longer) but the key is that
there is no information as to leak to an attacker trying to guess the keys.
For the latest and best compression for a first pass before encyption see
my compression page http://members.xoom.xom/ecil/compress.htm
this page friendker to java script browsers than my main page which would
try to stuff a cookie down your browser.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: New encryption algorithm
Date: 15 Aug 1999 14:02:56 GMT
>[EMAIL PROTECTED] writes:
>But lets theoretically assume that this algorithm really is
>revolutionary and that its author would be able to make money on its
>patent. In this case how can he insure his idea from being stolen by
>somebody else who could simply patent it first and become the inventor
>of
>the algorithm in terms of law?
He could present it at a crypto conference or publish it in a respected
journal first.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: [EMAIL PROTECTED] (Matthias Bruestle)
Subject: Re: Smart card generating RSA keys
Date: Sun, 15 Aug 1999 14:15:58 GMT
Mahlzeit
Peter Gutmann ([EMAIL PROTECTED]) wrote:
> The comment about "simply a random number" hides a lot of detail. With any
> type of PKC (conventional or ECC), you can't generate good keys without a
> source of unpredictable random numbers, something which is virtually
> unobtainable in a smart card.
I wonder why the don't let supply true random number with the key
generation command and mix this with internal bad random numbers.
Mahlzeit
endergone Zwiebeltuete
--
PGP: SIG:C379A331 ENC:F47FA83D I LOVE MY PDP-11/34A, M70 and MicroVAXII!
--
I hit myself and it was good.
-- Stuart Woolford
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: NIST AES FInalists are....
Date: Sun, 15 Aug 1999 14:06:50 GMT
In article <[EMAIL PROTECTED]>,
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > Well as for brute force if the keyspace is flat the fastest method
is
> > parallel linear searches. No matter what algorithm you use it will
not
> > be faster then testing all keys sequentially (unless the keyspace is
> > not flat).
>
> That is an incredible assertion. What is the mathematics behind it?
> It sounds like a very important theorem, if true. (As you might
> infer, I do not think it is true.)
Well if all keys are equal then the fastest brute force method is to
try them all (or half on avg.). Therefore a parallel linear search
would be the fastest. If for example keys are equivelent (i.e
complementation in DES) you add that in as a factor in your search
(it's still pretty much a linear search though).
I can't think of any faster method to test n equal keys...
> > BTW I seriously doubt in the 70's they had the ability to search the
> > DES keyspace in less then a year.
>
> You would lose your bet.
Ooops.. well no money on it. Well what companies had the power to
search the keyspace?
Tom
--
PGP 6.5.1 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: NIST AES FInalists are....
Date: Sun, 15 Aug 1999 15:43:29 GMT
In article <[EMAIL PROTECTED]>,
Rochus Wessels <[EMAIL PROTECTED]> wrote:
(...)
> The Attack on Frog may be practical for some protocols.
(...)
> To do the 2^56.7 work and acquire the 2^36 chosen ciphertexts in one
> hour isn't very far out of reach, (...)
If we are prepared to imagine a real world protocol that decrypts 2^36
chosen blocks (a thousand Gigabytes) with the same key we should also
be prepared to imagine a protocol that leaks the key as plaintext. I
don't think that such a gedankenexperiment can lead us to any
meaningful result.
Schneier's group attack on Frog is significant in the sense that it
uncovers a fact about variable ciphers such as Frog: that some of the
cipher instances will necessarily be "weaker" than others. The basic
idea of Frog is to deny the attacker detailed knowledge of how a
plaintext has been encrypted. Frog achieves this in the following
manner: it takes the secret key, expands it into a longer pseudo-random
array, "compiles" this into a sequence of individually reversible
instructions, and uses the resulting "program" to encrypt or, running
in backward order, to decrypt. (Observe that nothing whatsoever is
build into Frog as a defense against a known type of attack.) Even
though there exist much more general types of Frog than the one
submitted to NIST, I think all share this weakness: some of the keys
will produce "programs" that are less than ideally strong against a
particular attack.
The meaningful thing to do now is to ask what the significance of this
is. A few of the keys of a Frog-like cipher will be weak, but the
variable nature of this cipher makes it very unlikely that an attack
will be discovered for which all or a large fraction of the keys will
be weak. On the other hand, with a conventional "fixed wire" cipher it
is much more probable that an attack exists that works against all the
keys.
The possibility that someone in the future discovers a practical attack
against the AES is the *only* thing that should worry us. I think that
fixed wire ciphers are especially vulnerable in this sense.
Conceptually simple ciphers such as RC6 or ciphers that mix different
types of rounds such as MARS may have a slight advantage. Critical
applications should better combine in series ciphers of different type
and not depend on only one wire diagram, no matter how polished.
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
******************************
