Cryptography-Digest Digest #644, Volume #12 Sun, 10 Sep 00 03:13:01 EDT
Contents:
Re: Carnivore -> Fluffy Bunny? ("Aztech")
Re: RC5-SAFE? - SAFEBOOT (Tom St Denis)
Re: PRNG ("Paul Pires")
Re: RC5-SAFE? - SAFEBOOT ("Paul Pires")
Re: Scottu19 Broken (/dev/null)
Re: Encryption on missing hard-drives (/dev/null)
Re: Encryption on missing hard-drives (/dev/null)
Re: Encryption on missing hard-drives (/dev/null)
Request for Blind Signature API ("Joyce")
Re: Security of whitening alone? ("Alexis Machado")
Ciphertext as language (wtshaw)
Re: Security of whitening alone? ("Scott Fluhrer")
Re: RSA Patent -- Were they entitled to it? (Terry Ritter)
Re: RSA Patent -- Were they entitled to it? (Roger Schlafly)
IDEA - PGP ("December")
----------------------------------------------------------------------------
From: "Aztech" <[EMAIL PROTECTED]>
Subject: Re: Carnivore -> Fluffy Bunny?
Date: Sun, 10 Sep 2000 02:38:22 GMT
They should take a leaf out the British Government's book, their system was
put in place by the R.I.P Bill, quite an apt name since that's exactly what
it's going to do for the Internet or Internet related companies in the UK
..... "Just put a leased line from your network to MI5 so we can monitor all
the traffic ... so it will cost you a few million, who cares?"
Az.
"Jim Gillogly" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Janet Reno doesn't like the name Carnivore for the FBI sniffer --
> sounds too ominous, and she wants a kinder, gentler name after the
> rubber-stamp review has been completed... something that will solve
> all the PR problems by making it appear less threatening. I suggest
> "Fluffy Bunny". Naseem Javed suggests "Big Sister".
>
> For details see:
>
http://www.nando.net/technology/story/0,1643,500248800-500370529-502216731-0
,00.html
>
> It's nice to see the government has a good grasp of the important
> issues with this technology. (That's sarcasm, for those who are
> color-blind in that area.)
> --
> Jim Gillogly
> 19 Halimath S.R. 2000, 02:01
> 12.19.7.9.13, 2 Ben 16 Mol, Fourth Lord of Night
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: RC5-SAFE? - SAFEBOOT
Date: Sun, 10 Sep 2000 02:51:15 GMT
In article <8peohu$2n8$[EMAIL PROTECTED]>,
"lala" <[EMAIL PROTECTED]> wrote:
> Sorry, I', a novice, so sorry if this question is stupid. I believe
this
> program is great for total disk encryption.
> Some information sent to me says,....
> "The encryption method is based on the RC5 algorithm published by RSA
> Laboratories. This algorithm uses a 1024 bit key and 12 rounds with a
32-bit
> word size in CBC mode. Using this method, SafeBoot is able to encrypt
data
> at the rate of ~6MB/sec."
> Is this totally insecure, or still not bad encryption? It's the 32bit
not
> the 1024 bit I should be looking at right? i.e. this is not 128bit
> encryption. Thanks for advice.
Your obviously a crypto-newbie. The 32-bit word size means RC5 is
implemented as a 64-bit block cipher. The 1024-bit key is a bit
disconcerning since RC5 is normally only used with keys from 64 to 256
bits. 1024 bits seems excessive.
Also with 12 rounds a differential or linear attack could in theory be
applied, I would use at least 16 rounds and hope not to have a weak key
(low chance really).
plus 6mb/sec is really slow. My RC5 code with 12 rounds gets 22.25
MB/sec on my K6-2. So thats about four times slower then it should be.
And when someone says "128-bit encryption" while kinda vague, would
refer to the keysize not the block size.
BTW if what you copied is accurate I would avoid the program at all
costs.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: PRNG
Date: Sat, 9 Sep 2000 20:12:53 -0700
Terry Ritter <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
> On Sat, 9 Sep 2000 11:55:59 -0700, in
> <HMvu5.30907$[EMAIL PROTECTED]>, in sci.crypt
> "Paul Pires" <[EMAIL PROTECTED]> wrote:
>
> >
> ><[EMAIL PROTECTED]> wrote in message news:8pd7dv$cke$[EMAIL PROTECTED]...
> >> In article <[EMAIL PROTECTED]>,
> >> [EMAIL PROTECTED] (S. T. L.) wrote:
> >> > /* DIEHARDC ok (no 0.00 no 1.00) */
> >> >
> >> > This is not the way to interpret DieHard results.
> >>
> >> Technically there is no valid way to interpret DH results...
> >
> >I know of only one valid interpretation. If you get a 1 or zero to 6 places
you
> >"Fail bigtime"
>
> Extreme values certainly are indications of problem. Both "not random
> enough" and "too random" are common generator failures, and a bad
> generator often is really bad. But to put that last nail in the
> coffin, bad statistical results need to be repeatable.
>
> But even a value of .5 is not "good" if it occurs more often than
> expected. If we get mostly .5's, even though they are clearly well
> away from the extremes, we still have a problem.
>
>
> >Even then, it's not decicive (you could have won
> >the lottery). I have been working on running large numbers of Diehard
> >passes and processing the bulk results per line and have found one thing
> >usefull. If you track the Min value, Max value & average for each
> >individual test sometimes a flaw not seen in a single test can pop out.
>
> I would call that a quick and dirty way to look at the p-value
> distribution. That distribution should be about flat and the mean
> should approach .5 the more the tests are run. (100x the trials
> should give about 10x the accuracy in the mean.)
That's what I figured. My problem is figuring out what to do with
the data to highlight the problems better. your later suggestion of
chi-squared will be tried. Repeating KS's on top of KS's doesn't
sound usefull.
>
>
> >Here is the max, min, avg. for the 31x31 & 32x32 Binary Rank Tests
> >on one generator I was looking at. There were 100 tests run with a
> >different seed for each. The generator "passed" each of the hundred tests
> >but look.
> >
> >31x31 p-value= 0.992866, 0.320975, 0.571386
> >32x32 p-value= 0.997435, 0.320885, 0.597587
> >
> >The Minimum value out of a hundred tests is too weird
> >(defies probability). Expected would be in the 0.00XXXX range.
>
> Good pickup!
Yeh, I get suspicious when things go too well.
>
> I think it is important to have at least one generator or data set for
> which each test performs properly with no indication of problem. And,
> ideally, there would be some data for which the test picks up a known
> problem. Until we have that, we should consider the possibility that
> the test itself may have problems.
Diehard is a nice tool and I thank George for the gift but it would be nice
if you could parameterize it according to the construction of the PRNG
under test. If your PRNG (Say, a block cipher) output 64 bits each cycle
and the blocks were made from 4 bit sub-elements, it would be nice to
have a magic program that honed in on the possible problem alignments.
Hey, I can dream can't I?
>
>
> >I got something usefull out of a "Passing score" with Diehard but
> >it is very slow and tedious. Another thing that might be telling is
> >binning out the number of hit's for each Pvalue.
>
> That is very reasonable for each particular test. That is testing the
> p-value distribution.
>
>
> >If a thousand passes were run, and you round off the results to
> >two decimal places and bin the results, you should see, on avearge,
> >a flat distribution of ten residents per bin. Doing a KS on this might be
> >usefull.
>
> With those kind of numbers, we expect 10 counts per bin in 100 bins,
> and at that level a chi-square test should be very useful.
Like I said, I'll give it a try.
>
>
> >The problem is that this is way to complicated for a casual test.
>
> Maybe I don't understand what "this" refers to. Just running the
> tests and accumulating results may take time, but I don't see much
> complicated about it.
Complicated is the wrong word. I am a big advocate of the use of
analysis to optimize design. waiting days for test data isn't much
good for "what if" playing and it tests my patience more than the PRNG.
Thanks for the suggestions.
Paul
>
> In general, one would start out with fast, simple tests, and then only
> if those look good, continue on to longer, more complicated tests.
> Unfortunately, there is no natural end to testing. But running vastly
> larger tests can be reasonable to see if subtle indications of
> problems found in smaller tests were just chance.
>
> When I was testing really-random noise circuits, my initial tests
> picked up very unexpected and strange correlation patterns in
> particular generators. Increasing the number of trials showed the
> same patterns, at which time they became fairly real.
>
> ---
> Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
> Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
>
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: RC5-SAFE? - SAFEBOOT
Date: Sat, 9 Sep 2000 20:28:41 -0700
Tom St Denis <[EMAIL PROTECTED]> wrote in message
news:8pesut$5sf$[EMAIL PROTECTED]...
> In article <8peohu$2n8$[EMAIL PROTECTED]>,
> "lala" <[EMAIL PROTECTED]> wrote:
> > Sorry, I', a novice, so sorry if this question is stupid. I believe
> this
> > program is great for total disk encryption.
> > Some information sent to me says,....
> > "The encryption method is based on the RC5 algorithm published by RSA
> > Laboratories. This algorithm uses a 1024 bit key and 12 rounds with a
> 32-bit
> > word size in CBC mode. Using this method, SafeBoot is able to encrypt
> data
> > at the rate of ~6MB/sec."
> > Is this totally insecure, or still not bad encryption? It's the 32bit
> not
> > the 1024 bit I should be looking at right? i.e. this is not 128bit
> > encryption. Thanks for advice.
>
> Your obviously a crypto-newbie. The 32-bit word size means RC5 is
> implemented as a 64-bit block cipher. The 1024-bit key is a bit
> disconcerning since RC5 is normally only used with keys from 64 to 256
> bits. 1024 bits seems excessive.
>
> Also with 12 rounds a differential or linear attack could in theory be
> applied, I would use at least 16 rounds and hope not to have a weak key
> (low chance really).
>
> plus 6mb/sec is really slow. My RC5 code with 12 rounds gets 22.25
> MB/sec on my K6-2. So thats about four times slower then it should be.
Sorry for the off track but...
It's Dennis Miller time.
Gosh, if everybody would state the platform and clock speed when
discussing stats it would be so nice. Clocks per byte isn't great but I think
it's the most relevent spec if it is derived from actual testing. Another wonder
spec is when someone posts C source and then claims performance for
what is obviously a higly optimized, pipelined nitro-burning assembler version.
"The Source is free and un-patented. Oh, you want the fast one? I'll have our
sales rep set up an appointment." By the way Tom. I'm not aiming this at you.
Your post just reminded me of it.
Paul
>
> And when someone says "128-bit encryption" while kinda vague, would
> refer to the keysize not the block size.
>
> BTW if what you copied is accurate I would avoid the program at all
> costs.
>
> Tom
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
From: /dev/null <[EMAIL PROTECTED]>
Subject: Re: Scottu19 Broken
Date: Sun, 10 Sep 2000 00:49:03 -0400
> [EMAIL PROTECTED] babbles:
> > But why would the NSA concern itself with Scott19u, as, although it
> > may well be secure, I doubt that anyone is taking it seriously enough
> > to use it - for reasons unrelated to its security as a cipher.
>
> Oh now I have to give reasons? Nah. NSA likes breaking all crypto
> espescially from fanatics.
>
What do you know of them? It is their job. If they do break something
it is very unlikely you or anyone else outside the agency will know.
-m-
------------------------------
From: /dev/null <[EMAIL PROTECTED]>
Subject: Re: Encryption on missing hard-drives
Date: Sun, 10 Sep 2000 00:58:08 -0400
Mike;
Don't let it rattle you. These folks are fine people. What you will
find here are the same sorts that you deal with every day.
Being a security guru is not nearly as glamorous or impressive as
being a rocket scientist. It isn't nearly as head swelling either.
Enjoy being a mule in a world of Unicorns...
One day they will want some help.
-m-
"Douglas A. Gwyn" wrote:
>
> Mike Andrews wrote:
> > Absolutely true. It's a page-turner. I'm surprised the military
> > didn't suppress it and turn it into a page-burner.
>
> That's not the business we're in.
------------------------------
From: /dev/null <[EMAIL PROTECTED]>
Subject: Re: Encryption on missing hard-drives
Date: Sun, 10 Sep 2000 01:06:12 -0400
Mike Andrews wrote:
>
> Scripsit Douglas A. Gwyn <[EMAIL PROTECTED]>:
> : Mike Andrews wrote:
> :> Absolutely true. It's a page-turner. I'm surprised the military
> :> didn't suppress it and turn it into a page-burner.
>
> : That's not the business we're in.
>
> There are other parts of .mil than the ARL.
Been there, lab rat for them.
> Some of them have
> classified people's PhD dissertations right out from under
> them;
One of your faculty friends fed you bull shit and you bought
it.
> one of my faculty friends told me about one of his PhD
> candidates that that happened to. He was head of her committee.
Sorry, this is crap.
>
> Her dissertation had to do with recognizing content in natural
> language texts. IIRC,it was Daddy DIRNSA who came in and took
> all her notes and drafts of her dissertation away.
Worked for him (DIRNSA)...
Bull shit and more bull shit. Do you not understand that NSA
has to obey laws just like the rest of us?
> She got to
> pick a new topic, and the Graduate College let her start her
> 5-year period over again, but it cost her something like 2
> years.
Do you actually believe that she would have been required by any
school to start again?
>
> I'd bet money she's not the only one, by a noticeable coefficient.
Bet your ass. Doesn't happen. Purely does not happen. First
NLP is basically a major disappointment in CompSci. We educate all
these PhD's every year in CompSci. They get hired into DoD contractor
positions where they fleece the .gov with promisses of NLP that
never quite pan out -- but DO cost a hell of a lot of money.
Been there worked in the labs...
>
> And then there were the sessions at a conference on optics, where
> the presenters had to announce that these presentations were not
> open to nationals from foreign countries - or that's what I can
> remember of the sytory, anyway. They were UNCLAS, but the
> announcements still were required.
Yep, that does happen. Go to LLNL or one of the other federally
funded labs and that will happen. It is federal money after all. Now
I realize that tax payers fronted the money and tax payers are allowed
to attend...
>
> I may be naive from time to time, but I'm not blind.
>
Not blind perhaps... what is left? This is sci.crypt, you should
be able to figure out the intent.
> --
> A doctor can bury his mistakes but an architect can only advise his
> clients to plant vines. -- Frank Lloyd Wright
------------------------------
From: /dev/null <[EMAIL PROTECTED]>
Subject: Re: Encryption on missing hard-drives
Date: Sun, 10 Sep 2000 01:07:51 -0400
Jeeze, this IS sci.crypt isnt it?
------------------------------
From: "Joyce" <[EMAIL PROTECTED]>
Subject: Request for Blind Signature API
Date: Sun, 10 Sep 2000 13:18:49 +0800
Dear all,
Would you tell me where Blind Signature API (in Java / C++) can be found or
how to write a Blind Signature function?
Thanks in advanced.
Regards,
Joyce
------------------------------
From: "Alexis Machado" <[EMAIL PROTECTED]>
Subject: Re: Security of whitening alone?
Date: Sun, 10 Sep 2000 02:56:55 -0300
"Scott Fluhrer" <[EMAIL PROTECTED]> wrote in message
news:8pcc6k$dpd$[EMAIL PROTECTED]...
>
> Andru Luvisi <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> >
> > Assuming one has a well known good random transformation, for example
> > DES encryption with a well known key, what attacks can you see against
> > the following algorithm?
> >
> > Let p(x) be the transformation. Let q(x) be the inverse transformation.
> > Let the 128 bit key k have a left part, l, and a right part r.
> > ^ means xor.
> >
> > E_k(x) = p(x^l)^r
> > D_k(y) = q(x^r)^l
> >
> > In other words, the key is *only* used for whitening before and after
> > applying the transformation.
> If b is the block size (eg. 64 for DES), and you are allowed 2**a chosen
> plaintexts, then you can break this with O(2**(b-a)) effort.
>
> Algorithm:
>
> - Choose the plaintexts 0, 1, ..., 2**a - 1, and obtain the corresponding
> ciphertexts E(0), E(1), ..., E(2**a-1)
> - For each ciphertext pair E(2*k), E(2*k+1) that you have, compute E(2*k)
^
> E(2*k+1) and store those in the list L
> - For j from 0 to 2**b stepping by 2**a, compute p(j) ^ p(j+1), and check
if
> it's in the list L.
> - If p(j) ^ p(j+1) = E(2*k) ^ E(2*k+1), then check if l (left part of the
> key) = j^(2*k) or j^(2*k+1). If so, you've rederived the key.
>
> You might be able to convert this into a known plaintext attack, but it's
> likely to become much less efficient, unless your known plaintext has some
> nice properties.
>
> --
> poncho
>
Hi, Scott
I'm not sure I understood the cipher proposition:
- X and Y are the 2 halfs of a 128-bit plaintext.
- E and D are the corresponding halfs of the ciphertext.
- R and L are the 2 halfs of a 128-bit key.
- The equations are
E = p(X ^ L) ^ R (1)
D = q(Y ^ R) ^ L (2)
In this case I have another way.
Inverting (1) we have
X = q(E ^ R) ^ L (3)
"XORing" left and right sides of (2) with (3) results
X ^ D = q(Y ^ R) ^ q(E ^ R) (4)
If we have any plaintext-ciphertext pair ((X,Y) and (E,D)), there is, *at
least*, an O(2**64) brute-force attack on equation (4) to find R.
Similarly, starting from (2) we find L in O(2**64).
The total complexity to find the key is O(2**64 + 2**64) = O(2**65). Since
the key have 128 bits ...
This reduction is very easy. This is why I think I failed to understand the
proposition.
---
Alexis
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Ciphertext as language
Date: Sat, 09 Sep 2000 23:38:33 -0600
It been said that there is a clear distinction between ciphertext and
language, yet codewords are a form of ciphertext. Actual known languages
can be adapted to encrypted communication. It seems an interesting notion
to create a language, even one that can be spoken, in a derived manner
that produces its own vocabulary, mathematically determined.
Having done more that a dozen algorithms with base 78 ciphertext, it
seemed attractive to take on 78 sounds in an artificial language. It was
simple to write a translation program to produce readable words. There
are nineteen characters used, thirteen consonants, BDFGHLMNPRSTV, and six
vowels, AEIOUX. I suggest that all six vowels sound like the name of the
letter except U, which should be 00 as in smooth. The resulting sound of
the words is fairly unambiguious, certainly not a romance language.
Taking the algorithm Providence, any group of four normal alphabetic
characters can be base-translated to three characters in base 78. In my
program, these are shaped letters, and can be converted to the new system
where each base 78 character is represented by a consonant and vowel pair.
Providence uses three keys, excluding transposition here, two are
permutated normal alphabets. While the defaults might be used, a
permutated alphabet or a pangram can be used to set the two substitution
keys.
Consider the pangram I wrote prior to attending the ACA convention in
Providence, RI, a couple of weeks ago (The algorithm was names the same
for another Providence):
broach five lumpy quahogs with a junked zax = broachfivelumpyqgswtjnkdzx
The resulting permutation sets the language Quahog as output. Input is
any four letters, output is six letters explained above. Separate groups
can be distinctive, words, or groups derive from the text string including
coded spaces and punctuation.
Here are some equivalents: come down here soon = lovadx debugo galide txsego
Names are likewise handled: john mary gary bill = terage potxsx tegiso sogori
If we used John Savards' favorite, Pack my box with five dozen liquer jugs,
packmyboxwithfvedznlqurjgs, call it Lush, these would be the result:
come down here soon = semena torate hivxna limuto
john mary gary bill = luhxte nelxdu valodu faritu
Here is this sentence in Lush as translated by the program.
here|is| this|sen tence|in |lush|as |transla ted|by|t he|progr amxpadding
(e)[z]<h>(s)[m] (z)(o)(o)[f](g) (u)(y)(o)<i>(c) (i)(s)<y>(s)<r>
[f](d)(y)<f>(g)
(x)(e)<e>[j][e] (o)<h><z><p>[y] [t](e)[v](m)[r] (z)[s](n)<t>[m] (n)(h)<j>
hivxna lovuvo dodolu minoto dopafi pilote lohelu gitola misohi haruhu
donave fetxmx hipxvi hxvolx bomevu bonira
Everything works backwards as well to recover the original text. This
represents an simplified version of what could be.
--
A Pangram(corrected, needed a G):
Vexed xenophobes fear crypto's jazzy, quaint workings.
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: Security of whitening alone?
Date: Sat, 9 Sep 2000 23:02:45 -0700
Alexis Machado <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
> "Scott Fluhrer" <[EMAIL PROTECTED]> wrote in message
> news:8pcc6k$dpd$[EMAIL PROTECTED]...
> >
> > Andru Luvisi <[EMAIL PROTECTED]> wrote in message
> > news:[EMAIL PROTECTED]...
> > >
> > > Assuming one has a well known good random transformation, for example
> > > DES encryption with a well known key, what attacks can you see against
> > > the following algorithm?
> > >
> > > Let p(x) be the transformation. Let q(x) be the inverse
transformation.
> > > Let the 128 bit key k have a left part, l, and a right part r.
> > > ^ means xor.
> > >
> > > E_k(x) = p(x^l)^r
> > > D_k(y) = q(x^r)^l
> > >
> > > In other words, the key is *only* used for whitening before and after
> > > applying the transformation.
> > If b is the block size (eg. 64 for DES), and you are allowed 2**a chosen
> > plaintexts, then you can break this with O(2**(b-a)) effort.
> >
> > Algorithm:
> >
> > - Choose the plaintexts 0, 1, ..., 2**a - 1, and obtain the
corresponding
> > ciphertexts E(0), E(1), ..., E(2**a-1)
> > - For each ciphertext pair E(2*k), E(2*k+1) that you have, compute
E(2*k)
> ^
> > E(2*k+1) and store those in the list L
> > - For j from 0 to 2**b stepping by 2**a, compute p(j) ^ p(j+1), and
check
> if
> > it's in the list L.
> > - If p(j) ^ p(j+1) = E(2*k) ^ E(2*k+1), then check if l (left part of
the
> > key) = j^(2*k) or j^(2*k+1). If so, you've rederived the key.
> >
> > You might be able to convert this into a known plaintext attack, but
it's
> > likely to become much less efficient, unless your known plaintext has
some
> > nice properties.
> >
> > --
> > poncho
> >
>
> Hi, Scott
>
> I'm not sure I understood the cipher proposition:
>
> - X and Y are the 2 halfs of a 128-bit plaintext.
> - E and D are the corresponding halfs of the ciphertext.
> - R and L are the 2 halfs of a 128-bit key.
> - The equations are
>
> E = p(X ^ L) ^ R (1)
> D = q(Y ^ R) ^ L (2)
I believe that that is a different construction. The difference is really
in the definitions of the various variables. Here are the definitions used
in the OP's construction:
X (and D) is the 64 bit plaintext
E (and Y) is the 64 bit ciphertext
R and L are the 2 halfs of a 128-bit key
And, equation (1) shows us how to encrypt, and (2) shows us how to decrypt.
>The total complexity to find the key is O(2**64 + 2**64) = O(2**65). Since
>the key have 128 bits ...
Oh, and OP's construction had (at best) 64 bit security (using a reduction
very similar to yours, on two known plaintexts/ciphertexts), even though it
also used a 128 bit key.
--
poncho
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: RSA Patent -- Were they entitled to it?
Date: Sun, 10 Sep 2000 06:26:56 GMT
On 10 Sep 2000 01:09:31 GMT, in <8pen0b$qd6$[EMAIL PROTECTED]>,
in sci.crypt [EMAIL PROTECTED] (Bill Unruh) wrote:
>In <[EMAIL PROTECTED]> [EMAIL PROTECTED] (Larry
>Kilgallen) writes:
>
>]And that is why MIT was entitled to the RSA patent and entitled to
>]appoint the RSA company to license it.
>
>]The patent system guarantees a period of exclusivity to an inventor
>]_in_return_for_disclosing_the_particulars_of_the_invention. GCHQ
>]did not disclose anything in a timely fashion.
>
>It at least used to be in the USA that it was the first to invent, not
>the first to apply, who was entitled to the patent.
As far as I know, that is still as generally true as it always was,
but a first inventor can lose the patent by not "proceeding toward
patent," since that is an apparent choice for trade secrecy.
Inventors do not get to manipulate the system by using trade secrecy
for as long as possible, then applying for patent.
>A later attempt
>would be overturned.
If the first inventor published the invention, that publication would
constitute "prior art" which would "overturn" a later application.
But "prior art" is a term-of-art in patent law, and generally refers
to open *publication* (or sale). Something which is done but kept
secret is generally *not* "prior art."
So if the first inventor did *not* publish, they probably did not
establish "prior art," so there would be nothing to prevent an
application from another inventor to issue on that invention.
How could it work any other way? If the first inventor does not apply
for patent, how could the PTO know anything at all about the
invention? So how could they know to refuse an application from
someone else?
>If the first person did not file on time, the
>patent would become public and unpatentable.
Until the invention is published it does not become "public." So if
the first inventor does not file, there is no public exposure, and no
use by society. When a first inventor chooses trade secrecy over
patent protection, a later inventor can and often does obtain a patent
on that same invention and apply it against the first inventor. The
second inventor does have to actually invent the thing independently,
of course.
>I do not know when the US
>abandoned the first to invent, but I thought it was well after 1983.
As far as I know, US patent law has been essentially unchanged in this
respect for half a century. It is still "first to invent," but not
unconditionally so, and that's the way it's always been.
The first inventor is entitled to a patent as long as they continue to
move toward a patent. But if the first inventor were to go off and do
other things while the next inventor finished up and applied for
patent first, the first inventor might well lose the right to the
patent.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: Roger Schlafly <[EMAIL PROTECTED]>
Subject: Re: RSA Patent -- Were they entitled to it?
Date: Sat, 09 Sep 2000 23:33:19 -0700
Jim Gillogly wrote:
> [GCHQ] didn't really understand what they had, and shelved it because they
> couldn't see useful applications. Ellis told Diffie in the 80s (I
> think it was) that DH, M and RSA had done more with it than GCHQ had.
I am skeptical about this. The declassified papers by Ellis, Cocks
and others seemed to show that they understood what they were doing.
Even if they didn't, these papers were circulated to many experts
in GCHQ and NSA, and surely many of them understood them.
Ellis was probably referring to what he personally did with the
ideas he had. Other secret papers on the subject are still secret,
and we don't know who did more with it, whatever that means.
DH-M-RSA certainly did more in terms of publicity and public impact,
and maybe Ellis was referring to that.
Aztech wrote:
> Also, you have to ask if RSA were actually entitled to this patent because
> they weren't the first to discover public key crypto!
Jim Gillogly wrote:
> Yes, certainly RSA were entitled to the credit, ...
No. RSA are not entitled to the credit for discovering public
key crypto, no matter how you figure it. It had already been
discovered by Merkle, and independently by Hellman and Diffie.
The RSA inventors were introduced to the subject by reading
the published Diffie-Hellman paper.
------------------------------
From: "December" <[EMAIL PROTECTED]>
Subject: IDEA - PGP
Date: Sun, 10 Sep 0 07:39:48
Reply-To: "December" <[EMAIL PROTECTED]>
Hi:)
First of all, let me apologise for bringing such a simple question or
three here. I have trawled through a heap of newsgroups and webpages
trying to find info, which has proved futile.
Right, my computer setup is a Commodore Amiga 1200. It is likely I am
going offline soon and wish to send a friend in the US disks now and
again, which will contain personal texts. I want this to be encrypted and
currently the best looking method is IDEA - found in PGP.
(I assume it exists in all versions of PGP, across all platforms.)
This method doesn't require exchange of keys, only a passphrase.
Stop me at any time if I'm wrong.
So, I can read and write to PC disks fine on this platform but I'm having
problems trying to find a decrypter. On the Amiga PGP 2.6.3 is a pathetic
little 400,000 byte archive in complete form. The Windows98 version is
7mb and she's not too happy to download and attempt install of this, to
allow decryption of any future files.
Is there a stand-alone PC IDEA decrypter, and could you point me to..?
I also have Amiga RC4 and RC6 encryption tools if they are easier to deal
with. The ZIP password thang was originally considered, but is weak as
hell, apparently:)
As you can see, I'm not up on the subject that is cryptography, so please
be gentle with your replies:P
I'll post again if I forget anything...
------------------------------
** 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
******************************
