Cryptography-Digest Digest #788, Volume #12 Thu, 28 Sep 00 04:13:00 EDT
Contents:
Re: Adobe Acrobat -- How Secure? (Stephan Eisvogel)
Re: Adobe Acrobat -- How Secure? (Paul Rubin)
Re: Adobe Acrobat -- How Secure? (SCOTT19U.ZIP_GUY)
Re: Adobe Acrobat -- How Secure? ("John A. Malley")
Re: PRNG improvment?? (Terry Ritter)
Re: Adobe Acrobat -- How Secure? (Dido Sevilla)
Re: I am only an egg... (Dido Sevilla)
Re: I am only an egg... (Terry Ritter)
Re: On block encrpytion processing with intermediate permutations (Mok-Kong Shen)
Re: Notice: Problems with DiehardC. (Mok-Kong Shen)
Re: Josh MacDonald's library for adaptive Huffman encoding (Mok-Kong Shen)
Re: "Secrets and Lies" at 50% off (Arturo)
Re: Why is TwoFish better than Blowfish? (Arturo)
Re: Javascript SHA-1 Implementation ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: Stephan Eisvogel <[EMAIL PROTECTED]>
Subject: Re: Adobe Acrobat -- How Secure?
Date: Thu, 28 Sep 2000 05:13:25 +0200
"David C. Barber" wrote:
> I am looking to distribute some documents I don't want the user to be able
> to alter or print. Acrobat was suggested, but IIRC, wasn't the Steven King
> story distributed through Acrobat, and it was broken quickly just by loading
> it into the full fledged Acrobat program?
Jesus, PDF? Just buy one of those self-destructing InfoSafe(tm) devices that
you can see in all those mission impossible movies. David A.Scott, a regular
here, also sells them but there you have to agree to also take 1.000 free
"Bruce is evil" stickers.
There are several patches for Acrobat Reader which reenable printing of
protected documents (by Phrozen Crew and others). I have not seen patches
for the real Acrobat but think it is easy to break that too, an obscure
Russian crack site may even already have it.
Depends whom you face, if its Joe Xerox, PDF should be enough because
the patches are tricky to apply with all those heaps of Acrobat versions
around. Hours of stupid ftp searching guaranteed. If its a determined enemy,
and your document is worth something, avoid electronic distribution.
Stephan
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: Adobe Acrobat -- How Secure?
Date: 27 Sep 2000 20:18:41 -0700
"David C. Barber" <[EMAIL PROTECTED]> writes:
> I am looking to distribute some documents I don't want the user to be able
> to alter or print. Acrobat was suggested, but IIRC, wasn't the Steven King
> story distributed through Acrobat, and it was broken quickly just by loading
> it into the full fledged Acrobat program?
If the user can see the document, it's impossible to do what you're
asking really securely. It doesn't matter how good your cryptography
or even how trustworthy their secure-PC hardware is. They can always
photograph the screen or copy down the content by hand into a paper
notebook. So forget it. If you show content to someone, unless you
totally control the hardware that they're on *and* you have someone
watching them to make sure they don't copy it, they can copy it.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Adobe Acrobat -- How Secure?
Date: 28 Sep 2000 03:21:45 GMT
[EMAIL PROTECTED] (Stephan Eisvogel) wrote in
<[EMAIL PROTECTED]>:
>"David C. Barber" wrote:
>> I am looking to distribute some documents I don't want the user to be
>> able to alter or print. Acrobat was suggested, but IIRC, wasn't the
>> Steven King story distributed through Acrobat, and it was broken
>> quickly just by loading it into the full fledged Acrobat program?
>
>Jesus, PDF? Just buy one of those self-destructing InfoSafe(tm) devices
>that you can see in all those mission impossible movies. David A.Scott,
>a regular here, also sells them but there you have to agree to also take
>1.000 free "Bruce is evil" stickers.
>
I am sorry I am out of "Bruce is evil" stickers.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
From: "John A. Malley" <[EMAIL PROTECTED]>
Subject: Re: Adobe Acrobat -- How Secure?
Date: Wed, 27 Sep 2000 21:07:51 -0700
Paul Rubin wrote:
>
> If the user can see the document, it's impossible to do what you're
> asking really securely. It doesn't matter how good your cryptography
> or even how trustworthy their secure-PC hardware is. They can always
> photograph the screen or copy down the content by hand into a paper
> notebook. So forget it.
The IBM Cryptolope technology popped into mind when first I read Mr.
Eisvogel's post, but your reply yanked the rug out from under me. Here's
the whiz-bang content protection system from Big Blue:
http://www-4.ibm.com/software/security/cryptolope/about.html
It, too, falls to screen snapshots - the electronic kind. Just use any
GUI window capture tool and grab a bitmapped image of the secured
document after your decrypt it with the decryption key from the
cryptolope infrastructure. Redistribute the grabbed image as you see
fit. Once the distributor catches on you can't expect to get any more
items if the distributor knows its you when you come back for more.
> If you show content to someone, unless you
> totally control the hardware that they're on *and* you have someone
> watching them to make sure they don't copy it, they can copy it.
Sad but true.
Appears there is no protocol to prevent Bob from copying and
redistributing messages from Alice after Bob decrypts them. Alice can
stop sending messages to Bob once she figures out what Bob's doing.
Otherwise, Alice must rely on some social threat to Bob (i.e. ostracism,
vendetta, lawsuit, etc.), on Bob's conscience (sin or no sin) or on
Bob's sense of honor to keep him from copying and distributing their
communications.
John A. Malley
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: PRNG improvment??
Date: Thu, 28 Sep 2000 05:20:01 GMT
On Wed, 27 Sep 2000 16:59:38 -0700, in <[EMAIL PROTECTED]>,
in sci.crypt Eric Lee Green <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] wrote:
>> On Wed, 27 Sep 2000 10:52:25 GMT, Tim Tyler <[EMAIL PROTECTED]> wrote:
>[...]
>> that by first ensuring that the key values were uniformly distributed,
>> the initial pattern would be randomized away by enough shuffling. It
>
>"shuffling" is what block ciphers do internally. It is quite easy to make a
>"shuffler" whose output is predictable, especially when you know its input
>values.
It certainly is true that block ciphers are huge simple substitutions,
and as such define a keyed "random" permutation between plaintext and
ciphertext code values. But I think the term "shuffling" normally
refers to the step-by-step process which permutes an entire codespace
as in a table.
The usual descriptions of shuffling are essentially reversible: given
knowledge of any two of the original state, the random sequence, and
the resulting state, one can find the unknown. But that is not
necessarily true if appropriate shuffling is applied more than once.
>> seems to me, purly intuitively, that even with a PRNG like Excel's
>> RND(), with ENOUGH shuffling, and dealing only with index values, not
>> the key values, eventually a suitably random, truly uniform OTP could
>> be created easily. Is that not the case?
>
>That is not the case. The output of Excel's RND() function is perfectly
>predictable, if it uses the rand() function in the "C" library (which it most
>probably does). Thus the inputs to your "shuffler" will be perfectly
>predictable.
Assuming both the RNG initial state and the original table values are
known. Shall we assume that?
>Furthermore, the output of Excel's RND() function cycles after
>2^31, which means you'll need to re-key it from a source of truly random
>numbers well before that time.
If we know the initial table state, and the resulting table state, we
know something about what permutation has occurred (although, in the
proposed situation, the table was to have 10 copies of each value,
which will hide the permutation). But if shuffling occurs multiple
times, even knowing the overall permutation does not expose the RNG
sequence to attack.
>Thus you'd be better off with a plain 128-bit
>counter to produce the values you're going to shuffle.
Since a counter is probably the single most predictable RNG there is,
it seems quite unlikely that anyone would be better off using that
than a real RNG, almost no matter how poor.
On the other hand, if we want to have an appropriate shuffling with
the ability to take an initial state to any other state, we must have
sufficient keying. The proposed 2560-element shuffling, for example,
would require at least 25298 bits of information to select each
possible permutation (see, for example:
http://www.io.com/~ritter/JAVASCRP/PERMCOMB.HTM#Factorials
), and then we wonder why we have an RNG at all. I would be happy to
shuffle twice, discarding about 25% of the keying stream each time,
and then I would call the result as strong as the keys, and also
strongly protective of the keying sequence itself.
If we are willing to step back from theoretical (OTP) to practical
(stream cipher) security, we might think about filling the state for
one RNG from a key, then using that RNG sequence to fill a larger RNG
and so on, until the final RNG had more than sufficient state to
produce every possible permutation twice. Each RNG would have to be
nonlinearized in some way, of course. I think we are quite a long
ways from being able to use the characteristics of such an RNG to
reduce the possible permutations sufficiently for exploitable
weakness.
I have discussed keyed shuffling for a few small tables in:
http://www.io.com/~ritter/KEYSHUF.HTM
and the production of a confusion sequence for a stream cipher in:
http://www.io.com/~ritter/CLO2DESN.HTM
The latter describes using a sequence of RNG's to expand the key state
from 992 bits through additive RNG's of deg. 31, 127, 607, 3217, and
9689, which is a final RNG state of 9689 * 32 = 310,048 bits.
>Thus your "shuffler"
>must have the characteristics of a good block cipher in CBC mode (to mask the
>known plaintext of the inputs). Basically, you need a significant amount of
>TRUE randomness in order to initialize your "shuffler". For example, you could
>get 128 bits of true randomness from somewhere, use it to set up a key for
>Twofish, then encrypt a 128-bit counter (each encryption, increment the
>counter) and feed this to a MD5 entropy pool from whence you occasionally
>drain off 128 bits of intermediate state. There is a limit to how many bytes
>you can obtain from this process though... at 2^128 values you cycle, and thus
>must again re-key from a source of true random numbers.
>
>Note that the security of any scheme which builds "one time pads" using a PRNG
>is no greater than that of the least secure part of the "shuffler" algorithm
>that is used in the PRNG. For example, if you use TwoFish and a 128-bit
>counter and MD5, you're no more secure than TwoFish by itself would be.
That depends, of course, on the attack. For example, if the cipher
attack requires a knowledge of the plaintext and ciphertext, as is
quite often the case, preventing that knowledge effectively has made
the cipher stronger. It thus becomes necessary for opponents to use
some other sort of attack, given far less information about the keyed
structure of the cipher transformation.
>You
>might as well just use TwoFish in counter mode and avoid having to transfer
>megabytes of key material in some secure manner. In general, a one time pad is
>more secure than a good block or stream cipher only where you have a source of
>true random numbers big enough to build the pad. If you don't have such a
>source of true random numbers, use a good block or stream cipher and avoid
>being thought of as a total idiot.
Being anything less than total would hardly be extreme.
>--
>Eric Lee Green [EMAIL PROTECTED]
>Software Engineer "The BRU Guys"
>Enhanced Software Technologies, Inc. http://www.estinc.com/
>(602) 470-1115 voice (602) 470-1116 fax
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: Dido Sevilla <[EMAIL PROTECTED]>
Subject: Re: Adobe Acrobat -- How Secure?
Date: Thu, 28 Sep 2000 13:25:45 +0800
"David C. Barber" wrote:
>
> I am looking to distribute some documents I don't want the user to be able
> to alter or print. Acrobat was suggested, but IIRC, wasn't the Steven King
> story distributed through Acrobat, and it was broken quickly just by loading
> it into the full fledged Acrobat program?
>
Forget it. Not unless you add a click-wrap license, and place your
information under the DMCA and jump through all kinds of legal
contortions will it be even remotely possible. And even then, end users
will probably just laugh at it and say: "Screw the legal consequences.
David can't see me cracking this document of his anyhow." There really
is no technological solution. If someone's determined enough, all they
need to do is fire up a screen capture program, or to open a copy of MS
Word or whatever, open your file reading program, share the screen with
your file reader and Word, and just type whatever he or she sees on the
file reader's window to the Word window. Nothing to it. Cryptography
gives you a measure of control over your information, but only as much
as the intended recipients of that information will allow you to have.
This is also why the MPAA and RIAA's efforts with DVD-CCA and SDMI are
doomed. The intended recipients are not willing to give them the amount
of control over their information that they want to have, so no amount
of technology they throw at it will ever make any scheme they come up
with more secure.
--
Rafael R. Sevilla <[EMAIL PROTECTED]> +63 (2) 4342217
ICSM-F Development Team, UP Diliman +63 (917) 4458925
OpenPGP Key ID: 0x0E8CE481
------------------------------
From: Dido Sevilla <[EMAIL PROTECTED]>
Subject: Re: I am only an egg...
Date: Thu, 28 Sep 2000 13:45:49 +0800
David Rush wrote:
>
> So at the risk of opening the door to those wiser than I patenting
> ideas I don't know how to develop (*yet*), I'm wondering what has been
> done in the area of using the convolution operation (from signals
> analysis) as an encryption transformation. It certainly would combine
> every bit of the key with every bit of the plaintext. Of course,
> convolution is also computationally expensive to perform, although
> there are ways to work around/with that.
>
Interesting thought. However, if my DSP classes back in college have
not gone the way of /dev/null in my brain, a convolution is essentially
polynomial multiplication. For the convolution to be invertible by an
inverse convolution (polynomial division), your signal (message) would
have to become longer by the length of the kernel (key). Another
problem is the frequency domain representation. In the frequency
domain, a convolution is just a multiplication, so cryptanalysis may be
much easier after performing a discrete Fourier transform, or its
analogue (whatever that may be). I have no idea how the DFT-equivalent
would be formulated if your signals are elements of a finite field, but
my guess is it would involve choosing a set of orthogonal functions over
the finite field in which your signal is expressed, as with any other
integral transform. I can't imagine what these functions would look
like in a finite field like, say, GF(2^8), but I'm not going to say that
they don't exist (I wouldn't know).
--
Rafael R. Sevilla <[EMAIL PROTECTED]> +63 (2) 4342217
ICSM-F Development Team, UP Diliman +63 (917) 4458925
OpenPGP Key ID: 0x0E8CE481
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: I am only an egg...
Date: Thu, 28 Sep 2000 06:29:59 GMT
On Thu, 28 Sep 2000 13:45:49 +0800, in
<[EMAIL PROTECTED]>, in sci.crypt Dido Sevilla
<[EMAIL PROTECTED]> wrote:
>David Rush wrote:
>>
>> So at the risk of opening the door to those wiser than I patenting
>> ideas I don't know how to develop (*yet*), I'm wondering what has been
>> done in the area of using the convolution operation (from signals
>> analysis) as an encryption transformation. It certainly would combine
>> every bit of the key with every bit of the plaintext. Of course,
>> convolution is also computationally expensive to perform, although
>> there are ways to work around/with that.
>>
>
>Interesting thought. However, if my DSP classes back in college have
>not gone the way of /dev/null in my brain, a convolution is essentially
>polynomial multiplication. For the convolution to be invertible by an
>inverse convolution (polynomial division), your signal (message) would
>have to become longer by the length of the kernel (key). Another
>problem is the frequency domain representation. In the frequency
>domain, a convolution is just a multiplication, so cryptanalysis may be
>much easier after performing a discrete Fourier transform, or its
>analogue (whatever that may be). I have no idea how the DFT-equivalent
>would be formulated if your signals are elements of a finite field, but
>my guess is it would involve choosing a set of orthogonal functions over
>the finite field in which your signal is expressed, as with any other
>integral transform. I can't imagine what these functions would look
>like in a finite field like, say, GF(2^8), but I'm not going to say that
>they don't exist (I wouldn't know).
I have constructed general FFT-like transformations using orthogonal
pairs of Latin squares, a pair at each butterfly node. Each pair
forms a discrete mixing transformation which is reversible balanced,
and non-expanding. We can construct the squares from keys, select
among a given set on a node-by-node basis, and so on, thus
constructing a keyed block cipher with guaranteed diffusion. See, for
example:
http://www.io.com/~ritter/#MixTech
>--
>Rafael R. Sevilla <[EMAIL PROTECTED]> +63 (2) 4342217
>ICSM-F Development Team, UP Diliman +63 (917) 4458925
>OpenPGP Key ID: 0x0E8CE481
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: On block encrpytion processing with intermediate permutations
Date: Thu, 28 Sep 2000 10:06:47 +0200
Bryan Olson wrote:
>
> Mok-Kong Shen wrote:
>
> > I am not sure that I really understand your argument.
> > From a logical viewpoint I have some problems.
>
> Your responses, and the original post in the thread, show no
> evidence of any serious attempt to understand the material.
>
> > I use
> > additional steps to do permutation and you argued
> > that render the cipher extremely easy to attack. Now
> > one of the permutation is the identity. If that happens
> > to take places, is the original cipher also that easy
> > to attack?
>
> You specified a pseudo-random permutation. I wrote that a
> block with the properties that support the attack probably
> exists among about a thousand blocks. If the identity is
> one of the inter-round permutations, such a block will not
> exist. Now plug in the probability of the identity
> permutation and check if it's within a thousand orders of
> magnitude of contradicting my "probably exists" claim.
I believe there is misunderstanding.
Let me first say something which could indeed turn out
to be wrong, because I am no expert. As far as I understand,
differential analysis is commonly not a chosen-plaintext
attack. It depends on the relatively abundant possibility
of the opponent picking out pairs of plaintexts that satisfy
certain fixed differences. Note that in my scheme a message,
because of the whole file processing with word permutations,
has to be considered together as an ensemble of n blocks,
where n naturally varies from message to message. But let's
assume the unfavourable condition that n is always constant.
Now, if I don't err, you were saying that if all the n blocks
are chosen to be equal, then permutations don't cause any
real effect and hence could be considered to be non-existant.
Am I right in understanding you here? But then you are
considering a chosen-plaintext attack and not the
known-plaintext attack, because it is impossible that
normal messages being sent would have all n plaintext
blocks identical. Further, if the block contains m words,
then it is not sufficient that all blocks be equal but
further that all words in a block be equal. It is possible
that you could conceive of other tricks to annulate the
effect of permutation, but the argument above applies
in principle similarly, which means that the difficulty
of the opponent is greatly enhanced. (Note that I later
introduced a further 'complexity', namely random
rotations of the words, but that shouldn't be taken
into account in the present debate.)
Let me also point out a relatively minor point. If I
employ PRNG to do the permutation, then even during a
session the different messages will get different
permutations, so that, also in a chosen-plaintext
attack, unless you use all equal words to annulate
the permutation effect, you have to apply different
appropritely chosen plaintexts for the different
messages in order to realize annulation of permutation
effect of these messages.
Now coming back to what I wrote in the last post. Let's
call the block encryption algorithm E and assume that
it, in its normal operation, has a measure of difficulty
of attack R for differential analysis or the like. I
construct with my scheme a system that deals with n
blocks, not single blocks, in the way I originally
described using E as components but adding permutations.
For the opponent, the system is to be considered as
a whole black box. If I use the identity permutation
for all cycles, then my system is in fact simply using
E to encrypt all blocks, so we could consider that the
difficulty of attack remains to be R. Now compare two
cases: (1) I use the identity permutation in all cycles
and the opponent womehow knows that fact and (2) I use
random permutations that are different for all cycles
and the opponent has no knowledge of these permutations
at all. Isn't intuitively clear that case (2) is
materially more difficult than case (1)?
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Notice: Problems with DiehardC.
Date: Thu, 28 Sep 2000 10:09:43 +0200
Paul Pires wrote:
>
> I believe I have detected a problem with DiehardC v1.03
> and menu item #8 (31x31 and 32x32 binary matrix tests).
I recommend that you ask the author of DiehardC (not Diehard).
He will certainly be friendly engough to help you.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Crossposted-To: comp.compression,comp.theory
Subject: Re: Josh MacDonald's library for adaptive Huffman encoding
Date: Thu, 28 Sep 2000 10:14:35 +0200
Alex Vinokur wrote:
>
> Josh MacDonald's library for adaptive Huffman encoding :
> http://www.xcf.berkeley.edu/~ali/K0D/Algorithms/huff/
I like to repeat a question I asked before. How does
adaptive Huffman compare with static Huffman that
employs an exact frequency distribution of the texts?
Thanks.
M. K. Shen
------------------------------
From: Arturo <[EMAIL PROTECTED]=NOSPAM>
Crossposted-To: comp.security,comp.security.misc
Subject: Re: "Secrets and Lies" at 50% off
Date: Thu, 28 Sep 2000 09:32:48 +0200
On 27 Sep 2000 15:22:08 GMT, [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
wrote:
>[EMAIL PROTECTED] (Runu Knips) wrote in
><[EMAIL PROTECTED]>:
>
> I think the previous sender was joking. Of course he knew those
>were written by MR BS. But how could you insult such great crypto
>gurus like Ron Rivest by saying that Mr. BS is in the same class.
>Do you really belive that? I wonder if MR Rivest is offended?
>
Maybe Schneier has not worked for so long into designing/breaking
ciphers, and RSA�s S is not his. Still, a man able to design a cipher able to
go all the way up to the AES� final list is no newbie. Rivest has done it. So
has Bruce.
------------------------------
From: Arturo <[EMAIL PROTECTED]=NOSPAM>
Subject: Re: Why is TwoFish better than Blowfish?
Date: Thu, 28 Sep 2000 09:28:54 +0200
On 25 Sep 2000 15:38:26 GMT, [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
wrote:
>[EMAIL PROTECTED] (Runu Knips) wrote in
><[EMAIL PROTECTED]>:
>
>>Tom St Denis wrote:
>
> Having known people who know the man who designed blow fish or
>two fish leads me to believe both ciphers are most likely broken by
>the NSA before they were introduced to the public.
I doubt it. The author is Bruce Schneier, boss-in-chief of Counterpane
security and writer of the "bible" in crypto, Applied Cryptography. Not the
kind of guy I think most likely to have been bought by the NSA
> At least these
>are my feelings about these fishy ciphers. It seems like NSA humour
>to give both ciphers FISHY names.
Rather blame the author.
> But since the idea of a cipher is security. It is plain stupid to
>say Twofish is better than Blowfish becasue Blowfish is a PC cipher.
>If one has a PC and is sending messages to someone with a PC then why
>use a cipher that could becasue of its ability to be run on many machines
>would ecpoxe it to more attacks. Even if they algoritmically had
>the same level security which can't be proved anyway.
>
Right, maybe. But the AES is not being chosen just to play with on a
PC. It is intended to be used as a general-purpose standard, PC, software,
hardware or whatever. It has to be strong, resistant to cryptanalysis, fast,
have several block + key size features, and so on.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Javascript SHA-1 Implementation
Date: Thu, 28 Sep 2000 08:04:11 GMT
Cornelius Sybrandy wrote:
> Greetings all.
> I've been doing some web design and I noticed a severe lack of
> JavaScript code that hashes passwords. Out of boredom and experimenting
> with JavaScript, I decided to create my own. I implemented a version of
> SHA-1 in Javascript for the sole purpose of hashing passwords. There is
> more information in the comments provided. I felt I should let this
> application be reviewed by the group before releasing it to the world.
> Anyway, have fun with it and let me know what you think.
I have seen bank web pages that use MD5 for password hashing:
https://ibanka.unibanka.lv/ib/en.htm
https://tkb.lv/SScripts/start.plx?L=EN&P0=Netscape&P1=4
== <EOF> ==
Disastry
http://i.am/disastry/
------------------------------
** 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
******************************
