Cryptography-Digest Digest #762, Volume #9 Thu, 24 Jun 99 17:13:03 EDT
Contents:
Re: one time pad (Greg Ofiesh)
Re: one time pad (Greg Ofiesh)
Re: one time pad ("Harvey Rook")
Online material? (Cheshire Cat)
CBC mode (?) ("Serge")
USENIX Security Symposium: Program & Registration Now On-line (Jennifer Radtke)
Re: one time pad (Patrick Juola)
Re: Caotic function ([EMAIL PROTECTED])
Re: On an old topic of internet publication of strong crypto ([EMAIL PROTECTED])
Re: A different method of encryption ([EMAIL PROTECTED])
Re: one time pad ([EMAIL PROTECTED])
Re: Converting arbitrary bit sequences into plain English texts ([EMAIL PROTECTED])
Re: one time pad (Jerry Coffin)
Re: one time pad ([EMAIL PROTECTED])
Re: On an old topic of internet publication of strong crypto (Paul Koning)
----------------------------------------------------------------------------
From: Greg Ofiesh <[EMAIL PROTECTED]>
Subject: Re: one time pad
Date: Thu, 24 Jun 1999 18:45:57 GMT
> I can recover your message in seconds by intercepting these messages
> and observing that the first character is one of the two characters
> that did not appear as the first character in *any* received message.
> Continuing this observation for the second, third, and so forth,
> gives me your complete message, almost without effort.
I see your point.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Greg Ofiesh <[EMAIL PROTECTED]>
Subject: Re: one time pad
Date: Thu, 24 Jun 1999 18:22:58 GMT
> > Also, a OTP's strength is entirely found in the fact that given a
> > cipher stream only, any plain text stream is an equal candidate to
> > be the true plain text.
>
> No, that is patently false. "Oryx blfp mophh" is less likely to be
> the plaintext than is "Need more funds".
Let me clarify. Oryx blfp mophh would be rejected and never make the
list.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: "Harvey Rook" <[EMAIL PROTECTED]>
Subject: Re: one time pad
Date: Thu, 24 Jun 1999 12:12:12 -0700
Greg Ofiesh <[EMAIL PROTECTED]> wrote in message
news:7ksjkc$tj5$[EMAIL PROTECTED]...
> Predictability-
>
> A true random bit generator (RBG) can produce 400 zeros, but this is
> undesirable. Therefore, a true RBG is not desired.
>
Counter to intuition, this is desirable. If you eliminate runs of zeros,
then you are elminating potential message candiates. You see, if the file
encrypts to "The ingredients to Kellogg's SMART START are..." then the
cryptographer knows that the file does not contain the ingredients to
Kellogg's SMART START.
Since the probability of getting 400 zeros is 1/(2^400) a value which is
sooooo small, worrying about it is counter productive. Why stop there? If
you root out 0's why not route out stream's of 1's as well. Then 01's? Then
any reapeating stream? You are making it easier to guess the original cypher
by picking a stream with special properties.
To give an example. The German's designed their enigma cypher to give no in
information away. It would never encrypt a letter to itsself. This actually
helped the allies crack enigma. If you saw the letter B you knew that the
plain text could not be B. In one case, the allies recoverd a longish steam
of cypher text that contained no L's. A cryptographer correctly guessed the
the German's were testing a connection between to enigma machines by holding
down the L key. Using this information, they quickly cracked that days
password.
> Predictability can be hampered by limitations, but it turns out that
> predictability is not an issue. The issue is minimizing patters while
> maximizing message candidates that the opponent must choose from. And
> every message candidate must be given the illusion of having the same
> probability of being correct as the correct message has.
>
You maximize message candidates by maximizing unpredictability. The
probability of a long stream of zero's is so vanishingly small, that
worrying about it is counter productive.
Harvey Rook
[EMAIL PROTECTED]
Spam Guard in effect. The mail isn't cold, it's hot.
------------------------------
From: [EMAIL PROTECTED] (Cheshire Cat)
Subject: Online material?
Date: Thu, 24 Jun 1999 19:31:05 GMT
Hi folks,
Does anyone know of any online materials available for a newbie
interested in cryptanalysis? I'm talking about real basic stuff that'd
cover the math/number theory involved...
---
cheshire at letterbox dot com
------------------------------
From: "Serge" <[EMAIL PROTECTED]>
Subject: CBC mode (?)
Date: Thu, 24 Jun 1999 23:37:26 +0400
I did find a test array for Blowfish in CBC mode. Length of array 29 bytes.
Is there a standart method to fill last block up to 8 bytes? I did try to
fill last 3 bytes with zero, but it was wrong.
Regards,
Serge.
------------------------------
Crossposted-To: muc.lists.www-security,ocunix.mail.freebsd.security
From: [EMAIL PROTECTED] (Jennifer Radtke)
Subject: USENIX Security Symposium: Program & Registration Now On-line
Date: Thu, 24 Jun 1999 19:46:28 GMT
The program, put together by volunteer security experts, is of
the highest quality and highest relevance to systems professionals
concerned with leading-edge technologies and strategies.
8TH USENIX SECURITY SYMPOSIUM
August 23-26, 1999
JW Marriott Hotel, Washington, D.C.
Sponsored by USENIX in Cooperation with the CERT Coordination Center
==========================================================================
Review the Program at http://www.usenix.org/events/sec99
==========================================================================
* Exchange ideas with the industry's top security insiders.
* Gain command of leading-edge tools and techniques at specifics-driven
tutorials.
* Explore the latest advances in Internet security, intrusion
detection,distributed systems, and applications of cryptography.
Two days of in-depth tutorials taught by experienced, expert instructors
*Intrusion Detection and Network Forensics, Marcus J. Ranum
*Advanced Topics in Windows NT Security, Phil Cox
*An Introduction to Virtual Private Networks, Tina Bird
*How to Write Programs Securely, Matt Bishop
*What Hackers Know About You, Brad Johnson
*Cryptography from the Basics Through PKI, Daniel Geer & Avi Rubin
Keynote by a pioneer of Internet security technologies:
"The Next Generation of Security"
by Taher Elgamal, President, Information Security, Kroll-O'Gara
Over 20 refereed reports on the best new research in areas like:
*Managing Access Control
*Intrusion Detection
*Creating Secure Environments for Software, and much more
Invited talks by several of security's leading lights including:
*Marcus Ranum on a Burglar Alarm Builder's Toolbox
*Ross Anderson on Electronic Commerce
*Paul Van Oorschot on Public Key Infrastructure (PKI)
*Edward Felten on designing a secure electronic stock market
=========================================================================
USENIX, the Advanced Computing Systems Association, is an international,
not-for-profit society made up of scientists, engineers, and system
administrators working on the cutting edge of systems and software. For 25
years USENIX conferences and workshops have emphasized quality exchange of
technical ideas unfettered by stodginess or commercialism.
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: one time pad
Date: 24 Jun 1999 15:17:37 -0400
In article <7ktn6b$aqk$[EMAIL PROTECTED]>,
Greg Ofiesh <[EMAIL PROTECTED]> wrote:
>
>> > How many aeons did you say you had to look through this list?
>>
>> It's irrelevant. The point is that as long as 100 0xa7's in a row is
>> exactly as likely as any other sequence of 100 characters, the
>> attacker has no better idea that this particular decryption is valid
>> compared to all the others that his criteria says are plausible.
>
>
>This is exactly what I disagree with. First, the odds that 100 0xa7's
>would occur are astronomical. Then the fact that a valid candidate
>would math anything is astonomical (since they all have 1 in
>astronomical chances). But then you combine the two and you have
>astronomical squared. That has got to give weight, don't you think?
No, it doesn't.
Formalize the conditional probabilities and you'll see what I mean.
-kitten
------------------------------
Date: Thu, 24 Jun 1999 03:58:16 -0400
From: [EMAIL PROTECTED]
Subject: Re: Caotic function
John E. Kuslich wrote:
>
> Chaos does not DEPEND on complex numbers any more than electromagnetic
> theory DEPENDS on complex numbers. It is just awfully hard to talk
> about either subject without tripping over the concept of complex
> numbers...
No. A common presentation of chaos is an illustration of a strange
attractor in a 2D space. Thus you can represent the collection of
points visited as a collection of complex numbers. However, the complex
plane in not the only space that contains strange attractors.
Trivially, there are 3D analogues for any 2D attractor. We just don't
happen to have a special term for the coordinates except, I suppose, for
3-vector.
Where in "sensitive dependence upon initial conditions" do you find
complex numbers?
>
> Remember the book "Physics Without Math" that was published a few years
> ago??
>
> Right, it could happen, you could understand physics without
> math...right...you could...right...
>
> I our public schools they are now trying to teach math without math.
> "How do you feel about your answer Johnny??" You wouldn't want to ruin
> the little buggers self esteem by telling him he had the wrong answer
> now would we??
>
> I don't think you could begin to understand chaos without understanding
> the math behind it.
>
> JK
>
> Douglas A. Gwyn wrote:
> >
> > "John E. Kuslich" wrote:
> > > My criticism was intended for the individual who originally made the point
> > > that complex numbers and chaos and fractals (and even cryptography) are
> > > not related...
> >
> > I disputed the claim that chaos depended on complex numbers.
> > There are, of course, uses of complex numbers throughout analysis,
> > including being the simplest way to express the famous Mandelbrot
> > function whose divergence map you've all seen on calendars, etc.
> > But chaos depends only on the nature of dynamical systems, not on
> > whether or not complex numbers are somehow used in their description.
> > In fact there are chaotic 1-dimensional systems, for which clearly
> > a complex-number model would be inappropriate.
>
> --
> CRAK Software (Password Recovery Software)
> Http://www.crak.com
> [EMAIL PROTECTED]
> 602 863 9274 or 1 800 505 2725 In the USA
------------------------------
Date: Thu, 24 Jun 1999 04:13:29 -0400
From: [EMAIL PROTECTED]
Subject: Re: On an old topic of internet publication of strong crypto
Mok-Kong Shen wrote:
>
> [EMAIL PROTECTED] wrote:
> >
>
> > The way ITAR was implemented, importation from outside UKUSACAN
> > didn't matter; what mattered was whether or not strong crypto
> > was available from a US-based webserver to non-UKUSACAN nationals,
> > wherever they happened to reside or to be when they obtained the
> > strong crypto. This is from memory, of course, and so I Could
> > Be Wrong. But I think I got the main part right.
>
> What if the author does not have the text of his paper at his site
> but simply provides a link to the page on the foreign server (which
> in this case has to keep the material for longer time)? For access
> by the reader it makes no difference at all whether what the link
> points to is stored locally or remotely, thanks to the design of
> the world wide web. Should even that be objected to, he can simply
> write that a paper is available overseas at www.xxx.yyy (i.e. without
> the mouse click functionality). Now this last is a pure reference,
> like any literature references found at the end of a scientific paper.
> I doubt whether even an authority of a country under the worst
> dictatorship of the modern world could forbid such references.
Read some history. Many people have trouble understanding a country
that licensed copy machines (I'm referring to the pre-xerox
duplicators). Would you believe in a country where is was illegal to
assemble much less publish a phone book? That's a reference book
containing phone numbers. A reference book containg cryptological
pointers would be in the "burn before reading" category.
A typical legislator's attitude is that "you can craft a law to do
anything". IMHO many modern laws are attempts to illustrate that
principle.
> Any nation claiming to be democratic certainly could not afford that
> kind of censorship.
All countries are democratic. Just ask their ministers of propoganda!
After all "People's Democratic Republic" goes right along with "Maximum
Leader-For-Life" et al.
------------------------------
Date: Thu, 24 Jun 1999 04:19:56 -0400
From: [EMAIL PROTECTED]
Subject: Re: A different method of encryption
Greg Ofiesh wrote:
>
> > I think the main point of the criticism is that one should not step
> > into a well-developed field and tell people how things should be done
> > without first *learning* enough about the field to have a chance of
> > contributing something new and useful.
>
> May I offer an observation about this forum?
No one can stop you.
------------------------------
Date: Thu, 24 Jun 1999 04:34:00 -0400
From: [EMAIL PROTECTED]
Subject: Re: one time pad
Terry Ritter wrote:
>
> On Wed, 23 Jun 1999 18:06:41 GMT, in <7kr7n8$dva$[EMAIL PROTECTED]>, in
> sci.crypt [EMAIL PROTECTED] wrote:
>
> >I would like to put forth the following claims
> >and if anyone would care to comment, disprove,
> >ect., I would appreciate it. I thought I new
> >some things (being new to cryptography), but a
> >patient individual helped me see I have more to
> >learn. He suggested I come to Deja, so here I am.
> >
> >1. One time pads, when implemented, deployed, and
> >used correctly are the only known cipher that
> >guarantees the security of the plain text over a
> >non secured media. (Physical security is assumed
> >for this discussion.)
>
> False. The key word here is "guarantees." Unless we have a proof
> which applies in practice, there can be no such "guarantee" in a
> realized cipher.
>
> The OTP which is "proven" secure is the *theoretical* OTP which
> assumes and thus "uses" a perfect theoretical random keystream. Alas,
> a theoretical OTP can only "protect" theoretical data. When we get
> into the real world, we have to measure what we have and guarantee
> that the theoretical assumptions are met in practice. But that is
> impossible.
>
> If we have some known plaintext, all it takes to enter the OTP is to
> have a relationship in the keystream such that some future bits can be
> predicted from past bits. (This could be some sort of correlation
> between bits or multi-bit symbols.) We have tests which check for
> particular correlations, but we have no test which can prove that no
> such correlation exists. Thus we have no proof of strength.
>
> Even if we had ideal measures, our concepts of randomness and entropy
> are statistical: even good results refer only to the body of data
> tested, not previous data, not subsequent data, and not even each and
> every byte of the test. Individual bytes could leak information, yet
> the overall sequence might still be measurably random (whatever that
> might mean). But if we leak *any* information, then, clearly, our
> "guarantee" is something less than one might expect.
>
> One approach to a solution might be to build a physically-random
> device which cannot be incorrectly built, cannot fail to perform,
> cannot be damaged in an undetectable way, and will meet every possible
> test for randomness, even if we have not yet defined those tests.
> Then we could say that our device was "provably random," which would
> imply a security proof for an OTP using such a device as a keystream
> generator. In my opinion, any attempt to build such a device would be
> a foolish quest.
>
> On the other hand, I am willing to believe that a well-designed,
> well-constructed, and well-tested physically-random RNG could be very
> secure indeed. The difference is that we have no absolute *proof*.
> And that places the OTP firmly into the body of ciphers we know.
Terry, I tend to agree with you about the fallaciousness of assigning
relative strengths to ciphers, but this usage of the term proof is
probably not a good one. It implies a mathematical level of proof.
Note that we have no equivalent proof that the earth is not flat. We
could inhabit a strange hyperbolic space with the speed of light varying
with distance from the center of the earth.
But we do have emperical proof. Both the flat earth scenario and the
insecure OTP scenario can be addressed in terms of a lesser standard of
proof. The legal system uses "preponderance of evidence", "proof beyond
a reasonable doubt" etc. to set standards less than mathematically
rogorous. BY YOUR OWN ARGUMENTS, waiting for a rigorous mathematical
proof of cipher strength, even OTP strength, is a waste of time.
The standard of proof referred to in "provably secure" is not that of
mathematical rigor applied to all aspect of the implementation. It is,
instead, a proof that IFF you have a good pad you have security ghod
cannot defeat. This is a useful conclusion because building a good pad
is feasible whereas building a non-crackable cipher system is
problematic.
------------------------------
Date: Thu, 24 Jun 1999 03:47:16 -0400
From: [EMAIL PROTECTED]
Subject: Re: Converting arbitrary bit sequences into plain English texts
There's a boundary hidden somewhere here. As we move from compilable
source code to translated source code to encoded source code we come
close to steganography. Is there really a difference between hiding
source code in the party of words and the LSBs of pixels? I suspect the
government will find this distinction less than convincing.
Rather than find clever ways of hiding the source code we should push on
the basic silliness of banning source code. Optimally, we like
something just far enough from compilable to be exportable. There is
really is no need to _hide_ the material, only a need to distinguish it
from machine-usable source code. After all we're citizens to be
protected not crimminals to be persecuted.
A suggestion in this direction would be to take an ANSI or ISO compliant
source file and induce a pattern of syntax errors. Naturally the
pattern of errors should be easily reversed, perhaps by hand.
1. It should clearly be "not useful" source code.
2. It should be easily transformed into "useful source code".
When we focus on these distinctions we may find that the export
regulations are void for vagueness. They do not adequately describe the
difference in a way that reasonable person can know what is legal and
what is not.
wtshaw wrote:
>
> In article <[EMAIL PROTECTED]>, Mok-Kong Shen
> <[EMAIL PROTECTED]> wrote:
>
> > Bauerda wrote:
> >
> > > To make the sentences a little more natural (than yes yes no yes yes
> no ) why
> > > not just use any word starting (or ending) with a letter from the
> first half of
> > > the alphabet for a zero and the second half for a one? People might
> not even
> > > realize that a file is encoded in the message this way.
> >
> > We need constructs that are gramatically complete sentences,
> > a bunch of words may be objected as not being natural language
> > texts.
> >
> Ah! Something based on a variation of the Baconian Cipher? I suppose that
> a program could make a series of sentences that would pass, even true ones
> as I have suggested, but to have an overall plot or gross meaning...that
> is another matter.
> --
> Mirror, mirror on the wall: Where do you get your information?
------------------------------
From: [EMAIL PROTECTED] (Jerry Coffin)
Subject: Re: one time pad
Date: Wed, 23 Jun 1999 13:17:20 -0600
In article <7kr7n8$dva$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
says...
[ ... ]
> 1. One time pads, when implemented, deployed, and
> used correctly are the only known cipher that
> guarantees the security of the plain text over a
> non secured media. (Physical security is assumed
> for this discussion.)
True.
> 2. Maintaining statistical randomness produces a
> weakness in the pad since the probability of some
> values already seen in the bit stream are less
> likely to be found again.
For a truly random stream, the likelihood of a value appearing at some
point in the stream is _independent_ of its appearance at other points
in the stream. If you're using some sort of pseudo-random generator
that generates numbers in such a way that they won't be repeated with
more than a given frequency, you no longer have a one-time-pad.
> 3. As long as a minimal amount of randomness is
> guaranteed, the pad's security is its strongest.
> To require strong randomness is to limit the
> opportunities of what can be found on the pad and
> thus limit the candidates of possible plain text
> hidden by the OTP's output.
Randomness is qualitative, not quantitative. IOW, either your stream
is random, or it's not. There's no "strength" or "percentage"
involved. If there's any ability to find patterns or correlations in
the stream, then the key is not random. It may model randomness in
some fashion to some degree, but it's still not random. For most
practical purposes, a well written LFSR (for one example) models
randomness well enough that breaking such encryption is relatively
rare, but it IS still (at least theoretically) possible. To truly
guarantee against any possibility of the cipher being broken, the key
stream must be really and truly random.
------------------------------
Date: Thu, 24 Jun 1999 04:43:58 -0400
From: [EMAIL PROTECTED]
Subject: Re: one time pad
Jerry Coffin wrote:
>
> In article <7krli9$jqr$[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
>
> [ ... ]
>
> > First, in my first post, I used the term "statistical" randomness. It
> > is a term I received when reading about PI, which is supposively the
> > most statistically random sequence of digits known to man. By this, it
> > is ment that the digits are generally well distributed, and that they
> > occur approximately as often as each other- that 1' occur as
> > frequently, as 2's which occur as frequently as..., you get the idea.
>
> Right -- I'm not sure it's statistically any more (or less) random
> than lots of other transcendental numbers though -- I've never tried
> to do a direct comparison, but I'd be a bit surprised if you could
> find much in the way of long-term patterns in something like the
> square root of 2 or 10. More or less by definition, any
> transcendental number is going to lack any real pattern...
Check out the "continued fraction" representation of sqrt( 2 ). I was
surprised to find it qute regular.
>
> > Also, a OTP's strength is entirely found in the fact that given a
> > cipher stream only, any plain text stream is an equal candidate to be
> > the true plain text.
>
> Quite true.
>
> > Now to the point. If we say that a OTP has truly random values and
> > that the pad's contents are totally independent of each other, then
> > there is the extremely low possibility for a series of bits to display
> > a pattern, though the pattern may never occur again. For example,
> > there could occur a series of BYTE values 0xa7 (or any value) that
> > repeats, say, 100 times.
>
> Yup, it can (at least appear to) contain a pattern. I won't try to
> get into the (more or less meaningless) discussion of whether it
> constitutes a pattern if it happened by accident or not.
>
> > I proposed this ment nothing, until someone disagreed with me and
> > advocated I turn to this forum for advise and insight. So I ask you,
> > does it make sense that randomness is a requirement, that patterns must
> > be avoided, in building a one time pad?
>
> NO -- if you avoid any particular set of possibilities, and the
> attacker can find the possibilities you've avoided, then he's found at
> least some limit on the possibilities for the plaintext. This isn't
> likely to be a useful attack in most cases, but if you pick out enough
> things as looking like patterns, and refuse to use them, you could (at
> least theoretically) eliminate enough for the attacker to decrypt a
> few small bits of what you've encrypted.
>
> > It appeared to me that this individual is correct. For example, if you
> > take a long sentence of 100 characters and you apply the segment of the
> > pad to it and someone guesses that the segment is in fact all 0xa7,
> > then one would have to conclude that the proposed candidate is indeed
> > the plain text because the odds against it appear astronimcal.
>
> The problem is that the attacker has no more reason to believe that
> you've used a segment containing a repeating character than another
> set of characters of the same length. He can guess that it's all 0xa7
> and it might decrypt to something reasonable. However, by using other
> keys, he can decrypt the same ciphertext to every other plaintext he
> considers reasonable.
>
> > so I wonder now just how much relationship must occur in build a pad.
> > It seems that weak statistical randomness must be employed if nothing
> > else but to prevent this scenario.
>
> I disagree. If, for example, 0x00 appears 20 times in a row, then the
> plaintext for those 20 characters will show up in the ciphertext. The
> problem is that the attacker has NO way of guessing that this is
> really the correct plaintext. Without knowing up-front that there's a
> 20-byte run of zeros in the key, he has no more reason to guess the
> plaintext is showing through unchanged than any other run of 20
> characters.
>
> Another poster (at least I don't think it was you) recently asked
> about using this to feed misinformation to the enemy. If you had a
> truly secure channel, you could do this pretty easily. Start with a
> (presumably false) message you want to send to your enemy. You can
> then pick out a key that will decrypt this to a different message of
> the same length. You can then transmit the false message as
> plaintext, and (with a little luck) your enemy may assume it was sent
> un-encrypted entirely by accident. The intended receiver, however,
> knows to decrypt it with the secretly transmitted key, and gets the
> correct message.
>
> If you make only a few judicious changes between the two messages,
> with most bytes identical between the two messages, then the key that
> has to be transmitted secretly will contain mostly zero bytes. Even
> if you use something as simple as run-length encoding on the key, it
> will then be considerably smaller than the entire message, so it can
> then be transmitted by a secure channel of much lower bandwidth.
> Ultimately, the real key might consist of nothing more than the
> position in the openly transmitted message at which "not" will be
> inserted. In this case, the key might be transmitted by an
> _extremely_ low-bandwidth medium, which might render the entire scheme
> quite practical.
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: On an old topic of internet publication of strong crypto
Date: Thu, 24 Jun 1999 12:27:56 -0400
Mok-Kong Shen wrote:
>
> The topic or viewpoints below are (almost quite) old but I do
> like to have some discussions thereon in view of the fact that (as
> I learned recently from posts elsewhere) there is a probability
> that the Bernstein case be re-opened in the near future.
>
> My question: Would the following scenario be of some significance
> to the issue of prohibition of internet publication of strong crypto?
>
> An author writes a paper on strong crypto. He claims copyright on it
> but at the same time states that any copying is free provided that
> the copy is done in its entirety (which means that in particular
> any copy contains his name). He sends that in paper form to a
> server located in a country without crypto regulations where it
> is, after scanning or otherwise, published as a web page (for a
> short time so that the server need not have a huge capacity for
> serving lots of people for such purposes). The author then imports
> his own writing from that server via internet and puts it on his site,
> stating that the material has been imported from that server on
> such and such a date.
You seem to be assuming that there are problems with publishing
papers about crypto. In the US anyway I don't think that is true.
It was tried, but that attempt was defeated.
> Would that be o.k., since the author is not exporting but only
> redistributing something that he has imported from a foreign
> country?
Not necessarily. If you were talking about software rather than
something like a scientific paper, it doesn't matter to the US
that it came from elsewhere: once you bring it in you can't send
it back out.
paul
PS. IANAL, so apply suitable amounts of salt to the above.
------------------------------
** 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
******************************
