Cryptography-Digest Digest #610, Volume #11 Sat, 22 Apr 00 23:13:01 EDT
Contents:
Re: Tutorial on text encryption (Paul Schlyter)
Re: AES Style CAST Cipher (Tom St Denis)
Re: Requested: update on aes contest (stanislav shalunov)
Re: MERCY large block cipher ("Scott Fluhrer")
Re: GSM A5/1 Encryption (Guy Macon)
Re: OAP-L3: Secure, but WAY more dificult to use than other equally (Guy Macon)
Re: Primality Test-how many iterations suffice for n digit number ? (Scott Contini)
Re: The Illusion of Security (Terry Ritter)
(MERCY) Overcomming the slack used by IV's (Tom St Denis)
Re: The Illusion of Security ("Joseph Ashwood")
Re: factor large composite ("Joseph Ashwood")
Re: The Illusion of Security (Tom St Denis)
Re: The Illusion of Security (Tom St Denis)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: Tutorial on text encryption
Date: 23 Apr 2000 01:40:40 +0200
In article <efr6foKr$GA.227@cpmsnbbsa03>,
Joseph Ashwood <[EMAIL PROTECTED]> wrote:
>How secure do you want it?
>If you don't care about security, try this
>randseed(key);
>for all i
> data[i] = data[i] XOR rand();
>end for
>
>it's not portable, but it will probably work short term.
Why not instead:
for all i
data[i] = data[i] OR 0xFF
end for
??? This cipher is VERY secure... :-))))
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: pausch at saaf dot se or paul.schlyter at ausys dot se
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: AES Style CAST Cipher
Date: Sun, 23 Apr 2000 01:26:44 GMT
Tom St Denis wrote:
>
> At http://24.42.86.123/cipher.c is a clearly commented copy of a 128-bit
> block cipher based that uses the CAST style sboxes. Essentially I
> copied the ones from CAST-128.
>
> The cipher is very simple, it's fast and it's a balanced feistel, unlike
> CAST-256 which is not. The Key schedule is very complete in the sense
> that every bit of the key is used in each round very quickly.
>
> The source is complete it includes the sboxes, the ECB encrypt/decrypt
> and the key schedule.
>
> Please let me know what you think.
>
> Tom
I made some minor modifications to the round structure to make it
simpler, which I put up about 30 mins ago.
I also did some timing tests and the same C ref optimized via DJGPP
(-O3 -mpentium) gives 10 Mbyte/sec performance, which is not too bad.
That translates roughly to 650,000 blocks a second, or 38.46 cycles/byte
on my K6-II 400mhz. I know this is not in the 20 cycle/byte range, but
I bet with tons of ASM optimizations (I can name a few obvious ones) 30
cycles/byte will be easy to obtain.
You can get a copy of it via http://24.42.86.123/cipher.c and it
includes the short timing test.
Why do I think it's noteworthy (for those of you reading the post saying
shut up dumb kid). Well I use the sboxes from CAST-128, which doesn't
automatically make it secure, but at least they are not arbitrary. It's
also a cipher design using components from CAST that is not a unbalanced
feistel. I chose a balanced feistel instead.
I have one question... If you look at my source I have the PHT then the
key mixing... should it be the other way around? I just left it like so
because I don't know which is better...
Tom
------------------------------
Subject: Re: Requested: update on aes contest
From: stanislav shalunov <[EMAIL PROTECTED]>
Date: Sun, 23 Apr 2000 01:29:06 GMT
Tom St Denis <[EMAIL PROTECTED]> writes:
> I think all crypto should be in software simply because I would tend
> to trust what I can see more then what's inside a little IC.
How do you "see" what your binary executable does?
Do you trust your compiler?
Do you trust your standard libraries?
Do you trust your kernel?
Do you trust your kernel modules?
Do you trust the compiler your compiler was built with?
Do you trust the compiler that the previous compiler was built with?
...
Do you trust that your account isn't broken into?
It's much more difficult to tamper with hardware. And embedding
secret backdoors in block cipher chip is tough: symmetric encryption
is a deterministic operation; it interoperates, or it's tampered with.
Purely hardware RNGs are a different matter: stuff that could look
very random could very well be some 512-bit-block cipher counter mode.
> Tough, I like twofish, you like serpent... we both suck or what?
You can like whatever you want. You can also use whatever you want.
But duliting standards for flexibility makes no sense. You get
FTP protocol on this road: a tremendously bloated and complicated
protocol for trivial purpose. Or IPSec.
Anyway, we're not on some committee that will standartize on a protocol.
And it's very good that no such committee exists.
--
stanislav shalunov | Speaking only for myself.
My address in From: is correct; if yours isn't, I don't want to hear from you.
Try to reply in newsgroup. I don't need courtesy copies.
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: MERCY large block cipher
Date: Sat, 22 Apr 2000 18:14:39 -0700
Tom St Denis <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> For FSE2000 there was a presentation on a large block cipher called
> MERCY? I was wondering if the team has a webpage or something...
http://www.cluefactory.org.uk/paul/mercy/
The "team", as it were, consists of Paul Crowley.
--
poncho
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: GSM A5/1 Encryption
Date: 22 Apr 2000 21:57:41 EDT
In article <8dsf8h$qk0$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (David A. Wagner) wrote:
>
>In article <8dakoh$6jl@journal>, Guy Macon <[EMAIL PROTECTED]> wrote:
>> The idea that I have ever advocated any change to the
>> internals of any well analyzed crypto method is pure fantasy.
>
>Well, either you have to modify the internals of the ciphertext
>frame format and the crypto, or you have to modify the internals
>of the plaintext frame format and the speech coding. In GSM,
>the frame length and speech coding format are finely tuned and
>interdependent on each other; you can't just change one and ignore
>the other.
Absolute nonsense. I have to do no such thing. Just as I am able to
add random characters at the start and end of a character based plaintext,
I can add a second or two of white noise from a true random source to
the start and end of every voice message. Now please explain to me how
this in any way modifies any GSM internals.
You are also ignoring the fact that it was YOU who said that this
coversation was about cyphers in general and not just GSM. In fact,
looking at your responses, I see a clear pattern of you ignoring any
portion of what I write in which I prove you wrong. Sorry, but I am
here to learn, not to observe cheap debating tricks. I will seek out
those who are willing to teach me and maybe even learn from me.
>The bottom line is, for GSM, I suspect the type of change you
>advocate will not be nearly so easy as you seem to believe.
>
>In any case, even if you find a way to implement it, you will lose
>something like 15% of bandwidth. That's a huge overhead, for a
>security benefit that can be achieved other ways without any overhead.
You cannot describe a method to achieve the (slight) security benefit
in other ways without any overhead. If you could, you would have done
so. I have zero confidence that you will actually read and try to
understand the following, but here it is for the 4th time:
*********************** START OF DESCRIPTION ************************
Assume that you have been dillegent and have set up the best possible
choice for crypto algorithm, combined with a well designed security
system that addresses non-crypto attacks.
Assume that your system is widely believed to be strong when faced
with chosen plaintext attacks, and that this has been tested by a
number of experts.
Given the above assumptions, you can achieve a slight increase in
your overall security by adding a random number of random bits to
the beginning and end of your message before doing any encoding.
It is highly probable that this will not increase security, but
if a weakness to a known plaintext or chosen plaintext attack is
discovered in the future, the random bits will make part of the
message unknown and unchosen, and will introduce an unknown and
unchosen offset of where the first character of the message starts,
thus possibly making the known plaintext or chosen plaintext attack
infeasable.
The cost of doing this is very low, and can be chosen to be as low
as the user desires. If 1% at the beginning and at the end is too
much, make it 0.1%.
This addition will work with all known crypto programs. They all
accept plaintext, and will accept plaintext that is partially
random bits.
In most cases it is not necessary to remove the random data when
the message is decoded. It is trivial for a human to differentiate
random data data in print or audio from an intelligable message.
*********************** END OF DESCRIPTION ************************
I am waiting for your description of the "security benefit that can
be achieved other ways without any overhead." It would seem that
all such methods would have been applied in the first paragraph of
my description above.
Then again, you seem to be replying to some internal voice rather than
what I actually post in actual messages, so I fully expect you to once
again fail to address what I write. At least you are entertaining.
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: Secure, but WAY more dificult to use than other equally
Date: 22 Apr 2000 22:02:32 EDT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Tom St Denis) wrote:
>
>
>
>lordcow77 wrote:
>>
>> In article <[EMAIL PROTECTED]>, Anthony Stephen
>> Szopa <[EMAIL PROTECTED]> wrote:
>> >I just put you in my permanent kill file then I read this.
>>
>> Hello?!?! If he were in your killfile, you wouldn't even see his
>> message. If your understanding of how to use simple newsreader
>> software is so defective (or you're just a blustering liar), how
>> can it be expected that your cryptography software is any better.
>
>Not to be irrevelant but for someone that pulls apart my language you
>should have said "cryptographic software" not "cryptography software"..
I have seen software that is cryptographic here, but some of the
software here is just cryptic.
>Hehehe, I am just joking around.
>
>Tom
Me too.
Guy
------------------------------
From: [EMAIL PROTECTED] (Scott Contini)
Subject: Re: Primality Test-how many iterations suffice for n digit number ?
Date: 23 Apr 2000 02:20:47 GMT
In article <[EMAIL PROTECTED]>,
Francois Grieu <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] (Scott Contini) wrote:
>> Francois Grieu <[EMAIL PROTECTED]> wrote:
>>> According to Robert D. Silverman (*), citing an article by
>>> I. Damgard, P. Landrock et C. Pomerance, for numbers 512 bits
>>> or more, 8 Miller-Rabin tests are enough for an error
>>> probability below 2^-100.
>>
>> This assumes that the number to be tested for primality was selected
>> randomly. If you don't know anything about where the number came from
>> (for example, if somebody e-mailed you some number and asked you to
>> test if it were prime) then you would require 50 iterations to
>> have probability below 2^-100.
>
>I understand Scott's point: randomly seeded primes is an hypothesis in
>the reasoning used to get to the 2^-100 estimate [and is verified in
>the technique proposed in Robert D. Silverman's paper]. I should have
>mentioned it.
>
>This said, I wonder (= dont know at all) if there is a workable way
>to construct a 512 bit number which will pass the strong pseudoprime
>test for
>
>a) even one randomly chosen witness, with reasonable probability
> (variant: random small prime witness)
>
>b) a few given small primes (say the 8 first).
>
>
> Francois Grieu
I think the answer is yes. The "Carmichael numbers" are the numbers which
cause the most difficulty in this primality test. Red Alford showed how
to construct many Carmichael numbers (for example, he first proved
by construction the existence of 2^128 -1 Carmichael numbers), and then Carl
Pomerance and Andrew Granville joined him to prove that there are infinitely
many Carmichael numbers. If my memory is correct, their paper, titled
"There are infinitely many Carmichael numbers", shows how to construct
Carmichael numbers that pass the strong pseudo prime test (aka as
Miller-Rabin test) to arbitrary bases.
By the way, I call it the "strong pseudo prime test" to describe the
primality test rather than "Miller-Rabin test" since John Selfridge
had discovered the test long before Miller and Rabin published their
result, but unfortunately Selfridge did not publish it. A couple
decades ago, there were a group of number theorsists that did some
nice work and shared the results among each other (which, at that
time, constituted most of the people that were interested in the
results). However, due to number theory becoming much more popular
over that last 30 years or so (which can be credited a lot to
cryptography), publishing in the field has become much more important,
and hence many things were re-invented. This is not to
take any credit away from Miller and Rabin (indeed, they proved that
a number fails the test with probability at most 1/4 per iteration),
but it is my way of recognizing the contributions that some of the
earlier number theorists made.
Scott
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: The Illusion of Security
Date: Sun, 23 Apr 2000 02:22:55 GMT
On Sun, 23 Apr 2000 01:04:01 GMT, in <[EMAIL PROTECTED]>,
in sci.crypt Tom St Denis <[EMAIL PROTECTED]> wrote:
>Terry Ritter wrote:
>> >Ok, what is the alternative?
>>
>> The first thing we can do is realize that cipher technology has
>> nothing like the engineering and manufacturing control that we assume
>> and expect in every other product we use and buy. Because of this,
>> the present state of the art does not give us sufficient information
>> to trust any cipher, no matter who has made or approved it.
>>
>> Consequently, we should avoid representing to others that a cipher is
>> "probably" unbreakable, since we can have no real understanding of
>> what those probabilities actually are.
>>
>> What we can do is to accept the unfortunate cryptographic reality as
>> being beyond that addressed by conventional cryptographic wisdom. So
>> if we are to improve our situation, it will be necessary to do
>> something *different* from the way cryptography has been done in the
>> past. For example, we might seek to innovate protocols and strategies
>> which reduce our exposure and minimize our desirability as a target.
>> And since we cannot know when we are being successfully attacked, we
>> might seek to use ciphers in ways which terminate any such success.
>>
>> Endlessly using the same cipher as everyone else is to join the group
>> which is the ideal target for attack. One alternative is to use
>> ciphers which not everyone uses. Because less data are protected
>> under these ciphers, they provide less payoff for successful attack,
>> and that may reduce our opponents' motivation to choose us as their
>> target. We can change ciphers frequently, which compartmentalizes our
>> data, and also provides less payoff for a successful attack on any
>> single cipher. Presumably there are various other approaches as well,
>> but they all require *doing* something which has not generally been
>> part of academic cryptography to date. That means we will not find
>> these answers in cryptographic texts.
>>
>> In the end, we cannot trust the ciphers we use, no matter who has made
>> or approved them. Doing the same as everybody else just makes us part
>> of the most obvious and rewarding target. To improve our situation,
>> we must do something beyond what conventional cryptography recommends.
>
>You are not being realistic. We cannot throw away all current symmetric
>ciphers just because you feel less warm and fuzzy about them. Symmetric
>ciphers are used millions of times a day, and they do have an impact on
>theft and compromise, therefore they must be doing there job.
Nonsense. It is *you* who are not being realistic: Being realistic
means addressing facts and reality. Our limitations in knowing cipher
strength are obvious facts. You can stick your head in the sand, but
the facts will remain nevertheless.
I have not suggested that we "throw away all current symmetric
ciphers." As far as I can tell you made that up. Using asymmetric
ciphers would not change the basic problem.
>True 100 years from now (or 50, or 25) AES may become weaker then
>conjectured, but for now we can assume that AES will be secure and not
>the point of attack.
First, AES cannot "become weaker;" any particular design will not
change through time. So if AES would be weaker in 100 years, it is
weaker *now*. It is only "our" knowledge that may change. But *our*
knowledge is *not* the same as our opponents' knowledge, and that is
the problem. We simply have no basis for assuming that our opponents
have the same limitations we do. Personally, I expect that some of
our unknown opponents are far more accomplished than any academic we
know.
Simply *assuming* that AES is secure is unwarranted, and encouraging
others to believe this is actually *deceptive*, unless of course you
have evidence to back up your claim. But there is no such evidence.
You can assume whatever you want, but there is no scientific basis for
it. That is not reality, and that is not being realistic.
>The alternative of course is to ditch all symmetric ciphers, send all
>information as plaintext and say "this is the best we can do".
That would be *your* alternative. I would not suggest that, and I
have described whole ranges of more appropriate alternatives.
>While your point of view is appropriate your attitude is not.
>Tom
My attitude? You mean like addressing uncomfortable reality instead
of insisting that it does not exist, or that we can't do anything
about it anyway? Well, yes, I guess my "attitude" would be
uncomfortable if you assume that the conventional wisdom knows best,
and all that society needs to know has been properly addressed by
academics. But in this case it does not take very much insight to see
that such an assumption is appallingly, obviously and massively false.
Conventional cryptography is built on a foundation of sand. Until the
ramifications of a contest against unknown and unknowable opponents
are addressed, there can be no deep understanding of what cryptography
means or what it can realistically provide. That would be distinctly
different from assuming a cipher is strong because everybody thinks it
must be.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: (MERCY) Overcomming the slack used by IV's
Date: Sun, 23 Apr 2000 02:24:02 GMT
The motivation behind MERCY apparently is that normal block ciphers need
IV's to become secure over a large range of blocks. However why can't
you just expand the sector number to the size of the block?
For example on a FAT32 system each sector is designated by a 32 bit
number, well why can't you just do something like
s = sector #
IV = s || s || s || s
(for a 128 bit block)
Or use the 's' as a seed for a word sized LFSR and make the Iv that way?
Basically you don't need to implicitly store the IV to use one. just
derive it from the sector number.
I.e MERCY is moot.
Tom
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: The Illusion of Security
Date: Sat, 22 Apr 2000 19:20:28 -0700
> You are not being realistic. We cannot throw away all
current symmetric
> ciphers just because you feel less warm and fuzzy about
them. Symmetric
> ciphers are used millions of times a day, and they do have
an impact on
> theft and compromise, therefore they must be doing there
job.
Actually Ritter has to my knowledge never proposed such a
drastic concept, what he has always encouraged, and I
presume will rightfully continue encouraging, is that one
should be realistic and more importantly conservative in our
statements of the strength of a cipher. I generally try to
make statements like "Cipher X is currently considered
strong" or "There are no known useful attacks against cipher
x in spte of the fact that it has been analysed heavily"
>
> True 100 years from now (or 50, or 25) AES may become
weaker then
I would say will almost certainly be weaker than we
currently believe.
> conjectured, but for now we can assume that AES will be
secure and not
> the point of attack.
>
> The alternative of course is to ditch all symmetric
ciphers, send all
> information as plaintext and say "this is the best we can
do".
No the alternative is to qualify what you say. Just as
various people (including yourself) have made rather
inflated claims of the security of an algorithm.
Will we ever be able to judge the real security of a cipher?
A very debatable proposition, but I do think that in time we
will be able to make probable conjectures as to the strength
of an algorithm, but I'm not sure if we can, generally, gain
a high probability of correctness. Right now all we can say
is that the expected strength against a certain attack is a
value, but we cannot conjecture against unknown attacks.
Perhaps I'm wrong, and we will never be able to raise the
lower limit above 0. Either way it's a currently pointless
exercise in argument, because our certainly is always 0. Mr
Ritter has acknowledged this and has often sought to make it
clear that in his view all we can do is stack the deck, so
to speak, by taking precautions that would oft-times seem
foolish to many.
Joe
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: factor large composite
Date: Sat, 22 Apr 2000 19:25:23 -0700
> Do you mean for all primes of that size?
Ye I meant all the primes of that size. Even if you can find
an algorithm that takes 1/(10^100) of the size it will still
be too big. Of course algorithms grow at different speeds,
but often the first step involves storing some large
quantity of primes in memory.
> It is even perfectly possible
> to factor a 1024 bit number on a 64k system...
Given an infinite amount of time, it would be possible to
factor it on a system with 2048 bits of RAM plus code space,
through trial division by all numbers. In order to factor
using the more advanced methods, 512 bits takes several
gigabytes of RAM.
Joe
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: The Illusion of Security
Date: Sun, 23 Apr 2000 02:30:31 GMT
Terry Ritter wrote:
> >True 100 years from now (or 50, or 25) AES may become weaker then
> >conjectured, but for now we can assume that AES will be secure and not
> >the point of attack.
>
> First, AES cannot "become weaker;" any particular design will not
> change through time. So if AES would be weaker in 100 years, it is
> weaker *now*. It is only "our" knowledge that may change. But *our*
> knowledge is *not* the same as our opponents' knowledge, and that is
> the problem. We simply have no basis for assuming that our opponents
> have the same limitations we do. Personally, I expect that some of
> our unknown opponents are far more accomplished than any academic we
> know.
That's the thing, a cipher is only insecure if we know it is. If
99.99999% of all the people on earth cannot break a cipher, then I will
use it. Them's the facts. Cuz I really only want to use a cipher to
keep people like you, and the rest of the group from snooping in my
email, etc.. If only one person in this world can read my private email
(other then the intentends) good for him/her.
> Simply *assuming* that AES is secure is unwarranted, and encouraging
> others to believe this is actually *deceptive*, unless of course you
> have evidence to back up your claim. But there is no such evidence.
> You can assume whatever you want, but there is no scientific basis for
> it. That is not reality, and that is not being realistic.
> >The alternative of course is to ditch all symmetric ciphers, send all
> >information as plaintext and say "this is the best we can do".
>
> That would be *your* alternative. I would not suggest that, and I
> have described whole ranges of more appropriate alternatives.
Such as, in your point of view no prng is secure, therefor we are back
to the OTP...
> >While your point of view is appropriate your attitude is not.
> >Tom
>
> My attitude? You mean like addressing uncomfortable reality instead
> of insisting that it does not exist, or that we can't do anything
> about it anyway? Well, yes, I guess my "attitude" would be
> uncomfortable if you assume that the conventional wisdom knows best,
> and all that society needs to know has been properly addressed by
> academics. But in this case it does not take very much insight to see
> that such an assumption is appallingly, obviously and massively false.
Some caution is warranted, but you have to work with what you are
given. If I had to make a program to encrypt money transactions, I
would rather use DES with it's 56 bit key then nothing. Likewise with
the AES ciphers.
> Conventional cryptography is built on a foundation of sand. Until the
> ramifications of a contest against unknown and unknowable opponents
> are addressed, there can be no deep understanding of what cryptography
> means or what it can realistically provide. That would be distinctly
> different from assuming a cipher is strong because everybody thinks it
> must be.
People don't just say "oh it looks strong". People attack it from every
which angle and say this is the best we can do. Then others do
similar. After 100s of people do similar we can assume it's most likely
secure.
Which is more probable though. Having 1000s of scientists test, probe
and disect the cipher to find no real flaws, only to have a hidden group
find the flaws? or that they didn't find anything because we won't find
anything?
Tom
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: The Illusion of Security
Date: Sun, 23 Apr 2000 02:33:18 GMT
Joseph Ashwood wrote:
>
> > You are not being realistic. We cannot throw away all
> current symmetric
> > ciphers just because you feel less warm and fuzzy about
> them. Symmetric
> > ciphers are used millions of times a day, and they do have
> an impact on
> > theft and compromise, therefore they must be doing there
> job.
> Actually Ritter has to my knowledge never proposed such a
> drastic concept, what he has always encouraged, and I
> presume will rightfully continue encouraging, is that one
> should be realistic and more importantly conservative in our
> statements of the strength of a cipher. I generally try to
> make statements like "Cipher X is currently considered
> strong" or "There are no known useful attacks against cipher
> x in spte of the fact that it has been analysed heavily"
>
> >
> > True 100 years from now (or 50, or 25) AES may become
> weaker then
>
> I would say will almost certainly be weaker than we
> currently believe.
>
> > conjectured, but for now we can assume that AES will be
> secure and not
> > the point of attack.
> >
> > The alternative of course is to ditch all symmetric
> ciphers, send all
> > information as plaintext and say "this is the best we can
> do".
> No the alternative is to qualify what you say. Just as
> various people (including yourself) have made rather
> inflated claims of the security of an algorithm.
>
> Will we ever be able to judge the real security of a cipher?
> A very debatable proposition, but I do think that in time we
> will be able to make probable conjectures as to the strength
> of an algorithm, but I'm not sure if we can, generally, gain
> a high probability of correctness. Right now all we can say
> is that the expected strength against a certain attack is a
> value, but we cannot conjecture against unknown attacks.
> Perhaps I'm wrong, and we will never be able to raise the
> lower limit above 0. Either way it's a currently pointless
> exercise in argument, because our certainly is always 0. Mr
> Ritter has acknowledged this and has often sought to make it
> clear that in his view all we can do is stack the deck, so
> to speak, by taking precautions that would oft-times seem
> foolish to many.
> Joe
This is pure garbage. We can measure the security of a cipher right
now. Are our measurements definative? No.
We can tell when a cipher is obviously or subtly flawed (DES, FEAl, RC5,
Blowfish, CAST, 3-WAY, IDEA, RC2, RC6, Twofish, Serpent..... all have
detected problems). But is it conclusive? No really. Just like any
statistiscal test is not the final answer.
Tom
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and sci.crypt) via:
Internet: [EMAIL PROTECTED]
End of Cryptography-Digest Digest
******************************
