Cryptography-Digest Digest #697, Volume #12 Sun, 17 Sep 00 07:13:01 EDT
Contents:
Re: QUESTION ABOUT ALGORITHMS ("Paul Pires")
New and recent books from Wiley (CryptoBook)
RC4: Tradeoff key/initialization vector size? (Stephan Gehring)
Re: Double Encryption Illegal? (Paul Schlyter)
Re: Double Encryption Illegal? (Paul Schlyter)
Re: Extremely slow in DES software implementation ("Kasper Pedersen")
Re: Intel's 1.13 MHZ chip (Vernon Schryver)
RSA Cryptography Today FAQ (1/1) ([EMAIL PROTECTED])
Re: QUESTION ABOUT ALGORITHMS (Serge Paccalin)
Re: RC4: Tradeoff key/initialization vector size? (David Crick)
Re: ExCSS Source Code (Gisle =?iso-8859-1?Q?S=E6lensminde?=)
Re: Question on self-shrinking (Francois Grieu)
Re: RC4: Tradeoff key/initialization vector size? (Tom St Denis)
Re: Double Encryption Illegal? (Tom St Denis)
Re: SDMI Crypto Challenge (Tom St Denis)
Re: QUESTION ABOUT ALGORITHMS (Mok-Kong Shen)
----------------------------------------------------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: QUESTION ABOUT ALGORITHMS
Date: Sat, 16 Sep 2000 22:42:51 -0700
Big Boy Barry <[EMAIL PROTECTED]> wrote in message
news:t9Xw5.3209$[EMAIL PROTECTED]...
> If someone publsihes an algorithm, can someone else patent it?
Nope. Well depends, as long as the inventor is the one fileing and no more than
one
year has gone by .
Except in some weird situations, the inventor is the only one who can seek
a patent for the material.
Paul
>
>
> "Melinda Harris" <[EMAIL PROTECTED]> wrote in message
> news:hBKw5.30993$[EMAIL PROTECTED]...
> > Ladies and Gentlemen
> > Can anyone tell me how to patent an algorithm. Where to go. What to sign
> and
> > how much it costs???
> > Any response would be greatly appreciated
> > EIA
> >
> >
>
>
>
------------------------------
From: [EMAIL PROTECTED] (CryptoBook)
Subject: New and recent books from Wiley
Date: 17 Sep 2000 06:00:28 GMT
16 September 2000
Classical Crypto Books is pleased to announce the following recent update to
the CCB catalog focusing on: New and recent books from John Wiley & Sons.
COMPUTER SECURITY
SECRETS AND LIES: Digital Security in a Networked World
by Bruce Schneier
When Bruce Schneier wrote Applied Cryptography, he thought cryptography was The
Answer for digital security. Now he knows how naive he was and how difficult
the problem really is. Highly accessible, thoughtful; must read for every
computer user. Published at $29.99.
HB, John Wiley & Sons, 2000, 431 pp.
Nonmember $27.95, Member $24.95
BIOGRAPHIES AND MEMOIRS
ALLAN PINKERTON: The First Private Eye
by James Mackay
Pinkerton, synonymous with security/protection. His trademark, an eye,
inspired the term "private eye". As Lincoln's spymaster, he managed a network
of spies behind Confederate lines. "A man at once deeply admirable and quite
obnoxious." -- The Times. Published at $27.95.
HB, John Wiley & Sons, 1997, 256 pp.
Nonmember $25.95, Member $23.95
CRYPTOLOGY
THE BIT AND THE PENDULUM: From Quantum Computing to M Theory -- The New Physics
of Information
A friendly guide to a revolution now taking place at the forefront of science.
Bits are us, and everything else too, or so it seems. A lighthearted approach
to some weighty ideas, including quantum cryptography, quantum teleportation,
and wetware. Published at $27.95.
HB, John Wiley & Sons, 2000, 287 pp.
Nonmember $25.95, Member $23.95
THE TWOFISH ENCRYPTION ALGORITHM: A 128-Bit Block Cipher
by Bruce Schneier
Published at $49.99.
HB, John Wiley & Sons, 1999, 202 pp.
Nonmember $46.95, Member $42.95
PROGRAMMING
CRYPTOGRAPHY FOR VISUAL BASIC: A Programmer's Guide to the Microsoft CryptoAPI
by Richard Bondi
The little-known, CryptoAPI is a large collection of strong crypto routines
that come for free with Windows. Difficult to use, until now. This book
supplies interface code and describes how to call, and use, the central crypto
routines from Visual Basic. Includes a CDROM. Published at $49.99.
SB, John Wiley & Sons, 2000, 479 pp.
Nonmember $45.95, Member $41.95
APPLIED CRYPTOGRAPHY (SECOND EDITION): Protocols, Algorithms, and Source Code
in C
Published at $79.99.
HB, John Wiley & Sons, 1996, 783 pp.
Nonmember $74.95, Member $69.95
APPLIED CRYPTOGRAPHY (SECOND EDITION): Protocols, Algorithms, and Source Code
in C
by Bruce Schneier
Published at $54.99.
SB, John Wiley & Sons, 1996, 783 pp.
Nonmember $49.95, Member $43.95
CURRENT AFFAIRS
THE ELECTRONIC PRIVACY PAPERS: Documents on the Battle for Privacy in the Age
of Surveillance
by Bruce Schneier
Published at $59.99.
HB, John Wiley & Sons, 1997, 765 pp.
Nonmember $55.95, Member $50.95
HISTORY
WAR BENEATH THE SEA: Submarine Conflict During World War II
by Peter Padfield
Published at $30.00.
HB, John Wiley & Sons, 1995, 576 pp.
Nonmember $27.95, Member $25.95
INTELLIGENCE
MACARTHUR'S UNDERCOVER WAR: Spies, Saboteurs, Guerrillas, and Secret Missions
by William B. Breuer
Published at $24.95.
HB, John Wiley & Sons, 1995, 271 pp.
Nonmember $22.95, Member $20.95
SHADOW WARRIORS: The Covert War in Korea
by William B. Breuer
Published at $27.95.
HB, John Wiley & Sons, 1996, 272 pp.
Nonmember $25.95, Member $23.95
UNDERCOVER TALES OF WORLD WAR II
by William B. Breuer
Published at $24.95.
HB, John Wiley & Sons, 1999, 252 pp.
Nonmember $22.95, Member $19.95
THE RED ORCHESTRA: The Soviet Spy Network Inside Nazi Europe
by V. E. Tarrant
Published at $24.95.
HB, John Wiley & Sons, 1996, 224 pp.
Nonmember $22.95, Member $20.95
ESPIONAGE: The Greatest Spy Operations of the 20th Century
by Ernest Volkman
Published at $24.95.
HB, John Wiley & Sons, 1995, 290 pp.
Nonmember $22.95, Member $20.95
ESPIONAGE: The Greatest Spy Operations of the 20th Century
by Ernest Volkman
Published at $16.95.
SB, John Wiley & Sons, 1995, 288 pp.
Nonmember $15.95, Member $14.95
SPIES: The Secret Agents Who Changed the Course of History
by Ernest Volkman
Published at $16.95.
SB, John Wiley & Sons, 1994, 304 pp.
Nonmember $15.95, Member $14.95
BEGINNERS AND ENTHUSIASTS
SPY SCIENCE: 40 Secret-Sleuthing, Code-Cracking, Spy Catching Activities for
Kids
by Jim Wiese
SB, John Wiley & Sons, 1996, 128 pp.
Nonmember $12.95, Member $11.50
FOREIGN LANGUAGE
DUETSCH FUR ALLE: Beginning College German: A Comprehensive Approach, Third
Edition
by Werner Haas, Gustave Bording Mathieu
A BEST BUY! Published at $44.95.
HB, John Wiley & Sons, 1987, 599 pp.
Nonmember $9.95, Member $7.95
==============
HB = Hardbound
SB = Softbound
==============
All items are in stock and available now. Member prices are available to
members of the American Cryptogram Association, the US Naval Cryptologic
Veterans Association, and full-time students. Shipping and handling are extra.
For complete ordering information, a free catalog of crypto books by return
e-mail, or for information about membership in the American Cryptogram
Association, please send e-mail to: [EMAIL PROTECTED]
Best Wishes,
Gary
Gary Rasmussen
Classical Crypto Books
E-Mail: [EMAIL PROTECTED]
Fax: (603) 432-4898
------------------------------
From: Stephan Gehring <[EMAIL PROTECTED]>
Subject: RC4: Tradeoff key/initialization vector size?
Date: Sat, 16 Sep 2000 23:49:56 -0700
Hi,
I am looking at a situation where RC4 is initialized using a secret key
concatenated with a public initialization vector, The latter varies with
each message sent and is sent as plaintext along with the encrypted
message.
The question I have is what considerations are taken into account when
determining the size of the key versus the size of the initialization
vector. For example, should the size of the initialization vector be a
percentage of the key size? What is the minimum tolerable size of the
initialization vector for a key of a given size?
Thanks, Stephan
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Crossposted-To: comp.databases.oracle
Subject: Re: Double Encryption Illegal?
Date: 17 Sep 2000 09:55:54 +0200
In article <8pvnav$gdt$[EMAIL PROTECTED]>,
Tom St Denis <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>,
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>>
>>
>> PRdO wrote:
>>>
>>> IMHO double encryption *does not* add security, i.e., double
>>> encryption in 128-bit doesn't equal better encryption.
>>> (since encryption uses random keys, "randoming" again the data
>>> would not lead to more secure data).
>>
>> If you have an algorithm that does a perfect job (do
>> you happen to have one?), then there is by definition
>> nothing to improve. Otherwise, multiple encryption may
>> help, if done properly.
>
> Ah but double encryption is not the way to go about it.
So you're claiming that triple-DES is no more secure than single-DES ???
--
================================================================
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: [EMAIL PROTECTED] (Paul Schlyter)
Crossposted-To: comp.databases.oracle
Subject: Re: Double Encryption Illegal?
Date: 17 Sep 2000 09:56:27 +0200
In article <[EMAIL PROTECTED]>,
wtshaw <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>, Mok-Kong Shen
> <[EMAIL PROTECTED]> wrote:
> ...
>> You meant it should be triple, like 3-DES??
>>
>> M. K. Shen
>
> When a person uses 3-DES, they are single encrypting with 3-DES.
FYI: 3-DES consists of three rounds of DES, using two or three
different keys.
> An algorithm can be made of any conbination of steps. When two or more
> pieces are combined, the result is one piece. Consider that such a
> request, regulation, standard, whim, or pipe dream to limit so called
> double encryption is a fog to confuse whereever possible; ambiguity shows
> dualism of purpose.
Nonsense! Calling the use of two encryptions in succession "double
encryption", or three encryptions in succession "triple encryption"
is a correct description of the procedure.
However, "double enryption" or "triple encryption" is not always more
secure than "single encryption". Consider for instance the good ol'
Caesar cipher: double-Caesar or triple-Caesar will be no more secure
than single-Caesar. But triple-DES will be more secure than single-DES.
--
================================================================
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: "Kasper Pedersen" <[EMAIL PROTECTED]>
Subject: Re: Extremely slow in DES software implementation
Date: Sun, 17 Sep 2000 08:55:55 GMT
"Eric Young" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Kasper Pedersen wrote:
> > "P.C. Teo" <[EMAIL PROTECTED]> wrote in message
> > news:8psqqj$fg3$[EMAIL PROTECTED]...
> > > I am implementing a standard DES software (Downloaded from Internet)
in my
> > > project. I found that it takes around 25+ seconds to encrypt a 1MB
file
> > but
> > > PGP takes less than 4 seconds.
> > Hoping not to sound like too annoying:
> > I implemented DES in optimized assembler for Pentium-II/K6 and newer
cpu's.
> > around 2.5MHz on a K7TB-700 (running 16 rounds).
>
> On a pentium II 350mhz (NT), a particular widly distributed free DES
> implementation gets 5.95 Mbytes/sec for DES-CBC and
> 2.34 for DES-EDE-CBC mode (triple DES). This is C code.
> The pentium Assember code is 8.1 Mbytes/sec and 2.9 Mbytes/sec.
>
> I would sugest you look for a different DES implementation :-)
Beware: I used block frequency, you used bytes per second.
Quick math: bytes_processed/cpu_clock_frequency
2.5MHz *8 bytes /700MHz = 0.028
8.1Mbyte/sec /350MHz = 0.023
I still win? Maybe, maybe not. As far as I remember, the K7 CPU is somewhat
faster than the Pentium-II when it comes to my DES implementation, around
20%?
And 0.028/0.023=1.22.
I do believe I had my hands (or - in this case - my analyzer) on yours.
/Kasper
------------------------------
From: [EMAIL PROTECTED] (Vernon Schryver)
Subject: Re: Intel's 1.13 MHZ chip
Date: 17 Sep 2000 00:27:02 -0600
In article <[EMAIL PROTECTED]>,
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
>No, I'm saying that you have invented a picture of how major
>computer procurements have occured in the NSA that if true
>would constitute malfeasance on the part of high-ranking
>public officials, without providing any evidence to back it up.
>Such accusations are serious matters, not to be made frivolously.
>Indeed, you could be running afoul of the libel laws.
That's poppycock as even (or especially) a career government employee
knows. Never mind that what the other fellow said could not be libel
given the far stronger statements published frequently from famous
commentators and polticians. Some politicians have made careers by
saying worse.
The need to wave big boxes is always a major part of their sales cycle,
just as in the sales cycle for nice cars, big trucks, or fancy houses.
First you convince the customer to buy. The you let the customer find
and use the rationalizations needed to get past the corporate budget
committee or the Congressional oversight or whatever committee.
I saw that syndrome work up close during my 8 years long ago in a
Dept of Comm organization that eventually had a couple of CDC 6000's.
I've also see it from the other side. An awful lot of fancy (for the era)
graphics boxes were sold because of a multi-player flight simulator game,
including into outfits where the use of the game even on lunch hours was
explicitly forbidden because ancient VAX's would crash when they saw
several dozen multicast UDP packets per second. The game was enough fun
to convince people that they really didn't mind converting code and that
the incumbant vendors' new boxes weren't so nice after all.
Vernon Schryver [EMAIL PROTECTED]
------------------------------
Crossposted-To:
talk.politics.crypto,alt.security.ripem,sci.answers,talk.answers,alt.answers,news.answers
Subject: RSA Cryptography Today FAQ (1/1)
from: [EMAIL PROTECTED]
reply-to: [EMAIL PROTECTED]
Date: 17 Sep 2000 09:15:43 GMT
Archive-name: cryptography-faq/rsa/part1
Last-modified: 1997/05/21
An old version of the RSA Labs' publication "Answers to Frequently Asked
Questions about Today's Cryptography" used to be posted here until May
1997. These postings were not sponsored or updated by RSA Labs, and
for some time we were unable to stop them. While we hope the information
in our FAQ is useful, the version that was being posted here was quite
outdated. The latest version of the FAQ is more complete and up-to-date.
Unfortunately, our FAQ is no longer available in ASCII due to its
mathematical content. Please visit our website at
http://www.rsa.com/rsalabs/ to view the new version of the FAQ with your
browser or download it in the Adobe Acrobat (.pdf) format.
RSA Labs FAQ Editor
[EMAIL PROTECTED]
------------------------------
From: Serge Paccalin <[EMAIL PROTECTED]>
Subject: Re: QUESTION ABOUT ALGORITHMS
Date: Sun, 17 Sep 2000 12:04:00 +0200
[Posted to/publi� sur sci.crypt
copy mailed to/copie par courriel � mok-kong.shen@t-
online.de.]
On/le Sat, 16 Sep 2000 18:19:27 +0200,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote/a �crit...
>
>
> Melinda Harris wrote:
> >
> > Can anyone tell me how to patent an algorithm. Where to go. What to sign and
> > how much it costs???
>
> For European patents, see
>
> http://www.european-patent-office.org
Don't bother, you cannot patent an algorithm in Europe.
--
___________
_/ _ \_`_`_`_) Serge PACCALIN
\ \_L_) [EMAIL PROTECTED]
-'(__) L'hypoth�se la plus �labor�e ne saurait remplacer
_/___(_) la r�alit� la plus bancale. -- San-Antonio (1921-
2000)
------------------------------
From: David Crick <[EMAIL PROTECTED]>
Subject: Re: RC4: Tradeoff key/initialization vector size?
Date: Sun, 17 Sep 2000 11:15:25 +0100
Stephan Gehring wrote:
>
> Hi,
>
> I am looking at a situation where RC4 is initialized using a secret key
> concatenated with a public initialization vector, The latter varies with
> each message sent and is sent as plaintext along with the encrypted
> message.
> The question I have is what considerations are taken into account when
> determining the size of the key versus the size of the initialization
> vector. For example, should the size of the initialization vector be a
> percentage of the key size? What is the minimum tolerable size of the
> initialization vector for a key of a given size?
>
> Thanks, Stephan
>From the CipherSaber[-1] documentation (http://ciphersaber.gurus.com)
The user key is a text string, rather than a hex value, because
humans are more likely to be able to memorize a text string with
sufficient entropy. To leave room for the initialization vector,
the length of the user key must be less than 246 bytes. To insure
adequate mixing of the initialization vector and user key, we
recommend you select a user key of 54 bytes or less.
--
+-------------------------------------------------------------------+
| David A. Crick <[EMAIL PROTECTED]> PGP: (SEP-2000 KEY) 0x3226F499 |
| Damon Hill Tribute Site: http://www.geocities.com/MotorCity/4236/ |
| M. Brundle Quotes: http://members.tripod.com/~vidcad/martin_b.htm |
+-------------------------------------------------------------------+
------------------------------
From: [EMAIL PROTECTED] (Gisle =?iso-8859-1?Q?S=E6lensminde?=)
Subject: Re: ExCSS Source Code
Date: 17 Sep 2000 12:37:06 +0200
In article <8q0m5m$hhn$[EMAIL PROTECTED]>, Bryan Olson wrote:
>David A Molnar wrote:
>
>> Also the licensing of players. Since you can't build a
>> player without implementing CSS.
>
>There's a net.myth that the purpose of CSS was to control
>licensing of players. The DVD consortium already had that
>with its patent pool. The conditions to license CSS are
>entirely content-control requirements.
>
In which countries has the DVD consortium valid patents, and what for.
--
Gisle S�lensminde ( [EMAIL PROTECTED] )
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going
to land, and it could be dangerous sitting under them as they fly
overhead. (from RFC 1925)
------------------------------
From: Francois Grieu <[EMAIL PROTECTED]>
Subject: Re: Question on self-shrinking
Date: Sun, 17 Sep 2000 12:48:39 +0200
[EMAIL PROTECTED] (David A. Wagner) wrote:
> Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
>> I was recently thinking a bit about self-shrinking LFSR generators,
>> and was wondering... are there any differences between the following
>
>> do {
>> a = lfsr_bit();
>> b = lfsr_bit();
>> } while( a ); return b;
>>
>> do {
>> a = lfsr_bit();
>> b = lfsr_bit();
>> } while( b ); return a;
>
> These two are clearly equivalent; you can just swap the initial
> states of the two registers.
Benjamin Goldberg's point is that there is only one register.
The two designs do appear equivalent: for any lfsr there exist a mirror
lfsr that output the sequence reversed (*), and reversing the lfsr in
one construct will turn it into the other construct, with output
reversed.
Francois Grieu
(*) <http://www.cdg.org/tech/a_ross/LFSR.html>
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: RC4: Tradeoff key/initialization vector size?
Date: Sun, 17 Sep 2000 10:39:30 GMT
In article <[EMAIL PROTECTED]>,
David Crick <[EMAIL PROTECTED]> wrote:
> Stephan Gehring wrote:
> >
> > Hi,
> >
> > I am looking at a situation where RC4 is initialized using a secret
key
> > concatenated with a public initialization vector, The latter varies
with
> > each message sent and is sent as plaintext along with the encrypted
> > message.
> > The question I have is what considerations are taken into account
when
> > determining the size of the key versus the size of the
initialization
> > vector. For example, should the size of the initialization vector
be a
> > percentage of the key size? What is the minimum tolerable size of
the
> > initialization vector for a key of a given size?
> >
> > Thanks, Stephan
>
> From the CipherSaber[-1] documentation (http://ciphersaber.gurus.com)
>
> The user key is a text string, rather than a hex value, because
> humans are more likely to be able to memorize a text string with
> sufficient entropy. To leave room for the initialization vector,
> the length of the user key must be less than 246 bytes. To insure
> adequate mixing of the initialization vector and user key, we
> recommend you select a user key of 54 bytes or less.
I would strongly recommend against using ASCII text as the key for
RC4. You should really hash it first.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Crossposted-To: comp.databases.oracle
Subject: Re: Double Encryption Illegal?
Date: Sun, 17 Sep 2000 10:40:59 GMT
In article <8q1tea$bhp$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Paul Schlyter) wrote:
> In article <8pvnav$gdt$[EMAIL PROTECTED]>,
> Tom St Denis <[EMAIL PROTECTED]> wrote:
>
> > In article <[EMAIL PROTECTED]>,
> > Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> >>
> >>
> >> PRdO wrote:
> >>>
> >>> IMHO double encryption *does not* add security, i.e., double
> >>> encryption in 128-bit doesn't equal better encryption.
> >>> (since encryption uses random keys, "randoming" again the data
> >>> would not lead to more secure data).
> >>
> >> If you have an algorithm that does a perfect job (do
> >> you happen to have one?), then there is by definition
> >> nothing to improve. Otherwise, multiple encryption may
> >> help, if done properly.
> >
> > Ah but double encryption is not the way to go about it.
>
> So you're claiming that triple-DES is no more secure than single-
DES ???
Read my message. Geez. I said "double" encryption is not the way to
go about added security.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: SDMI Crypto Challenge
Date: Sun, 17 Sep 2000 10:44:39 GMT
In article <8q17js$b6n$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Scott Craver) wrote:
> Tom St Denis <[EMAIL PROTECTED]> wrote:
> >
> >If I can play the audio on my comp I can rip it. Plain and simple.
> >And since MP3 technology already exists I can re-encode it to a
> >suitable form.
>
> I think you might be confusing SDMI with encryption. This
> is not audio encryption, but audio watermarking. When you
> rip the CD to your hard drive and MP3 compress it, the
> "don't record me" labels will (they hope) survive inside
> the music. Then, later, some black-box MP3 recorder will
> refuse to make a copy of it.
If you can't hear the watermark then I can do an analogue rip. So
what. Or I can filter it out. Or ... Just like hiding messages in
JPEG's. I can always filter it out.
> >Why not release good music that people will not mind buying instead
of
> >selling rubish and hoping for some DMCA to protect you?
>
> Kids are forking out gobs of cash as it is, that's why.
> Maybe it's a search for a cause: any slump in sales our
> recording industry might blame on MP3 piracy rather than a
> preponderance of NKOTB-type bands.
Ever notice that the levy on CDs and DVDS is because of music/video
piracy? But I often use CDs to pirate software ... hehhehehe so why
don't all software companies get shares in the levy?
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: QUESTION ABOUT ALGORITHMS
Date: Sun, 17 Sep 2000 13:22:04 +0200
Serge Paccalin wrote:
>
> On/le Sat, 16 Sep 2000 18:19:27 +0200,
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote/a �crit...
> >
> >
> > Melinda Harris wrote:
> > >
> > > Can anyone tell me how to patent an algorithm. Where to go. What to sign and
> > > how much it costs???
> >
> > For European patents, see
> >
> > http://www.european-patent-office.org
>
> Don't bother, you cannot patent an algorithm in Europe.
It depends on how clever that you could rendered that
under a cover of some hardware, I suppose.
M. K. Shen
------------------------------
** 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
******************************
