Cryptography-Digest Digest #971, Volume #9        Mon, 2 Aug 99 15:13:06 EDT

Contents:
  Re: With all the talk about random... (John McDonald, Jr.)
  Re: CFB mode with same initialization vector (Peter Pearson)
  Re: Is breaking RSA NP-Complete ? ([EMAIL PROTECTED])
  Re: SSL vs TLS (Gabriel Belingueres)
  Re: With all the talk about random... (Jim Felling)
  Re: bits and bytes ("karl malbrain")
  Re: Help please (WWI/WWII ciphers) (Jim Felling)
  Re: The security of TEA ([EMAIL PROTECTED])
  Re: SSL vs TLS (Bjoern Sewing)
  Re: another news article on Kryptos (wtshaw)
  Re: Americans abroad/Encryption rules? (W.G. Unruh)
  Re: Americans abroad/Encryption rules? (W.G. Unruh)
  Re: How to write REALLY PORTABLE code dealing with bits (Was: How Big  (dave)
  Re: Pencil-and-paper compression algorithms [Re: Between Silk and Cyanide] (Xcott 
Craver)
  Re: Americans abroad/Encryption rules? (W.G. Unruh)
  Re: Americans abroad/Encryption rules? (W.G. Unruh)
  Re: Americans abroad/Encryption rules? (W.G. Unruh)
  Re: Americans abroad/Encryption rules? (W.G. Unruh)
  Re: Americans abroad/Encryption rules? (JPeschel)
  Re: Americans abroad/Encryption rules? (SCOTT19U.ZIP_GUY)

----------------------------------------------------------------------------

From: [EMAIL PROTECTED] (John McDonald, Jr.)
Subject: Re: With all the talk about random...
Date: Mon, 02 Aug 1999 14:57:30 GMT

On Fri, 30 Jul 1999 19:15:19 -0500, Frank Kienast
<[EMAIL PROTECTED]> wrote:

>I guess I could now go and decrypt all those old files and re-encrypt
>them with PGP or something, but given that information such as what I
>thought about my boss ten years ago is probably nothing earth-shaking if
>someone found it now, I will probably not bother.

        This statement illustrates something else that is often
neglected in cryptography:  the "who cares" factor.  After all, if my
encryption will store my information for thousands or millions of man
years, then lets suppose that using a method such as distributed.net
would crack it in 10.

Most of the time, in 10 years, I could care less how "secret" that
information was.... So at what point is encryption "good enough?"  

I propose that when current encryption would take current technology
enough time that the "who cares" factor emerges, then encryption is
strong enough. (This of course means that as our technology speeds up,
we need to find better, stronger algorythms...)

Peace.

[-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-]
 John K. McDonald, Jr.      Alcatel, USA

 [EMAIL PROTECTED]
 please remove -delete- for responses.
 --
 "I speak for me and not this company"

 TO SPAMMERS:
 Please  view   the  definitions   for 
 "telephone     facsimile    machine," 
 "unsolicted  advertisement,"  and the
 prohibition  and penalty  for sending
 unsolicited faxes before sending  Un-
 solicited  Commercial   E-mail to the 
 above   address.   Violators  WILL BE 
 PROSECUTED.   These   can   be  found
 in:
 
 The Telephone Consumer Protection Act
 of  1991,    Title   47,   Chapter 5,
 Subchapter II, Section 227.
[=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=]

------------------------------

From: Peter Pearson <[EMAIL PROTECTED]>
Subject: Re: CFB mode with same initialization vector
Date: Mon, 02 Aug 1999 09:43:24 -0700

Daniel Vogelheim wrote:
> 
> why is encryption in CFB mode insecure, if you use the same
> initialization vector multiple times?

The danger is that you might encrypt plaintexts whose
beginnings are identical, thereby producing ciphertexts
whose beginnings are identical. It is not respectable
for an encryption system to reveal the fact that messages
X and Y have the same beginning, even if the system doesn't
reveal what that beginning is.

If some convention in your plaintext guarantees that
the first block of plaintext will be different every
time, the system is as strong as the underlying block
cipher, even with fixed IV. (Corrections, you other guys?)

- Peter

------------------------------

From: [EMAIL PROTECTED]
Subject: Re: Is breaking RSA NP-Complete ?
Date: Mon, 02 Aug 1999 16:41:17 GMT

I wrote:
> NP-hard is a set of functions, not languages or
> decision problems.  A function is NP-hard if and only
> if it is polynomially reducible to and from deciding
> some NP-complete language.

Well, two minutes after posting I've already found
a reference that says I'm wrong.  It says NP-hard
is the superset of NP-complete consisting of languages
to which NP-complete problems can be polynomially
reduced.  Sorry for the mis-information.

--Bryan


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

------------------------------

From: Gabriel Belingueres <[EMAIL PROTECTED]>
Subject: Re: SSL vs TLS
Date: Mon, 02 Aug 1999 15:48:52 GMT

Hi,

TLS is a little different from SSL. The biggest change I see is in the
MAC computation, it uses new a stronger version of HMAC (RFC 2104).

Also, the Fortezza ciphersuite is not allowed in TLS (who cares!).

The block ciphers now are allowed to have a 255 bytes padding, rather
than the unjustified 63 bytes of SSL.

If you want a complete list, you can find it in the Consensus
Development web site. There are an Internet draft
talking about that:

http://www.consensus.com/ietf-tls/ietf-tls-home.html

The file is <draft-ietf-tls-ssl-mods-00.txt>

I hope it will be usefull to you.

In article <[EMAIL PROTECTED]>,
  Bjoern Sewing <[EMAIL PROTECTED]> wrote:
> Hi
>
> can anyone tell me the differences between
> SSLv3 and TLSv1 ??
>
> Thanks a lot
>
> Bjoern
> --
> ---------------------------------------------------------------
> Bjoern Sewing - University of Bielefeld        (TF-NOV - N3.02)
>
> email:        [EMAIL PROTECTED]
> ---------------------------------------------------------------
>


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

------------------------------

From: Jim Felling <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: With all the talk about random...
Date: Mon, 02 Aug 1999 12:04:52 -0500



[EMAIL PROTECTED] wrote:

> In article <[EMAIL PROTECTED]>,
>   Dave Knapp <[EMAIL PROTECTED]> wrote:
> > > Nothing is truly random though.  Why do you think we have laws of
> > > physics and developing laws of quantum mechanics?  Just cuz you
> can't
> > > explain something doesn't mean it's random.
> >
> > It's either truly random or it's nonlocal.  Me, I prefer truly random,
> > as do most other physicists.
>
> So you are saying that some things are not bounded by a set of rules?
> I can't believe that.

Even things bound by a set of rules, can still exhibit random behavior.
Just because a system is constrained, does not mean that within that
constraint it is random.(bad example: a six sided die will generate numbers
1-6, just because it will never roll a 10 or a 14, does not reduce its
randomness within the range it generates)



>
>
> > > If you could look at a piece of amercium and see alpha particles
> leave
> > > you could predict what your counter will produce, but since that's
> > > believed to be difficult we assume it's 'random'.  Simple as that.
> >
> > No, the randomness is _when_ the Am decays, not what happens to the
> > alpha particle once it is emitted.
>
> Pardon my ignorance.  An alpha particle is the 'waste' of an atom
> right?  So in this case if you could view the electrons and such in the
> atom then you should be able to predict what it will do.
>
> Just because something is difficult doesn't mean it's random.  Of
> course viewing things with wave lengths shorter then light itself my
> prove difficult but there are other methods I am sure.

It is IMPOSSIBLE to do.  Quantum phenomena are FUNDAMENTALLY unpredicatble,
and indeterminate.  There are physical quantities such that the
error_in_measurment_Q1* error_in_measurment_Q2  >= fixed constant.

This results in those phenomena being FUNDAMENTALLY indeterminate.

> In your argument things like how much rain will fall in a year (down to
> the mm) would be 'random' but I still say if you could inspect every
> cloud, measure every gust of wind, you could dictate the mm of rain.
>
> From a cryptographic standpoint, if I use a piece of Am and count the
> alpha particles (Mike Rosing has a good paper on this) it would be
> unpredictable for someone not in possesion of the piece of Am.  This
> would in a sense be 'random' since the other guy can't inspect it.  But
> I still don't think it's truly random.

Even if I have the piece of Am before you do, after you do, and at any
arbitrary time in-between when you are not using it to generate numbers  and
watch your lab carefully, and an privy to an arbitrarily large percentage of
your data(say X%) I still cannot( assuming you have your equipment setup
properly), deduce any information about the remaining (100-X)% .  This is
fundamental, and due to the nature of reality.

> Tom
> --
> PGP key is at:
> 'http://mypage.goplay.com/tomstdenis/key.pgp'.
> Free PRNG C++ lib:
> 'http://mypage.goplay.com/tomstdenis/prng.html'.
>
> Sent via Deja.com http://www.deja.com/
> Share what you know. Learn what you don't.


------------------------------

Reply-To: "karl malbrain" <[EMAIL PROTECTED]>
From: "karl malbrain" <[EMAIL PROTECTED]>
Subject: Re: bits and bytes
Date: Mon, 2 Aug 1999 10:00:54 -0700


<[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
> I may be a little out of line here, but what does this have to do with
> cryptography?  Shouldn't this be taken to a different news group?

For better or worse, cryptography has been divided into STREAMS or BLOCKS.
Unfortunately, bits and bytes fall out from that division.

BTW, the IBM 7090 was a two's complement machine.  The distinction on the
ranges of signed numbers in C is designed to cover for ONES COMPLEMENT
arithmetic, like the Control Data 6600, etc, where a minus zero is defined,
but was never generated by the <<complement and subtract>> adder.  Karl M



------------------------------

From: Jim Felling <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Help please (WWI/WWII ciphers)
Date: Mon, 02 Aug 1999 12:31:41 -0500

Geographic location perhaps? Those look like possible lat/long coordinates
degrees + decimal seconds?

Mike Blais wrote:

> If anyone can help me with this it would truly be appreciated, by me and my
> girlfriend have spent far too much time on this and are ready to give
> up(this isn't really our type of stuff).
>
> We have a package (newsletter) that has a code hidden in it, and our only
> hint was that it was a code stolen from the Germans in the war(don't know
> which war).  Unless the code is actually hidden in the text this is what we
> believe is the code:          223,172,926  paragraph 2 section (b) and a
> page later
>                    89,254,167 section (b) paragraph (iii)
> We don't know if the section/paragraph  numbers mean anything but I figured
> they should be included.
> So what I have is this  223 172 926 89 254 167 and the answer key is like
> this
>                         ---- ------- ---------- --- ----
> As far as I found on the web  the only number for letter cipher was the
> Zimmerman Telegraph, but the key I found was in German. Also there are more
> answer spaces than numbers and the only numbers in the rest of the package
> are telephone numbers(all real)
> Any tips from whether we're on the right track to a solution would be great.
>
> Mike Blais
>
> Kirsten Johnston
>
> [EMAIL PROTECTED]
>
> Port Coquitlam BC


------------------------------

From: [EMAIL PROTECTED]
Subject: Re: The security of TEA
Date: Mon, 02 Aug 1999 12:27:43 -0400



[EMAIL PROTECTED] wrote:

> Here is some critical thinking.  ALGORITHMS ARE NOT THE ONLY THING THAT
> MAKE SECURE APPLICATIONS.
>

No shit....
The point I was trying to make in my original post is that I am not using
TEA in my applications.  I was curious as to the security of the algorithm
because it is so simple and easy to understand.  If I need something secure
I"ll use something different.

> Now that I said that.  I would say TEA is a bad algorithm to use.  X-
> TEA might be better but I would stick with algorithms which have taken
> more of a beating.
>
> BTW the reason I said the above is because everyone talks about how
> strong algorithm X is but never on how to use the algorithm.  People
> should ask 'is this application of algorithm X' secure ...

Here let my post some encrypted binary data to see if you can crack it.  =)


------------------------------

Date: Mon, 02 Aug 1999 19:28:37 +0200
From: Bjoern Sewing <[EMAIL PROTECTED]>
Subject: Re: SSL vs TLS

Hi Gabriel 
> 
> TLS is a little different from SSL. The biggest change I see is in the
> MAC computation, it uses new a stronger version of HMAC (RFC 2104).
> 
> http://www.consensus.com/ietf-tls/ietf-tls-home.html
> 
> The file is <draft-ietf-tls-ssl-mods-00.txt>

The draft only describes , what changes should be done,
but not the changes have been done.

Even so thanks 

Bjoern

-- 
===============================================================
Bjoern Sewing - University of Bielefeld        (TF-NOV - N3.02)

email:  [EMAIL PROTECTED]               
===============================================================

------------------------------

From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: another news article on Kryptos
Date: Wed, 28 Jul 1999 01:17:13 -0600

In article <[EMAIL PROTECTED]>, "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:

> wtshaw wrote:
> >> Best to not put blinders on prematurely.  If I got it right, *a whole new
> > ball game* could be sort of a cryptic clue.
> 
> Not likely; that's a standard American idiom.

Some people use double meanings.
-- 
Freedom means having the right to chose to be isolated and left 
alone. It also means not having the right to force someone to get 
involved.  But, the continuation of freedom demands that some of 
us act for those that can't or won't.

------------------------------

From: [EMAIL PROTECTED] (W.G. Unruh)
Subject: Re: Americans abroad/Encryption rules?
Date: 2 Aug 99 17:01:26 GMT

[EMAIL PROTECTED] (Lincoln Yeoh) writes:

>How about a foreigner with PGP visiting USA and then trying to erm leave?

Nope.

>Or what if I had no intention of entering the USA but the plane had to stay
>longer than expected on US soil? Can I get off the plane with my notebook
>PC?

That makes no difference. Your intentions are irrelevant-- it is your actions
(ie your landing in the US). 
Erase all crypto on your laptop before you leave the USA. (of course you might 
want to weight the probablility that anyone will actually find the crypto 
on your disk and knowing what it is, arrest you).


>My uncle had a bad experience with the US immigration officials - his plane
>somehow had to stay on US soil longer and they made the passengers leave
>the plane. The immigration authorities kept pestering him about why he
>didn't have a visa. My uncle was very annoyed and angry.

Yes, they do that. I had a friend who lived in Canada since he was 1 but did 
not have a Cdn passport. His plane went through the USA and when he was found
woithout a US visa they arrested him and detained him so that he was unable 
to catch his plane to Canada. Then they told him that they would deport him.
(which was of course what he wanted to do all along.) 


------------------------------

From: [EMAIL PROTECTED] (W.G. Unruh)
Subject: Re: Americans abroad/Encryption rules?
Date: 2 Aug 99 17:06:41 GMT

[EMAIL PROTECTED] (JPeschel) writes:

>>(W.G. Unruh) writes:

>>You are just not allowed to take out of the USA any program which could
>>create such an encrypted email 

>Bill, that's strange. When was the "personal use exemption" taken off the
>books?

I have not noticed it in the EAR. It was originally passed as an ammendmanet to
ITAR but I am not sure that it survived the transfer to Commerce dept. 
I guess one should check tht. However that exemption is pretty useless. You
must keep the program with you at all times, are not allowed to even have it 
placed in luggage, or left in your hotel room, and must keep a diary of exactly 
where you went and where the laptop went and then must keep that diary for 
5 years in case someone want to see it. Far easier to erase it and reload it 
when you get to that foreign country.

------------------------------

From: dave <[EMAIL PROTECTED]>
Crossposted-To: 
alt.folklore.computers,alt.comp.lang.learn.c-c++,comp.lang.c++,microsoft.public.vc.language
Subject: Re: How to write REALLY PORTABLE code dealing with bits (Was: How Big 
Date: Sun, 01 Aug 1999 18:49:20 GMT

Well, I have to add my mouthful to this thread.   Being too young, dumb
and poor to play with the big boys back then, I have no idea when "Byte"
evolved, nor what it originally meant.  I have a recollection of working
with an IBM in the late sixties, and I think the manual referred to
eight bit bites, and the Fortran (II or III) used coded in octal or hex.

More critical to the debate is when did the term "byte" move from
esoteric usage by specialists to common usage, and here, too, I'll have
to rely on memory.  The 4004 microprocessor worked with 4 bit wide data,
and this was a bite for this chip, and I'm pretty sure it was bite, not
byte. ("Don't take a bit, take a whole bite"...just the sort of thing
that E.Eng's chuckle over)  When the 8008 arrived with 8 wide data, the
term "Bite" promoted itself to the wider data field.   I recall that the
8008 worked with two  4-bit registers, so we were treated to upper and
lower "nibbles" making up one bite, or byte.
I'll nominate this as the point in time where Byte became a real word in
the real world.   One major magazine at the time was "BYTE", and another
was Dr DOBBS.  Who remembers that Dobbs really was a Doctor -
orthodontist (?), and wasn't the banner on the early issues something
like "Running fast with no overbite"?
Just my two bits worth......regards,  Dave



------------------------------

From: [EMAIL PROTECTED] (Xcott Craver)
Subject: Re: Pencil-and-paper compression algorithms [Re: Between Silk and Cyanide]
Date: 1 Aug 1999 22:08:00 GMT

>In 1983 another member, Larry Loen, proposed the "Compressocrat", which
>does what you're suggesting: he started with a ternary encryption of
>the alphabet, with ETAON getting two trits each, IRSHD getting three,
>PFCUMWY getting four, BGVKQ getting five, and XJZ getting six, using a
>fixed alphabet.  They were then re-encrypted into 26 letters with a
>keyed alphabet.  This worked well for compressing English and squeezing
>out redundancy, and was tried for a few times before getting dropped
>through lack of problem submissions from the members.  

        Cool.  If it's prefix-free (and complete) then you could 
        convert to trinary, perform some encryption on the trits, then
        convert the result back using the original compression table,
        adding dummy bits on the end if necessary to get a whole # of
        symbols.  Now your ciphertext looks like transposition no 
        matter what you used for encryption.  Cheap distribution
        matching.
        
                                                        -Caj

------------------------------

From: [EMAIL PROTECTED] (W.G. Unruh)
Subject: Re: Americans abroad/Encryption rules?
Date: 2 Aug 99 17:20:49 GMT

[EMAIL PROTECTED] (Dmitri Alperovitch) writes:

>>Bill, thats strange. When was the personal use exemption taken off the
>>books?

Sorry. I was wrong. There is a personal use examption also under the EAR.
And it is much less stringent than the EAR exemption. In fact it seems that 
you can permanantly export encryption under the personal use exemption.  
The one under ITAR became moot when control of encryption passed to EAR.

So, if you are a US citizen or a Landed Immigrant, you can take it out with
you. If you are a foreigner, you had better erase all encryption from your
laptop before you leave the USA.

>From the Regulations 770.2
...
              (m) Interpretation 13: Encryption software
                      controlled for EI reasons

Encryption software controlled for EI reasons under ECCN 5D002 may be
pre-loaded on a laptop and exported under the tools of trade provision
of License Exception TMP or the personal use exemption under License
Exception BAG, subject to the terms and conditions of such License
Exceptions.  This provision replaces the personal use exemption of the
International Traffic and Arms Regulations (ITAR) that existed for
such software prior to December 30, 1996.  Neither License Exception
TMP nor License Exception BAG contains a reporting requirement.


In 740.15
((BAG)age Exemption.
...
 (f) Special provisions: encryption software subject to EI
 controls

 (1) Only a U.S. citizen or permanent resident as defined by 8
 U.S.C. 1101(a)(20) may permanently export or reexport encryption
 items controlled for EI reasons under this License Exception.

(2) The U.S. citizen or permanent resident must maintain
effective control of the encryption items controlled for EI
reasons.

(3) The encryption items controlled for EI reasons may not be
exported or reexported to Country Group E:2, Iran, Iraq, Sudan,
or Syria.

....
740.9

TEMPORARY IMPORTS, EXPORTS, AND REEXPORTS (TMP)
...
        (i)  Tools of trade.  Usual and reasonable kinds and
        quantities of tools of trade (commodities and software) for
        use by the exporter or employees of the exporter in a lawful
        enterprise or undertaking of the exporter.  Eligible tools of
        trade may include, but are not limited to, such equipment and
        software as is necessary to commission or service goods,
        provided that the equipment or software is appropriate for
        this purpose and that all goods to be commissioned or
        serviced are of foreign origin, or if subject to the EAR,
        have been legally exported or reexported.  The tools of trade
        must remain under the effective control of the exporter or
        the exporter's employee (see part 772 of the EAR for a
        definition of "effective control").  The shipment of tools of
        trade may accompany the individual departing from the United
        States or may be shipped unaccompanied within one month
        before the individual's departure from the United States, or
        at any time after departure.  No tools of the trade may be
        taken to Country Group E:2 (see Supplement No.1 to part 740)
        or Sudan.  For exports under this License Exception of laptop
        computers loaded with encryption software, refer to item
        interpretation 13 in 770.2 of the EAR.

.....
(4)  Return or disposal of commodities and software.  All
commodities and software exported or reexported under these
provisions must, if not consumed or destroyed in the normal
course of authorized temporary use abroad, be returned as soon as
practicable but no later than one year after the date of export,
to the United States or other country from which the commodities
and software were so exported, or shall be disposed of or
retained in one of the following ways:
...


See http://www.access.gpo.gov/bxa/ear/ear_data.html

------------------------------

From: [EMAIL PROTECTED] (W.G. Unruh)
Subject: Re: Americans abroad/Encryption rules?
Date: 2 Aug 99 17:11:05 GMT

[EMAIL PROTECTED] (JPeschel) writes:

>>Lincoln Yeoh writes, in part:
>>How about a foreigner with PGP visiting USA and then trying to erm leave?
>>

>Nope, the rule applies to citizens of the "land of the free."

Nope, the laws of the USA apply to everyone on the soil of the USA ( and 
sometimes even to non-citizens off the soil of the USA). You are not allowed
to export crypto whoever you are.

------------------------------

From: [EMAIL PROTECTED] (W.G. Unruh)
Subject: Re: Americans abroad/Encryption rules?
Date: 2 Aug 99 17:13:37 GMT

[EMAIL PROTECTED] (Dmitri Alperovitch) writes:

>I understand that, but once you are out of the States, you are no longer bound 
>by the the country's laws and, therefore, I don't think they would have the 

Oh yes you are. A US citizen is bound by the laws of the USA wherever in the 
world that person is  located.

------------------------------

From: [EMAIL PROTECTED] (W.G. Unruh)
Subject: Re: Americans abroad/Encryption rules?
Date: 2 Aug 99 17:15:26 GMT

[EMAIL PROTECTED] (JPeschel) writes:

>> [EMAIL PROTECTED] (Dmitri Alperovitch)

>>Can you post any links to official documents to support this?  That would
>>be greatly appreciated.
>>

>Yes, I can.

Will you do so?

------------------------------

From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: Americans abroad/Encryption rules?
Date: 02 Aug 1999 18:23:40 GMT

>[EMAIL PROTECTED] (W.G. Unruh) writes:

>Sorry. I was wrong. There is a personal use examption also under the EAR.
>And it is much less stringent than the EAR exemption. In fact it seems that 
>you can permanantly export encryption under the personal use exemption.  
>The one under ITAR became moot when control of encryption passed to EAR.

Good work, Bill, I knew someone would find it.  (You did mean to write less
stringent
than the ITAR exemption, though, I think.)

I seem to recall quite a bit of talk praising and condemning the ITAR exemption
when Schneier first mentioned the rule's appearance in the Federal Register. My
feeling is we'll take what we can get. 

Joe


__________________________________________

Joe Peschel 
D.O.E. SysWorks                                 
http://members.aol.com/jpeschel/index.htm
__________________________________________


------------------------------

From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Americans abroad/Encryption rules?
Date: Mon, 02 Aug 1999 19:28:07 GMT

In article <wgu20.933614017@riemann>, [EMAIL PROTECTED] (W.G. Unruh) 
wrote:
>[EMAIL PROTECTED] (Dmitri Alperovitch) writes:
>
>>I understand that, but once you are out of the States, you are no longer bound
> 
>>by the the country's laws and, therefore, I don't think they would have the 
>
>Oh yes you are. A US citizen is bound by the laws of the USA wherever in the 
>world that person is  located.

if your off us soil and you send encryption to any one you can"t be accussed 
of exporting from the us since your exporting from some where else.

 


David A. Scott
--
                    SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
                    http://www.jim.com/jamesd/Kong/scott19u.zip
                    http://members.xoom.com/ecil/index.htm
                    NOTE EMAIL address is for SPAMERS

------------------------------


** 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
******************************

Reply via email to