Cryptography-Digest Digest #926, Volume #11 Fri, 2 Jun 00 19:13:01 EDT
Contents:
Re: Solovay-Strassen primality test (Marek Futrega)
Re: Contest rule proposal (Mark Wooding)
Re: Contest rule proposal (Mark Wooding)
Re: DVD encryption secure? -- any FAQ on it (Bryan Olson)
Re: Finding primitive polynomials via the Berlekamp method? (Mok-Kong Shen)
Cipher design a fading field? ([EMAIL PROTECTED])
Re: Cipher design a fading field? (tomstd)
Re: XTR (was: any public-key algorithm) (Ian Goldberg)
Re: Good ways to test. (Mok-Kong Shen)
Re: Good ways to test. (tomstd)
Re: Good ways to test. (Terry Ritter)
Re: Contest rule proposal (Terry Ritter)
Re: Finding primitive polynomials via the Berlekamp method? (Terry Ritter)
Re: Contest rule proposal (Terry Ritter)
Re: Good ways to test. (tomstd)
Re: Finding primitive polynomials via the Berlekamp method? (Terry Ritter)
Re: Contest rule proposal (tomstd)
Re: Cipher design a fading field? ("Paul Pires")
----------------------------------------------------------------------------
From: Marek Futrega <[EMAIL PROTECTED]>
Subject: Re: Solovay-Strassen primality test
Date: Sat, 3 Jun 2000 00:08:56 +0200
On Fri, 2 Jun 2000, Bob Silverman wrote:
> > The basis of the Solovay-Strassen algorithm is the fact that for any
> > given composite number "n", there are at most n/2 values of "a" less
> > than "n" for which "n" is an Euler pseudo-prime with base "a".
>
> Hint: Think about Euler's criterion for quadratic reciprocity.
>
It doesn't help me much.
M.
___
[EMAIL PROTECTED]
http://rainbow.mimuw.edu.pl/~maf
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Contest rule proposal
Date: 2 Jun 2000 22:06:16 GMT
Terry Ritter <[EMAIL PROTECTED]> wrote:
> The claim that "stream ciphers are stateful; block ciphers are
> stateless" is true as a generalization only. Another generalization
> is that block ciphers require the accumulation of data, and stream
> ciphers do not.
Err... So then a construction which uses a block cipher in CBC mode is a
block cipher still, even though it doesn't operate on a block, whereas
the same underlying cipher used in a CFB construction becomes a stream
cipher. That seems to be lacking logic to me. (Yes, I can implement
CFB in an unbuffered way.)
> Now, shall we reject any block cipher proposal which uses cipher block
> chaining (CBC)?
The underlying block cipher is clearly eligible.
I see block ciphers as being convenient primitive operations from which
useful things like stream ciphers (with which you can actually encrypt
large chunks of data), and hash functions may be constructed. I don't
see them as things to use on their own.
-- [mdw]
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Contest rule proposal
Date: 2 Jun 2000 22:14:27 GMT
Mark Wooding <[EMAIL PROTECTED]> wrote:
> Terry Ritter <[EMAIL PROTECTED]> wrote:
>
> > Now, shall we reject any block cipher proposal which uses cipher block
> > chaining (CBC)?
>
> The underlying block cipher is clearly eligible.
In fact, I'd go as far as to suggest that, while DES is a block cipher,
DES-ECB (which maintains no extra state) is a stream cipher.
But I'm probably just weird.
-- [mdw]
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: DVD encryption secure? -- any FAQ on it
Date: Fri, 02 Jun 2000 22:09:22 GMT
David A. Wagner:
> Bryan Olson wrote:
> > Casper H.S. Dik
> > > the disks are just a bunch
> > > of bits; you can read them you can copy them
> >
> > Giving you a copy of a bunch of bits that will not play as a
> > movie. And to even get those bits requires defeating part
> > of the system.
>
> Err, as far as I can see, that's just not true.
> Did you mean something different?
>
> Making bit-for-bit copies is exactly what the studios do when
> they release DVD's; the result pretty clearly does play as a movie,
> and I can't imagine the result will be any different when it's a
> pirate wielding the equipment.
What I mean is that having the bunch of bits - the easy part
of the copying process - is not sufficient. You have to
create media that looks like a legit DVD. It is not the
case that if one can read a DVD one can make a (working)
bit-for-bit copy.
> Sure, bit-for-bit copying requires special hardware, but so what?
> That's also (roughly) true for piracy of CD's, and that clearly
> hasn't made the problem go away.
Normal industrial access to the special hardware for CD's
doesn't require entering into the same kind of secrecy
agreements required to get into the DVD game. Also, now
there's consumer equipment will copy CD's.
> Actually, I'm told that the DVD
> pressing process was specially designed so that CD-pressing equipment
> could be used to press DVD's with little modifications.
Right, but that ignores the mastering process.
Incidentally, I have two computers that can play DVD movies,
three computer DVD drives, two PCI DVD decoders, several
working versions of three software players and a set-top DVD
player. I've defeated Macrovision everywhere and region
coding on the computers. I've modified hardware, firmware
and software. I've de-CSS'ed and played the result from a
hard-drive. I've made bit-for bit copies of CD's. But in my
many hours if research (=surfing) on the subject, I have not
even heard anyone report success in making working
bit-for-bit copies of protected DVD's.
If the (now broken) DVD protection system was not a copy
protection mechanism at all, how come it prevented so many
people from making copies? If someone thinks that nothing
stops them from making bit-for-bit DVD copies, would it be
too much to ask that they actually do so before telling us
how easy it is?
--Bryan
--
email: bolson at certicom dot com
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Finding primitive polynomials via the Berlekamp method?
Date: Sat, 03 Jun 2000 00:30:58 +0200
Terry Ritter wrote:
> All primitive polynomials are irreducible, but irreducibles are not
> necessarily primitive, unless the degree of the polynomial is a
> Mersenne prime. One way to find a primitive polynomial is to select an
> appropriate Mersenne prime degree and find an irreducible using
> Algorithm A of Ben Or:
Sorry for a dumb question. I am confused. Does that mean ALL
primitive polynomials must have a degree equal to a Mersenne
prime? But there are e.g. primitive polynomials over GF(2) with
even degrees, if I don't err.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED]
Subject: Cipher design a fading field?
Date: Fri, 02 Jun 2000 22:21:47 GMT
Sci.crypt,
Given the results of the cipher contest, it appears that designing a
strong block cipher is quite easy. Some 7 or 8 ciphers remain
unattacked on the contest site. Even assuming that all of the ciphers
have some weakness, it seems that finding a -practical- weakness is very
difficult.
That being said, is cipher design an obsolete enterprise? If a group of
amateurs can design a strong cipher then certainly governments can.
Since many government ciphers are available, what is the point of
creating new ones?
Speed is one good reason. It seems that AES will answer this
requirement. Some niches also might need a custom algorithm but
many of these could be built on a base cipher.
Why else is a new cipher required? Will AES be the -final- cipher?
I study crypto as a fascinating hobby and will continue to do so. My
question is mostly aimed at commericial/military/government
requirements.
--Matthew
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Subject: Re: Cipher design a fading field?
From: tomstd <[EMAIL PROTECTED]>
Date: Fri, 02 Jun 2000 15:35:05 -0700
In article <8h9c1b$cuv$[EMAIL PROTECTED]>, matthew_fisher@my-
deja.com wrote:
>Sci.crypt,
>
>Given the results of the cipher contest, it appears that
designing a
>strong block cipher is quite easy. Some 7 or 8 ciphers remain
>unattacked on the contest site. Even assuming that all of the
ciphers
>have some weakness, it seems that finding a -practical-
weakness is very
>difficult.
>
>That being said, is cipher design an obsolete enterprise? If a
group of
>amateurs can design a strong cipher then certainly governments
can.
>Since many government ciphers are available, what is the point
of
>creating new ones?
>
>Speed is one good reason. It seems that AES will answer this
>requirement. Some niches also might need a custom algorithm but
>many of these could be built on a base cipher.
>
>Why else is a new cipher required? Will AES be the -final-
cipher?
>
>I study crypto as a fascinating hobby and will continue to do
so. My
>question is mostly aimed at commericial/military/government
>requirements.
it's true the pro's are certainly better at making ciphers, but
newer attacks are comming out all the time. So I would expect
the design criteria of ciphers to change with time, i.e the
requirement of new ciphers.
For me it's just fun and a hobby. I periodically play with
various crypto-tools (sboxes, bit perms, etc..) and I just have
fun.
Tom
* 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] (Ian Goldberg)
Subject: Re: XTR (was: any public-key algorithm)
Date: 2 Jun 2000 22:43:58 GMT
In article <8h9a5j$8r$[EMAIL PROTECTED]>,
Eric Verheul <[EMAIL PROTECTED]> wrote:
>
>Paul Rubin <[EMAIL PROTECTED]> wrote in message
>news:8h98j0$mb0$[EMAIL PROTECTED]...
>> In article <8h880e$rjo$[EMAIL PROTECTED]>,
>> Eric Verheul <[EMAIL PROTECTED]> wrote:
>> >For the RSA comparison we used all the standard tricks: CRA,
>> >montgomery multiplication, sliding windows exponentiation, karatsuba
>> >and we have tried everything to avoid that unfair comparison (not
>> >that I think that anyone on this list believes that). And yes the
>> >software is our own (actually Arjen Lenstra's; he has written
>> >Freelip, remember).
>>
>> Why don't you just post some timings of your RSA software on standard
>> processors? Then people can straightforwardly compare them with the
>> other good implementations out there (OpenSSL, MIRACL, PGP bnlib, etc).
>Better still, why don't you make your own timings with the testsoftware
>(executables)
>that we provide on www.ecstr.com ?
Now you're just being silly. We're supposed to run some arbitrary
executable we found on your web site, on _your_ say-so? I don't
think so. Why don't we see source there? You've described the algorithm
in detail in your paper, so it's not a secret.
- Ian "not to mention that I don't do Windows"
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Good ways to test.
Date: Sat, 03 Jun 2000 00:55:11 +0200
tomstd wrote:
> For example which would you rather use FEAL-8 or Blowfish? Why
> would you pick one or the other?
I believe that any decision to choose a cipher in the real world is
inevitably bound to more or less subjectivity. Because there is no
rigorous yet practical measure of strength, there can be no truly
objective decision from the very beginning. Actually the matter is
not too much better in many other situations. If you choose to buy
one of two brands of wrist watches while someone else chooses
the other, could you prove that his decision is wrong?
M. K. Shen
------------------------------
Subject: Re: Good ways to test.
From: tomstd <[EMAIL PROTECTED]>
Date: Fri, 02 Jun 2000 15:54:16 -0700
In article <[EMAIL PROTECTED]>, Mok-Kong Shen <mok-
[EMAIL PROTECTED]> wrote:
>
>
>tomstd wrote:
>
>> For example which would you rather use FEAL-8 or Blowfish?
Why
>> would you pick one or the other?
>
>I believe that any decision to choose a cipher in the real
world is
>inevitably bound to more or less subjectivity. Because there is
no
>rigorous yet practical measure of strength, there can be no
truly
>objective decision from the very beginning. Actually the matter
is
>not too much better in many other situations. If you choose to
buy
>one of two brands of wrist watches while someone else chooses
>the other, could you prove that his decision is wrong?
My point was that while we can't state the strength of a cipher,
we can point out what it does right. This can lead to
suggestive levels of strength of the function.
>From a medical point of view it's similar. If 5% of the people
get sick with brand A, and only 0.01% with brand B, well we
would pick brand B. But that doesn't mean in the long run brand
B is any better. Just over that short period of analysis.
tom
* 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] (Terry Ritter)
Subject: Re: Good ways to test.
Date: Fri, 02 Jun 2000 22:58:30 GMT
On Fri, 02 Jun 2000 14:25:01 -0700, in
<[EMAIL PROTECTED]>, in sci.crypt tomstd
<[EMAIL PROTECTED]> wrote:
>You're just being childish.
>
>Do we need crypto? Yes.
>
>Do we have practical Crypto? Yes.
>
>Are we willing to risk it at the hands of experience people? Yes.
>
>You know some doctors have patients that die to.
"too"
>Medicine is
>hardly proven ground, but we use it too.
Medicine -- like almost everything other then cryptography -- lets us
see the results. In medicine, if a treatment does not work, we know
it. In cryptography, if a cipher is not secure from our opponents, we
do not know it.
I would call that a distinct difference.
In cryptography, we don't know the outcome, so we can't improve the
cipher if it is broken by unknown opponents, and that situation will
never get any better unless we change the cipher.
>For example it has yet
>to be proven Tylenol has no adverse long-term sideeffects. Just
>because we don't see them. Does this mean we throw away all
>medicine?
It means we look for adverse long-term side effects. We keep in mind
that they may exist. Similarly, we keep in mind that we cannot trust
any cipher to not have fatal long-term side effects.
>To me Medicine and Crypto are in the same boat that you so
>desperately want to sink.
As far as I can tell, you have absolutely no idea about my motives. I
have spent over a decade of life on cryptography; what about you?
I have some principles, and those principles include Truth. The Truth
is that cryptography is not like those other things we trust. The
Truth is that we cannot develop trust in a cipher like other things in
our world. The Truth is that we need to be a great deal more careful
about assuming what is unbreakable and to whom. Unless, of course,
you just want to sell your product or your design or just you and are
willing to say anything and everything to do so.
>Just to attack you for a moment, your own ciphers could be
>flawed, but you put them up as 'secure'.
Really? Where do I do that? It's an easy mistake to make, and I
write a lot of text, but it should not be there.
Where is it?
>From my web page we have: 'Everyone wants a practical cipher which is
proven "absolutely secure," but such a cipher does not exist, and
probably never will.'
On the other hand, it is necessary to have *some* strength claim for a
cipher, or it is not going to be possible to judge whether the design
has met its goals.
>I think you are lying
>then. Prove me wrong.
Hey, I have a better idea: Why don't I just treat you like I would
treat anybody else who called me a liar?
---
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: Contest rule proposal
Date: Fri, 02 Jun 2000 22:59:23 GMT
On 2 Jun 2000 14:30:27 -0700, in
<8h991j$pj0$[EMAIL PROTECTED]>, in sci.crypt
[EMAIL PROTECTED] (David A. Wagner) wrote:
>In article <[EMAIL PROTECTED]>, Terry Ritter <[EMAIL PROTECTED]> wrote:
>> The claim that "stream ciphers are stateful; block ciphers are
>> stateless" is true as a generalization only. Another generalization
>> is that block ciphers require the accumulation of data, and stream
>> ciphers do not.
>
>Yeah, ok, that is also a useful metric to characterize different types
>of encryption schemes. I'll concede that.
>
>But, beware: Many stream ciphers also require the accumulation of data.
>
>e.g., any stream cipher in ciphertext feedback mode with a 8-bit
>character size requires accumulation of 8 bits at a time. I wouldn't
>call that a block cipher.
But if the data are sent or produced in 8-bit units, getting another 8
bits hardly requires "accumulation," and so does not have that block
characteristic.
Still, the distinction seems to be the char-by-char changing beyond
8-bit ECB which implies internal state as used in your original
metric. But we have those pesky other cases which also need to be
tagged somehow so we can talk about them and relate them to the rest
of what we know. We are not trapped by these definitions: There is
no reason why would could not contrast and compare any particular
design in several ways. It is just rarely done.
>> The current academic meaning of "block cipher" is a
>> simulated huge Simple Substitution, which -- coincidentally -- *does*
>> require the accumulation of a "block" of data.
>
>Yes. A good definition for a block cipher is that it is intended
>to act as a pseudorandom permutation. You're right; just saying that
>it is "stateless" is not so helpful. A pseudorandom permutation is,
>of course, always stateless, but the reverse is not necessarily true.
Good way to put it.
>> Now, shall we reject any block cipher proposal which uses cipher block
>> chaining (CBC)?
>
>I consider CBC mode a technique for building a stream cipher out of
>a block cipher. Thus, DES is a block cipher, but DES-CBC is a streaming
>mode of encryption. I would not call DES-CBC encryption a block cipher;
>one of its components is a block cipher, but it itself is not a block cipher.
I could not agree more.
>> Personally, I think any cipher of any form whatsoever should be
>> allowed for analysis and discussion.
>
>Me, too. I'm personally not sure why the restriction in the sci.crypt
>cipher contest is there. But, if the contest folks think it is important
>to omit stream ciphers for some reason, IMHO Chutzpah must go.
But that really depends upon what the contest folks thought when they
were making their rule. Just because they use the *words* "block
cipher" doesn't mean they were using *your* *definition* of a block
cipher. And maybe they would want the rule to be interpreted loosely
anyway, to admit just the sort of range we do not see in academic
proposals.
---
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: Finding primitive polynomials via the Berlekamp method?
Date: Fri, 02 Jun 2000 23:01:12 GMT
On Fri, 02 Jun 2000 13:52:51 -0700, in
<[EMAIL PROTECTED]>, in sci.crypt lordcow77
<[EMAIL PROTECTED]> wrote:
>Never mind; I realized that the Berlekamp Q matrix method only
>reveals if a polynomial is irreducible, not whether it is
>primitive or not (although the first condition is a neccesary
>but not sufficient condition for the second).
Many of the usual methods are similarly limited.
---
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: Contest rule proposal
Date: Fri, 02 Jun 2000 23:05:17 GMT
On 2 Jun 2000 22:14:27 GMT, in <[EMAIL PROTECTED]>, in
sci.crypt [EMAIL PROTECTED] (Mark Wooding) wrote:
>Mark Wooding <[EMAIL PROTECTED]> wrote:
>> Terry Ritter <[EMAIL PROTECTED]> wrote:
>>
>> > Now, shall we reject any block cipher proposal which uses cipher block
>> > chaining (CBC)?
>>
>> The underlying block cipher is clearly eligible.
>
>In fact, I'd go as far as to suggest that, while DES is a block cipher,
>DES-ECB (which maintains no extra state) is a stream cipher.
I agree. It is certainly streaming the block.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
Subject: Re: Good ways to test.
From: tomstd <[EMAIL PROTECTED]>
Date: Fri, 02 Jun 2000 16:05:14 -0700
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Terry
Ritter) wrote:
>
>On Fri, 02 Jun 2000 14:25:01 -0700, in
><[EMAIL PROTECTED]>, in sci.crypt
tomstd
><[EMAIL PROTECTED]> wrote:
>
>>You're just being childish.
>>
>>Do we need crypto? Yes.
>>
>>Do we have practical Crypto? Yes.
>>
>>Are we willing to risk it at the hands of experience people?
Yes.
>
>
>>
>>You know some doctors have patients that die to.
>
>"too"
>
>>Medicine is
>>hardly proven ground, but we use it too.
>
>Medicine -- like almost everything other then cryptography --
lets us
>see the results. In medicine, if a treatment does not work, we
know
>it. In cryptography, if a cipher is not secure from our
opponents, we
>do not know it.
>
>I would call that a distinct difference.
>
>In cryptography, we don't know the outcome, so we can't improve
the
>cipher if it is broken by unknown opponents, and that situation
will
>never get any better unless we change the cipher.
>
What about all the "new" drugs tested in the early 50's/60's
that caused 'unknown' side effects? What about DDT (the
pesticide... I may have got the name wrong), what about...
You can hardly claim medicine hasn't had it's let downs. Drugs
pulled from the shelves... etc.
Yes, right after we know every nook and cranny of the human
body, then we can probably say 'this is the best cure'. Until
then it's educated guessing.
Again, when I am sick, I goto a doctor. Why? It's better then
nothing.
>>For example it has yet
>>to be proven Tylenol has no adverse long-term sideeffects.
Just
>>because we don't see them. Does this mean we throw away all
>>medicine?
>
>It means we look for adverse long-term side effects. We keep
in mind
>that they may exist. Similarly, we keep in mind that we cannot
trust
>any cipher to not have fatal long-term side effects.
What about things we don't look for? What if 20 years from now
we find out Tylenol can cause Arthritis in younger people? Whoa
never looked for that.
>>To me Medicine and Crypto are in the same boat that you so
>>desperately want to sink.
>
>As far as I can tell, you have absolutely no idea about my
motives. I
>have spent over a decade of life on cryptography; what about
you?
>
>I have some principles, and those principles include Truth.
The Truth
>is that cryptography is not like those other things we trust.
The
>Truth is that we cannot develop trust in a cipher like other
things in
>our world. The Truth is that we need to be a great deal more
careful
>about assuming what is unbreakable and to whom. Unless, of
course,
>you just want to sell your product or your design or just you
and are
>willing to say anything and everything to do so.
>
I agree, we cannot say 'Cipher X is unbreakable', but we have to
draw the line somewhere and say 'We will use cipher X based on
it's analysis it seems secure'. There is no two ways about it
Terry. Either you use it, or you don't. if you don't then you
have no security at all.
>>Just to attack you for a moment, your own ciphers could be
>>flawed, but you put them up as 'secure'.
>
>Really? Where do I do that? It's an easy mistake to make, and
I
>write a lot of text, but it should not be there.
>
>Where is it?
>
>From my web page we have: 'Everyone wants a practical cipher
which is
>proven "absolutely secure," but such a cipher does not exist,
and
>probably never will.'
>
>On the other hand, it is necessary to have *some* strength
claim for a
>cipher, or it is not going to be possible to judge whether the
design
>has met its goals.
This is a contradiction. Since the strength of a cipher is
undefined, how can you meet it?
>>I think you are lying
>>then. Prove me wrong.
>
>Hey, I have a better idea: Why don't I just treat you like I
would
>treat anybody else who called me a liar?
Whatever. I don't care much for this pointless dribble. You
yourself post your ciphers and claim they are all broken.
That's pointless backwards thinking.
Reality: Strength of Cipher = unknown.
Reality: Requirement of Cipher = True.
Reality: Pick the best we got, relative to all known attacks.
Tom
* 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] (Terry Ritter)
Subject: Re: Finding primitive polynomials via the Berlekamp method?
Date: Fri, 02 Jun 2000 23:08:10 GMT
On Sat, 03 Jun 2000 00:30:58 +0200, in
<[EMAIL PROTECTED]>, in sci.crypt Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
>Terry Ritter wrote:
>
>> All primitive polynomials are irreducible, but irreducibles are not
>> necessarily primitive, unless the degree of the polynomial is a
>> Mersenne prime. One way to find a primitive polynomial is to select an
>> appropriate Mersenne prime degree and find an irreducible using
>> Algorithm A of Ben Or:
>
>Sorry for a dumb question. I am confused. Does that mean ALL
>primitive polynomials must have a degree equal to a Mersenne
>prime? But there are e.g. primitive polynomials over GF(2) with
>even degrees, if I don't err.
It means that if we want to find primitives, and are working at a
Mersenne prime degree, we only need find irreducibles, since all
irreducibles of Mersenne prime degree are primitive. For other
degrees we need additional tests that distinguish primitive from just
irreducible.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
Subject: Re: Contest rule proposal
From: tomstd <[EMAIL PROTECTED]>
Date: Fri, 02 Jun 2000 16:06:44 -0700
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Terry
Ritter) wrote:
>
>On 2 Jun 2000 22:14:27 GMT, in
<[EMAIL PROTECTED]>, in
>sci.crypt [EMAIL PROTECTED] (Mark Wooding) wrote:
>
>>Mark Wooding <[EMAIL PROTECTED]> wrote:
>>> Terry Ritter <[EMAIL PROTECTED]> wrote:
>>>
>>> > Now, shall we reject any block cipher proposal which uses
cipher block
>>> > chaining (CBC)?
>>>
>>> The underlying block cipher is clearly eligible.
>>
>>In fact, I'd go as far as to suggest that, while DES is a
block cipher,
>>DES-ECB (which maintains no extra state) is a stream cipher.
>
>I agree. It is certainly streaming the block.
That makes no sense. DES-ECB = DES, the specification of DES
says nothing about how long the message is, only that it's block
size is 64 bits.
CBC modes may be considered a stream cipher, but not the actual
underlying function.
Tom
* 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: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: Cipher design a fading field?
Date: Fri, 2 Jun 2000 16:07:29 -0700
Interesting question
Seems to me that sometimes a process or endeavor is valuable as just that.
Even if the stated end is not achieved, does that mean that the "means"
explored has no value? Consider thought experiments. Is the value of
daydreaming tied to the value of the result?
Every time a concept gets twisted around and looked at from a different
viewpoint, everyone has a chance to capitalize on it. I would have no
problem with the thought that an idea on a new cipher without much practical
use might stimulate a thought for a new attack. Maybe even one with broad
applicability.
It sure seems to have worked the other way around.
Why is another cipher required? I think the fact that someone wishes to do
it is sufficient. Might just be chum on the waters but then again, we might
just learn something.
Paul
<[EMAIL PROTECTED]> wrote in message
news:8h9c1b$cuv$[EMAIL PROTECTED]...
> Sci.crypt,
>
> Given the results of the cipher contest, it appears that designing a
> strong block cipher is quite easy. Some 7 or 8 ciphers remain
> unattacked on the contest site. Even assuming that all of the ciphers
> have some weakness, it seems that finding a -practical- weakness is very
> difficult.
>
> That being said, is cipher design an obsolete enterprise? If a group of
> amateurs can design a strong cipher then certainly governments can.
> Since many government ciphers are available, what is the point of
> creating new ones?
>
> Speed is one good reason. It seems that AES will answer this
> requirement. Some niches also might need a custom algorithm but
> many of these could be built on a base cipher.
>
> Why else is a new cipher required? Will AES be the -final- cipher?
>
> I study crypto as a fascinating hobby and will continue to do so. My
> question is mostly aimed at commericial/military/government
> requirements.
>
> --Matthew
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
** 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
******************************
