Cryptography-Digest Digest #152, Volume #11 Fri, 18 Feb 00 14:13:01 EST
Contents:
Re: EOF in cipher??? (lordcow77)
Re: Question about OTPs ("Dr.Gunter Abend")
Re: OAP-L3 Encryption Software - Complete Help Files at web site (Lincoln Yeoh)
Re: Method to break triple-DES (Mickey McInnis)
Re: UK publishes 'impossible' decryption law ("shivers")
Re: Processor speeds. (Mok-Kong Shen)
Re: EOF in cipher??? (Mok-Kong Shen)
Re: VB & Crypto (Glenn Larsson)
Re: I stole also the diary and calendar of Markku J. Saarelainen (Mok-Kong Shen)
Re: NTRU Speed Claims (100x faster, etc.), explained (Mike Rosing)
Re: Basic Crypto Question 4 (Mok-Kong Shen)
Re: Does the NSA have ALL Possible PGP keys? (Johnny Bravo)
Re: EOF in cipher??? (Johnny Bravo)
Re: Keys & Passwords. (Mok-Kong Shen)
Re: Basic Crypto Question 4 (Mike Rosing)
Re: EOF in cipher??? (Johnny Bravo)
Re: EOF in cipher??? (Jerry Coffin)
Re: Q: Division in GF(2^n) (Jerry Coffin)
Re: EOF in cipher??? (Jerry Coffin)
----------------------------------------------------------------------------
Subject: Re: EOF in cipher???
From: lordcow77 <[EMAIL PROTECTED]>
Date: Fri, 18 Feb 2000 08:59:11 -0800
In article <[EMAIL PROTECTED]>, Runu Knips
<[EMAIL PROTECTED]> wrote:
>Thats both against the standard. ISO specifies that int must be
at least
>16 bit (i.e. it says short must be 16 bit, and sizeof(int) >=
>sizeof(short),
>which means int is also at least 16 bit). A character value,
however, is
>the smallest type which has at least 7 bit.
ISO C Standard 5.2.4.2.1 :
"Their implementation-defined values shall be equal or greater
in magnitude (absolute value) to those shown, with the same
sign...number of bits for smallest object that is not a bit-
field CHAR_BIT 8"
"If the value of an object of type char is treated as a signed
integer when used in an expression, the value of CHAR_MIN
shall be the same as that of SCHAR_MIN and the value of
CHAR_MAX shall be the same as that of SCHAR_MAX. Otherwise, the
value of CHAR_MIN shall be 0 and the value of CHAR_MAX shall
be the same as that of UCHAR_MAX) The value UCHAR_MAX+1
shall equal 2 raised to the power of CHAR_BIT"
* 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: "Dr.Gunter Abend" <[EMAIL PROTECTED]>
Subject: Re: Question about OTPs
Date: Fri, 18 Feb 2000 18:15:13 +0100
John Savard wrote:
>>Is that still true if you compress the plaintexts beforehand?
>>Especially if you use a compression algorithm that nearly
>>completely removes the redundancy of the original byte streams.
>
> That is sort of the complementary case to the OTP.
>
> Zero-redundancy plaintext, on the other hand, could be
> encrypted unbreakably even by a trivial system of encryption,
> since even if it was easy to try all possible keys, every key
> would yield a possible plaintext.
Oh, really? If you use a home-made compression program, unknown
to the eavesdropper, it probably will compress ineffectively, so
that the statistical test gives a result, and if you use a
commercially available packer, he may try all possibilities in
order to *see* the plaintext. I fear, this trick will *not* solve
Arthur Dardia's problem. It only makes it harder to detect a
probable plaintext, because all possible packers have to be
tested for all possible decryptions.
> The point is that the existence of such a case is not an
> argument against worrying about making a mistake that totally
> vitiates the security of an OTP.
No, of course. I only asked whether *simple* tools exist for
breaking impaired "OTP" of compressed messages.
Ciao, Gunter
------------------------------
From: [EMAIL PROTECTED] (Lincoln Yeoh)
Crossposted-To: talk.politics.crypto,alt.privacy
Subject: Re: OAP-L3 Encryption Software - Complete Help Files at web site
Date: Fri, 18 Feb 2000 17:16:32 GMT
Reply-To: [EMAIL PROTECTED]
On Thu, 17 Feb 2000 22:43:42 -0800, Anthony Stephen Szopa
<[EMAIL PROTECTED]> wrote:
>Convince us. Prove your position. Demonstrate that the software
>is "garbage."
Hmm didn't we go through this some time back in october 1999
(see OAP-L3: How Do You Spell S-H-A-R-E-W-A-R-E)
I ran your software through the LOAP-L3 (Link's Omniscient Analysis Program
- Level 3).
e.g.:
Sample output:
C:\>LOAP-L3.EXE
Beginning analysis (please wait)
.........
Done!
Result: "OAP-L3 is weak crypto/snake oil"
Thank you for using LOAP-L3!
C:\>
As you can see, LOAP-L3 is a very useful piece of software. However you
aren't allowed to reverse engineer it to find out how it does what it does.
The source code and the algorithm used are top secret. I'm telling you it
works though! And I know what I'm talking about. Really! Honestly! Other
people are wrong, if they disagree they haven't looked at it thoroughly
enough."
Have a nice weekend,
Link.
****************************
Reply to: @Spam to
lyeoh at @[EMAIL PROTECTED]
pop.jaring.my @
*******************************
------------------------------
From: [EMAIL PROTECTED] (Mickey McInnis)
Subject: Re: Method to break triple-DES
Date: 18 Feb 2000 17:07:29 GMT
Reply-To: [EMAIL PROTECTED]
In article <88iko6$d3j$[EMAIL PROTECTED]>, "Scott Fluhrer"
<[EMAIL PROTECTED]> writes:
|>
|> Mickey McInnis <[EMAIL PROTECTED]> wrote in message
|> news:88hlt8$m76$[EMAIL PROTECTED]...
|> > In article <[EMAIL PROTECTED]>, Johnny Bravo
|> <[EMAIL PROTECTED]> writes:
|> > |> On Thu, 17 Feb 2000 17:28:31 +0100, "Adam Szewczyk"
|> > |> <[EMAIL PROTECTED]> wrote:
|> > |>
|> > |> >Hello,
|> > |> >
|> > |> >I study computer science at the University of Wroclaw (Poland).
|> Actually I'm
|> > |> >looking for an implementation of a method to break triple-DES (linear
|> and
|> > |> >differential cryptanalysis). If you know where I can find those
|> informations
|> > |> >please let me now.
|> > |>
|> > |> ROTFLMAO.
|> > |>
|> > |> If you ever figure such a thing out, let me know, there are a few
|> banks
|> > |> here in the US with entire too much money.
|> >
|> > Actually, I've heard that there was a paper published recently showing
|> > a potentially practical attack on Triple DES that's considerably less
|> > effort than standard key exhaustion against a 112 bit (2xDES) key.
|> > It's some sort of meet-in-the middle attack, and was not too many times
|> > more trials than regular DES by key exhaustion.
|> >
|> > If true, and if I recall correctly, it did sound like Triple DES was
|> > significantly less secure than previously thought.
|> >
|> > Unfortunately, I don't have a reference. I think it was in the last year
|> > or so that I saw it mentioned, probably on this newsgroup.
|>
|> Is this the attack by Stephen Lucks(sp?)? In the version of the paper
|> I saw, it took gobs of known plaintext, O(2**90) trial DES encryptions
|> and an unspecified (large) number of table operations. I have the paper
|> at work -- if you need any more details, ask.
|>
That might be it. My recollection was that it was far less than 2**90
trials, but I can't say for sure.
Thanks,
|> --
|> poncho
|>
|>
|>
|>
--
Mickey McInnis - [EMAIL PROTECTED]
--
All opinions expressed are my own opinions, not my company's opinions.
------------------------------
From: "shivers" <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: UK publishes 'impossible' decryption law
Date: Fri, 18 Feb 2000 17:16:03 -0000
Scotty wrote in message
<[EMAIL PROTECTED]>...
>
>Gordon Walker wrote in message <[EMAIL PROTECTED]>...
>>On Fri, 18 Feb 2000 11:16:17 +0100, "ink" <[EMAIL PROTECTED]>
>>wrote:
>>
>>>>Any firearm can be used as a weapon. The US govt considers crypto to be
>>>dangerous
>>>>
>>>>enough that it is classified as a "munition". What does that tell you?
>>>
>>>Hardly any other government has doen that. What does that tell you?
>>
>>Many western governments (UK, France etc) have restricted cryptography
>>in some way. I neither know nor care whether they implemented these
>>restrictions by such a classification.
>
>BTW France was very restricted, until a short while ago, when the whole law
>was reversed, so that now France is much freer than the UK.
>
>
>
Isn't the whole of Europe restricting crypto (which is classified as a
munition) under the Wasannaar agreement (might be spelt wrong). The US
(AFAIK) signed this agreement as well, but implements the crypto part of it
differently.
See http://cwis.kub.nl/~frw/people/koops/cls2.htm for details.
(don't know how accurate it all is, but it looks pretty serious)
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Processor speeds.
Date: Fri, 18 Feb 2000 18:27:44 +0100
John wrote:
>
> MHZ (I suspected) was the key. I guess I wanted a rough
> estimate of how much faster the best home PC is as compared to
> the latest "super-computer." I know that the gap is closing.
On the other hand, a computer consiting of a huge number of
PC-chips (like the one used for nuclear simulation) is a super-
computer. Distributed computing in the proper sense, where
fairly long communication paths and hence overheads are involved,
may still be not competive in some applications. But computers
of the afore-mentioned kind is, I believe, more cost-effective
than computers with a few number of super-fast processors and
can probably be more easily built and maintained and also expanded
as the necessity arises. But there are some big computing centres
(with the 'classical' super-computers) where such opinions are
(understandably) more or less heresy even today.
M. K. Shen
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: EOF in cipher???
Date: Fri, 18 Feb 2000 18:27:53 +0100
Runu Knips schrieb:
>
> "Trevor Jackson, III" schrieb:
> > Mok-Kong Shen wrote:
> > > To be sure that I didn't misunderstand, I like to ask whether the
> > > code (from KR):
> > > while ((C = getc(fp)) != EOF)
> > > .........
> > > needs to be modified or using rb is sufficient for taking care of
> > > the presence of any bit combinations in the file. Thanks.
> > The issue is the type of the variable C. To operate correctly it must
> > be an int not a char.
>
> Unfortunately, the above code will run on many systems without
> problems until fp is a binary file which happends to contain
> the code 0xff, which is equal to (signed char)-1 (on machines
> with 8 bits for a character).
I have read quite a lot in this thread but, because of non-unanimity
of opinions expressed, am still not sure of what is to be done
correctly. Could some experts please post a piece of C or C++ code
for writing AND reading binary stuffs to/from a file (byte sequences
containing arbitrary bit combinations) that are standard conforming
and guaranteed to work on all systems (together with things to be
taken care of on the command level of the operating systems,
if any). That would bring the discussions to a happy end. Thanks
in advance.
M. K. Shen
=========================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: Glenn Larsson <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: VB & Crypto
Date: Fri, 18 Feb 2000 18:14:19 +0100
lordcow77 wrote:
> VB is a poor prototyping language for anything other than GUIs.
> The lack of bit operations and unsigned integer support really
> hurts and the weak typing of the language allows (ie. Variants)
> logic and algorithm errors to creep in where they normally would
> be caught in a more strongly typed language.
Perhaps, but like the fighter pilots say
-"It's not the plane that counts; it's the pilot"
Regards,
Glenn
(P.S: Likewise; as an ex ASM hacker, i could say that
C++ is kidstuff)
_________________________________________________
Spammers will be reported to their government and
Internet Service Provider along with possible legal
reprocussions of violating the Swedish "Personal
Information Act" of 1998. (PUL 1998:204)
This is punishable by a fine or 6 month to 2 years
imprisonment (Paragraph 49)
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: I stole also the diary and calendar of Markku J. Saarelainen
Date: Fri, 18 Feb 2000 18:43:04 +0100
William A. Nelson wrote:
>
> organization in detail. It does appear that Markku J. Saarelainen had the
> skill of deceiving and influencing people since early 1970's.
This group is devoted to cryptology and tightly related issues
not to human skill, psychology or even religion!!
M. K. Shen
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: NTRU Speed Claims (100x faster, etc.), explained
Date: Fri, 18 Feb 2000 12:09:14 -0600
John Myre wrote:
> In regards to NTRU's suitability for use, is it correct to say
> that it expands the plaintext significantly? That is, the plaintext
> is a sequence of N values, each modulo p ("the small modulus").
> The ciphertext is also a sequence of N values, but they are modulo
> q ("the large modulus"). This means that the data has expanded
> by log(q)/log(p). In their example parameter sets, we have:
>
> (expansion) plain cipher
> security N q p log(q)/log(p) bits bits
> ----------------------------------------------------
> moderate 107 64 3 3.8 170 642
> high 167 128 3 4.4 265 1169
> highest 503 256 3 5.0 797 4024
>
> (approximately)
I think that's a bit too high. After asking Joe Silverman lots
of dumb questions, he explained that you can get it down to 3:4
plain:cipher ratio. Still, there's definitly expansion.
> I suppose if we are just trying to exchange session keys, then
> this doesn't matter, since the plaintext is small, anyway.
> (And RSA, et al., also have a minimum message size, which
> seems comparable to the numbers above).
I think the purpose of NTRU is key exchange. That may not be the
way it's marketed, but that's how the mathematicians see it.
> Are there cases where we want to encrypt larger data?
Large blocks of keys? In general, I don't think so.
Patience, persistence, truth,
Dr. mike
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Basic Crypto Question 4
Date: Fri, 18 Feb 2000 19:21:12 +0100
[EMAIL PROTECTED] wrote:
>
> Has Elliptic Curve Crypto Come of Age?
You may like to read
http://cacr.math.uwaterloo.ca/~ajmeneze/publications/ecdsa.pdf
(or ..../ecdsa.ps)
M. K. Shen
------------------------------
From: Johnny Bravo <[EMAIL PROTECTED]>
Crossposted-To: misc.survivalism
Subject: Re: Does the NSA have ALL Possible PGP keys?
Date: Fri, 18 Feb 2000 13:19:35 +0000
On Fri, 18 Feb 2000 10:56:59 -0500, "Trevor Jackson, III"
<[EMAIL PROTECTED]> wrote:
>Well, some of these issues have real, practical implications. Like where does your
>lap go when you stand up.
>
>My cat would really like to know. ;-)
Cats know a lot more than most people realize, they just pretend
indifference to fool people. :)
--
Best Wishes,
Johnny Bravo
"The most merciful thing in the world, I think, is the inability
of the human mind to correlate all it's contents." - HPL
------------------------------
From: Johnny Bravo <[EMAIL PROTECTED]>
Subject: Re: EOF in cipher???
Date: Fri, 18 Feb 2000 13:22:45 +0000
On Fri, 18 Feb 2000 10:28:00 -0500, "Trevor Jackson, III"
<[EMAIL PROTECTED]> wrote:
>The issue is the type of the variable C. To operate correctly it must
>be an int not a char.
Unsigned char works if your compiler can handle it, ANSI C.
--
Best Wishes,
Johnny Bravo
"The most merciful thing in the world, I think, is the inability
of the human mind to correlate all it's contents." - HPL
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Keys & Passwords.
Date: Fri, 18 Feb 2000 19:31:12 +0100
Serge Paccalin wrote:
>
> [EMAIL PROTECTED] wrote
> > Not seldom one is limited to the input of maximal 8 characters.
> > I prefer to use in that case 8 characters from the set {a-z, 0-9},
> > determined mechanically (in a rather inelegant way). But the problem
> > is that there is some probability that one forgets such sequences.
> > So I keep a secure copy for the eventual worst case. This is
> > certainly far from ideal. Does someone know a better solution?
>
> The only solution I know is to code a passphrase into a shorter
> string:
>
> - keep the 1st letter of every word
> - keep any punctuation
> - use digits if there are numbers...
>
> Here's an example:
>
> 2bon2b,t'stq...
>
> ("To be or not to be, that's the question...")
Does someone happen to know a simple but not bad hashing program
that converts a normal passphrase to {a-z, 0-9} or another set with
elements that are human-friendly for input (and memory)?
M. K. Shen
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: Basic Crypto Question 4
Date: Fri, 18 Feb 2000 12:28:55 -0600
[EMAIL PROTECTED] wrote:
>
> Has Elliptic Curve Crypto Come of Age?
I'll vote yes :-)
> Will it now play a significant role in Public key crypto, especially in
> the emerging wireless market with the advantage of shorter key length
> (160 ECC eq to 1024 RSA), and faster speeds.
If manufacturers use any smarts it will. Managers tend to be dumb tho,
see Dilbert.
> Is EEC mature enough as a technology to emerge and take a sizable chunck
> of the crypto market?
technology and market share have *nothing* in common. See Microsoft.
> Certicom is the main contender for ECC Crypto, now they have even
> released a PKI Toolkit based on ECC.
Yup. If you can afford it, it's probably pretty good.
> There are also some Free ECC Crypto Libraries. How do they compare with
> the Certicom ECC API?
Damn good question. What are you willing to pay to get an answer?
> For Wireless it seems the choice between ECC and RSA/DH is clear...ECC
> wins all the way.
>
> The NIST has even included a Digital Standard based on ECC....
Yeah, pretty cool huh?
Patience, persistence, truth,
Dr. mike
------------------------------
From: Johnny Bravo <[EMAIL PROTECTED]>
Subject: Re: EOF in cipher???
Date: Fri, 18 Feb 2000 13:33:43 +0000
On Fri, 18 Feb 2000 18:27:53 +0100, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
>I have read quite a lot in this thread but, because of non-unanimity
>of opinions expressed, am still not sure of what is to be done
>correctly.
The problem is the wide variety of systems and data handling for them,
your best bet would be to use an ANSI C compiler. It would make it easier
to get a working answer to your question. Even in ANSI C there is more
than one possible way. :)
The following example will open the first argument and copy it a byte at
a time to the second argument, aka the copy command (but without warnings
for overwrites and usage lines ect). copy file1.txt file2.txt
#include <stdio.h>
main(argc, argv)
int argc;
char *argv[];
{
unsigned char inbyte;
FILE *inputfile, *outputfile;
/*Open input file if possible*/
if ((inputfile = fopen(argv[2], "rb"))==NULL)
{
printf("Can't open input file.\n");
exit(1);
}
/*Open output file if possible*/
if ((outputfile = fopen(argv[3], "wb"))==NULL)
{
printf("Can't open output file.\n");
exit(1);
}
/*For each byte read, output that byte*/
while ((inbyte = getc(inputfile)) != EOF)
putc(inbyte, outputfile);
/* The following three lines are assumed in most implementations
but it never hurts to be complete */
fclose(inputfile);
fclose(outputfile);
exit(0);
}
--
Best Wishes,
Johnny Bravo
"The most merciful thing in the world, I think, is the inability
of the human mind to correlate all it's contents." - HPL
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: EOF in cipher???
Date: Fri, 18 Feb 2000 11:53:49 -0700
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
[ ... ]
> > > > while ((C = getc(fp)) != EOF)
[ ... ]
> > Unfortunately, the above code will run on many systems without
> > problems until fp is a binary file which happends to contain
> > the code 0xff, which is equal to (signed char)-1 (on machines
> > with 8 bits for a character).
>
> Only if the C library (presumably it came with the compiler)
> is implemented incorrectly.
Not so -- if "C" in the code above is defined as a char instead of an
int, there WILL be a problem. If, for example, char is signed by
default, C could contain -1 due either to reading 0xff from the file,
OR encountering EOF.
> (I suppose the whole thing would fail if "int" were 8 bits,
> but please - has there *ever* been such an implementation?)
There not only never has been such an implementation, but there never
CAN be either: the standard specifically requires that int have a
range from at least -32767 to +32767.
There is, however, still a legal implementation that could cause a
problem under C90: though int must be a minimum of 16 bits, there's no
guarantee or requirement that char be smaller than that. If both char
and int are 16 bits, you could theoretically run into a problem.
AFAIK, nobody's ever done such a thing -- in theory, it could make
some sense on a Unicode system, but I suspect a system large enough to
use Unicode as its char will also have int's of at least 32 bits.
Though I haven't checked to be sure, I believe this was fixed in C99.
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: Q: Division in GF(2^n)
Date: Fri, 18 Feb 2000 11:53:51 -0700
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
says...
[ ... ]
> I think that there should be certain 'principal' distinctions
> about what are patentable and what not.
At least in the US and the EU, there are exactly such distinctions.
> Laws, if I don't err, should weigh between interests of the
> individuals and the interests of the society as a whole.
Patent law is very careful to do so. Here in the US, the part of the
constitution that mandates a patent law is fairly specific in saying
that it's ultimately for the benefit of the consumer: in return for a
monopoly for a limited period of time, the inventor agrees to give the
invention to the rest of society after that period of time has
expired.
> In situations where something is to
> the disadvantages of the society, than interests of the individuals
> have to be sacrificed. I personally am against patenting algorithms
> in general.
I'm not. I think patents are very much like fences between people's
property. At one time here in the US, the "cowboys" were fond of
tearing down the fences put up by people trying to settle the land.
When you have a population density of a couple of people every 100
square miles or so, it was workable to simply say "I own all the cows
between this river and that ridge over there." In a modern age, the
population density is too high for this to be practicable.
Likewise, when the computer world consisted of "IBM and the seven
dwarves", it was easy to simply assume you could do whatever you
wanted. Computers were sold at such high profit margins that nobody
minded somebody else using their algorithm, because they all really
only made money on the hardware anyway. Today there are LOTS of
companies doing nothing but software. The competition is good for
consumers by reducing prices substantially. If the companies can't
protect their property, there's less chance of making money, less
competition, and the overall picture gets ugly in a hurry.
> Imagine the situation where there are a lots of patents
> on how to solve partial differential equations. The advance of
> technology would be greatly hampered, wouldn't it?
You're building a straw man here. Yes, if all the possible methods of
doing something really fundamental were patented, it could be a bad
thing. Patents have a number of limitations though. One of them is
that you can only patent a new, novel and original idea. If I found a
slight _faster_ way of solving partial differential equations, I could
patent it. Based on that I might be able to write software that was a
little faster than your's until my patent expired. After that,
anybody and everybody could use it and the consumers would benefit
from all programs doing this kind of work being faster.
> I believe naming
> the particular methods of solution after the persons who find them
> is an appropriate way of 'rewarding' these in this case.
You're insane. Right now, companies like IBM and Lucent spend
millions of dollars a year financing research organizations (e.g. the
T.J. Watson research center and Bell Labs respectively) to create new
inventions. If you honestly think they're going to spend this kind of
money with NO chance of financial reward for it, you're simply nuts
(to use a technical term). They invest the money because it pays off.
In the long run, it pays off for the consumer as well: just for
example, walk into a computer store and look at the price of a hard
drive. Compare that to the price of the same amount of storage
several years ago. Most of the inventions that made that difference
and save consumers HUGE amounts of money came out of research
organizations that are financed entirely out of profits from the
patents they generate -- largely the TJ Watson research center in the
case of hard drives.
> Further,
> imagine cases where a surgeon patents his techniques (say cutting
> into the heart from a certain point), where an architect patents
> buildings of round base, where a cook patents putting pepper into
> certain dishes, etc. etc. etc. It is evident that we shouldn't
> allow everything to be patentable, isn't it? The principle of
> rewarding shouldn't always apply. (Consider even the law prohibiting
> smuggling. Allowing smuggling would 'reward' the smugglers of
> their efforts in transporting the commodities, wouldn't it?)
You're ignoring all sorts of reality here. Patent law requires that
an invention be new. To get a patent on round-based buildings, the
architect has to show that this has never been done before.
Patent law also requires that the invention be novel: to get a patent,
the architect has to not only show that nobody ever HAS build a round-
based building before, but also that it would be unlikely to occur to
others that they COULD do so to handle the same problem(s) he was
trying to solve.
Finally, to get a utility patent, you have to show that the patent is
truly useful, and constitutes an advance over previously known art in
this general area. IOW, the architect would have to show that the
round base really accomplishes something, rather than just being
somewhat different.
I mention "utility patents" above because there's also a separate
class called "design patents". A design patent is more like a
trademark -- it covers the "look" of a product, and is meant mostly to
prevent others from using packaging that looks enough like your's to
fool consumers into thinking they're buying your product when they're
not. In the computer arena, this has been applied (for example) to
things like windowing systems -- for example, there's a design patent
on the exact borders used in DesqView, but you're not likely to be
deemed infringing unless your product is nearly indistinguishable from
DV, so the consumer might mistake your product for their's.
For the record: I'm not an attorney; don't take anything I say as
legal advice. If you have legal questions related to patents, you
really need to see a licensed patent attorney. If you don't know any,
I work with patents all the time, and will be happy to refer anybody
to one or two of whom I think relatively highly -- and no, I wouldn't
benefit from doing so beyond the peace of mind that I'd have helped
you steer clear of some others of whom I prefer not to think at all.
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: EOF in cipher???
Date: Fri, 18 Feb 2000 11:53:46 -0700
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
[ ... ]
> > Wrong. Bytes are written to binary files, characters to text files.
>
> Interesting. Tell me, just how do they do that on a machine that doesn't
> _have_ bytes?
The C standard apparently defines "byte" a bit differently than you
do. According to the standard, all machines having conforming
implementations of C MUST have bytes. Specifically, a "byte" is the
amount of storage needed to hold one char. With that given, it's
clear that Doug is making a subtle, yet valid, distinction.
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
** 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
******************************
