Cryptography-Digest Digest #957, Volume #9 Fri, 30 Jul 99 22:13:03 EDT
Contents:
Re: How Big is a Byte? (was: New Encryption Product!) ("Tony T. Warnock")
Re: Is breaking RSA NP-Complete ? (Peter Pearson)
Re: (Game) 80-digits Factoring Challenge (Keith Ellul)
Re: How Big is a Byte? (was: New Encryption Product!) (John Myre)
Re: cryptography tutorials ([EMAIL PROTECTED])
Re: (Game) 80-digits Factoring Challenge (Jim Gillogly)
Re: cryptography tutorials (John Savard)
Re: Bad Test of Steve Reid's SHA1 ([EMAIL PROTECTED])
Hash (One-Way) Functions ([EMAIL PROTECTED])
Re: cryptography tutorials (John Savard)
Re: Looking for RC4 alternative ([EMAIL PROTECTED])
Re: Prime numbers wanted ("Kasper Pedersen")
Re: Hash (One-Way) Functions (wtshaw)
Re: With all the talk about random... (Frank Kienast)
Re: How Big is a Byte? (was: New Encryption Product!) ("Douglas A. Gwyn")
Re: How Big is a Byte? (was: New Encryption Product!) ("Douglas A. Gwyn")
Re: SSL vs TLS (Eric Young)
Re: OTP export controlled? (wtshaw)
Re: OTP export controlled? (John Savard)
----------------------------------------------------------------------------
From: "Tony T. Warnock" <[EMAIL PROTECTED]>
Crossposted-To: alt.folklore.computers
Subject: Re: How Big is a Byte? (was: New Encryption Product!)
Date: Fri, 30 Jul 1999 11:12:55 -0600
Reply-To: [EMAIL PROTECTED]
>
> >> >The problem with this is that array[0] is the first item.
> >>
> >> Only in C and its descendants; in Fortran, if I recall properly, array(1)
> >> is the first item.
Actually Fortran has has arbitrary lower and upper bounds for arrays since the
1977 standard.
I've used things such as D(-1:1,-1:1), etc in PDE's.
------------------------------
From: Peter Pearson <[EMAIL PROTECTED]>
Subject: Re: Is breaking RSA NP-Complete ?
Date: Fri, 30 Jul 1999 09:27:22 -0700
Anton Stiglic wrote:
>
> Bob Silverman wrote:
>
> > In fact there are several well known crypto systems (e.g. Chor-Rivest,
> > Ajtai-Dwork, and other knapsack related problems) that are known to be
> > NP-Complete.
>
> I am not an expecrt in these cryptosystems, so I'll just give references:
>
> "Most encryption algorithms based on the knapsack problem are breakable",
> see
> Brickel, "The cryptanalysis of knapsack cryptosystems", R.D. Ringeisen
> and F.S.
[and on and on and on]
In the interest of precision, please note that Bob Silverman's original
objection was to the following assertion, which you, Anton Stiglic,
made:
No, it is not NP-Complete. In fact, there is no crypto-system that is
based on an NP-Complete problem.
To make such an assertion with honest confidence, one would have to
have an awesome familiarity with the field, which I don't believe you
care to claim. Furthermore, the alert reader will note that this
assertion cannot be proven by testimony about the difficulty of
producing such a cryptosystem, nor by listing examples of weak
cryptosystems.
>
> P.s There is noting I hate more than people having super-egos blasting away
> on news groups,
> news groups are supposed to be a place for discussion, not blasting away
> one's ego. In my INITAL
> post, I pre-appologized for not having the correct terms on hand, and then
> gave a reference. Read
> the reference before replying back, and help promote a deascent discussion
> enviroment on this news
> group.
Don't be discouraged. Being flamed by Bob Silverman is not proof
of irremediable imbecility.
- Peter
------------------------------
From: [EMAIL PROTECTED] (Keith Ellul)
Crossposted-To: sci.math
Subject: Re: (Game) 80-digits Factoring Challenge
Date: Fri, 30 Jul 1999 17:46:40 GMT
On Thu, 29 Jul 1999 17:42:14 -0700, "Dann Corbit"
<[EMAIL PROTECTED]> wrote:
>It's not a prime. But factoring it will require Quadratic Sieve, NFS, or
>ECPP or some other big hammer. The simple algorithms all fail. It would
>factor overnight on one of the workstations I have here. But I echo Bob
>Silverman's question: "Why should I want to factor this number when I can
>just as easily come up with a similar value that would be tough to factor?"
>Is it a Charmichael number? Some other type of special pseudo-prime? What
>brings this number to the fore as opposed to some other?
Hmm.. when's that TWINKLE box going to hit the market? ;-)
-Keith!
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: How Big is a Byte? (was: New Encryption Product!)
Date: Fri, 30 Jul 1999 11:56:58 -0600
Patrick Juola wrote:
<snip large discussion of C etc.>
Did this push a "hot button" of yours? Did you forget
yourself and try to educate someone via Usenet?
Oh, well, *I* enjoyed it.
John M.
(The choir)
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: cryptography tutorials
Date: Fri, 30 Jul 1999 14:11:54 -0400
> http://www.ecn.ab.ca/~jsavard/crypto.htm
Dude OUCH!
Your page hurts my eyes. =)
But nice site.
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Crossposted-To: sci.math.symbolic
Subject: Re: (Game) 80-digits Factoring Challenge
Date: Fri, 30 Jul 1999 11:18:26 -0700
Graham Matthews wrote:
>
> kctang posted:
> >Please factorize the 80-digits number:
> >
> >256261430091697968103677033465028955910<continue at next line>
> >15360341017076023809547878443033203276429
>
> A factorisation of his number is,
>
> [ <390347485656505685796633763675565645387, 1>,
> <65649565965745836645455485654584436466567, 1> ]
>
> This factorisation was done with Magma using the STANDARD Factorisation()
> function. Hence I gave only the number as argument to the factorisation
> and relied on Magma to intelligently select factorisation algorithms and
> relevant parameters for whatever algorithms it selected.
>
> The time taken to produce the above factorisation was
>
> Total time: 36462.739 seconds
>
> The timing was done on a big UltraSparc computer. I have no idea how
Good job, Graham -- Magma must have some good stuff in it.
I was burned once when posting the solution to one of the challenges
posted here on sci.crypt -- the poster used the solution to infringe
on someone else's privacy. There was little motiviation provided
this time, so I might have demonstrated success by giving the last 5
or 6 digits of each number rather than giving the complete
factorization, and waited for more information on provenance before
blowing it all. Guess I'm getting paranoid.
Well, kctang? Did you learn what you needed? What insights resulted
from the experiment, and how do you propose to use them? I figure you
owe that much information for 10 hours of computing effort.
--
Jim Gillogly
7 Wedmath S.R. 1999, 18:09
12.19.6.7.5, 10 Chicchan 13 Xul, First Lord of Night
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: cryptography tutorials
Date: Fri, 30 Jul 1999 19:21:21 GMT
[EMAIL PROTECTED] wrote, in part:
>> http://www.ecn.ab.ca/~jsavard/crypto.htm
>Dude OUCH!
>Your page hurts my eyes. =)
>But nice site.
Thanks for the feedback. I've recently tried to modify the page to
make it more "snazzy", using white printing on a black background for
part of the home page to suggest the "mysterious" nature of secret
codes.
If you look at the HTML, you'll find that since I use different
commands to set up the white-on-black and blue-on-orange areas (the
default for the whole page is blue-on-black) I chose the four colors
so as to have *some* degree of readability even in the case of a
partial failure of the commands in some browsers. (But if you're in
16-color mode with a B&W screen, I don't think I can help.)
Earlier, I had some negative feedback on my polyalphabeticity page
http://www.ecn.ab.ca/~jsavard/pp010103.htm
because the background there impaired readability; I've changed the
backgrounds to lower their contrast considerably not long ago, so I
hope the body of my site, even when I use backgrounds, is reasonable.
But I know that front page is perhaps a bit much. (And, of course, I'm
also using rather more typefaces on that page than the canons of good
taste allow...)
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Bad Test of Steve Reid's SHA1
Date: Fri, 30 Jul 1999 19:12:16 GMT
Thanks to Jerry Coffin (http://www.itl.nist.gov/fipspubs/fip180-1.htm),
D. L. Keever (VC++ version of Mr. Reid's algorithm), Robert G. Durnal
(DOS SHA-1 code), and Bob Dellaca for their helpful replies to my
posting. Thanks especially to Bob Dellaca who pointed me to a copy of
Steve Reid's SHA-1 implementation, at
http://ftp.funet.fi/pub/crypt/hash/sha/sha1.c, that works (was exactly
the same as the one on Mr. Schneier's diskette less a typo).
So far no-one has told me what LITTLE_ENDIAN does. Does it refer to
one of the alternate methods referred to as 7. and 8. on the NTIS site
(thanks to Jerry Coffin for that URL)? I would assume not since, as D.
L. Keever mentions, you do need to define LITTLE_ENDIAN to get the
right digest. Or does it refer to the "technical correction" that
generated SHA-1 (FIPS 180) in the first place? Something else? Just
curious.
Again, thanks, you four.
Rob Rohrbough
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Hash (One-Way) Functions
Date: Fri, 30 Jul 1999 15:50:17 -0400
Ok, I have a question:
I am not sure about MD5, but SHA can take an input of over 1000
characters long. The digest of this input is only 20 characters
long...now if these algorithms have very few collisions, how is it
possible for a inputs over 1000 characters long to all have a unique
hash only 20 characters long?
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: cryptography tutorials
Date: Fri, 30 Jul 1999 19:37:49 GMT
[EMAIL PROTECTED] (John Savard) wrote, in part:
>[EMAIL PROTECTED] wrote, in part:
>>Dude OUCH!
>>Your page hurts my eyes. =)
>>But nice site.
>Thanks for the feedback. I've recently tried to modify the page to
>make it more "snazzy", using white printing on a black background for
>part of the home page to suggest the "mysterious" nature of secret
>codes.
I've now modified the page. One white on black area is still present,
but now it is in a table instead of being the main page; now that I
understand cellpadding I can achieve a reasonable effect this way. And
the light background is buff instead of orange. So the index page
should be easier on the eyes.
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Looking for RC4 alternative
Date: 30 Jul 1999 20:45:16 GMT
A little while ago I posed the following question on coderpunks:
In the first line of RC4:
i = (i + 1) mod 256
'i' cycles through 256 values.
If we add in an odd number, 0 < r < 256, ie:
i = (i + r) mod 256
'i' also cycles through 256 values - but in a different sequence.
Do these new 127 variants of RC4 behave in a similar way with
regard to cycle length and precautions regarding the key set-up?
The renowned Anon replied:
Probably so. Consider setting r = 3 for specificity. Then you
have i = i + 3, j = j + s[i].
This should be similar to regular rc4 with i' * 3 = i and
j' * 3 = j, and all array elements s'[i'] * 3 = s[i]. (This is
just a permutation of the s array and a change in i, j.) These
relationships should be maintained across the state
transformation i' = i' + 1, j' = j' + s'[i]'.
The output will be different, because s[s[i]+s[j]] will not be
the same as s'[s'[i']+s'[j']]. But the basic characteristics of
the cipher, in terms of cycle length, digraph frequencies, etc.,
should be the same.
Also Ian Goldberg commented:
It's fairly easy to see that the byte generation parts of RC4 and
your variant (call it RC4(+r)) are in fact isomorphic:
Suppose after key setup, the array contains values
S[0],...,S[255].
Define an array T by T[i] = S[r*i]/r. (All computation mod 256,
of course.)
It's easy to see that running RC4(+r) on the array S will give
equivalent results as running RC4 on the array T. (Here,
"equivalent" means "scaled up by the constant factor r"; that is,
the nth byte output from running RC4(+r) on S is x and if the nth
byte output from running RC4 on T is y, then x = r*y (mod 256).)
So with regard to cycle length, RC4(+r) is obviously equivalent
to RC4.
Now the key setup depends on whether you change the i+1 in that
part of the code to i+r as well. In any event, it won't be
fundamentally different (but I haven't thought about this part
too much).
So if you believe that given a few hundred bytes out output of
RC4, you can recover the initial state of the S array, whatever
it happened to be, then RC4(+r) is of exactly the same strength
as RC4.
On the other hand, if you believe that the key-setup part of RC4
is the weak bit (so that the arrays S that result from RC4's key
setup routine are in some sense easier to break than starting
with random permutations for S), then RC4(+r) may be stronger,
since it produces a different (though related) set of initial
arrays S.
I later commented:
In the line:
t = (S[i] + S[j]) mod 256
the 'a+b' operation could be replaced by 'a-b', 'b-a' or
'a XOR b' with presumably the same result. (This part seems to
be a crude one-way function for extracting the output that does
not effect the generator's internal state)
moreover, in the line:
j = (j + S[i]) mod 256
it may be possible to replace the '+' operator in a similar
fashion. If so, this gives us a family of 2048 generators that
could be selected by using key bits.
Modifications such as these should be enough to avoid serious
legal problems 8-)
Keith
------------------------
'Unwise a grave for Arthur'
-- The Black Book of Carmarthen
------------------------------
From: "Kasper Pedersen" <[EMAIL PROTECTED]>
Subject: Re: Prime numbers wanted
Date: Fri, 30 Jul 1999 22:38:24 +0200
Vincent <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Hello guys and girls,
> Here is my "problem" :
>
> Is there any faster algorithm than the following one, which, given an
(odd)
> number n, returns the first prime number p>=n ?
> Assuming that I have a function is_prime tellimg me if a number is (or has
> enough odd to be) prime (The Miller-Rabin test).
> int My_Simple_Algorithm (int n)
> {
> int temp=n;
> while (!is_prime(temp)) temp+=2;
> return(temp);
> }
A long time ago I and a group of other assembler nerds had a small contest
for fun: Who can count the number of primes from 2 to 10^9 fastest on a
8088-5 with 8K RAM?
I won with a routine nicknamed 'WiteSkip 1G'. I used a hardcoded stepping
table that stepped your 'temp' variable to 'the next number that isn't
divisible by the 6 lowest prime numbers'. This avoids testing the lower
primes.
(The is_prime part was fun. There were 52 bytes free RAM.)
I have a demonstration version for '386/C lying around somewhere.
/Kasper Pedersen
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Hash (One-Way) Functions
Date: Fri, 30 Jul 1999 16:44:37 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
> Ok, I have a question:
> I am not sure about MD5, but SHA can take an input of over 1000
> characters long. The digest of this input is only 20 characters
> long...now if these algorithms have very few collisions, how is it
> possible for a inputs over 1000 characters long to all have a unique
> hash only 20 characters long?
It isn't.
--
It is fine and dandy to choose to serve the government. It is fine
and dandy to obtain government services. It is still another thing
to find some in the crypto field have been serviced by government,
with contemplations of how they might do it better in the future.
------------------------------
From: Frank Kienast <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: With all the talk about random...
Date: Fri, 30 Jul 1999 19:15:19 -0500
Interesting. After purchasing an 8086 PC eleven years ago, I began
writing my own programs (in BASIC) for home use. One of them was an
encryption program, used for personal (diary-type) stuff. I knew little
to nothing about cryptography, but I had thought of the idea of simply
generating a random series of 1-byte numbers and adding them to each
letter in the text I
wanted to encrypt.
The algorithm went as follows:
1) Based on the key entered, generate a hash value between 0 and 1.
This becomes the seed.
2) Multiply this seed by 256 and add to the letter being encrypted in
the
text, "wrapping" if necessary. Actually, I used some smaller number to
confine the range to standard ASCII characters so I could look at the
encrypted file and determine what the text "looks" like, but I don't
remember the specifics and its not important here.
3) To generate the next seed, I used an old algorithm I had seen in
programmable calculator programs years earlier:
Add PI to the seed. Raise result to 5th power. Chop of whole number
part, leaving just the decimal part (between 0 and 1) as next seed.
I knew enough not to use the same key more than once. I didn't know why
then; I had just heard somewhere that you should never re-use keys. Now
I know the reason. If someone has access to multiple texts encrypted
with the same key, they can do a frequency analysis on each letter
position and determine the random number that is being added in that
position. But perhaps the method I used to come up with
easily-rememberable multiple keys is still of some interest. I picked a
secret word and appended the date in my own "weird" format. I could
later look at the (DOS) date on the file and figure out what key I
needed to use. For example, I might use the key "secret19990730" today
since today is July 30th, 1999.
I also knew that disk (actually, floppy at the time!) files could be
recovered once deleted, so I made the program interactive (encrypts one
line of text at a time as soon as you hit the <Return> key; no way to go
back to previous lines but was OK for diary-type writings).
For added security I even saved the program in unlistable form from
BASIC (kept an encrypted copy of the code itself in case I ever wanted
to make changes). I now realize that this was trying for "security
through obscurity", which does not work, not to mention the fact that
I'm sure there were also ways around "unlistable" code.
Anyway, over the course of several years I had a couple hundred files
encrypted in this way. There were a few files that I later found I
could not recover, because I apparently had made a typo when entering
the password (the program did not make you enter the password a separate
time for conformation).
Three years ago over the Christmas holidays I decided to try to recover
these several "lost" files. I found the original program, and installed
BASIC on my (486)PC. To crack the files, I decided to cycle through
ranges of the seed number space, trying to get to the hash by brute
force. I thought about ways to detect when decryption was successful,
and finally settled on counting the number of space characters found in
the file (I figured space would be a common character in files).
Surprise! After trying just a few hundred seeds, my cracking program
started beeping at me (I had programmed it to do this when it found a
large number of space characters using a particular seed). Turns out
that when I had written the original program years earlier, I had
neglected to declare the variables I was using to generate random
numbers as double precision. By default, they ended up single
precision. And they were recycling after about 300 characters!
Needless to say, I easily cracked all the "lost" files.
For fun, I did try changing all my variables to double precision and
tried to break it again. This time, after trying different seeds for
half a day, it still had not been broken. I'm sure, though, that on a
faster computer (or even just using a faster language such as C), one
could easily do a brute force attack on all the possible seed numbers
that can be represented in a double precison number.
That just goes to show that it is easy to develop a false sense of
confidence in algorithms that are in fact not secure at all (due either
to the algorithm itself being poor, or subtle errors in implementation).
Anyway, I'm sure I haven't said anything that most people in this group
don't already know, but I thought it might be an enjoyable little story
anyway.
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.
Frank Kienast
> The random() generator used in Borland C++ is
> s:=(s*134775813+1) mod 2^32
> When you use it in the form random(256), you get the most significant 8 bits
> of s.
> To crack a junk-OTP with this generator, I'll guess a single letter, maybe
> 'e'?
> Then there are 24 bits left. The simplest is to run through 16M
> possibilities, it takes less than a second per character. Assuming there are
> 20-non-'e' letters before the 'e', I have to wait 20 seconds for it to crack
> (checking that the output is ascii characters).
>
> When you have s, it's broken.
> To turn it around, random() is as weak as it can possibly be.
> To get that OTP, you need a real source of random numbers.
>
> /Kasper Pedersen
------------------------------
Crossposted-To: alt.folklore.computers
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: How Big is a Byte? (was: New Encryption Product!)
Date: Fri, 30 Jul 1999 20:05:56 GMT
Patrick Juola wrote:
> No, the reason for this is that the semantics of C-style arrays are
> defined as syntactic sugar over a pointer access. Which is one of
> the most serious security/reliability holes in C/Unix.
There is no necessary connection between the two.
It is easy to avoid accessing beyond the bounds of arrays
in C (on UNIX or otherwise), and failure to do so is a
problem with the programmer, not the language per se.
------------------------------
Crossposted-To: alt.folklore.computers
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: How Big is a Byte? (was: New Encryption Product!)
Date: Fri, 30 Jul 1999 20:07:20 GMT
[EMAIL PROTECTED] wrote:
>> [BK's] answer to the question of what he'd change if he had to do
> it all over again that that he would leave the E in the function
> creat().
That was Ken Thompson, not Brian Kernighan.
------------------------------
From: Eric Young <[EMAIL PROTECTED]>
Subject: Re: SSL vs TLS
Date: Sat, 31 Jul 1999 11:59:16 +1000
Bjoern Sewing wrote:
> can anyone tell me the differences between
> SSLv3 and TLSv1 ??
Not very much. Think of TLS v 1 as SSL v 3.1.
The changes that I can remember off the top of my head...
- Version number is 0x0301 instead of 0x0300.
- When requesting a client certificate, if the client cannot return one,
it returns a 0 length certificate list (and no verify message),
not a no-cert alert as in SSLv3. (minor protocol cleanup).
- Use HMAC for the mac algorithm. (security improvement but larger
CPU overhead).
- A different algorithm for generating session keys from the master
secret.
- TLS will not allow Ephemeral RSA when the server has a signing only
certificate. (The loss of ephemeral RSA I consider bad, in some
ways RSA export ciphers are stronger than non-export RSA because
if the server has a > 512 bit key, there will be a separate encryption
RSA key).
- alert message codes are greatly expanded.
- TLS ignores unknown record types (future expansion).
- TLS does not mind if there is extra data on the end of the client
hello message (future expansion)
- The block cipher padding can now be upto 256 bytes.
I would say that the biggest practical change between TLS and SSL
is the name.
If seem to remember that it took 3 days to put TLS into SSLeay.
eric ([EMAIL PROTECTED] | [EMAIL PROTECTED])
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Crossposted-To: talk.politics.crypto
Subject: Re: OTP export controlled?
Date: Fri, 30 Jul 1999 15:59:28 -0600
In article <wgu20.933332369@riemann>, [EMAIL PROTECTED] (W.G.
Unruh) wrote:
> "Douglas A. Gwyn" <[EMAIL PROTECTED]> writes:
>
> >It is ludicrous to think that export regulations can really keep
> >foreigners from implementing decent encryption.
>
> Not their purpose. Their purpose is to pervent US residents from providing
> foreigners with decent encryption. What the foreingners do on their own
> is not a purpose of the regulations.
Then, apparently, the regulations are aimed at citizen behavior and not a
foreigners' behavior. It would fit in with cooperation with other
governments to manage their own people accordingly, and finish the job by
circumventing the laws of various countries in a conspiracy of reciprocal
monitoring.
In any other case, a conspiracy means that those cooperating are one, that
those who exchange information are responsible for the acts of and act as
agents for those who circumvent any country's laws.
And, decent encryption is bound to become available everywhere, one way or
the other. The justifications of these regulations simply do not fly
since they are targeted at citizens rather those the government would
otherwise say they are most afraid of, foreigners. Plus, it is the
various conspiratorial governmental bodies that are the first to exchange
the types of technology that they really don't want in the hands of their
various populations anyway.
Remember the mandate given AES, to produce good encryption with no back
doors. I have said, be careful, you might get what you asked for. And,
the technical spiggot to produce newer and better forms of encryption is
not to be turned off on a whim or in a panic as people remember why they
must have it, according to government pronouncements.
--
Beware of quick sounding solutions to counter threats that are
said to endanger our freedoms if they tamper with those same
freedoms.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Crossposted-To: talk.politics.crypto
Subject: Re: OTP export controlled?
Date: Fri, 30 Jul 1999 22:03:20 GMT
[EMAIL PROTECTED] (W.G. Unruh) wrote, in part:
>"Douglas A. Gwyn" <[EMAIL PROTECTED]> writes:
>>It is ludicrous to think that export regulations can really keep
>>foreigners from implementing decent encryption.
>Not their purpose. Their purpose is to pervent US residents from providing
>foreigners with decent encryption. What the foreingners do on their own
>is not a purpose of the regulations.
The regulations, being enacted by a body without the necessary
jurisdiction, do not limit what foreigners can do on their own.
However, the _purpose_ of the regulations is clearly to ensure
foreigners will have and use less powerful encryption, even if
regulating the help US residents can give them is a very limited and
inadequate means to that end.
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
** 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
******************************
