Cryptography-Digest Digest #322, Volume #11 Mon, 13 Mar 00 12:13:01 EST
Contents:
can you decypher for me? ([EMAIL PROTECTED])
Re: Protocol question -- detecting patching of software (Mark Currie)
Re: MD5 collisions ("Tom St Denis")
Re: Passwords secure against dictionary attacks? (Alan J Rosenthal)
Re: How does % operator deal with negative numbers? (Bob Silverman)
Re: Random permutations (Tim Tyler)
Re: Q: Voice encryption (Mark Currie)
Re: How does % operator deal with negative numbers? ([EMAIL PROTECTED])
Re: Random permutations (Scott Nelson)
Re: CRC-16 Reverse Algorithm ? (Terry Ritter)
Re: sci.crypt.applied (Mark Currie)
Re: Magnetic Remenance on hard drives. (was: Re: Evidence Eliminator - ("Thomas J.
Boschloo")
Re: Just *Germain* primes (Paul Koning)
Re: ascii to binary (Paul Koning)
Re: US export status of RC4? (Paul Koning)
Re: US export status of RC4? (Paul Koning)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: can you decypher for me?
Date: Mon, 13 Mar 2000 14:59:18 GMT
I'm looking for an experienced cryptoanalyst to decypher some text for
me. I live in the UK and would welcome help from an expert. Email me
if you can help or if you know someone who can
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Subject: Re: Protocol question -- detecting patching of software
From: [EMAIL PROTECTED] (Mark Currie)
Date: 13 Mar 2000 15:21:00 GMT
Hi,
Maybe the answer is to design the game such that the "cheatable" parts
are done by the server, which the players have to trust as being fair. Without
knowing how the game works it is difficult to see if this is possible, but I am
merely pointing out another approach since the issue of detecting whether the
client software has been tampered with is an extremely difficult problem as was
pointed out by Paul Rubin.
Mark
In article <38c5b384$0$[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
>
>Hi all; here's a puzzler that's been nagging me for a few days:
>
>You have a multi-player game, where the players run a copy of
>the game on their own computer, and play over the net, connected
>to a server.
>
>It's possible to cheat by patching your copy of the game.
>
>Is it possible to design a protocol by which the server could
>challenge the user's software to ensure that it hasn't been
>modified?
>
>I know someone who did this many years ago by having the software
>execute a checksum on itself and verify the results. Theoretically,
>any tampering with the program would ruin the checksum and bust
>the tamperer. Of course, the tamperer could also patch the checksum
>routine. My friend worked around this problem by having eight
>different checksum routines in different parts of the program.
>The idea was that the tamperer wouldn't find all eight checksums
>and would miss at least one, thus getting busted. This is
>security-through-obscurity, however -- not a real solution.
>
>I'm trying to decide if there's a better way to do this. What I've
>got so far is this:
>
>* Program code contains a cryptographically secure checksum algorithm.
>
>* Server issues a challenge that says: Here is an initialization
> vector. Compute your checksum and send the result back to me.
>
>
>This doesn't work either though, as the tampered program merely
>keeps an untampered copy around and computes the checksum on that.
>Obviously, the checksum will have to include some sort of dynamic
>but known-to-the-server state. If the program is a game, the
>checksum could be computed based on the initialization vector, the
>program code, and the current game state. This still has holes in
>it though.
>
>
>Any thoughts on this?
>
>--
>-ed falk, [EMAIL PROTECTED] See
*********************#*************#*
>http://www.rahul.net/falk/whatToDo.html
#**************F******!******!*!!****
>and read 12 Simple Things You Can Do
******!***************************#**
>to Save the Internet **#******#*********!**WW*W**WW****
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: MD5 collisions
Date: Mon, 13 Mar 2000 15:33:35 GMT
SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]> wrote in message
news:8aiv5v$2ees$[EMAIL PROTECTED]...
> In article <9V5z4.14381$[EMAIL PROTECTED]>, "Tom St Denis"
<[EMAIL PROTECTED]> wrote:
>
> One of the measures of a hash would be the fact that there are few
> collisions for short strings. Why this is important seems to allude TOM
> but assuming you have a good hash that hashes to 128 bits. Then as
> Tom stated if the strings you are hashing are 256 bits then there will be
> many possilbe collisions. One way to reduce the collsions would be to
> use a conditional compressor like you find at my site. No wasted bits
> you just compress to a smaller string based on the subset of characters
> used in the 256 bit string.
We are talking about hashing here. And of course your compressor has no
collisions. IT IS A FUNCTION. Hashing is something entirely different.
And if collisions are hard to predict, that assumes there are a FEW NUMBER
OF THEM. Which you missed as well.
You seem to miss the point of compression, encryption and hashing all
together.
Compression: Make things smaller
Encryption: Randomize things
Hashing: identification, mixing
In many cases it's required to have fixed size outputs from the hash. And
it's entirely possible to find fixed size collisions while using any
compression codec.
Tom
------------------------------
Crossposted-To: comp.security.misc,alt.security.pgp
From: [EMAIL PROTECTED] (Alan J Rosenthal)
Subject: Re: Passwords secure against dictionary attacks?
Date: 13 Mar 2000 15:09:54 GMT
[EMAIL PROTECTED] (Alun Jones) writes:
>Good hash functions are excellent for verifying passwords, since they are
>not generally reversable (any function where two items can produce the same
>result cannot be reversed with any simplicity)
Thanks for your good explanation; here's where I pick the nit. (Certainly
easier than writing the explanation in the first place!)
Just because the hash of two items can be equal doesn't mean that the
hash function is not reversible, where reversible is of course defined
as computing *any* of the several inputs which hash to the desired value
(with the more direct definition it's impossible, but only in a silly sense,
because any of the multiple reversals will constitute an active password).
For example, consider a hash which just takes the first character of the key.
This is used in some computer language processors (although not generally
in good ones, because simply summing the ascii values of the entire string
mod something is better and not particularly more complex, but anyway...).
This is trivially reversed by just choosing any word which begins with the
given letter.
So if this hash were used as a password hash, if you saw the hashed password
then it would be easy to compute a password which would work when typed at
the Password: prompt (even though you might not arrive at the password the
user actually used).
Of course you wouldn't use such a hashing scheme and call it an "encryption"
of the password, but that's just because it's obvious that it's reversible.
In other cases, such as what amounts to a known-plaintext attack on DES^25,
it is not as obvious whether or not it's reversible, and the simple fact that
it is not one-to-one does not give you any assurance that it's not reversible.
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.javascript
Subject: Re: How does % operator deal with negative numbers?
Date: Mon, 13 Mar 2000 15:58:00 GMT
In article <[EMAIL PROTECTED]>,
Frank <[EMAIL PROTECTED]> wrote:
> I'm trying to write some non-kludgy JavaScript for a simple
> cryptography demonstration. One of the encrypt steps adds
> key%97, so the obvious decrypt step should be (-1*key)%97.
>
> In standard mathematics, -4 modulo 97 should equal 93.
Not quite. The integers mod 97 form *equivalence classes*.
-4 mod 97 is *equivalent* to 93 mod 97, but not equal.
> Instead, Netscape returns -4, Explorer returns 4.
> What's the deal? Is this going to be a royal pain?
Yes. It is going to be a royal pain. There is NO standard
in C or C++ for a % b when b is negative. It will be
compiler and machine dependent. OTOH, it is well defined
(and should not matter to you) how to handle a % b when a is
negative and b is positive. both -4 mod 97 and 93 mod 97 are
in the same equivalence class, so either is correct.
You may want to deal only with positive numbers; if so it is easy
enough to do
if (s = (a % b) < 0) s = b + s;
>
--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Random permutations
Reply-To: [EMAIL PROTECTED]
Date: Mon, 13 Mar 2000 16:07:07 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:
:>
:> With the latter method, if the range of the RNG is not large enough,
:> you will /sometimes/ get collisions among the RNG output - which will
:> probably translate into some residue of the initial non-random
:> configuration making its way into the final permutation.
:>
:> If this is true, it would be a relatively small imperfection.
: The integer-valued random numbers have normally a large range.
: Even if there are collisions, I don't think that it matters.
: I base my consideration on the fact that a random vector (with
: discrete values) in an n dimensional space does not need to have
: all its elements distinct. (In fact such a constraint would render
: that vector non-random.) But maybe you see some points that I
: am not aware.
Maybe I do. A minature example should be sufficient to illustrate them:
Consider a permutation of two items {A, B}, using a RNG with four possible
states: {0,1,2,3}, which guide a bubble sort routine:
Initial | Random index | Permutation after sort
A B 0 0 A B
A B 0 1 A B
A B 0 2 A B
A B 0 3 A B
A B 1 0 B A
A B 1 1 A B
A B 1 2 A B
A B 1 3 A B
A B 2 0 B A
A B 2 1 B A
A B 2 2 A B
A B 2 3 A B
A B 3 0 B A
A B 3 1 B A
A B 3 2 B A
A B 3 3 A B
The bubble sort is "lazy" - i.e. it only swaps items if it has to.
You will see that for all possible values of the random index,
"A B" occurs 10 times, while "B A" only occurs 6 times. Not balanced :-(
Clearly this problem diminishes with the size of the range of the RNG.
It does not depend much on the sort used - all types of sort are going to
do something non-random when presented with repeated entries - and it
would be a bit of a fluke if the sort routine happened to deskew the
results.
The problem becomes significant shortly after the "birthday" point - i.e
with a 32 bit RNG you'd need to permute over 100,000 elements before you
noticed very much that was statistically significant.
You /could/ totally eliminate this problem - for example by discarding any
runs with duplicated values - if you were concerned about it producing
biased results.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
I came. I saw. I stole your tagline.
------------------------------
Subject: Re: Q: Voice encryption
From: [EMAIL PROTECTED] (Mark Currie)
Date: 13 Mar 2000 16:16:05 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
>
>John Savard wrote:
>>
>> Mok-Kong Shen <[EMAIL PROTECTED]> wrote, in part:
>>
>> >I like to know whether there are reasons against using both
>> >techniques simultaneously.
>>
>> Usually, for digital voice encryption, a vocoder-like technique, such
>> as CELP, is used to digitize the voice with very high compression.
>> This prevents using analog scrambling as well.
>>
>> Since most analog scrambling techniques are very insecure, it would
>> seem there is no point in combining them with digital techniques,
>> considering the large cost in bandwidth.
>
>I don't yet understand why analog scrambling needs to increase
>bandwidth. You add noises in the same audio frequency range, don't
>you. True, it adds cost and is inferior to digital scrambling,
>and the sound quality will be poorer (I guess probably as a result
>of the fact that the energy of the proper signal getting through
>is reduced due to the simultaneous transmission of noise?).
>My point is that its use could supplement digital scrabling and that
>could be perhaps justified depending on applications. Of course,
>one applies analog scrambling first and the result is again
>'voice'. Thus I don't see your point of analog scrambling causing
>CELP impossible to be applied. By the way, could you please give
>a literature pointer to CELP?
>
>It seems that one commonly employs a stream cipher for digital
>scrambling. That's why I asked whether one could employ a block
>cipher like DES. I mean whether this blocking could ever cause
>any effect to the quality when one hears the result. Anyway, are
>block ciphers in fact employed in practice in digital scrambling
>or are they yet a theoretical possibility? Further, I am interested
>to know which stream ciphers are used in the common types
>of digital scrambling.
>
>Thanks.
>
>M. K. Shen
One reason for using stream ciphers is that they can be made into
self-syncronising ciphers that automatically correct themselves when errors
occur on the line. Unlike data, voice has to be real-time, i.e. you can't waste
time re-transmitting voice packets that have failed due to errors. On the
question of which algorithm to use - most block ciphers can be turned into
self-synchronising stream ciphers.
Mark
------------------------------
Crossposted-To: comp.lang.javascript
From: [EMAIL PROTECTED]
Subject: Re: How does % operator deal with negative numbers?
Date: Mon, 13 Mar 2000 16:17:34 GMT
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
Bill Unruh wrote:
> In <[EMAIL PROTECTED]> Frank <[EMAIL PROTECTED]> writes:
>
> ]I'm trying to write some non-kludgy JavaScript for a simple
> ] cryptography demonstration. One of the encrypt steps adds
> ] key%97, so the obvious decrypt step should be (-1*key)%97.
>
> ((-1*key)%97+97)%97
why so complicated ?
97 - key%97
will do it
- --
Disastry
http://i.am/disastry/
=====BEGIN PGP SIGNATURE=====
Version: Netscape PGP half-Plugin 0.14 by Disastry / PGPsdk v1.7.1
Comment: get this Plugin at http://disastry.dhs.org/pgp.htm
iQA/AwUBOMz4YTBaTVEuJQxkEQJegACaAr6NK+hyNbg0+cue7xI4JAApnh4AoNs8
TztMRMwIlfeZ7iFawFc6h7wp
=DLdu
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED] (Scott Nelson)
Subject: Re: Random permutations
Reply-To: [EMAIL PROTECTED]
Date: Mon, 13 Mar 2000 16:27:09 GMT
On Sun, 12 Mar 2000 20:27:40 +0100, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
>The common method of generating a random permutation is that
>due to Durstenfeld (see Knuth), utilising uniformly distributed
>real-valued random numbers in (0, 1] to swap pair of elements.
>Since such random numbers are most often derived from integer-
>valued random numbers through division operations,
Actually, I think it's usually done without reals.
For example, http://www.helsbreth.org/random/shuffle.html
doesn't use any. A division maybe, but no reals.
>an alternative
>method suggests itself, basing on the idea underlying the
>well-known procedure in classical cryptography of selecting the
>columns of a polyalphabetic substitution table with the aid of a
>given key. That is, one attaches to the elements to be permuted
>a field which is filled with the integer-valued random numbers
>(one for each element). Subsequently one sorts such records
>according to the said field. I guess that this method of doing
>random permutations (which evidently has nothing new in it) is
>equivalent (in quality) to that of Durstenfeld. Any comments?
>
Number of keys are almost always powers of 2.
Number of permutations are always N!.
Therefore, theoretically, the quality would be lower,
since all permutations can not be equi-probable.
But compared with other problems (such as the probability
of the code being improperly written) this bias is
insignificant.
Division is not particularly time intensive on modern
processors, and even on the ancient stuff I use,
it's not all that slow. Sorting on the other hand
is an Nlog(N) problem, so for "large enough" arrays,
this method will always take longer, regardless of
how much faster the random integer can be produced.
Also, producing a quality random number often takes longer
than any of the other steps. When optimizing for speed,
it's usually better to minimize the number of random
numbers needed.
Scott Nelson <[EMAIL PROTECTED]>
- Don't forget to vote on sci.crypt.random-numbers
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: CRC-16 Reverse Algorithm ?
Date: Mon, 13 Mar 2000 16:32:04 GMT
On Fri, 25 Feb 2000 14:18:56 -0500, in
<[EMAIL PROTECTED]>, in sci.crypt "Liu, Qingzhu
[CAR:CF36:EXCH]" <[EMAIL PROTECTED]> wrote:
>Hello,
>
>I try to implement an algorithm for crc-16 reverse
>(Poly: 1 + x + x^14 + x^16) in PIC17c756 assembly code.
>
>My questions are:
>1. What does the "Reverse' mean ?
"Reverse" means that the poly is intended to operate on bit-reversed
data. This was needed for large 60's-style computer reel-to-reel
tapes where the data could be read from either direction.
"Reverse" also means that the CRC poly is reversed from the original:
If we write CRC-16 as 0x18005, CRC-16 reverse will be 0x14003, which
is the same bit pattern read from opposite directions.
The way the reverse operation works depends upon the way CRC is
developed and deposited; this is the forward direction. The most
trivial way is to init the CRC register as zeros, CRC the data, then
deposit the CRC result, MS byte first. Then, when we traverse the
data plus the stored CRC result, the CRC result will be zeros.
To traverse the data in reverse direction, we again init the CRC
register as zeros, use the inverse CRC polynomial, and process the
data bits in reverse (starting with the lsb of the saved CRC value).
Again, the CRC result will be zeros.
It is also possible to init as ones, and to save the complement of the
CRC value (so the result will be non-zero), and check in reverse, but
doing that is more complicated.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
Subject: Re: sci.crypt.applied
From: [EMAIL PROTECTED] (Mark Currie)
Date: 13 Mar 2000 16:43:11 GMT
In article <Zo4z4.1645$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
says...
>
>I haven't seen a great deal of discussion of applied cryptography in this
>ng, that is, the nuts-n-bolts techniques used to implement a cipher in such
>a way that the final product is secure. I'm not proposing a new
>sci.crypt.applied newsgroup, but if it existed, perhaps the charter would
>propose discussions of:
>
>GENERAL SECURITY
> * Physical security
> * Emissions security (Tempest)
> * Communications security
>
>KEYING
> * Key generation
> * Key distribution
> * Keynets
> * Memorable (nmemonic) versus random keys
> * Rejection of weak keys
> * Key fill devices
> * Steganographic keying
> * Blind keying
> * Key escrow (boo! hiss!)
> * Biometrics
>
>HARDWARE
> * Available components
> * Design of ASICs and FPGAs including VHDL samples
> * Reverse-engineering countermeasures
> * Anti-tamper / tamper detection
> * Authentication
> * Smart cards
>
>SOFTWARE
> * Code to implement algorithms
> * Efficiency
> * User interface including non-interceptable key input
> * Anti-cracker
> * Anti-spoofer
> * Anti-any other type of hacking
> * Scrubbing media including RAM ("secure delete")
> * Identifying and destroying all temporary files and buffers
> * Better integration with Winblows environment
> * Discussion of weaknesses in commercial packages
>
>
>I'm sure most of you could come up with addtional categories. My thinking
>is that these discussions are not really about the science of
>"cryptography", rather, they are implementation detals relevant only to
>today's hardware and software environment. I looked through 3000 ng message
>headers in sci.crypt across the last couple of days, and the above topics
>didn't seem to get enough attention. Their importance is obvious, and
>though I notice some purists in the ng who argue that the only important
>thing is having the best cipher in the universe, but with poor (or even
>"average") implementation, it's like hanging a bank vault door on a house
>made of balsa wood.
>
>Any thoughts or flames?
>
>--
>
>Gary Watson
>[EMAIL PROTECTED] (Change dot sex to dot com to reply!!!)
>Nexsan Technologies Ltd.
>Derby DE21 7BF ENGLAND
>http://www.nexsan.com
>
>
Although I can't knock this group since I have picked up
valuable information in the past and I think that it definately has its place,
I have also seen the need for a group with a more "total solution" / applied /
practical bent. It is all very well having strong algorithms but in providing a
security solution there are many more points to consider
("weakest-link-in-the-chain"). I would also be happy to see a more practical
group.
Mark
------------------------------
From: "Thomas J. Boschloo" <[EMAIL PROTECTED]>
Crossposted-To: alt.privacy,alt.security.pgp
Subject: Re: Magnetic Remenance on hard drives. (was: Re: Evidence Eliminator -
Date: Mon, 13 Mar 2000 16:44:05 +0100
EE Support wrote:
>
> We contend it does not. Overwriting all zeros practically trashes
> files on the disk.
>
> Can you prove us wrong? Is there any method to simply and reliably
> decode from any disk surface the primary 0/1 patterns from RLL, etc
> encoding, after a single zero overwrite? We think there is none.
> Please prove us wrong and we will beat it.
I fantasize that your data is stored on hard disk tracks for a long time
before it gets wiped (esp. with new users of your still improving
software). So the magnetic data will leak over to the surface area next
to the track. Then you overwrite with zero's once! That leaves traces of
the previous data next to the track. Above a certain treshold the data
will have been 1 and below it will have been 0. Not very commercially
intesting until your product apeared, but it doesn't sound difficult to
recover IMO.
Better would be to steal the random data collection from the source of
pgp 6.5.1i or use Jarrow from counterpane to generate some
cryptographically strong random data and use it to overwrite previous
data on the harddisk. It doesn't have to be 10Gig strong for a 10Gig
harddrive, but hashing the initial random value a few times should do
the job. At no loss of speed (maybe 0.01% due to the hashing) you now
overwrite the previous data more securely than just by overwritting with
zero's only. That would be great.
Maybe the area close to the written track will still get magnetized by
the previous data, but you can't just set a treshold. You'll have to set
at least three treshold. One for going from 0->0 (very low magnetic
treshold), 0->1 (higher), 1->0 (still higher depending on time of last
wipe) and 1-1 (highest).
Hope this makes sense to the guys at sci.crypt and I am sure we'll hear
if I just had a brain fart.
> (Disks
> >generally use some form of run-length limited encoding). To handle all
> >possible disk encoding schemes types requires a particular sequence of 35
> >overwrite passes. You could reduce this if you knew the which disk encoding
> >scheme was used (1,7)RLL, (2,7)RLL or MFM. If you want to know about
> >overwriting data or how easy it is to recover overwritten data I can
> >recommend the following paper.
> >
> >http://www.cs.auckland.ac.nz/~pgut001/secure_del.html
> >
> >Don't buy or write a secure file deletion program until you've read it.
> >
> >
>
> We've read it. It's an interesting paper but we know of no service
> available which can put it's theory into provable, repeatable,
> evidential practical recovery of securely overwritten data.
That is really reassuring. (not) Still 35 wipes takes a long time.
Good luck to all of you,
Thomas
--
Atari Teenage Riot: "Life is like a video game with no chance to win"
PGP key: http://x11.dejanews.com/getdoc.xp?AN=453727376
Email: boschloo_at_multiweb_dot_nl
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: Just *Germain* primes
Date: Mon, 13 Mar 2000 11:48:34 -0500
[EMAIL PROTECTED] wrote:
>
> In article <[EMAIL PROTECTED]>,
> John Savard <[EMAIL PROTECTED]> wrote:
> >enough) a little mistake in the documentation; the numbers turned up
> >in the Sophie Germain mode are the ones usable as actual moduli.
>
> May I say something almost entirely off-topic and annoying? Thank you.
> ...
> What, then, is different about Sophie Germain that we'd single her out in
> this unusual way? I'm afraid the answer is obvious, ...
I always wonder why people (in recent times) insist on
immediately attributing things like this to sinister
motives.
Perhaps the "answer is obvious" to you, but it isn't to me.
In the absence of a lot more evidence, it's irresponsible to
claim (or imply) that the terminology you complained about is
inspired by a desire to discriminate. Not only that, but the
more unsupported claims like this there are, the less likely
any such claim is to be taken seriously. Which would be a bad
thing in the case where it *does* need to be taken seriously.
paul
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: ascii to binary
Date: Mon, 13 Mar 2000 11:51:34 -0500
"John M. Gamble" wrote:
> Was there ever, in this scheme of encoding, a standard for the APL character
> set?
Yes, Unicode includes the APL character set.
paul
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: US export status of RC4?
Date: Mon, 13 Mar 2000 11:53:06 -0500
Impervious wrote:
>
> Hello all,
>
> Does anyone know the current US export regulations for RC4? I have a
> freeware utility I want to release based on an RC4 Implementation with
> a 256-bit key and SHA hashing, but I don't want to get in any
> trouble!! :)
>
> If anyone can help or point me to a URL with info I'd be sincerely
> grateful.
>
> Manuel
--
!-----------------------------------------------------------------------
! Paul Koning, NI1D, D-20853
! Lucent Corporation, 50 Nagog Park, Acton, MA 01720, USA
! phone: +1 978 263 0060 ext 115, fax: +1 978 263 8386
! email: [EMAIL PROTECTED]
! Pgp: 27 81 A9 73 A6 0B B3 BE 18 A3 BF DD 1A 59 51 75
!-----------------------------------------------------------------------
! "A system of licensing and registration is the perfect device to deny
! gun ownership to the bourgeoisie."
! -- Vladimir Ilyich Lenin
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: US export status of RC4?
Date: Mon, 13 Mar 2000 11:53:33 -0500
Impervious wrote:
>
> Hello all,
>
> Does anyone know the current US export regulations for RC4? I have a
> freeware utility I want to release based on an RC4 Implementation with
> a 256-bit key and SHA hashing, but I don't want to get in any
> trouble!! :)
>
> If anyone can help or point me to a URL with info I'd be sincerely
> grateful.
Oops, sorry, wrong button.
Try this one: http://www.bxa.doc.gov/
paul
------------------------------
** 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
******************************
