Cryptography-Digest Digest #762, Volume #12 Sun, 24 Sep 00 14:13:01 EDT
Contents:
Re: Software patents are evil. ("Trevor L. Jackson, III")
Re: Software patents are evil. ("Trevor L. Jackson, III")
Re: Software patents are evil. ("Trevor L. Jackson, III")
Re: 128-bit Secure LFSR ("Trevor L. Jackson, III")
Re: 128-bit Secure LFSR (Whoops) ("Trevor L. Jackson, III")
Re: What make a cipher resistent to Differential Cryptanalysis? (Mok-Kong Shen)
Re: What make a cipher resistent to Differential Cryptanalysis? (Mok-Kong Shen)
Re: 128-bit Secure LFSR (Whoops) (Jeff Gonion)
Re: 128-bit Secure LFSR (Tom St Denis)
Re: Cryptography Challenge ("Colin Barker")
----------------------------------------------------------------------------
Date: Sun, 24 Sep 2000 13:05:27 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Software patents are evil.
Jerry Coffin wrote:
> In article <yqSy5.108$Lf5.1216@client>, [EMAIL PROTECTED]
> says...
>
> [ ... ]
>
> > 17 years later. By that time, a new and superior algorithm will be
> > patented, starting the circle over again. Oh joy.
>
> I've already pointed out things like RSA, DH and LZW that are
> obviously a LONG ways from completely obsolete.
>
> > This is pretty funny. Name ONE time that this has EVER happened. They
> > might buy a patent from you, but they won't help you enforce a patent they
> > don't own.
> >
> > > There are a fair number of quite large companies
> > > that do NOTHING but help their clients enforce patents. For one
> > > example, the Mahr-Leonard Management Company has made a huge amount
> > > on patent licensing. Contrary to some statements in this thread
> > > though, the owners of the patents really DO make money on them -- it
> > > doesn't all go to the attorneys or anywhere close to it.
> >
> > I would be interested in seeing some figures for small-time people or
> > start-up companies to see how this really works out for "the little guy."
>
> If you're honestly interested, go find them. I've given you the name
> of one company to look at. Assuming you have an IQ above room
> temperature, it'll be incredibly easy for you to find out that most
> of what you've been saying is wrong. There's only so far I can go in
> providing you the information, and a bit less far I'm willing to go.
> I suppose I could plug the company name into Yahoo!, Google, Alta
> Vista, etc., and find you a plethora of URLs, but I doubt it would
> make any real difference: if you're not willing to do that tiny bit
> on your own, then the hard part of actually reading and understanding
> what they say is obviously far more than you'll bother with. I
> already understand what's going on, but my re-reading things I
> already know isn't going to suddenly make YOU understand more than
> you do now.
>
> > In my experience working as a subcontractor and as an employee, the firms I
> > have worked for have never bothered to try and patent anything.
>
> Okay. What of it?
>
> > I will admit that there have been compelling arguments that I had not
> > thought of to support patents. I still think they are evil, and here's why:
> >
> > "Back in the day" (I've been a programmer a long time) people used to invent
> > algorithms and just publish them in the ACM. No patent, no secrecy, no
> > nothing. "Lookie! A new algorithm! Here is the explanation. Have fun."
> > Now, back in those days, algorithms exploded like a bomb blast going off.
> >
> > With the heavy advent of patents (and even copyrights for that matter) that
> > has really simmered down.
>
> This has nothing to do with patents at all. The simple fact is that
> if (for example) you wanted to sort some things in a computer in
> 1948, you invented an algorithm to do it. You quickly noticed that
> your 10 KHz CPU took a long time to sort much using your lousy first
> attempt at a sorting algorithm. Therefore, you set out to invent
> something better, and quickly did so.
>
> For better or worse, the Quicksort has long-since been invented and
> enough theory has been studied that we know a sort in the normal
> sense of the word can't get a lot better than the Quicksort already
> is, at least in the average case.
>
> New algorithms DO still get invented; consider the Introsort, which
> was invented quite recently. It improves on the Quicksort by
> guaranteeing that the worst case is still O(N lg N). If this had
> happened 30 years ago, it would have been MAJOR news, but nowadays
> sorting is rarely enough of consequence that most programmers haven't
> noticed it at all.
>
> New algorithms now tend to be in more specialized niches where CPU
> speed still isn't adequate to render algorithmic improvements
> meaningless. Gamers routinely invent new graphics rendering
> algorithms, but unless you happen to be a gamer, you probably don't
> care. Hardware is improving so fast that I don't expect this to last
> a lot longer either though.
>
> Most people lack incentive to invent new algorithms, especially in
> fundamental areas where most of us would notice them. Most of the
> time, they can easily use a canned algorithm in their standard
> library. Even if they had a wonderful new idea, it would take little
> short of a miracle for it to be much more than slightly better than
> existing ones for most of the really fundamental operations, so even
> when it does happen, it means very little.
>
> None if this, though, has ANYTHING to do with patents or even
> copyrights. To give another example, you could say essentially the
> same thing about automobiles, but with a different time frame. 100
> years ago, everybody who built a horseless carriage invented a new
> placement for the brake pedal, a different way for shifting to work,
> and so on. Automobiles have progressed to the point that all of this
> is now well standardized, and manufacturers desperate for anything to
> separate themselves from the field call 1% adjustments revolutionary,
> and do things like inventing tail fins, side scoops, etc., because
> they haven't had a substantive new invention in 20 years or so...
One might says this leveling off of innovation is characteristic of a mature
technology. As software may be maturing we should expect to see a similar
leveling, since there are now giants upon whose shoulders we may stand.
------------------------------
Date: Sun, 24 Sep 2000 13:12:32 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Software patents are evil.
Paul Pires wrote:
> Twilight zone. I responded below but.....
>
> Is it just me or did this Re: post just get lopped off the branch
> by Usenet? Do you see a new posting from me immediately below
> this one? or are we still attached to the original thread?
>
> Don't laugh, Usenet has been really weird lately.
Replications does seem to be sporadic. Did you notice a 9-point response from me a
day or so ago?
>
>
> Bill Unruh <[EMAIL PROTECTED]> wrote in message
> news:Pine.LNX.4.10.10009231520010.7529-
>
> <SNIP>
> >
> > Please read. prove does not mean "it follows logically and inelluctibly
> > from some premises." A proof is a test of the truth of a statement. That
> > is waht the patent office does. That is what the applicant must do. He
> > must supply to the patent office all evidence which he knows of which
> > might invalidate the patent. He must swear that this patent covers new
> > material. These are all standards of proof. Unfortunately as you point
> > out patent examiners do not know everything about everything and may
> > well be convinced when they should not be. That is why bringing some
> > sort of adversarial role into the patent process might help. Ie, a
> > patent can be challenged via the patent office by the same process as
> > the patent was granted.
>
> I'll ignore your testy intro. I know what prove means and I even guessed
> at your usage. But, this idea above actually sounds like a good idea. I'm
> not being nasty, I think this is neet. One problem, How can you retract,
> or reduce a patent once granted without due process. Note: a regulatory
> action is not due process.
>
> Maybe combine this with a provisional status. Something like: A patent can be
> forced back into the review process (1 time only) within 6mos. after granting if
> certain
> challenge requirements are met. Have to be pretty strengent or it will be weak
> to
> a denial of service by flood attack.
>
> Naw, this just won't work. if it is reducible, it is not a patent yet. No one
> would licence a provisional patent so you might as well not do it.
Disagree. Some potential licensees might be hesitant, but others, who examined the
patent and found it worthy, would still enter a licensing agreement. The patent
applicant could easily influence this by offering more favorable terms during the
probation period, or making license payments conditional upon the completion of the
probationary period. Thus I doubt the effect would be significant.
------------------------------
Date: Sun, 24 Sep 2000 13:15:16 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Software patents are evil.
Bill Unruh wrote:
> In <9Cbz5.2401$[EMAIL PROTECTED]> "Paul Pires" <[EMAIL PROTECTED]>
>writes:
>
> ]Twilight zone. I responded below but.....
>
> ]Is it just me or did this Re: post just get lopped off the branch
> ]by Usenet? Do you see a new posting from me immediately below
> ]this one? or are we still attached to the original thread?
>
> I think it was something I did. Not sure what. Oh well the branch was
> getting mighty long. ( and am I pointing in the right direction with
> that saw?)
>
> ]<SNIP>
> ]>
> ]> Please read. prove does not mean "it follows logically and inelluctibly
> ]> from some premises." A proof is a test of the truth of a statement. That
> ]> is waht the patent office does. That is what the applicant must do. He
> ]> must supply to the patent office all evidence which he knows of which
> ]> might invalidate the patent. He must swear that this patent covers new
> ]> material. These are all standards of proof. Unfortunately as you point
> ]> out patent examiners do not know everything about everything and may
> ]> well be convinced when they should not be. That is why bringing some
> ]> sort of adversarial role into the patent process might help. Ie, a
> ]> patent can be challenged via the patent office by the same process as
> ]> the patent was granted.
>
> ] I'll ignore your testy intro. I know what prove means and I even guessed
> ]at your usage. But, this idea above actually sounds like a good idea. I'm
> ]not being nasty, I think this is neet. One problem, How can you retract,
> ]or reduce a patent once granted without due process. Note: a regulatory
> ]action is not due process.
>
> Well, if the granting thereof is "due process' then surely such a
> bureaucratic, rather than legal reconsideration would also be due
> process. The end result could always be taken to court just as a patent
> can now.
>
> ]Maybe combine this with a provisional status. Something like: A patent can be
> ]forced back into the review process (1 time only) within 6mos. after granting if
> ]certain
> ]challenge requirements are met. Have to be pretty strengent or it will be weak
> ]to
> ]a denial of service by flood attack.
>
> Well, at least in part the filing fees etc would act as a deterent. A
> one time review would not be a good idea or it would behove the patentor
> to have a friend launch a silly challenge to use up that single review.
> On the other hand that single review could be a collective one-- ie a
> number of people could, if they so wished, join in challenging the
> patent in that review process.
>
> ]Naw, this just won't work. if it is reducible, it is not a patent yet. No one
> ] would licence a provisional patent so you might as well not do it.
>
> Well, patent pending seems to be something which carries weight as well.
> Another approach would be to open the granting process-- ie publish
> patent applications as well as granted patents. That way the patent
> could be challenged in the intial review as well. One could limit the
> scope of the challenge (pointing out prior art for example).
There is a downside to public applications. When a secret patent application fails the
applicant can attempt to preserve their IP with trade secrecy. When a public patent
application
fails the applicant would have no "Plan B".
------------------------------
Date: Sun, 24 Sep 2000 13:18:21 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: 128-bit Secure LFSR
Tom St Denis wrote:
> I reposted my slfsr to my website at
>
> http://www.geocities.com/tomstdenis/files/slfsr.c
>
> I am using a single 128-bit LFSR in self-shrinking mode. I would
> appreciate someone who could verify the polynomial used. I am using
> the LFSR in galois config. I made the LFSR poly with a program called
> LFSR.EXE that I found on an ftp that was posted here a bit ago.
>
> It's compact code, albeit not that efficient (are any LFSR's
> efficient?). It features a simple rekeying :), fast enough for desktop
> usage and it's really simple...
Sparse LFSRs can be implemented very efficiently (~memory bandwidth). As
the number of terms in the polynomial goes up so does the work that has to
be performed to produce each output.
------------------------------
Date: Sun, 24 Sep 2000 13:20:53 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: 128-bit Secure LFSR (Whoops)
Jeff Gonion wrote:
> P.S. - I've got a PDF paper that explains LFSR's pretty well, in
> everyday english, including Golumb�s criteria for randomness,
> modulo-2 polynomial math, and The Berlekamp-Massey algorithm,
> which is used to determine the shortest LFSR that can produce
> a given bitstream. If anyone would like a copy, I can email it,
> since this newsgroup doesn't seem to accept binaries.
I'm interested. Why not place the paper on the web and simply publish the URL?
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: What make a cipher resistent to Differential Cryptanalysis?
Date: Sun, 24 Sep 2000 19:36:48 +0200
Simon Johnson wrote:
>
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> > "David C. Barber" wrote:
> > >
> > > DES, for example is considered resistant to Differential
> Cryptanalysis,
> > > particularly in its selection of S-boxes. What about them, or any
> cipher,
> > > makes it DF resistant?
> >
> > I believe that one good way is to arrage to have the
> > S-boxes of the cipher be all different and to have
> > them either key-dependent or fixed but having their
> > ordering dependent on the key. I like to know references
> > to analysis results for such situations, if any.
>
> I don't see how an s-box can have its structure dependent on the key
> without a probability of producing very poor s-boxes. Is this an
> accepted risk or do they use some fool proof transformation.
I have personally no experience in S-box design. But
I suppose one could incorporate some checks to prevent
very poor boxes or else simply rely on the fact that
the chance of their occuring is very small and there
are many rounds of the cipher to compensate for that.
One could also let the key to select from a large set
of tested S-boxes. There are presumably better ways,
but I can't tell for lack of knowledge.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: What make a cipher resistent to Differential Cryptanalysis?
Date: Sun, 24 Sep 2000 19:36:42 +0200
Tom St Denis wrote:
>
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> > "David C. Barber" wrote:
> > >
> > > DES, for example is considered resistant to Differential
> Cryptanalysis,
> > > particularly in its selection of S-boxes. What about them, or any
> cipher,
> > > makes it DF resistant?
> >
> > I believe that one good way is to arrage to have the
> > S-boxes of the cipher be all different and to have
> > them either key-dependent or fixed but having their
> > ordering dependent on the key. I like to know references
> > to analysis results for such situations, if any.
>
> That's not entirely correct. It's possible to have random key
> dependent sboxes and still be vulnerable to attacks.
No practical cipher is absolutely secure. I am at least
not aware that the differential analysis can be applied
to such S-boxes. And I am also asking for literatures
of other attacks, if any.
M. K. Shen
------------------------------
Date: Sun, 24 Sep 2000 12:49:23 -0500
From: [EMAIL PROTECTED] (Jeff Gonion)
Subject: Re: 128-bit Secure LFSR (Whoops)
I don't maintain a website, but if anybody is aware of somplace else
to post it, I'd be glad to.
- Jeff
In article <8ql66s$pnp$[EMAIL PROTECTED]>, Simon Johnson
<[EMAIL PROTECTED]> wrote:
> > P.S. - I've got a PDF paper that explains LFSR's pretty well, in
> > everyday english, including Golumb�s criteria for randomness,
> > modulo-2 polynomial math, and The Berlekamp-Massey algorithm,
> > which is used to determine the shortest LFSR that can produce
> > a given bitstream. If anyone would like a copy, I can email it,
> > since this newsgroup doesn't seem to accept binaries.
> > ----------------------------------------------------------------
>
> Any chance you could stick it on you're webspace? My e-mail server is a
> little dodgy! :)
>
> Simon
>
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: 128-bit Secure LFSR
Date: Sun, 24 Sep 2000 17:38:07 GMT
In article <[EMAIL PROTECTED]>,
"Trevor L. Jackson, III" <[EMAIL PROTECTED]> wrote:
> Tom St Denis wrote:
>
> > I reposted my slfsr to my website at
> >
> > http://www.geocities.com/tomstdenis/files/slfsr.c
> >
> > I am using a single 128-bit LFSR in self-shrinking mode. I would
> > appreciate someone who could verify the polynomial used. I am using
> > the LFSR in galois config. I made the LFSR poly with a program
called
> > LFSR.EXE that I found on an ftp that was posted here a bit ago.
> >
> > It's compact code, albeit not that efficient (are any LFSR's
> > efficient?). It features a simple rekeying :), fast enough for
desktop
> > usage and it's really simple...
>
> Sparse LFSRs can be implemented very efficiently (~memory
bandwidth). As
> the number of terms in the polynomial goes up so does the work that
has to
> be performed to produce each output.
That's not true. Consider Galois Config LFSRs.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Colin Barker" <[EMAIL PROTECTED]>
Subject: Re: Cryptography Challenge
Date: Sun, 24 Sep 2000 19:56:29 +0200
Buster Brown a �crit dans le message ...
>Hi All,
>
>Would any of you have read Talking to Strange Men, by Ruth Rendell.
>Supposedly this novel contains an encryption method that escapes me.
>
>The encryption method uses as key the first sentence of an agreed upon
>novel.
>
>For example:
>
>Given the following cipher-text:
>
>SIDKHKDM AF HCRKIABIE SHIMC KD LFEAILA
>
>And the following key from a novel:
>
>The snow lay thick on the steps and the snowflakes driven by the wind
>looked black in the headlights of the cars.
>
>
>WHAT IS THE ENCRYPTION ALGORITHM?
>
>My friend, a computer science student, says I should easily solve this,
>however I still can't determine what the algorithm is.
>A simple subsitution was used, supposedly.
SPOILER
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
HINT:
Assign successive letters of the alphabet (cipher letters) to successive
letters of the sentence (plain letters), ignoring letters in the sentence
which have already been assigned to.
--
Colin
E-mail: mailto:[EMAIL PROTECTED]
Internet: http://perso.wanadoo.fr/colin.barker
------------------------------
** 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
******************************
