Cryptography-Digest Digest #652, Volume #9 Thu, 3 Jun 99 18:13:03 EDT
Contents:
Re: Obscure Code ([EMAIL PROTECTED])
Re: Finding a 192 bit hash (Was: Using symmetric encryption for hashing)
([EMAIL PROTECTED])
Re: CRC32 (Bryan Olson)
Re: what cipher? ([EMAIL PROTECTED])
Re: Schoof's Algorithm (DJohn37050)
Encrypting with nNFSR - question. ("Bartłomiej Ziółkowski")
Re: PGP Key security? (Bill Roberts)
Re: The BRUCE SCHNEIER Tirade (Tim Redburn)
Re: what cipher? (John Myre)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Obscure Code
Date: Thu, 03 Jun 1999 17:42:43 GMT
In article <[EMAIL PROTECTED]>,
Paul Koning <[EMAIL PROTECTED]> wrote:
> "Oliver J. Hanau" wrote:
> >
> > Does anyone now if there is any kind of source on producing obscure
> > code, i.e. code that is hard for an attacker to analyze/debug?
> > (Assuming the decryption process takes place in an insecure
> > environment, and the attacker attempts to find the key and possibly
> > also the algorithm.)
>
> Waste of time. Such an exercise makes no sense, and I wouldn't
> bother looking for references to such silliness.
>
> paul
I beg do differ. The cost for the attacker includes the cost for
analyzing an algorithm and, if a successful attack is found, the cost
of implementing the attack. Increasing the overall cost for the
attacker is a valid cryptographic goal.
The trouble of course is that if an algorithm is difficult to analyze
then it is also difficult to estimate how strong it is. If somebody
does manage to analyze that algorithm and finds a trivial solution then
we have a disaster. Therefore it is always better to use an algorithm
that is easy to analyze and has been extensively studied than to use an
algorithm whose security depends on its resistance to analysis.
Having said that, there is actually a better solution (there always
seems to be a better solution for those applications where security and
not speed is the most important factor): Combine in series a very well
respected algorithm that has been extensively analyzed with another
algorithm designed specifically for making analysis difficult. Now you
have the best of both worlds.
By the way, "obscurity" is a term normally used to describe security
based on a secret cipher. In practice it is very difficult to keep a
cipher secret and therefore obscurity is normally a very bad idea.
There are other ways to make a cipher difficult to analyze even if the
cipher itself is public.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Finding a 192 bit hash (Was: Using symmetric encryption for hashing)
Date: Thu, 03 Jun 1999 17:55:02 GMT
In article <[EMAIL PROTECTED]>,
"Thomas J. Boschloo" <[EMAIL PROTECTED]> wrote:
> Paul Onions wrote:
> >
> > It's not one-way: given a hash output, simply "invent" the other
ciphertext
> > bits and decrypt. This gives a preimage of the output.
> >
> > It's not collision-resistant: as above, but "invent" two lots of
ciphertext
> > bits and decrypt each. This gives two preimages with the same
output.
> >
> > So using any kind of invertible message transformation in this way
is no
> > good for constructing a cryptographic hash.
>
> I finally get it (I think). If I would sign a RSA modulus this way,
some
> attacker could just take this signature and create an other key using
> the 'hash', 'inventing' some bytes and decrypting the result :-(
Um, sort of. If you signed a message (using RSA say) using
your proposed hash then an attacker could easily generate
another message for which your signature is also valid.
This is precisely because the hash isn't collision-resistant.
> Thanks for answering my question! But now I have a new problem; If I
> want to use something like Rijndael-192 for symmetric encryption, how
do
> I hash my conventional passphrase. Surely there are some solutions for
> this?!
For passphrase hashing you simply want to perform some kind of
costly processing to turn the passphrase into the key (costly
so that it thwarts dictionary attacks but not too costly that
it becomes a burden on the legitimate user) and you also want
it to be "unpredictable" (in the sense that it can't easily be
bypassed - e.g. partial info on the passphrase giving partial
info on the key).
These things usually take the form of an iterated hashing mechanism
of some kind, but as I've never actually looked into the pros and
cons of what to do in this situation, I'll refrain from suggesting
any kind of ad-hoc mechanism and hope that somebody else knows of
a good way of doing it instead :-)
Paul(o)
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: CRC32
Date: Thu, 03 Jun 1999 10:58:57 -0700
iLLusIOn wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
>
> Hello,
>
> I'm looking for any texts/urls with algorithms and descriptions
> of CRC-32 [...]
You've already gotten some answers on that, so I'll just address
one point.
> are there any ways to speed crc32 up a bit? or are there any
> faster (yet as "secure") algorithms as crc32? how high is the
> possibility that i'd get the same checksum twice? my
> implementation would be used to generate checksums of many
> files, getting the same checksum on two different files would be
> bad.
You've left out one important point: might an adversary try
to generate files with the same checksum? Using any of the
popular checksum algorithms, such as CRCs or Fletcher/Adler
sum of sums, we can easily construct files with the same
checksum, or with a given checksum.
If you're only worried about accidental collisions, a large
CRC is fine. If you have to resist intelligent attackers,
then you need a cryptographic hash such as SHA-1.
--Bryan
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: what cipher?
Date: Thu, 03 Jun 1999 18:45:21 GMT
Particle wrote:
> I'm looking for a stream cipher, or a block cipher
> that works in 8-bit intervals. (actually, I'm looking for
> the algorithm, I'm planning on implementing it myself)
>
> It is very important that the ciphertext retain the length
> of plain text. It has to be fast, and secure
That's a little tricky. Can we assume a new key for
each message, or enough extra space to store an IV?
With zero extra storage, the same message under the
same key always produces the same ciphertext. This
allows "dictionary" attacks.
[...]
> it would also be nice to have a feature of not having
> to decrypt all the text before a certain point (i.e.: so that
> I can seek to the middle of the file, get what I need,
> without ever touching the start)
Supporting random access reads but not writes is
easy. A block cipher in counter mode would work,
as would the SEAL stream cipher and some others.
Secure random access writes are tricky. Without
extra storage space, there's no way to prevent the
new data from using the same cipher+key+IV as the
old data. An attacker who can see the same file
at different times can gain information. Most
solutions involve re-writing a large page (several
kilobytes) even if only changing a bit. The secure
solution is to include an IV in each page and
change the IV on each write. Of course holding
the IV means each ciphertext page is slightly
larger than the plaintext.
A less secure but often acceptable solution is to
choose a cipher and mode such that any change
effects a whole page. We might also use the offset
of the page as an IV. The scheme still has the
dictionary problem, but the large page tends to
make the dictionary large, and the offset as IV
means each page has its own dictionary. See Peter
Gutmann's SFS for an example.
--Bryan
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: Schoof's Algorithm
Date: 3 Jun 1999 19:24:18 GMT
This is great. Very impressive. Can you tell us if you are planning to extend
to do curves over 2**m?
Don Johnson
------------------------------
From: "Bartłomiej Ziółkowski" <[EMAIL PROTECTED]>
Subject: Encrypting with nNFSR - question.
Date: Thu, 03 Jun 1999 20:17:39 GMT
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
Hi,
In my thesis I'm trying to find a way to generate functions (stream of
bits) which give maximal period of n-stage NFSR, which is T=2**n (n is
stage).
For example, if:
stage n: 8
all functions N(n): 2**256
functions generating maximal period B(n): 2**120
period (keystream): 2**8
and we can generate every B(n) with the same probabilty (to obtain
keystream) we could just xor every bit of keystream with every bit of
plaintext to obtain ciphertext. It would give us efficient and secure
stream cipher based on nNFSR (to break it brute force we have to
search at least 2**120 bitstreams).
To find a way to efficiently generate such functions I have to find
patterns and relationships between them but it's hard to find B(n) for
n>5. Now, I know that such functions have to be balanced (number of
0's equals number of 1's) and linear complexity (LC(x)) is also
important.
I need to know if there are any papers focused on such research (or
maybe people interested in NFSR's). If You know something let me know
:)
Regards,
Bartek.
P.S. At www.bis.pozn.com/Prezentacje/ziolkowski.htm is slide-show
about this.
Bartłomiej Ziółkowski
mail: [EMAIL PROTECTED]
=====BEGIN PGP SIGNATURE=====
Version: PGP 5.5.5
iQA/AwUBN1bUJBFvyGkawQxIEQK1IgCeJ7yLilsdJqBsKL26FGKKcu73xxYAnjSY
IezzH0FOvhYXd/ZYHJ93A1Xa
=xue0
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED] (Bill Roberts)
Subject: Re: PGP Key security?
Reply-To: [EMAIL PROTECTED]
Date: Thu, 03 Jun 1999 21:31:44 GMT
On 3 Jun 1999 03:39:05 GMT, [EMAIL PROTECTED] (STL137) wrote:
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
><<Try to choose a phrase with over 20 characters, mix case, add
numbers,
>punctuation, and purposely misspel a word or two (My dawg haz flez,
>plez!)>>
>
>Nah. Get a wordlist that has thousands of short words in it. Get 128
bits worth
>of random numbers and divide it up into 9 or 10 chunks. Then go
through your
>wordlist and pick out the words that correspond to those chunks. Keep
them in
>the original order. Bam! Instant great passphrase. For *example*
(this is not
>my real passphrase) a 128-bit phrase may go:
>Weasel Baby Iodine Queen Kitty Home Cow Rake Evil Joke
>
Good, but I would find it harder to remember the list of unrelated
words as opposed to some phrase.
=====BEGIN PGP SIGNATURE=====
Version: PGP Personal Privacy 6.0.2
iQA/AwUBN1b0NGKUERft8Tf8EQLkygCfaHtRR9nnfveVaOVO8ixo7U3uV84AnRWf
Y3tV6+JRNccIcYKi2cE/RFT1
=2dR2
=====END PGP SIGNATURE=====
Bill Roberts | Rutgers '66
[EMAIL PROTECTED] | Owego, NY
Fix reply to in order to reply
PGP fingerprint: D7C4 BCEF 0B53 C703 088B D893 6294 1117 EDF1 37FC
------------------------------
From: [EMAIL PROTECTED] (Tim Redburn)
Crossposted-To: talk.politics.crypto,alt.privacy
Subject: Re: The BRUCE SCHNEIER Tirade
Date: Thu, 03 Jun 1999 21:47:10 GMT
On Thu, 03 Jun 1999 02:10:04 GMT, [EMAIL PROTECTED]
(SCOTT19U.ZIP_GUY) wrote:
>In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Tim
>Redburn) wrote:
>>On Wed, 02 Jun 1999 01:56:35 GMT, [EMAIL PROTECTED]
<snip>
> You have shown that the if one uses a uniformily random file that
>the entropy is less than the maximum if a uniformly random key
>was used. However it is still over one million bytes. Now if one is
>using any file for the keyenc.key file and then use 16 charcters as
>the pass word you do not have 128bits since for one reason one can not
>enter all combinations of 256 bits for each character so one would have
>to type a longer string i am not sure how long I guess it depends on the
You are not sure how long ? But you designed the thing. If you
don't know then who does ? You clearly can't have done much analysis
of it yourself.
>ascii charter subset you use and but one can calulate the number of
>characters needed. You can still get the 128 or 200 or what ever you little
>heart desires. For those that what entropy that matches severy possilbe
>S table I have code at my site but I feel most people would be happy
>with a million bytes or so.
>
>
You keep reversing your arguments. If I say that the effective key
size is unknown then you say, use such a big key that it doesn't
matter. Then when I point out the problems of a large key, you say
that if you're happy with 128bit security, then use 128bit keys.
However, you admit in your post that your can only guess at the
size of key you need for 128bits. Surely you must see why people
have doubts about the security of your algorithm ?
<snip>
>>I don't actually run the software, for the reason you mention amongst
>>others, but even the doEnce function is hard to follow due to the
>>nonsense variable names used.
>
>
> Well I liked the names used if you don't change the names in your
>copy of the code.
I started to, but it was just taking too long. I have better things to
do with my time, and I'm sure many other people are in similar
situations.
> My god what is in a name they only represent numbers
No they don't. They represent concepts. These concepts are open
to interpretation. An array of int's could hold time series data, or
it could hold the contents of an S-Box, or it could hold an encryption
key, or it could hold data to be encrypted, or it could hold RGB
values that make up an image. Without a sensible name, it could
potentially take a long time to figure it out.
You seem to have a number of pointers, pointing to the same structure,
and a number of ways of accessing that structure. This only
adds to the confusion.
>so I can't think what you want there and I am sure if I made long names
>they would have no meaning.
Any sensible attempt at names would be better than what is there at
the moment.
>Hell it reminds me if code I write for an
>interial navigation system people bitched no names so made a table
>of names up.
A page of explanation of what the variables represent and how
they are used would go some way to helping.
>Like DAS was equal in table to Directionary Analog Scaler
>this made people like you happy. But it was goobly gook I used DAS
>as a varibale since it was my name. By the way the code worked but
>I doubt if anyone has any idea why.
Exactly. Nobody has any idea why. With encryption it is not possible
to simply run the program and run a few randomness tests on the
output. The 'why it works' bit must be known for people to trust
a cipher. Nobody has yet been able to confirm or deny if your
algorithm works, because of the trouble they have in
determining what the algorithm actually is.
>
> The doEnce function is the main encryption routine it is very short
>on input you have a pointer to location in memory while the virtual
That bit is obvious. But what conceptually is at that memory location?
A few minutes examination reveals that it is most likely the plain
text. But it shouldn't be necessary for someone reading your
code to have to work that out. It wastes time, time which
most people don't have to spare.
>file is laid out and the other input is the number of bytes in the file
>on output the virtual file has overlaid the other file in memory and it
>is the output file and the lenght in is exactly the same as lenght out.
>The rest should be easy to follow in the routine it is very short.
>
No, the rest is not easy to follow.
<snip>
>>> It took a long time to develop those macros I had many more but the
>>>compiler barfed when the level got deeper.
>>
>>I don't blame it.
>
> I do the macros make it more like a good macro assembler which are the
>best kind so you can build you own high level code. I don't have a good
>macro assembler like the good old PDP machines of yesterday.
>
By using macros, you can almost redefine a language. That makes it
harder for programmers that do know the underlying language to
understand what your code is doing.
<snip>
>>Personally, I don't like code hidden away in macros, just to 'make
>>things easier'. This means that you have to trust the macro writer did
>>his / her job properly. Why not use functions instead ?
>
> Finctions are slower during execution time.
I'm not sure about C, but in C++ functions can be made inline, so that
the compiler substitutes calls to a function with the actual function
code, so that there is absolutely no overhead at all. (there are some
limitations though eg. no loops in the function)
>
>>
>> And stick
>>to one method, there seem to be places in your code where you use
>>one method to access the tables one minute, then another the next.
>>
>
> like where in the code do you mean?
>
An extract from the doEnce function....
=====================================================
if( i19 != i19s){
pf19->a00 = 0x7ffff;
iz = geto19(ppo19, i19-1);
pf19->a00 = 0;
izz = geto19(ppo19, i19-1);
i19s += 0 == ( iz ^ izz);
}
=====================================================
You are using the structure "pf19->a00" to set the
value, then the macro "geto19(ppo19, i19-1)" to
get the value.
And back to the other point about variable names......
What on earth do "iz" and "izz" represent ?
And more to the point, what on earth is going
on here and how does it help the security ?
>>>
>>>>Every time you reuse a key, you double the amount of information
>>>>that an attacker has as to the value of the key. With all your
>>>>paranoia over security, million bit keys, etc, I would have thought
>>>>that reusing a key would be the last thing you would do.
>>>
>>> Well you thought wrong
>>
>>So Shannon was wrong then? All his work on unicity distance was
>>rubbish ? Is that really what you're saying ?
>
> No I am saying your wrong about me. I do reuse keys sorry to pop
>your bubble.
>
You would be far better to use 100 x 128bit keys than 1 x 12800bit key
to encrypt 100 different messages. That way if one of the 128 bit
keys is broken, then only one message is readable.
With one large key, you give an adversary 100 different attampts at
cracking the cipher, and once it's crakced then that is it. All your
messages can be read.
You seem to be overly paranoid about some aspects of cryptography,
namely huge key sizes, and then very unconcerned about others. Don't
forget, it only takes one weak link in a system to render the rest
useless.
>
>>
>>With the size of key that you are using, it is likely that for a few
>>megabytes of ciphertext, there are a many keys that would give
>>sensible decryptions, however, if the number of ciphertexts gets
>>large enough, then there will be fewer and fewer possible keys.
>>This makes deciphering easier. If you want maximum security then
>>change keys often, and don't re-encrypt the same plaintext twice.
>
> All it means if your using the same key over and over and the
>enemy knew it than yes like any method if you find a key that unlocks
>the messages your done. but the trick is finding that key.
>
The more ciphertexts you give them , encrypted with the same key,
the more clues the enemy has as to the contents of that key, No
encryption method has been proven to be totally secure when keys are
reused, so the more cipher text you give them, the easier decrpytion
becomes. Dont forget, you need a certain amount of cipher text to be
confident you have guessed a key correctly. The more cipher text
you give them , the more confident they can be.
>>
>>>however in the next version I may have the ability
>>>of a changing key each time 2 people exchange messages the key they use
>>>would change. I feel this is an important feature that is lacking. It also
>>
>>How do you propose this, without causing all the practical problems
>
> I will use data from one of the passes to create a mod in the keyenc.key file
>automatically after a successful decrytion set. Hay this is in the futrue it
>is not here yet.
>
Would you like to start a new thread and go into more detail on your
ideas ?
<snip>
>>So is "wrapped PCBC" where you believe the security of your
>>algorithm lies ?
>>
>
> The security is in 2 places one the 19 bit S-table with the
>effective keylength of up to one million bytes plus. And yes
Just to clarify. You are saying that the true security of scott19u.zip
lies with the substitution from the S-Box, hidden by your "wrapped
PCBC" mode.?
So you basically take the plain text, make substitutions
(using 19bit words) from the S-Box, then hide it all with your
chaining method ?
Now we seem to be getting somewhere. Would you care to expand on
any of that. (or correct it).
>since a larger block size usually adds to the security of encryption
I seem to remember a paper by Schneier that argued the opposite.
I can't remember the details though.
>that is why hardly any one use 8 bits. and know things look headed
>to 128 bits or more. THe problem is the files are not in block mutuples
>of this size. So the best thing is to treat the whole file ( or largest
>pratical block for the use) as a single block. So yes a lot of the
>security is in the "wrapped PCBC" that is why I am writting code that
>ancii (I hope) it allow others to use it with the AES candidate of choice.
>I already see one problem my open of a read only file will be "rb" though
>on most machine one should use "r" I am not going to worry about little
>things like that and hope some brains are used when looking at the code.
>
If you want others to use it, then it would be far better to describe
it at a conceptual level that includes all the details crucial to
security, then let others worry about writing the file handling code
and other implementation specific stuff.
It also makes it easier to analyse. (and hence people will have
more confidence in it's security if it stands up).
<snip>
>larger than 128 bits. But for the truely parinod if they can actually get
>a random file large enough I have a routine that increases the entropy
>of the pick.
Ey ? You have a deterministic routine that increases entropy ?
> Again you seem to think you have found something weak
>and if it makes you happy and it seems it does pat your self on the
>back. But pat your self more if you can prove the enropy is less than
>a million bytes.
The entropy value itself was not siginificant. What was significant
was that the algorithms designer didn't know what it was. This hardly
inspires confidence in the rest of the algorithm.
>
> Also if one types in a fixed number of symbols say 80 for a pass pharse
>and use any file for keyenc.key then any change of characters at all in
>that phrase causes a unique S-table. Sorry to disapoint you but there is
>no loss each change produces a unique encryption key.
>
No it doesn't. An 80 symbol key has to be padded. Any key less than
the maximum length, will have a corresponding maximum length key.
The S-Box is a permutation, the key is not necessarily a permutation.
There are more keys, than S-Boxes, Therefore some keys must produce
identical S-Boxes.This is the whole point of the entropy loss.
There is no guarantee that all 80 symbol keys give maximal length keys
(when padded) where no S-box is produced twice.
<snip>
>
> Again you still get more than a million byte which is a hell of a bit
>longer than 128 and you should know you did the calculations or did
>you forget how it was done.
Yes, and you can't tell people if they want a certain level of
securty what key size they should actually use, yet you
designed the thing.
>Don' get me wrong you did great work.
>But unfortunately you haven't made any progress since then.
>
The work was only basic maths in terms of cryptograophy.
I gave up looking further because I simply don't have
the time to extract the entire algorithm from the source code.
<snip>
> Hay you want a description He was willing to do it. Yes he made a
>few mistakes. But at least he was willing to get off his ass and take
>a look at it. He felt it was worth looking abd I think over all he wrote it
>up better than I could have.
>
I want an accurate description that describes scott19u.zip, Not
something that is similar to scott19u.zip. That would be a waste
of time. An inaccurate description is worse than no descrption.
>
>>Who better than the algorithms designer ?
>
> I think Paul Onions could write it up if he felt like it.
It is possible to find problems with your algorithm without
understanding it all. Paul might have made the effort
to decipher it all. If he did, it would be great if he would
share it with everyone. But you changed it since he analysed
it, so he would have to start over again. I doubt he
has the time or the inclination. (quite understanably).
>I don't Bruce could since this is to different than the
>weak stuff he plays
<opinion without basis mode on>
Yes, scott19u.zip is weaker......
<opinion without basis mode off>
<snip>
- Tim.
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: what cipher?
Date: Thu, 03 Jun 1999 15:02:42 -0600
A really good answer to this question depends on other
factors that have not yet been discussed, and on details
of the actual application. If I were paying someone
for their time to help with this, she would probably
start by asking questions to clarify the problem.
(The following rather long-winded discussion is really
just an expansion of the above comment. Skip if I'm
"preaching to the choir".)
For example, it sounds to me as if the problem is to
encrypt files (on disk) without changing their size,
but perhaps this isn't everything? Do we want to
encrypt data for communication, such as e-mail messages
or perhaps even individual keystrokes? If encrypting
files is the point, would a minimum file size (to match
the block size of the chosen cipher) be an acceptable
constraint? Or do we need to handle, say, files with
just three bytes in them? And of course, sometimes we
find we have overspecified the problem, anyway: it may
be, for example, that encrypting an entire disk drive
(rather than individual files) solves a problem in a
simpler way. It just depends on the situation.
Another broad class of questions would deal with the
threat model. That is, to decide on a cryptographic
system we need to decide what sorts of attacks to
defend against, based on a (conservative) estimate of
the powers and interests of the attackers. For example,
do we assume that the attackers might be able to modify
a disk file, so that we need some means of ensuring the
data is authentic, or are we just worried about keeping
the data secret?
Various posts in this thread have given advice of one
sort or another. Using OFB mode to create a stream
cipher out of a block cipher certainly is useful in
some situations. Similarly, data expansion may be
easy to avoid or tricky, depending on other constraints.
The thing to note is that to decide whether the advice
is applicable means knowiwng more about your situation.
Here in the newsgroup, just as for a one-on-one
situation, the answers will be better when the
question has more context. It just takes longer.
And is sometimes more interesting...
Particle wrote:
>
> I'm looking for a stream cipher, or a block cipher
> that works in 8-bit intervals. (actually, I'm looking for
> the algorithm, I'm planning on implementing it myself)
>
> It is very important that the ciphertext retain the length
> of plain text. It has to be fast, and secure (preferably,
> computationally secure). I would use a derivative of
> RSA, but that's a bit slow.
>
> Oh, I'm willing to use keys upto 128 bits, which
> will be totally randomly generated and secure from
> intruders.
>
> it would also be nice to have a feature of not having
> to decrypt all the text before a certain point (i.e.: so that
> I can seek to the middle of the file, get what I need,
> without ever touching the start)
>
> any ideas on a possible algorithm?
>
> please cc reply to my e-mail
> thanks.
>
> --
> Particle
> [EMAIL PROTECTED]
> http://www.geocities.com/SiliconValley/Way/7650
> Home of the Java Data Structures 2nd Edition.
------------------------------
** 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
******************************
