Cryptography-Digest Digest #125, Volume #10 Sat, 28 Aug 99 07:13:03 EDT
Contents:
Re: Where to find (Tim Redburn)
Re: UNknown-related key cryptanalysis?
Re: Can we have randomness in the physical world of "Cause and Effect" ? (Dave Knapp)
Re: Freeware windows public key encryption DLLs? ("Andy Jeffries")
(fwd)Factorization of RSA-155 (���J���L����ܤ�)
Re: Freeware windows public key encryption DLLs? (Matthias Bruestle)
Re: Can americans export crypto when in another country? (W.G. Unruh)
Re: Fermat theorem on primes? (W.G. Unruh)
Re: Can americans export crypto when in another country? (W.G. Unruh)
Re: How Easy Can Terrorists Get Strong Encrypt? (W.G. Unruh)
Re: Can americans export crypto when in another country? (W.G. Unruh)
Re: Can americans export crypto when in another country? (W.G. Unruh)
Re: Can americans export crypto when in another country? (W.G. Unruh)
Re: 512 bit number factored (W.G. Unruh)
Readability in export crypto ("Trevor Jackson, III")
Re: Can americans export crypto when in another country? ("Trevor Jackson, III")
Re: How Easy Can Terrorists Get Strong Encrypt? ("Trevor Jackson, III")
Re: Freeware windows public key encryption DLLs? ("Trevor Jackson, III")
Re: Can americans export crypto when in another country? ("Trevor Jackson, III")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Tim Redburn)
Subject: Re: Where to find
Date: Sun, 22 Aug 1999 21:38:15 GMT
On Sun, 22 Aug 1999 14:58:39 GMT, [EMAIL PROTECTED]
(SCOTT19U.ZIP_GUY) wrote:
<snip>
>Well you don't have a fucking
>clue as to if is weak.
<snip>
That's not strictly true. Your initial entropy calculations for
the S-Box were incorrect, suggesting that you did
not fully understand the basics of what you were doing at the time (I
and many others managed to spot the error and I am only
a beginner in cryptography (I can't speak for the others)).
Also your original code has a programming error in it - it accesses
unallocated memory - with undefined effects. As this
is the only absolute reference to your algorithm, anyone wanting to
analyse it must wonder how many other programming errors
there are and whether things are intentional or not. (was accessing
unallocated memory used to obtain a weak random number ? It
could have been .....not likely but without the algorithm how can we
be sure ?)
I would say that although there is no hard evidence that
your algorithm is weak, there are certainly plenty of clues dotted
around the place - not least your own inability to consistently,
coherently and accurately describe your own algorithm. You wrote it -
yet you can't describe it to others.
*** Serious Question *** (Please answer calmly) - David, when writing
scottx.zip, did you design it or write it ? In other words, did you
design and analyse your ideas on paper before coding, or did
you sit down and start writing code, making up the algorithm as you
went along with just some basic ideas for guidance ?
*** 2nd Serious Question *** - David, have you analysed your
algorithm(s) at all. If so, can you provide pointers
to any analysis that you have performed yourself. I do not mean
simply running randomness tests on the output - I mean proper
analysis by thinking about the way the algorithm works and
performing calculations etc...
-Tim.
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: UNknown-related key cryptanalysis?
Date: 28 Aug 99 05:06:52 GMT
John Savard ([EMAIL PROTECTED]) wrote:
: There are attacks involving identical plaintexts, enciphered with
: different keys, against many classical ciphers. However, modern block
: ciphers, from DES onwards, are quite resistant to that attack, since
: they are resistant to chosen-plaintext attacks, which are stronger.
I thought (a) was the plaintext, so this reply is not applicable.
------------------------------
From: Dave Knapp <[EMAIL PROTECTED]>
Subject: Re: Can we have randomness in the physical world of "Cause and Effect" ?
Date: Sat, 28 Aug 1999 06:01:07 GMT
matt wrote:
>
> I am neither a physicist, but it believe that Chaos Theory provides for
> true randomness, which is related to quantum mechanics.
Chaos theory does not provide for true randomness. It is entirely
classical, and describes systems that tend to be sensitive to initial
conditions.
Quantum mechanics requires either true randomness or nonlocality. As I
have written before, most physicists choose true randomness in the
absence of evidence for nonlocality, because nonlocality and causality
don't coexist very well. In other words, causality _requires_ true
randomness in QM.
-- Dave
------------------------------
Reply-To: "Andy Jeffries" <[EMAIL PROTECTED]>
From: "Andy Jeffries" <[EMAIL PROTECTED]>
Subject: Re: Freeware windows public key encryption DLLs?
Date: Fri, 27 Aug 1999 15:27:47 +0100
> Anyone know of any good freeware Dlls/Delphi components which can
> implement public key encryption, and digital signatures? Any secure
> algorithms are OK.
There is a good set of encryption/hashing components at the Delphi page,
hosted by Sam Simpson's Scramdisk site (http://www.scramdisk.clara.net/).
>From there, there is a link to public key stuff.
--
Andy Jeffries
TaekwonImports
-- See http://www.TaekwonImports.co.uk/ for more
information about Coach Lee's and Dr Yang's videos
------------------------------
From: [EMAIL PROTECTED] (���J���L����ܤ�)
Subject: (fwd)Factorization of RSA-155
Date: 27 Aug 1999 15:01:46 GMT
Thanks for [EMAIL PROTECTED] who notices me this info.
<<Origin: http://www.rsa.com/rsalabs/html/rsa155.html>>
On August 22, 1999, a group of researchers completed the
factorization of the 155 digit (512 bit) RSA Challenge Number. The
work was accomplished with the General Number Field Sieve. Here are
the details of the work:
The sieving software used two different sieve techniques: line sieving
and lattice sieving. The sieving was accomplished as follows:
Sieving: 35.7 CPU-years in total on...
160
175-400 MHz SGI and Sun workstations
8
250 MHz SGI Origin 2000 processors
120
300-450 MHz Pentium II PCs
4
500 MHz Digital/Compaq boxes
This CPU-effort is estimated to be equivalent to approximately 8000
MIPS years; calendar time for the sieving was 3.7 months.
124 722 179 relations were collected by eleven different sites,
distributed as follows:
(L: using lattice sieving code from Arjen K. Lenstra C: using line
sieving code from CWI)
* 20.1 % (3057 CPU days) Alec Muffett (L)
* 17.5 % (2092) Paul Leyland (L,C)
* 14.6 % (1819) Peter L. Montgomery, Stefania Cavallar (C,L)
* 13.6 % (2222) Bruce Dodson (L,C)
* 13.0 % (1801) Francois Morain and Gerard Guillerm (L,C)
* 6.4 % (576) Joel Marchand (L,C)
* 5.0 % (737) Arjen K. Lenstra (L)
* 4.5 % (252) Paul Zimmermann (C)
* 4.0 % (366) Jeff Gilchrist (L)
* 0.65 % (62) Karen Aardal (L)
* 0.56 % (47) Chris and Craig Putnam (L)
The resulting matrix had 6699191 rows and 6711336 columns, and weight
417132631 (62.27 nonzeros per row). Peter Montgomery's Cray
implementation of the blocked Lanczos algorithm took 224 CPU hours
and about 3.2 Gbytes of central memory on the Cray C916 at the SARA
Amsterdam Academic Computer Center to solve. This matrix is about 50%
larger, twice as dense and took 2.2 times as long to solve as that for
RSA-140.
A fairly extensive effort was expended in order to select the
polynomials for RSA-155. They were selected with the help of a new
polynomial search method developed by Peter Montgomery and Brian
Murphy (The Australian National University, Canberra). Calendar time
for the polynomial selection was nine weeks but could have been
reduced with the use of additional computers. This time was well worth
the effort as good polynomial selection can greatly reduce the sieving
time. Because RSA-155 spent more effort on polynomial selection than
was spent on RSA-140 the researchers were able to find a significantly
better polynomial. Whereas the polynomials for RSA-140 were about 8
times better than randomly selected ones, the ones for RSA-155 were
about 13.5 times better. RSA-155 took 35.7 CPU-Years as opposed to 8.9
CPU-Years for RSA-140. This is within the rough range of estimates
based on the factorization of RSA-140, though the CPU time was
somewhat less than predicted due perhaps to statistical variations, as
well as to the improved polynomial selection. There are theoretical
limits to the extent to which polynomial selection can be improved,
however.
The total calendar time for factoring RSA-155 was 5.2 months (March 17
- August 22) excluding polynomial selection time. If one includes
polynomial selection, the total elapsed time was 7.4 months, whereas
RSA-140 took about 9 weeks of elapsed time. It must be noted that
polynomial selection could be greatly reduced in elapsed time by using
more machines. Neither effort devoted many machines to this task.
--
[1;32m�� Origin: [33mKrynnLand [37m<Terry.Dragon2.Net> [m
[1;31m�� From: [36mntucsa.csie.ntu.edu.tw[m
------------------------------
From: [EMAIL PROTECTED] (Matthias Bruestle)
Subject: Re: Freeware windows public key encryption DLLs?
Date: Fri, 27 Aug 1999 23:20:42 GMT
Mahlzeit
[ Dr. Jeff ] ([EMAIL PROTECTED]) wrote:
> If they're freeware, how can you be assure of their security?
If they're not freeware, how can you be assure of their security?
At least with many freeware you get the source to look at.
Mahlzeit
endergone Zwiebeltuete
--
PGP: SIG:C379A331 ENC:F47FA83D I LOVE MY PDP-11/34A, M70 and MicroVAXII!
--
VI, the way, the light, the future...
-- Stuart Woolford
------------------------------
From: [EMAIL PROTECTED] (W.G. Unruh)
Subject: Re: Can americans export crypto when in another country?
Date: 28 Aug 99 09:23:09 GMT
"Trevor Jackson, III" <[EMAIL PROTECTED]> writes:
>I believe that US citizens suffer from the US crypto regs in the same way
>they suffer from the US tax regs. Contrary to most national tax systems,
>the IRS tries to collect tax from ll US citizens no matter where they
>reside. Similarly, the US crypto regs prohibit US citizens from
>contributing to unlicensed non-US crypto systems no matter where they
>perform the work.
No. The regulations control the EXPORT or crypto from the USA. Thus,
they do not control the development of crypto elsewhere, umless that
development included the export of crypto from the USA. Under ITAR, such
export included any technical support of crypto by a US citizen, but the
EAR reguations as I recall do not include such control of intagibles.
But you should read the EAR regualtions to be sure.
------------------------------
From: [EMAIL PROTECTED] (W.G. Unruh)
Subject: Re: Fermat theorem on primes?
Date: 28 Aug 99 09:01:15 GMT
"Thijs vd Berg" <[EMAIL PROTECTED]> writes:
><snip>
>> Fermat's little theorem says that if p is a prime and does not
>> divide a, then a^(p-1) = 1 mod p. Instead of doing copying from a
>Hi there mr. expert-wannabe,
>I suggest you also take a look in that text book of yours for that "proof".
>I you think its neccesary to flame, than don't make such a fool out of
>yourself.
>a=2,p=11*31=341 "OOOPS, (blush) did I say "proof"? But, but, you must
Perhaps you should also take a lesson in reading. Note that Shen said
"if p is a prime". Now some very deep and difficult math has led me to
the strong suspicion that p=11*31 is not a prime!
>believe me! I know very much a bout math, I even quoted Fermat, which is
>cool, and Euler too!
>Way to go mr. M. K. Shen!!! Keep on scanning the newsgroup for novices and
>amateurs and people who are just interested and keep on trying to look
>superior.
------------------------------
From: [EMAIL PROTECTED] (W.G. Unruh)
Subject: Re: Can americans export crypto when in another country?
Date: 28 Aug 99 09:27:25 GMT
[EMAIL PROTECTED] (Doug Stell) writes:
>Unless you give up your U.S. citizenship, doing so would be "U.S.
>envolvement" and would be covered under the export regulations. Living
>in Canada or marrying a Canadian would make zero difference.
Could you give a reference for this in the EAR regulations? Under ITAR,
this would be covered under "Technical assistance" which also required a
license, but I do not recall seeing such a subsection under EAR.
Also, it still has to be "export" of some sort. Ie, if the US citizen
could show that the stuff was not even in his head before he left the
USA, it would I suspect be hard to get a conviction under the export
sections. (Ie, the enabling legislation covers "export" and one cannot
redefine the terms in the enabling legislation to cover everything, if
that extention is not already in the legislation.)
------------------------------
From: [EMAIL PROTECTED] (W.G. Unruh)
Subject: Re: How Easy Can Terrorists Get Strong Encrypt?
Date: 28 Aug 99 09:06:51 GMT
Medical Electronics Lab <[EMAIL PROTECTED]> writes:
< A long license agreement in which TI says that the code MAY have
export restrictions and puts the complete onus on the user to comply
with any such restrictions>
>But it's clear TI thinks there are controls on compilers
>and other software.
No. It is clear tht TI is covering their ass, just in case someone comes
after them. They also make it clear that they are not making any
statement at all as to whether or not the Export regulations actaully do
apply, just that if they do, it is the user, not TI who is supposed to
carry the can.
------------------------------
From: [EMAIL PROTECTED] (W.G. Unruh)
Subject: Re: Can americans export crypto when in another country?
Date: 28 Aug 99 09:35:17 GMT
[EMAIL PROTECTED] (Michael D. Crawford) writes:
>What I would like to do is specifically port some crypto software
>(that's already written; I'd just be doing a port) and then give it back
>to its originator. I'd be bringing the crypto in from Switzerland to
>Canada, modifying it, and sending it back to Switzerland. The code is
>public domain (open source, not GPL'ed or anything - truly public
>domain) but I know for sure if I did the work in the US I couldn't send
>it back.
I cannot see how US export law would apply at all. you are not exporting
your crypto knowledge even when you leave the USA. You are at best
exporting your porting knowledge. Read teh EAR, and especially look for
anything which talks about "technical assistance".
While the USA could well hold you to US law, it would still need to have
a case to present to the court that you had violated some term in the
regulations. See if there is such a term.
------------------------------
From: [EMAIL PROTECTED] (W.G. Unruh)
Crossposted-To: talk.politics.misc,talk.politics.crypto
Subject: Re: Can americans export crypto when in another country?
Date: 28 Aug 99 09:39:57 GMT
"Trevor Jackson, III" <[EMAIL PROTECTED]> writes:
>Anthony Stephen Szopa wrote:
>Don't use the term "export" as you and I understand it. Use the term as defined
>by the regs. These definitions are unrelated.
No. Regulations cannot define terms-- that is for the supporting
legislations. If it uses export undefined, then export retains is normal
meaning. The regulations cannot then define "export" as "picking your
nose" no matter how objectionable the government may find the latter.
The regulations can try to clarify the definition, but it must retain
some link to its ordinary meaning.
As far as I know, the legislation does not define export as a special
term, and thus the regulations must have some link to the oridinary
meaning of that term.
>Yes.
>N.B., the typical attitude of a legislator is "You can craft a law to do
>anything". Rationality is not a constraint legislators admit.
>Constitutionality is not a constraint legislators admit.
But regulations are not legislation. Regulations cannot "do anything".
They can only do what the legislation allows them to do.
>Then the bureaucrats ignore the letter and spirit of the law and create the
>regs.
Then they run into trouble in the courts.
------------------------------
From: [EMAIL PROTECTED] (W.G. Unruh)
Subject: Re: Can americans export crypto when in another country?
Date: 28 Aug 99 09:11:21 GMT
[EMAIL PROTECTED] (Michael D. Crawford) writes:
>Hi,
>I'm an American citizen, presently living in the US, and I've been
>wanting for a while to port Speak Freely to the Be operating system.
>See http://www.speakfreely.org and http://www.be.com
>Speak Freely includes encryption, so if I port that while I'm in the US
>I can't contribute my changes back to the original source archives,
>which are in Switzerland.
>But I may be moving to Canada in a few months (I'm marrying a Canadian
>woman). Once I'm in Canada, as long as I create my port of the crypto
>software while I'm in Canada (so I never bring the crypto Speak Freely
>into the US, and don't take it back out again), can I export the crypto
>back to Switzerland without violating US laws?
For legal advice see a lawyer. Do not base decisions which could cost
you 10 years of your life on advice on the net.
But given tht let me make some comments (note I am NOT a lawyer).
The US restricts the export of crypto or crypto technology, whether free
or not, out of the country. This includes the expertise which you have.
Ie, now that you have announced to the net that you have some crypto
additions to Freely, the US could well arrest you and argue that the
crypto which you legally (under Canadian law) exported from Canada, was
actually developed in the USA and was thus exported from the USA to
Canada when you left the USA and then reexported from Canada. While your
export to Canada was legal, they might argue that your reexport to
oether countries was not. So, as a defense you would have to be able to
show that you did not have a crypto product when you left the USA, and
that the development and production of the product occured after you
went to Canada, and was thus out of US control.
Now, as a criminal case, the onus is on the gov't to prove that you
exported it "beyond reasonable doubt" However considering the costs to
you, you should be able to demonstrate almost beyond reasonable doubt
that you did not export it, but developed it independently in Canada.
Also, read the laws ( there are referenced to botht he US and Canadian
regulations on axion.physics.ubc.ca/ppp-linux.html) and talk to a lawyer
with some expertise in this kind of thing.
>I expect to travel to the US frequently on business and it would be a
>drag to get arrested for some free software work I do while in Canada.
>Canada itself has some export controls, but according to the Crypto Law
>Survey at:
>http://cwis.kub.nl/~frw/people/koops/lawsurvy.htm
>crypto is not export controlled if the software is in the public domain,
Note in this context "public domain" does not mean what it means in teh
copyright act, but is a special technical term defined in the Export
Control List regulations.
>which is the case for the original speak freely and will be true for my
>changes.
------------------------------
From: [EMAIL PROTECTED] (W.G. Unruh)
Subject: Re: 512 bit number factored
Date: 28 Aug 99 09:54:10 GMT
Paul Koning <[EMAIL PROTECTED]> writes:
>"Boudewijn W. Ch. Visser" wrote:
>>
>> See http://www.cwi.nl/cwi/Latest_News.html :
>> which models 95% of the keys used to secure electronic commerce on the
>> Internet.
>But I'm curious about the assertion that 95% of the keys used
>are 512 bit keys. Admittedly the sample is small, but my PGP keyring
PGP is NOT the primary method to "secure electronic commerce". Those are
proprietary schemes used by banks, etc.
------------------------------
Date: Sat, 28 Aug 1999 06:18:14 -0400
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.misc,talk.politics.crypto
Subject: Readability in export crypto
Jerry Coffin wrote:
> In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] says...
>
> ...which is perfectly fine as long as they didn't distribute machine-
> readable versions of the encryption algorithms to non-US citizens.
We use the term machine-readable to indicate material intended for the
consumption of machines rather than the consumption of humans. But this term is
a bit misleading. Two instances of the fuzziness of the term bear
consideration: scanning as a form of machine reading and printing in a form
intended for scanning.
Simply scanning a printed page could be considered "machine reading". If the
scanning is performed by a copier we'd probably consider it part of the process
of duplicating the printed page rather than "reading" because it produces no
info stored in a machine. Of course this can be further decomposed into a
scanner/printer pair where the intermediate scanned file is retained by the
computer driving both peripherals.
Somewhere along the noun/verb sequence <page> [scan] <image file> [OCR] <text
file> [compile] <object file> lies the point at which export is forbidden.
Clearly the initial printed page is permitted and the final object file is
forbidden. Speculating, I'd guess that an image file is permitted and a text
file is not. But what about PS or PDF files? They aren't really images, and
are typically used to represent printed pages rather than input to a compiler.
The act of preparing source code for legal export admits a spectrum of
possibilities based on font selection. The choice of a fount that is
particularly good for OCR might indicate that the information was
"mechine-readable". If the font is one that is particularly good for machines
and bad for humans, such as a bar code, would strongly indicate the info was
aimed at a machine rather than a human.
Non-ink-on-paper representations may also be suspect. A Braille rendering is
typically aimed at humans while punch-card rendering is typically aimed at a
machine. But these renderings are so close physically (while radically
different in encoding) that Questions Might Be Asked.
Summary
- "machine" probably means compiler rather than computer
- the intent of the person creating the rendering probably dominates the
decision
- the typical usage of the representation may determine the applicability of
the export regs
- there are so many ambiguities and potential misinterpretations that the regs
are clearly void for vagueness
(pun intended)
- applying logic to the regulations may be futile (is this post a waste of
bandwidth?)
------------------------------
Date: Sat, 28 Aug 1999 06:34:37 -0400
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.misc,talk.politics.crypto
Subject: Re: Can americans export crypto when in another country?
W.G. Unruh wrote:
> "Trevor Jackson, III" <[EMAIL PROTECTED]> writes:
>
> >Anthony Stephen Szopa wrote:
>
> >Don't use the term "export" as you and I understand it. Use the term as defined
> >by the regs. These definitions are unrelated.
>
> No. Regulations cannot define terms-- that is for the supporting
> legislations. If it uses export undefined, then export retains is normal
> meaning. The regulations cannot then define "export" as "picking your
> nose" no matter how objectionable the government may find the latter.
> The regulations can try to clarify the definition, but it must retain
> some link to its ordinary meaning.
I disagree. The tooth fairy does not write regulations. Bureaucrats do. QED.
> As far as I know, the legislation does not define export as a special
> term, and thus the regulations must have some link to the oridinary
> meaning of that term.
> >Yes.
>
> >N.B., the typical attitude of a legislator is "You can craft a law to do
> >anything". Rationality is not a constraint legislators admit.
> >Constitutionality is not a constraint legislators admit.
>
> But regulations are not legislation. Regulations cannot "do anything".
> They can only do what the legislation allows them to do.
This conclusion is not supported by the facts.
> >Then the bureaucrats ignore the letter and spirit of the law and create the
> >regs.
>
> Then they run into trouble in the courts.
Sometimes.
------------------------------
Date: Sat, 28 Aug 1999 06:52:31 -0400
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: How Easy Can Terrorists Get Strong Encrypt?
Medical Electronics Lab wrote:
> Trevor Jackson, III wrote:
> >
> > TI apparently likes belt, suspenders, and straightjacket.
>
> That's why lawyers get paid so much. They know how to attach
> them all at once!
>
> :-)
>
> So if I loan the CD to an Iraqi student, it *might* be illegal.
> But the student can take the CD, copy it onto their portable,
> and go home for holidays. At home, her government copies the
> disk and hands it over to a few terrorists.
>
> Suppose the US has a spy with the terrorists, and traces the
> source back to me (with help of the FBI back in the US). Would
> the Feds get me for breaking a *law* or a *regulation*?
>
> I agree that TI is just doing CYA, but there's a presumption
> on their part that somewhere, there may be a law which does in
> fact prohibit or restrict the distribution of their software.
> I presume it's because there *is* a law or regulation that has
> bit them in the butt once before. Otherwise they wouldn't waste
> their breath, lawyers cost too much to waste time on useless
> boiler plate.
This is speculation. I disagree with your presumption.
Do you remember the feeding frenzy that tookk place among the various
Federal Departments when that Texas company wne to washington to get a
"license" to launch a rocket? Turns out that there was no law or
regulation that required any kind of license.
But four (IIRC) separate departments volunteered to fix that. When they
had figured out which department got to regulate the previously
unregulated behavior they drew up regulations to fill the gap. When
they were done "fixing" the situation it was illegal to launch any kind
of rocket, even a tiny Estes model, without a massive paperwork effort.
It took a while for that stupidity to become apparent and model rockets
to become unburdened. But you'll be glad to know that other than model
rockets, more bureaucrats than ever are supervising your life.
If enough companies write contracts like TI they might convince some
bureaucrats that companies like TI need to be supervised. It would
serve them right and the public ill.
>
>
> The whole thing is pretty dumb, code moves at light speed and
> beauracrats move at snail speed. It's a fair bet that most
> "bad guys" at the level US Feds worry about have good crypto.
Ever met a burseaucrat that cares how fast you would be moving without
their supervision?
------------------------------
Date: Sat, 28 Aug 1999 06:53:53 -0400
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Freeware windows public key encryption DLLs?
[ Dr. Jeff ] wrote:
> In article <[EMAIL PROTECTED]>, matt <[EMAIL PROTECTED]> wrote:
> >Anyone know of any good freeware Dlls/Delphi components which can
> >implement public key encryption, and digital signatures? Any secure
> >algorithms are OK.
>
> If they're freeware, how can you be assure of their security?
If they're proprietary and the source only available in escrow you can be sure of
their insecurity!
------------------------------
Date: Sat, 28 Aug 1999 06:37:56 -0400
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Can americans export crypto when in another country?
W.G. Unruh wrote:
> [EMAIL PROTECTED] (Doug Stell) writes:
>
> >Unless you give up your U.S. citizenship, doing so would be "U.S.
> >envolvement" and would be covered under the export regulations. Living
> >in Canada or marrying a Canadian would make zero difference.
>
> Could you give a reference for this in the EAR regulations? Under ITAR,
> this would be covered under "Technical assistance" which also required a
> license, but I do not recall seeing such a subsection under EAR.
> Also, it still has to be "export" of some sort. Ie, if the US citizen
> could show that the stuff was not even in his head before he left the
> USA, it would I suspect be hard to get a conviction under the export
> sections.
Can you outline such a proof? Typically proving a negative is infeasible.
For criminal prosecution it is up to the government to prove that you did
have it in your head prior to departing the US.
> (Ie, the enabling legislation covers "export" and one cannot
> redefine the terms in the enabling legislation to cover everything, if
> that extention is not already in the legislation.)
------------------------------
** 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
******************************
