Cryptography-Digest Digest #710, Volume #11 Fri, 5 May 00 11:13:01 EDT
Contents:
Re: GPS encryption turned off (Guy Macon)
Re: GPS encryption turned off (Guy Macon)
Re: Tempest Attacks with EMF Radiation (Guy Macon)
Re: SBOX program using ideas from CA and ST (CAST design) (Tom St Denis)
ISO/IEC 11770-3 and ISO 9797 Where? (Tome')
AEES docs update ([EMAIL PROTECTED])
Re: GPS encryption turned off ("G.Kremer 1512-1594")
Re: GPS encryption turned off ([EMAIL PROTECTED])
test (Anonymous User)
Re: AEES Advanced ([EMAIL PROTECTED])
Re: U-571 movie (OT) (David Hamer)
Re: GPS encryption turned off ("Trevor L. Jackson, III")
Re: GPS encryption turned off (John Myre)
Re: RC6 (tm) as a Feistel Cipher ("Scott Fluhrer")
Re: AEES Advanced ([EMAIL PROTECTED])
Re: U-571 movie (back on topic) (William Rowden)
Re: RC6 (tm) as a Feistel Cipher (Tom St Denis)
Re: AEES Advanced ("ink")
Re: Any good attorneys? (Mok-Kong Shen)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: GPS encryption turned off
Date: 05 May 2000 06:12:40 EDT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Doug
Stell) wrote:
>
>Knowing the algorithm would be of no help, as any cryptographer would
>assume. Also, the algorithm will be highly protected by physical
>means, designed to prevent reverse engineering. Any attempt to access
>it would destroy it before you get to it. To keep the algorithm away
>from the GPS manufacturer, the operational code is squirted in by a
>single facilitty AFTER the GPS unit is built, physically secure and
>tested.
>
I worked on a project like that once. We recieved software labeled
"PRODUCTION SELF TEST V.X.XX" and had to make the units (not GPS,
another classified project) work with that. We weren't even real
clear on what the finished unit did; it looked like we made one part
of the hardware and someone else made the other part.
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: GPS encryption turned off
Date: 05 May 2000 06:20:42 EDT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Paul Koning)
wrote:
>
>Paul Schlyter wrote:
>>
>> That's only because a TV satellite doesn't cover the whole world. It
>> usually doesn't even cover all of the visible hemisphere of the world.
>
>Neither does GPS; in fact, GPS satellites are in lower orbits
>(a few thousand miles if memory serves) than TV satellites (which
>are in the Clarke orbit).
>
Clarke (AKA Geostationary) orbits miss the poles, but LEO (Low Earth
Orbit) military satellites typically cover the entire planet with
satellites that (oversimplified explaination alert!) orbit from
pole to pole as the earth turns underneath.
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Tempest Attacks with EMF Radiation
Date: 05 May 2000 06:31:29 EDT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(Mok-Kong Shen) wrote:
>
>
>
>Woody Brison wrote:
>
>> We had a guy at Ford Aerospace that brought in one of these
>> things, it looked like a little block with a rod sticking
>> up out of it. At the top of the rod was a ball of what
>> looked like steel wool, only of copper color. He said it
>> produced good ions and made everybody around it happy. He
>> sure was a positive upbeat guy. But when I first saw this
>> thing on his desk I had no idea what it was, I was fingering
>> the copper wool and wondering; then I walked over and took
>> ahold of the doorknob and about got knocked on my butt. So
>> now they're selling them as EMF blockers. Huh.
>
>The device you described seems to require very little energy. Can
>that be true?
He left out the part about the AC cord, but I have one and it has one.
It draws about 5W, and does a pretty good job of pulling dust out of
the air and coating everything within 2 feet of the unit with the dust.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: SBOX program using ideas from CA and ST (CAST design)
Date: Fri, 05 May 2000 11:04:35 GMT
ARRG I wrote this way to early in the morning...
Tom St Denis wrote:
>
> I am starting a new SBOX program using the properties from CAST where I
> make n, 2^n by 1, boolean functions and try them out.
>
> I currently test if each individual boolean function (2^n by 1) is
> non-linear [1] and follows SAC. Then I compose the log2(n) functions
> together and check if it's a bijection [2]. After that I do a Bit
> Independance Test. It's terribly slow (i.e optimizations galore) but
> does work.
I.e I need optimizations galore... I haven't done any yet.
> Excuse the poor math this is all knew to me (my other program was a just
> a random search method of sorts... ).
"this is all new to me".
Sorry about that, was way to early (around 1:30am I think)...
Anyways, about bounding the function don't I just something like 2^n *
p, where 'p' is the highest bound you are willing to accept. I.e if you
want to bound it to 1/2 +- 1/4 you set p to .25 and use 2^n * p as the
linear hi/lo bound?
Tom
------------------------------
From: [EMAIL PROTECTED] (Tome')
Subject: ISO/IEC 11770-3 and ISO 9797 Where?
Date: Fri, 05 May 2000 12:04:11 GMT
Where can i find something about this two standards ISO?
Someone can help me?
thanks
Tome'
------------------------------
From: [EMAIL PROTECTED]
Subject: AEES docs update
Date: Fri, 05 May 2000 12:42:58 GMT
AEES docs update including detailed description of
'AEES Advanced' is available to view online and for
download at
<www.alex-encryption.de>
Regards.
Alex.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Reply-To: "G.Kremer 1512-1594" <[EMAIL PROTECTED]>
From: "G.Kremer 1512-1594" <[EMAIL PROTECTED]>
Crossposted-To: sci.geo.satellite-nav
Subject: Re: GPS encryption turned off
Date: Fri, 05 May 2000 13:42:01 GMT
"Paul Rubin" <[EMAIL PROTECTED]> wrote in message
news:8ethgo$lp$[EMAIL PROTECTED]...
[sci.geo.satellite-nav added to newsgroups. Yes, we already know that
the P signal is still encrypted.]
Doug Stell <[EMAIL PROTECTED]> wrote:
>>>Over the air rekey: in case a GI leaves a military receiver in a bar].
>>Interesting. Are you saying they're going to rekey all the receivers
>>*except* the one left in the bar? How?!
>
>Yes, OTAR. The compromised receiver will simply revert to being an
>inaccurate one in a short time. OTAR is done all the time in military
crypto.
OTAR still seems worrisome. Say the attacker "borrows" a live receiver
(e.g. by bribing or seducing the GI in the bar) for long enough to
extract the algorithm and internal keys, and then gives the unit back
to the GI so it stays on the whitelist. (If necessary, the unit given
back to the GI is a new one that's been newly programmed with the old
unit's keys, since the old unit has been physically trashed by the key
extraction process). Now the attacker gets all the key updates which
s/he can propagate into other receivers. The entire security seems
to rest on the physical tamper resistance of the handheld receiver.
That seems like a serious vulnerability to me.
>Knowing the algorithm would be of no help, as any cryptographer would
>assume.
Once the algorithm is known, it's just a matter of getting keys from
a live unit.
>Also, the algorithm will be highly protected by physical means,
>designed to prevent reverse engineering. Any attempt to access it
>would destroy it before you get to it. To keep the algorithm away
>from the GPS manufacturer, the operational code is squirted in by a
>single facilitty AFTER the GPS unit is built, physically secure and
>tested.
I can't bring myself to believe the tamper resistant circuitry will
stay secure, especially over a long period of technology advances.
Remember the Clipper chip? It was also supposed to be secure, but
from what I heard, it was reverse engineered in relatively short order.
>Personally and without any substantiating information, I believe that
>this new approach is being put into place due to a compromise of the
>keys for the current system. For satelites, it was common to store a
>decade of Red keys in the bird, under the belief that they would be
>physically secure in a geo orbit. There was a newpaper article about
>another nation launching a satelite for a US party and having to blow
>up the rocket. When the bird was recovered, the GPS was missing.
>Blowing it up may have been a cover for stealing the GPS and its keys.
Yes, I remember that incident too (Chinese rocket), though I didn't
realize that it was a PPS-capable GPS receiver that had gotten nabbed.
I still wonder a thing like that was doing aboard a civilian
communications satellite. Also, *that's* a situation where OTAR makes
more sense, since there's 2-way communication with the satellite,
so it can authenticate itself to the ground station, etc.
I also wouldn't bet on nobody (i.e. space-capable foreign govt) being
able to snag a satellite out of geo orbit in the next decade.
>> Surely this has already been done (I mean by foreign
>>intelligence agencies, not sci.crypt nerds) for the existing algorithm.
>
>I am not sure if it has been fielded yet. By the way, the new scheme
>is called SAASM.
What does SAASM stand for? Thanks.
Btw, do you work on GPS? You've got some good info.
>From point2gps:
Have a look at the www.mercat.com WEB site and click on the sidebar feature
"WHAT is GPS???"
One of many sources....
regards,
--
=================================================================
Gerhard Kremer 1-800-NAV-4GPS
Email: [EMAIL PROTECTED]
WEB: www.point2gps.com
=================================================================
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: sci.geo.satellite-nav
Subject: Re: GPS encryption turned off
Date: Fri, 05 May 2000 13:49:32 GMT
In article <8ethgo$lp$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Paul Rubin) wrote:
>
> That seems like a serious vulnerability to me.
There is always a trade-off between operational vulnerability and
hardware vulernability. The operational vulnerability from propagating
physical keys currently outweighs the hardward vulnerability from
receiver exploitation. Hence, OTAR is less vulnerable than physical
re-keying...TODAY.
> I can't bring myself to believe the tamper resistant circuitry will
> stay secure, especially over a long period of technology advances.
You're right about the advance of technology. As the bad guys build
their multi-billion dollar material science forensic labs, the advantage
will swing back to the operational side. Of course, by then, the new
tamper resistant technology will be on its way out the door and the
cycle will begin anew.
> >Personally and without any substantiating information, I believe that
> >this new approach is being put into place due to a compromise of the
> >keys for the current system.
This is the natural evolution within the realm of counter and
countermeasure security. As you stated earlier, today's tamper
resistance will not be resistant to future technology advances. You
always have to be ahead of the enemy.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Anonymous User <[EMAIL PROTECTED]>
Subject: test
Date: 5 May 2000 16:15:41 +0200
test
===========================================================
Posted with AnonNews at http://anonymouse.home.pages.de/
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: AEES Advanced
Date: Fri, 05 May 2000 14:09:21 GMT
Hi Scott,
#If a block cipher does not act like a random permutation, then the
# attacker can deduce deep things about the internals by examining
# exactly how it deviates. Examining the last round is only one
# example, and I suspect it may have more advantage against your
#cipher than you expect.
I am sorry, but this statement has nothing to do with my algorithm.
Most of you here are so nervous and arrogant. A reason may be that
AES has something to do with money and revenue of attendees in nearest
future and has not much to do with cryptography and science.
#Are you seriously claiming that AEES has significantly better
# security than Twofish (or Serpent or Rijndael)?
Yes! I do.
Please take a look at comparison table below:
| Block | Key | S boxes | Round | Permutations |
S-box math
========================================================================
==============
Cerpent | 128 | 256 | 8 fixed | 32 | fixed
|transfr.tables
Twofish | 128 | 256 | 4 key-dependent | 16 | fixed
|transfr.tables
AEES | 256 | 2048 | 16 key-dependent | 16 |
key-dependent|finite groups
Rijndael| 128 | 256 | 1 fixed | 14 | no
|finite fields
Performance of AEES is not good in this comparison. But this is only
a question of time,hardware and development.
A propos Eli's and Adi's Differential Crytanalysis of DES-like
Cryptosystems
may be hardly applied to the architectur of my algorithm.
Please, take a look at updated AEES algorithm description
at www.alex-encryption.de.
Regards.
Alex.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Fri, 05 May 2000 10:16:08 -0400
From: David Hamer <[EMAIL PROTECTED]>
Subject: Re: U-571 movie (OT)
I will reiterate...this from an example of Luftwaffe daily settings.
In a month's worth of daily settings there are clearly several
counter examples to the 'never in the same place' rules for
Walzenlage [e.g. I IV II is followed by V IV I, and III I IV is
even followed by II I IV, etc.]. ^^^^^^^^
^^^^^^^
In general the Kriegsmarine was much more security conscious
when it came to Enigma use. One example - internal settings
were not left to the Enigma operator but were the province of the
Communications Officer [except for the less critical traffic]
- hence the locks fitted to naval Enigma variants. Also, naval
message key procedures were much more complex - see Ralph Erskine's
paper: "Naval Enigma: A Missing Link, Intl. J. of Intelligence
and Counterintelligence, Vol. 3(4).
Joaquim Southby wrote:
[snipped]
> "The air force never used the same rotor in the same position two days in
> a row, except perhaps from one keying period to the next."
>
> The Luftwaffe enforced this rule; the Kriegsmarine did not.
[snipped]
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
David Hamer The Crypto Simulation Group
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
------------------------------
Date: Fri, 05 May 2000 10:44:00 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: GPS encryption turned off
Stou Sandalski wrote:
> "Paul Schlyter" <[EMAIL PROTECTED]> wrote in message
> news:8esuno$fus$[EMAIL PROTECTED]...
> > In article <[EMAIL PROTECTED]>,
> > Paul Koning <[EMAIL PROTECTED]> wrote:
> >
> > >Neither does GPS; in fact, GPS satellites are in lower orbits
> > >(a few thousand miles if memory serves) than TV satellites (which
> > >are in the Clarke orbit).
> >
> > The GPS satellites orbit in 12-hour orbits, which will put them
> > approx. 20,000 km above the Earth's surface. The Clarke orbit is
> > 36,000 km above the Earth'ss surface.
> >
> > --
>
> I am again OTicking here but I was under the imression that the gps sats are
> in geosyncronous orbit, since if they are moving with relation to you, you
> will constantly need to calculate where the sats are in relation to earth's
> surface and where you are in relation to them?
No, the satellites are in much lower orbits. This is why constellation
management is so important for a good fix. It also means that the the
satellites have to regularly broadcast their ephemeris.
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: GPS encryption turned off
Date: Fri, 05 May 2000 08:36:40 -0600
Stou Sandalski wrote:
<snip>
> I am again OTicking here but I was under the imression that the gps sats are
> in geosyncronous orbit, since if they are moving with relation to you, you
> will constantly need to calculate where the sats are in relation to earth's
> surface and where you are in relation to them?
The GPS satellites are indeed in 12 hour orbits (nearly), and
so they are indeed moving in relation to you, and so you do
have to constantly calculate all the positions relatively. All
it really means is that time is a parameter in the formulas;
and don't forget that accurate time is an integral part of GPS.
John M.
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: RC6 (tm) as a Feistel Cipher
Date: Fri, 5 May 2000 07:34:13 -0700
Tom St Denis <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
>
> Scott Fluhrer wrote:
> > > Any thoughts?
> > An obvious problem I see is that the *only* diffusion between (A,D) and
> > (B,C) is the shifts. If I can find a pair (A,B,C,D) and (A',B,C,D')
that
> > has the property (truncated differential) such that: every time line 2
and
> > line 3 are executed, the t is the same between the two encryptions, then
I
> > known that, after encryption, the two encryptions will output the same B
and
> > C. By the birthday paradox, I should be able to find such a pair using
> > about 2**(5*R) chosen plaintexts, where R is the number of rounds.
Having
> > found such a pair, I should be able to deduce nontrivial information
about
> > the expanded keys used in the starting/ending round.
>
> This is assuming of course that the rotation doesn't change in any other
> step. I will agree that you can fix the rotations in the first round
> trivially. However as you enter into the second round getting fixed 't'
> values for any pair will be more difficult.
No: you don't start by finding a (A,B,C,D), (A',B,C,D') pair that has
identical 't' values, you pick random (A,B,C,D),(A',B,C,D') pairs, encrypt
them, and compare their outputs -- if the encrypted B,C components are the
same, then it is likely to have happened. You pick lots of pairs -- it is
likely to happen eventually...
A more traditional way of stating my observation is that there is a 1 round
truncated differential of the form (*,0,0,*)->(*,0,0,*) with probability
2**-10.
>
> Obviously there is some work todo because the F function only uses 5+32
> of the 64 bits supplied. One other idea is to compress the two
> registers downto 5 bits (i.e eight 8x5 sboxes) and also use the two in
> the other part... so you get
>
> t = F(C, D); A = ((A xor G(D, C)) <<< t) + S[4r+0];
> t = F(D, C); B = ((B xor G(C, D)) <<< t) + S[4r+1];
> ...
>
> Which would make it considerably slower but also modify the entire word
> based on the two inputs not just one.
But it does, of course, totally muck up my attack...
--
poncho
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: AEES Advanced
Date: Fri, 05 May 2000 14:37:46 GMT
Sorry for bad tables outlook in previous post
Hi Scott,
#If a block cipher does not act like a random permutation, then the
# attacker can deduce deep things about the internals by examining
# exactly how it deviates. Examining the last round is only one
# example, and I suspect it may have more advantage against your
#cipher than you expect.
I am sorry, but this statement has nothing to do with my algorithm.
Most of you here are so nervous and arrogant. A reason may be that
AES has something to do with money and revenue of attendees in nearest
future and has not much to do with cryptography and science.
#Are you seriously claiming that AEES has significantly better
# security than Twofish (or Serpent or Rijndael)?
Yes! I do.
Please take a look at comparison table below:
| Block | Key | S boxes
===============================================
Cerpent | 128 | 256 | 8 fixed
Twofish | 128 | 256 | 4 key-dependent
AEES | 256 | 2048 | 16 key-dependent
Rijndael| 128 | 256 | 1 fixed
| Rounds| Permutations |S box math
===============================================
Cerpent | 32 | fixed | transfr.tables
Twofish | 16 | fixed | transfr.tables
AEES | 16 | key-dependent| finite groups
Rijndael| 14 | no | finite fields
Performance of AEES is not good in this comparison. But this is only
a question of time,hardware and development.
A propos Eli's and Adi's Differential Crytanalysis of DES-like
Cryptosystems
may be hardly applied to the architectur of my algorithm.
Please, take a look at updated AEES algorithm description
at www.alex-encryption.de.
Regards.
Alex.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: William Rowden <[EMAIL PROTECTED]>
Subject: Re: U-571 movie (back on topic)
Date: Fri, 05 May 2000 14:41:00 GMT
In article <8etiee$jv6$[EMAIL PROTECTED]>,
Joaquim Southby <[EMAIL PROTECTED]> wrote:
> He's partly correct and thinking of the right thing. From David
> Kahn's "Seizing the Enigma":
>
> "The air force never used the same rotor in the same position two days
> in a row, except perhaps from one keying period to the next."
By what amount (percent) would this reduce the key space to be searched?
--
-William
SPAM filtered; damages claimed for UCE according to RCW19.86
PGP key: http://www.eskimo.com/~rowdenw/pgp/rowdenw.asc until 2000-08-01
Fingerprint: FB4B E2CD 25AF 95E5 ADBB DA28 379D 47DB 599E 0B1A
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: RC6 (tm) as a Feistel Cipher
Date: Fri, 05 May 2000 14:54:17 GMT
Scott Fluhrer wrote:
>
> Tom St Denis <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> >
> >
> > Scott Fluhrer wrote:
> > > > Any thoughts?
> > > An obvious problem I see is that the *only* diffusion between (A,D) and
> > > (B,C) is the shifts. If I can find a pair (A,B,C,D) and (A',B,C,D')
> that
> > > has the property (truncated differential) such that: every time line 2
> and
> > > line 3 are executed, the t is the same between the two encryptions, then
> I
> > > known that, after encryption, the two encryptions will output the same B
> and
> > > C. By the birthday paradox, I should be able to find such a pair using
> > > about 2**(5*R) chosen plaintexts, where R is the number of rounds.
> Having
> > > found such a pair, I should be able to deduce nontrivial information
> about
> > > the expanded keys used in the starting/ending round.
> >
> > This is assuming of course that the rotation doesn't change in any other
> > step. I will agree that you can fix the rotations in the first round
> > trivially. However as you enter into the second round getting fixed 't'
> > values for any pair will be more difficult.
> No: you don't start by finding a (A,B,C,D), (A',B,C,D') pair that has
> identical 't' values, you pick random (A,B,C,D),(A',B,C,D') pairs, encrypt
> them, and compare their outputs -- if the encrypted B,C components are the
> same, then it is likely to have happened. You pick lots of pairs -- it is
> likely to happen eventually...
>
> A more traditional way of stating my observation is that there is a 1 round
> truncated differential of the form (*,0,0,*)->(*,0,0,*) with probability
> 2**-10.
Now I get it ok...
> >
> > Obviously there is some work todo because the F function only uses 5+32
> > of the 64 bits supplied. One other idea is to compress the two
> > registers downto 5 bits (i.e eight 8x5 sboxes) and also use the two in
> > the other part... so you get
> >
> > t = F(C, D); A = ((A xor G(D, C)) <<< t) + S[4r+0];
> > t = F(D, C); B = ((B xor G(C, D)) <<< t) + S[4r+1];
> > ...
> >
> > Which would make it considerably slower but also modify the entire word
> > based on the two inputs not just one.
> But it does, of course, totally muck up my attack...
It also needs more ram, you need at least eight 8x5 sboxes and either
eight 8x8 sboxes or eight 8x32 sboxes for the other function. So it's
about 2kb + 2kb = 4kb, or 2kb + 8kb = 10kb. The former will fit in a
x86 cache and use less space, but take more code space (would have todo
some linear mixing before the substitution, i.e a 3-layer 2-PHT).
As a side bonus you would need less rounds to get ideal diffusion of key
bits and plaintext bits.
Tom
------------------------------
From: "ink" <[EMAIL PROTECTED]>
Subject: Re: AEES Advanced
Date: Fri, 5 May 2000 16:54:41 +0200
<[EMAIL PROTECTED]> wrote
> Hi Scott,
<cut>
>
> Performance of AEES is not good in this comparison. But this is only
> a question of time,hardware and development.
I'm not a cryptographer and although I've studied your documents
don't consider myself able to comment on the strength or weakness
of your cipher. Yet the performance issue you mention is something
I'd like to comment on. IMHO it is a bad thing to develop a
software that runs slowly in comparison to existing software,
essentially doing the same thing and to say that it will get
faster as soon as better hardware is available. Software should
offer the best possible performance on *any* platform. Simply
tying the software performance to the hardware performance is
what brought us monsters like MS Windows or SAP. A statement
like "If the program is too slow, use a faster computer" should
be banned.
Just my 2 cents.
Regards
Kurt
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Any good attorneys?
Date: Fri, 05 May 2000 17:03:28 +0200
Stou Sandalski wrote:
> I heard something that if a nation has a status of a favored-trade nation (I
> am not sure of the term)... they might be required as part of their
> agreement to honor us patents and copyright laws, I don't know if canada is
> like that however.
>
Indeed, there can be special treaaties between a pair of nations. One has
to be careful to check that. In the present case, however, the Canadian
patent office should be able to give competent informations about that.
You mentioned copy laws. That, as far as I know, is more of truly
internatonal nature, i.e. violation will be treated everywhere in the same
manner, while patents are acknowledged locally in the individual
countries. In Europe one can apply for an european patent with different
number of countries being covered, at different costs, of course.
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
******************************
