Cryptography-Digest Digest #925, Volume #11 Fri, 2 Jun 00 18:13:01 EDT
Contents:
Re: RIP Bill 3rd Reading in Parliament TODAY 8th May (George Edwards)
Re: RIP Bill 3rd Reading in Parliament TODAY 8th May (George Edwards)
Re: Pomegranate, a simple base-independent generator (Mok-Kong Shen)
Re: Self Shrinking LFSR (lordcow77)
Re: Contest rule proposal (Mark Wooding)
Re: Contest rule proposal (Terry Ritter)
Re: Good ways to test. (Terry Ritter)
Re: XTR (was: any public-key algorithm) (Paul Rubin)
Re: Contest rule proposal (Terry Ritter)
Re: Good ways to test. (tomstd)
Re: Contest rule proposal (Terry Ritter)
Re: TC3 Update (tomstd)
Re: Contest rule proposal (David A. Wagner)
Re: Good ways to test. (David A. Wagner)
Re: Good ways to test. (tomstd)
Re: XTR (was: any public-key algorithm) ("Eric Verheul")
----------------------------------------------------------------------------
From: George Edwards <[EMAIL PROTECTED]>
Crossposted-To:
uk.media.newspapers,uk.legal,alt.security.pgp,alt.privacy,uk.politics.parliament,uk.politics.crime,talk.politics.crypto,alt.ph.uk,alt.conspiracy.spy,alt.politics.uk,uk.telecom
Subject: Re: RIP Bill 3rd Reading in Parliament TODAY 8th May
Date: Fri, 2 Jun 2000 22:02:32 +0100
In article <[EMAIL PROTECTED]>, Demon
<[EMAIL PROTECTED]> writes
>
>In the past, the Labour party took a rather different view of encryption. In
>its 1995 policy paper ``Communicating Britain's Future'' it stated:
>The only power we would wish to give to the authorities, in order to pursue
>a defined legitimate anti-criminal purpose, would be to enable decryption to
>be demanded under ****judicial warrant**** (in the same way that a warrant
>is required in order to search someone's home).
You are assuming that politicians keep their undertakings. Does the
history of ten centuries not sugest otherwise? For the most recent
cases,see harriet harman, and the privatisation of air traffic control.
--
George Edwards
------------------------------
From: George Edwards <[EMAIL PROTECTED]>
Crossposted-To:
uk.media.newspapers,uk.legal,alt.security.pgp,alt.privacy,uk.politics.parliament,uk.politics.crime,talk.politics.crypto,alt.ph.uk,alt.conspiracy.spy,uk.telecom
Subject: Re: RIP Bill 3rd Reading in Parliament TODAY 8th May
Date: Fri, 2 Jun 2000 21:57:21 +0100
In article <[EMAIL PROTECTED]>, Adrian Kennard
<[EMAIL PROTECTED]> writes
>Proving you have forgotton a key *should* be easy though - surely.
>
>"Hmmm, nope, I cant remember it" - proved.
old and cynical as i am, i fear this will not do. basic human rights
(such as not incriminating yourself) seem to be on the hit list for this
governmment.
--
George Edwards
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Pomegranate, a simple base-independent generator
Date: Fri, 02 Jun 2000 23:14:11 +0200
wtshaw schrieb:
> In review of some classic ciphers, I again noted the means of generating a
> numeric series part of the Gromark cipher. The method is simple addition
> of digits and affixing the result to the end of the series. Be not
> astonished, as a pseudorandom thingee, it repeats
I believe that in our group I am probably not the single person who
doesn't have access to books describing the Gromark cipher. Could
you please give a sketch of the stuff involved here in mathematical
terms? Many thanks in advance.
M. K. Shen
------------------------------
Subject: Re: Self Shrinking LFSR
From: lordcow77 <[EMAIL PROTECTED]>
Date: Fri, 02 Jun 2000 14:05:42 -0700
In article <[EMAIL PROTECTED]>, Mike Rosing
<[EMAIL PROTECTED]> wrote:
>a day on a reasonable PC. There are faster ways to do this, a
few
>months
>ago someone posted the URL for a paper that showed some
efficient
>methods
>for checking if polynomials are primitive.
>
Could you provide a reference?
* 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] (Mark Wooding)
Subject: Re: Contest rule proposal
Date: 2 Jun 2000 21:02:34 GMT
Terry Ritter <[EMAIL PROTECTED]> wrote:
>
> On 2 Jun 2000 19:28:17 GMT, in <[EMAIL PROTECTED]>, in
> sci.crypt [EMAIL PROTECTED] (Mark Wooding) wrote:
>
> >Terry Ritter <[EMAIL PROTECTED]> wrote:
> >>
> >> On 2 Jun 2000 14:59:11 GMT, in <[EMAIL PROTECTED]>,
> >> in sci.crypt [EMAIL PROTECTED] (Mark Wooding) wrote:
> >
> >The point is that you can have a patent on a particular structure of
> >cipher, or a method for designing ciphers. While this clearly covers
> >all ciphers designed in this way, you can make specific instances of
> >your design free while maintaining your `rights' over the underlying
> >method or structure.
>
> Alas, that is not something I want to do.
Irrelevant. The point is that it's possible, and seems to work.
> >In the case of ciphers, I don't see very much in the way of
> >worthwhile secret ciphers.
>
> I have no idea what you mean, since there *are* *no* secret patents.
I wasn't talking about secret patents, now.
> Thus, there *can* *be* no patented secret ciphers. Instead, it is the
> *un*patented ciphers which can be secret, and you don't see them
> because -- surprise! -- they are *secret*.
Except that, to be useful, ciphers tend to need to be put into protocols
and applications. Once that's happened, people start getting interested
in them at this point, and then, often, they leak. Which is what
happened with RC[24].
> >Let's say I have a gadget which can duplicate pints of beer, and I use
> >it to take a copy of your pint. You've lost nothing in this process
> >that I can see. The world is exactly the same except that I now have a
> >pint too. Who's done harm here, and to whom?
>
> 1. If there is a law prohibiting such copying, you have violated the
> law.
Oh, dear, Terry. You're better than this. If the law prohibits X, then
doing X violates the law. This holds for all X. For many values of X
where the condition is true, the law in question is daft, or at least
questionable.
> 2. Presumably there is some reason for having such a law, such as for
> society to provide financial support for the continued development of
> beer in a way that does not involve non-beer-users.
Ahh. But that's not working properly anyway. `Beer development' seems
to mainly involve cutting costs at the expense of quality. [Snip
off-topic rant about small breweries which produce good beer being taken
over by large breweries which cut costs and produce lower-quality beer
in larger volumes more cheaply.]
> The point -- since you choose to avoid it -- is that so-called "free"
> ciphers are not free for users. Instead, "free" ciphers are free for
> companies who then sell the result with greater profit. I fail to see
> how this has benefited the user, and it certainly has not supported
> the continued process of cipher development.
Except that -- aha! -- free ciphers can be used in -- you guessed it! --
free software! See SSLeay (or OpenSSL as it is now), GnuPG, OpenSSH,
and many others for examples. This can't happen with non-free ciphers.
> And what kind of argument is that anyway? Didn't your mother ever
> tell you that just because everyone else is jumping off a cliff is no
> reason for you to do so? What *they* do is really quite irrelevant to
> what *I* do.
She taught me to recognize and follow good examples.
-- [mdw]
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Contest rule proposal
Date: Fri, 02 Jun 2000 21:17:00 GMT
On 2 Jun 2000 12:30:44 -0700, in
<8h9214$pag$[EMAIL PROTECTED]>, in sci.crypt
[EMAIL PROTECTED] (David A. Wagner) wrote:
>Oh, and by the way, there is an important error in the Chutzpah document.
>It claims that Chutzpah is a block cipher, not a stream cipher. That's
>just plain wrong, and the mistake highlights a fundamental misunderstanding
>of the standard terminology.
>
>Stream ciphers are stateful; block ciphers are stateless. Chutzpah is
>a stream cipher. And the contest is supposed to be for block ciphers only.
>Therefore, I think we can conclude that Chutzpah does not belong.
>
>Am I missing something here?
I think you *are* missing something. These distinctions are not as
clear as you might think. I have a discussion on this:
http://www.io.com/~ritter/GLOSSARY.HTM#CipherTaxonomy
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. Of course, that definition would include a whole
range of ciphers which are not currently (academically) thought of as
"block ciphers." The current academic meaning of "block cipher" is a
simulated huge Simple Substitution, which -- coincidentally -- *does*
require the accumulation of a "block" of data. To not use "block" for
designs which require the accumulation of data and yet are not
simulated Simple Substitutions would seem very strange.
Now, shall we reject any block cipher proposal which uses cipher block
chaining (CBC)? Such a cipher would have chaining state, and would
technically be a stream meta-cipher. The distinction is sometimes
useful, but preventing discussion because of it would seem rather
non-academic.
Personally, I think any cipher of any form whatsoever should be
allowed for analysis and discussion.
---
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: Good ways to test.
Date: Fri, 02 Jun 2000 21:17:11 GMT
On Fri, 02 Jun 2000 12:16:39 -0700, in
<[EMAIL PROTECTED]>, in sci.crypt tomstd
<[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Terry
>Ritter) wrote:
>>
>>On Fri, 02 Jun 2000 11:25:32 -0700, in
>><[EMAIL PROTECTED]>, in sci.crypt
>tomstd
>><[EMAIL PROTECTED]> wrote:
>>
>>>In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Terry
>>>Ritter) wrote:
>>
>>>>[...]
>>>>Unfortunately, cryptanalysts can't know the strength of a
>system
>>>>unless they can break it. If they can't break it, the system
>>>may be
>>>>weak anyway.
>>>
>>>Conversely just because they can break it, doesn't mean it's
>>>insecure.
>>
>>No, it means that they then know a true upper bound on the
>strength,
>>and so can make their decision in the presence of data -- as
>opposed,
>>say, to superstition.
>
>What about provably secure block ciphers that use components
>with well understood structures, say CAST sboxes?
You really have no idea what you are talking about, do you?
I have not been saying, over and over, that there *are* *no* provably
secure ciphers just for my health. Provably secure practical ciphers
do not exist. Everybody wants them to exist, they just do not.
There is a whole sub-body of work -- which I generally consider
academically deceptive -- which talks about provable security,
generally in the context of some or another detailed assumption. Some
of those claims have been found wrong, others, by their nature, cannot
be applied in practical use, such as the one-time-pad (OTP). That
does not mean that an OTP is insecure; it does mean that in practice
we cannot achieve the theoretical model which is used to "prove" OTP
security. It does mean that people who use an "OTP" are subject to a
rude awakening when what they thought was a provably secure system
actually turns out to be not what they thought it was.
If you insist on handwaving this chimera of "provable security," you
will have to be a great deal more specific, although I don't know that
I really want to go through it all. I suppose I should just argue
that if there were such a thing, why would we need AES, and why would
anyone use anything else? It seems to me that to claim that practical
"provable security" exists and yet is not used is to claim that
everybody but you is an idiot. That is quite a claim.
>Although I agree new attacks come out each yet (and I doubt this
>argument will ever end), you have to draw a line and say "good
>enough" I will use it. Otherwise crypto wouldn't be used
>anywhere.
And that has nothing to do with whether a cryptanalyst can know the
strength of the cipher, and thus tell a client that everything is OK.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: XTR (was: any public-key algorithm)
Date: 2 Jun 2000 21:22:40 GMT
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).
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Contest rule proposal
Date: Fri, 02 Jun 2000 21:25:36 GMT
On 2 Jun 2000 13:26:59 -0700, in
<8h95aj$pe3$[EMAIL PROTECTED]>, in sci.crypt
[EMAIL PROTECTED] (David A. Wagner) wrote:
>In article <kuUZ4.44749$[EMAIL PROTECTED]>,
>Paul Pires <[EMAIL PROTECTED]> wrote:
>> An inventor has no legal standing or remedies from someone who is using
>> information in a patent in any way unless they commercialize it.
>
>My understanding is that that's just not true. Implementation of RSA
>even for research purposes without a license is illegal (and will be,
>until the RSA patent expires). It might be nice if non-commercial use
>were allowed, but I don't think that's the way patent law actually works.
That's correct: Non-commercial *use* is not automatically allowed.
But a contest entry from a patent holder would seen to have granted
implicit rights to analysis, although still not *use* for purposes
beyond contest analysis per se, even if said use is non-commercial.
---
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 14:25:01 -0700
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. Medicine is
hardly proven ground, but we use it too. 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?
To me Medicine and Crypto are in the same boat that you so
desperately want to sink.
Just to attack you for a moment, your own ciphers could be
flawed, but you put them up as 'secure'. I think you are lying
then. Prove me wrong.
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: Contest rule proposal
Date: Fri, 02 Jun 2000 21:32:32 GMT
On 2 Jun 2000 13:58:11 -0700, in
<8h9753$phc$[EMAIL PROTECTED]>, in sci.crypt
[EMAIL PROTECTED] (David A. Wagner) wrote:
>In article <[EMAIL PROTECTED]>, Terry Ritter <[EMAIL PROTECTED]> wrote:
>> I would say that simply by entering a contest where analysis is
>> clearly expected and required, a patent holder would have given up the
>> sort of total control you imagine.
>
>That might be the most logical outcome, but logic is not the whole of
>the law. No offense intended here, but: The question is not what you
>would say, but rather what the judge would say. I would be impressed
>if anyone can give us any definite assurances on that score.
I would too. No offense intended, but *nobody* can tell you what the
judge would say. If they could, we would not need a judge.
Nevertheless, many situations of this sort depend upon intent and
damages. Nobody swoops down and puts somebody in jail for patent
infringement. Instead, one is generally warned in writing to desist,
and if the activity continues, a lawsuit is filed in federal court for
damages, whereupon you get to explain how running a network of said
cipher for a university is not in fact *use*. This just does not
happen by accident, unless somebody re-develops the same cipher.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
Subject: Re: TC3 Update
From: tomstd <[EMAIL PROTECTED]>
Date: Fri, 02 Jun 2000 14:31:09 -0700
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(Mark Wooding) wrote:
>tomstd <[EMAIL PROTECTED]> wrote:
>
>> 1. Explain the notation please :)
>
>A finite field GF(q) (or, sometimes F_q, where the F is in
>blackboard-bold face, like Z when we're talking about the
integers) is a
>set of q elements, upon which operations of addition and
multiplication
>are defined. Both operations are associative and commutative;
there
>exist additive and multiplicative identities labelled 0 and 1
>respectively; each element has an additive inverse; each
nonzero element
>has a multiplicative inverse; multiplication is distributive
over
>addition. (Have I missed anything out?)
>
>It can be shown (apparently) that any finite field contains p^m
>elements, where p is prime, and m is a positive[1] integer, and
that the
>finite fields of a particular size are in fact all isomorphic
to each
>other (i.e., there's a simple transformation you can perform on
elements
>of one field to get elements of the other, and all of the
arithmetic
>operations work properly so that when you translate back again
you get
>the right answer).
>
>Also, F^*_q (the field without the zero element) is cyclic;
that is,
>there exists an element g <- F^*_q such that, for any other
element x <-
>F^*_q there exists an integer i where g^i = x.
>
>F_p, where p is prime, looks rather similar to Z_p -- the
integers mod
>p. F_{p^m} can be looked at as being the set of order-(m - 1)
>polynomials with coefficients in Z_p, where polynomials are
reduced
>modulo some irreducible polynomial v(x) of order m. When we do
this, we
>write that we represent GF(p^m) as GF(p)[x]/(v(x)). Phew!
>
>Oh, yes, finally, if S is a set of elements, we tend to write
that S x S
>is the set of pairs of elements of S, and, in general, that S^n
is the
>set of n-tuples of elements of S, often represented, where S is
an
>appropriate ring, as column vectors of n elements of S. And,
just for
>completeness, P(S) (P is blackboard-bold again) is the `power-
set' of S,
>or the set of all subsets of S. P(S) is sometimes written 2^S,
since it
>has 2^{|S|} elements.
>
>(If I've got any of that wrong, could someone please show me
up?)
I think I get it now. Thanks for clearing it up.
>> 2. Can anyone explain why those sboxes are "provably"
>> cryptographically secure?
>
>I'll pass on that one for now.
>
I think by the looks of it, the Interpolation attack will
probably break it.
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] (David A. Wagner)
Subject: Re: Contest rule proposal
Date: 2 Jun 2000 14:30:27 -0700
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.
> 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.
> 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.
> 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.
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: Good ways to test.
Date: 2 Jun 2000 14:33:57 -0700
In article <[EMAIL PROTECTED]>,
tomstd <[EMAIL PROTECTED]> wrote:
> You're just being childish.
No. You referred to some ciphers as "provably secure". They weren't.
I feel that Terry Ritter was quite right to object. Terry Ritter's point
remains: we do not have a full-fledged proof of security for any practical
cipher.
------------------------------
Subject: Re: Good ways to test.
From: tomstd <[EMAIL PROTECTED]>
Date: Fri, 02 Jun 2000 14:44:58 -0700
In article <8h9985$pjk$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (David A. Wagner) wrote:
>In article <[EMAIL PROTECTED]>,
>tomstd <[EMAIL PROTECTED]> wrote:
>> You're just being childish.
>
>No. You referred to some ciphers as "provably secure". They
weren't.
>I feel that Terry Ritter was quite right to object. Terry
Ritter's point
>remains: we do not have a full-fledged proof of security for
any practical
>cipher.
>
>
I agree completely with what you are both saying. I just don't
think that's the end of it.
For example which would you rather use FEAL-8 or Blowfish? Why
would you pick one or the other?
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: "Eric Verheul" <[EMAIL PROTECTED]>
Subject: Re: XTR (was: any public-key algorithm)
Date: Fri, 2 Jun 2000 23:38:33 +0200
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 ?
Eric
------------------------------
** 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
******************************
