Cryptography-Digest Digest #891, Volume #9 Fri, 16 Jul 99 15:13:03 EDT
Contents:
Re: Neato Talk ([EMAIL PROTECTED])
Password generation question (Phillip George Geiger)
Re: Funny News (John Myre)
Re: Neato Talk (Keith A Monahan)
Re: DES permutations ([EMAIL PROTECTED])
Re: SSL and FTP over SSL -- Need resources. (Lincoln Yeoh)
quantified security ([EMAIL PROTECTED])
Re: Password generation question ([EMAIL PROTECTED])
Re: Why public key in PGP (Patrick Juola)
Re: Password generation question (Medical Electronics Lab)
Re: How to crack monoalphabetic ciphers ([EMAIL PROTECTED])
Re: How to crack monoalphabetic ciphers ([EMAIL PROTECTED])
Re: quantified security ([EMAIL PROTECTED])
Re: Why public key in PGP (David A Molnar)
Re: quantified security (David A Molnar)
Re: Why public key in PGP ([EMAIL PROTECTED])
Re: Password generation question ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Neato Talk
Date: Fri, 16 Jul 1999 15:11:24 GMT
In article <7mndse$rmr$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Keith A Monahan) wrote:
> Tom,
>
> Thanks for posting that link... I actually attended that conference,
and
> I can't believe I missed his talk... Then again I wasn't into crypto
back
> then.
How can you miss the talk if you were there? I have never been to a
crypto conference but isn't it formal and all, with a schedule...?
Anyways I finally listened to it all. It was actually quite
interesting (it's a change from reading all the papers anyways).
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Free PRNG C++ lib:
'http://mypage.goplay.com/tomstdenis/prng.html'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Phillip George Geiger <[EMAIL PROTECTED]>
Subject: Password generation question
Date: 16 Jul 1999 15:36:54 GMT
Lots has been written in this forum on obtaining "good" random
numbers for use as passwords, one-time-pads, or just teasing NSA
employees who find mysterious files called
nuclear_secrets_sold_to_china.july1999.encrypted
on your system. I'm looking for some feedback on the method I use
to generate keys.
Once upon a time, I decided that the five character, all lowercase
ASCII password I was using to encrypt the records of my highly
profitable drug dea^H^H^H^H^H^H^H^Hvolunteer work at a local soup
kitchen wasn't all that secure.
So here's what I did on my home linux machine:
$ cat /dev/random > bunch_o_bits
I sat there and played GnobotsII (a mindless video game with such cool
sound effects as "Yahoo!" and "Aaaaeeeeeeeiiiii!") for about 10 minutes
while the bunch_o_bits file slowly grew.
Large Assumption: /dev/random gets its bits from periodic keyboard
hits, mouse movements, etc, and not some stupid deterministic
pseudo random number generator. I read that on the alt.linux.advocacy
group once, so it must be true.
After the bunch_o_bits file was about 10K, I munched it with MD5
$ md5sum bunch_o_bits
f482ae701e46005a358a01c139f1ae74 bunch_o_bits
Having more time and personal paranoia than legitimate work to do,
I went ahead and memorized that ugly string of hex numbers for use
as a passphrase.
The above procedure seems to my semi-crypto-literate mind to be a
pretty good way to generate a key that nobody could guess or somehow
generate with the same procedure, provided my Large Assumption holds.
Does it?
If the NSA decided that my...er...soup kitchen...was just too much
competition for their own...um...cooks...would they be able to "guess"
or otherwise reconstruct my password?
I know the real weak link in my privacy has more to do with my bones'
ability to resist the impact of a baseball bat than my file encryption,
but you gotta start somewhere.
Does my Large Assumption hold?
Is MD5 a good/appropriate way to take 10K bits and get a 128-bit value
for use as a password?
Thanks for reading my post, and tune in next time when I post a 400K
binary file to this group along with a challenge to decode the ciphertext
from my very own "pseudo-OTP" encryption program.
Just kidding. :-)
--
Phil Geiger
[EMAIL PROTECTED]
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Funny News
Date: Fri, 16 Jul 1999 09:49:09 -0600
Bradley Yearwood wrote:
>
> In article <[EMAIL PROTECTED]>, John Myre <[EMAIL PROTECTED]> wrote:
<snip orig post>
> >
> >The specific argument that control is useless because criminals
> >will ignore regulations is false logic.
>
> It is no more false than any other use of bad assumptions.
> Bad assumption: control and regulation are not at least as much
> of a potential threat as the actions of an individual criminal.
<major snip>
"No more false?"
Hmmm. It may have seemed that I was taking a position on
crypto control, but that was not my intent. I meant only to
address the (in)validity of a particular argument, not the
truth or otherwise of the conclusion.
<Wry grin>: I should know better than to insert a dry, pedantic
thought into a volatile debate. For my next trick, I will take
on gun control or abortion, or maybe both at the same time...
John M.
------------------------------
From: [EMAIL PROTECTED] (Keith A Monahan)
Subject: Re: Neato Talk
Date: 16 Jul 1999 17:22:45 GMT
Tom,
It wasn't actually a crypto conference perse, more like a 'hacker' type of
conference, like a computer security type conference.
There is no 'formal' schedule for each person, you siumply attend which
ever talk you want to go to. Very informal, with classes across a few
days. If you happen to be at lunch, don't get up until 10am, etc, it's
very easy to missa talk.
Keith
[EMAIL PROTECTED] wrote:
: How can you miss the talk if you were there? I have never been to a
: crypto conference but isn't it formal and all, with a schedule...?
: Anyways I finally listened to it all. It was actually quite
: interesting (it's a change from reading all the papers anyways).
: Tom
: --
: PGP key is at:
: 'http://mypage.goplay.com/tomstdenis/key.pgp'.
: Free PRNG C++ lib:
: 'http://mypage.goplay.com/tomstdenis/prng.html'.
: Sent via Deja.com http://www.deja.com/
: Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: DES permutations
Date: Fri, 16 Jul 1999 16:26:34 GMT
In article <7mfoqc$n2a$[EMAIL PROTECTED]>,
(snip)
[EMAIL PROTECTED] wrote:
> Fabs are like the treasury's mints: there aren't that many and they
are
> easily monitored. Programmers are less readily herded.
>
What is a Fab? Am I correct in assuming that it is a hardware
implementation of an encryption algorithm?
Could be interesting pun possibilities here since Fab
also is short for Fabulous.
Which Fabs are Fab and which aren't?
> What are you going to do, classify prime numbers? --Jodie Foster's
char
> to NSA director in _Contact_
>
I wouldn't be surprised if this happens.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (Lincoln Yeoh)
Subject: Re: SSL and FTP over SSL -- Need resources.
Date: Fri, 16 Jul 1999 17:51:28 GMT
Reply-To: [EMAIL PROTECTED]
On Mon, 12 Jul 1999 19:22:14 GMT, [EMAIL PROTECTED] wrote:
>I am developing an FTP server specialized for electronic commerce.
>Among other requirements, it must support SSL.
>
Ouch! FTP uses two connections, then you've got to cater for the
differences between PORT and PASV modes. Urk!
I don't think there's a spec for SSL-FTP. But you could just put each
normal FTP connection within an SSL one. But for PORT FTP it means the
client probably needs to _provide_ a server style cert to the FTP server
for the data connection.
How about just using https instead?
Link.
****************************
Reply to: @Spam to
lyeoh at @[EMAIL PROTECTED]
pop.jaring.my @
*******************************
------------------------------
From: [EMAIL PROTECTED]
Subject: quantified security
Date: Fri, 16 Jul 1999 18:00:45 GMT
This is kinda naive but it might spark converstaion...
In lieu of the drake equation (which predicts or equates the chances of
life on other planets, that are sentient, and are currently plugged
into radios as well....) I have been toying with this...
The chances of you being hacked on the net is
C = abcde
a = (0 to 1) chances of you getting picked out of the rest of the
people on the net.
b = (0 to 1) chances of your commercing getting picked. You may be
picked but will they continue attack if they know it won't make them
profit? (i.e who will rob from the poor?)
c = (>0 to 1) chances that usefull information is leaked that can be
used to crack the key.
d = (>0 to 1) chances of finding the key while the conversation is
valid. (i.e timestamped converstations, or find a banks DES key three
years later is not viable).
e = (>0 to 1) chances one of the parties will commit a fraudgelant act.
Any other ideas? I had a few more but I can't remember them.
Basically each other factor effects the attack. For example if you
only have an 10% chance of being picked chances are you will not be
hacked (or attempted) 9 out of 10 tranactions. And that out of the
1/10 transaction they will only really attempt to get something from
you (i.e they found you, now they want to know what they can get)
1/b/1/10 times...
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Free PRNG C++ lib:
'http://mypage.goplay.com/tomstdenis/prng.html'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Password generation question
Date: Fri, 16 Jul 1999 18:06:44 GMT
<Snip>
Well the linux RNG much like Yarrow does not assign much 'randomness'
value to keyboard inputs or mouse inputs. That's why it takes alot of
them before you get outputs. Generally it's assume to be random enough
and less deterministic then a PRNG. If you have a fairly active
computer (server or just play alot) then it should be a good source.
You should note that the output is normally hashes anyways. If the
output of /dev/urandom is 'random' then you will not need to hash it to
get a value, you could have just read 16 bytes from it and used that as
your password. Albeit hasing a larger amount may be more sound, cause
you have more random inputs into the hash (remember mouse and keyboard
are not terribly random).
However forcing yourself to memorize 128 bits (or 32 hex digits) is a
pain. Why would you self-torture?
You could have just as easily made up a ryme or something and avoid the
gibbly gook.
Tom
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: Why public key in PGP
Date: 16 Jul 1999 14:34:04 -0400
In article <7mnsm4$mo6$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
>In article <7mlv56$eg$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
>> <snip>
>
>> for symmetrical schemes. The idea in PKC is that I can give you my
>> public key and you can send me messages without a secure medium. I
>> could publish my public key on a server (whoa neato idea) and others
>> could pluck it off when they need it.
>
> Could you elaborate on that? Why a public key helps protecting
>without a secure medium? And why it saves you anything to publish the
>key?
Because the public key can only be used for encryption, not for
decryption; if you have a copy of the cyphertext and the key that
was used to *en*crypt it, you have no efficient way of obtaining
the plaintext. The key that is used to decrypt is a different key,
related to but unreconstructable-from the encryption/private key.
So if I publish my public key, then anyone who knows my public key
can encrypt a message to send to me, but knowing my public key does
not provide access to any messages anyone *else* has encrypted and
sent to me.
-kitten
------------------------------
From: Medical Electronics Lab <[EMAIL PROTECTED]>
Subject: Re: Password generation question
Date: Fri, 16 Jul 1999 12:29:51 -0500
Phillip George Geiger wrote:
> Large Assumption: /dev/random gets its bits from periodic keyboard
> hits, mouse movements, etc, and not some stupid deterministic
> pseudo random number generator. I read that on the alt.linux.advocacy
> group once, so it must be true.
You can also point it at a hardware device, but that's the default.
[...]
> The above procedure seems to my semi-crypto-literate mind to be a
> pretty good way to generate a key that nobody could guess or somehow
> generate with the same procedure, provided my Large Assumption holds.
> Does it?
It would be hard to guess :-)
>
> If the NSA decided that my...er...soup kitchen...was just too much
> competition for their own...um...cooks...would they be able to "guess"
> or otherwise reconstruct my password?
Sure. But they won't guess. They'll hire on as a cook, mount a
camera over your keyboard and get it directly. Don't hire too many
"cooks" :-)
> Does my Large Assumption hold?
> Is MD5 a good/appropriate way to take 10K bits and get a 128-bit value
> for use as a password?
It's insane! So it must be a good thing eh?
> Thanks for reading my post, and tune in next time when I post a 400K
> binary file to this group along with a challenge to decode the ciphertext
> from my very own "pseudo-OTP" encryption program.
>
> Just kidding. :-)
Don't give anybody any ideas!!!
If you can actually memorize that garbage, you've got a good password.
But if you've got competition at that level, a password is the
least of your worries!
Patience, persistence, truth,
Dr. mike
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: How to crack monoalphabetic ciphers
Date: Fri, 16 Jul 1999 18:42:24 GMT
In article <7mn9u8$eat$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> In article <7mn97v$e3o$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
> > Yes, I would suppose so since each compression algorithm works
> > differently.
>
> Then hybrid systems like LZSS+huffman or LZ77+huffman would really
> throw this off?
>
Maybe not. If it's compressed with one, it may not compress at all with
the other. Not sure though, not a compression expert.
> > This is what I thought you were talking about<above>. Since a PRNG
> has
> > a period, it will eventually repeat and then it can be analyzed and
> > broken. This of course assumes you have enough ciphertext. If the
> PRNG
> > only repeats itself 5 time, for example, when applied to a plaintext
> > message, you won't get a good enough analysis. If it repeats 100
> times
> > when applied to a message, you will get a good analysis of the
cipher.
>
> Well it was what I was talking about. What if the period is longer
> then the message?
>
If the period is longer then the message, you have an OTP, as long as
you don't use the same seed for the PRNG again.
> Tom
> --
> PGP key is at:
> 'http://mypage.goplay.com/tomstdenis/key.pgp'.
> Free PRNG C++ lib:
> 'http://mypage.goplay.com/tomstdenis/prng.html'.
>
> Sent via Deja.com http://www.deja.com/
> Share what you know. Learn what you don't.
>
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: How to crack monoalphabetic ciphers
Date: Fri, 16 Jul 1999 18:44:41 GMT
While I'm here, can somebody provide links to information about
compression. I keep hearing all this stuff about LZ77 and stuff, but I
don't know exactly how they work. Thanks in advance.
In article <7mn9pq$ea6$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (Jerry Coffin) wrote:
> > I'm not sure what "ultimal" means, but whatever it is, it apparently
> > doesn't apply to any of the LZ-based compression schemes, as all of
> > them have a set of codes that are invalid at any given time.
>
> Well in LZSS (variant of LZ77) you encode things by
>
> bit = 1 code = (12 bits distance)(4 bits length)
> bit = 0 literal
>
> (or whatever length/distance you choose).
>
> I could not see where an invalid stream comes from? All the lookup
> does is copies out of a local ring buffer. In a *complete* huffman
> tree no binary sequence is invalid. You may for example run out of
> bits before finding a data-leaf on the tree though...
>
> > > The only way to really check for errors is to check the CRC (which
> is
> > > not absolute either).
> >
> > If you honestly believe this, you simply don't know much about LZ-
> > based compression schemes.
>
> But I do. If you think about it if a sequence or coding mechanism is
> omited then you haven't done all you can to sqeeze the information.
> You could do a lookup in the ring buffer where you haven't been yet
> (i.e looking upto -1024 on the first byte) but that shouldn't really
> effect the program running (other then to produce garbage out).
>
> > > Check the DEFLATE specs there are no invalid decodings at any
point.
> >
> > Here -- since you like on-line documents, take a look at:
> > http://www.patents.ibm.com/details?pn=US04558302__
> >
> > That's the patent on LZW compression. The claims are far too dense
> to
> > try to understand, but the disclosure of the patent is really quite
> > readable, though it'll probably take a couple of times through
before
> > you completely understand how LZW compression works.
>
> I know how LZW works. I wouldn't use LZW if I was forced to. I like
> LZSS since it's simple to code. I have a zero memory LZSS coder if
you
> would like to see it... LZSS+Huffman is a good combination as well.
>
> > Of course, other LZ variants work differently in some respects, but
> > they all have one basic concept in common: the compressor and
> > decompressor build up string tables in parallel. At any given point
> > in the stream, the compressor can only send codes the decompressor
> > already knows about, or (at least in the case of LZW) a code that's
> > exactly one greater than any the decompressor has seen yet.
> >
> > At any given point, however, there's an entire set of codes that
> > absolutely, positively canNOT occur in the stream because the
> contents
> > of the strings to which they should be decoded has not been defined
> > yet.
>
> You are talking about codebook methods. In LZ77 you codes are not
> indexes they are distance/length pairs. And they should always be
> valid. (although like above a -1024 distance on the first byte would
> make garbage out).
>
> > Once you've read through the patent, I'll be happy to go over any
> > points you may have trouble with -- I'm reasonably certain I
> > understand it (both the patent, and LZW compression) quite well.
> >
> > I'd also note that if you look through the popular literature on the
> > subject, you'll find LOTS of stories about LZ-based compression, and
> > LZW in particular, that are completely wrong. Misconceptions abound
> > about exactly how LZ-based compression works, and (in particular)
> > about what Terry Welch invented that was new and original (I.e.
about
> > the exact differences between LZW and LZ77, LZ78, etc).
>
> Well I know about the methods. I did a short paper in my grade 13
> comp.sci class on the methods. I have printed material on
> huffman/shannon-fano/arith lzw/lz78/lz77/lzss etc... I even have a
> paper on lossy LZSS coding and vector quantization...
>
> Only in LZ78 and LZW (of the LZ methods) can you truly have invalid
> codes. This is a waste of space though. If for the first 100 bytes
> only the lower 7 bits of the lookup are being used then there is
wasted
> space (if your index is 10 bits for example). In LZ77 and LZSS same
> thing however the codes should still be accepted (producing garbage
> out) since it's perfectly valid to read out of the ring buffer at any
> point (it's easier to code for this assumption then check the CRC
> afterwards).
>
> Tom
> --
> PGP key is at:
> 'http://mypage.goplay.com/tomstdenis/key.pgp'.
> Free PRNG C++ lib:
> 'http://mypage.goplay.com/tomstdenis/prng.html'.
>
> Sent via Deja.com http://www.deja.com/
> Share what you know. Learn what you don't.
>
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: quantified security
Date: Fri, 16 Jul 1999 18:35:38 GMT
<snip>
Sorry about this. Here is the final revision. I just messed a bunch
up...
C = a * b * max(O(B) / T, O(Ap) / T)) * e
a = chances of you getting picked
b = chances of you getting attacked
T = time valid for (seconds)
O(B) = brute force per second
O(Ap) = Attack based on known plaintexts per second
p = known plaintext
e = chance of one party disclosing the secret.
=============
Of course a OTP does not fit this model since there is no chance of
cracking it (other then e>0) and e=1 does not fit in this model as well.
Thanks for the patience. Please respond to this message.
Tom
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Why public key in PGP
Date: 16 Jul 1999 18:37:06 GMT
[EMAIL PROTECTED] wrote:
> But why don't you just use an intractable PRNG and make random session
> keys? If you both share the same PRNG state then no need for RSA!
Do you mean using the same PRNG on each side and just iterating
state over the course of several conversations? Then you're assuming
that the PRNG isn't predictable "backwards in time." Probably a valid
assumption, but how would it be any more valid than assuming your favorite
public key system isn't compromised? You'd have to exhibit the PRNG and
argue why it's more secure than the public key system.
If you mean creating a new state/key for the PRNG for every conversation,
then I think that's the same thing.
-David Molnar
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: quantified security
Date: 16 Jul 1999 18:59:13 GMT
> C = abcde
> a = (0 to 1) chances of you getting picked out of the rest of the
> people on the net.
> b = (0 to 1) chances of your commercing getting picked. You may be
> picked but will they continue attack if they know it won't make them
> profit? (i.e who will rob from the poor?)
I think these are dependent on some of the same factors as c and d.
For instance, if you are running a browser known to do bad random number
generation, an adversary who knows that will probably rip you off, even if
you are poor. So high c implies high a and b. Except quantifying how much
an unknown adversary knows is difficult.
> c = (>0 to 1) chances that usefull information is leaked that can be
> used to crack the key.
Difficult to quantify without going over your implementation with a
fine-tuned comb, I think. Also this value depends on how much the
adversary knows. Unless you can show that your knowledge of the
implementation is exhaustive, you don't know that you know more than he
does.
> d = (>0 to 1) chances of finding the key while the conversation
is
> valid. (i.e timestamped converstations, or find a banks DES key three
> years later is not viable).
Easiest to quantify. Will still have to make assumptions about what
kind of hardware is available to an adversary.
> e = (>0 to 1) chances one of the parties will commit a fraudgelant act.
Depends on who they are. Are they out for fame or for your money or what?
How do you tell beforehand?
> Any other ideas? I had a few more but I can't remember them.
> Basically each other factor effects the attack. For example if you
> only have an 10% chance of being picked chances are you will not be
> hacked (or attempted) 9 out of 10 tranactions. And that out of the
> 1/10 transaction they will only really attempt to get something from
> you (i.e they found you, now they want to know what they can get)
> 1/b/1/10 times...
Do you mean 1/10 * 1/10 = 1/100 times for a = .1, b= .1, c =1 d=1 e=1 ?
The thing is that the factors are not independent, so I don't think
you can simply set values, multiply, and get a meaningful number. After
being given a situation with a specified adversary, you might be able to
work out how they all affect each other and set values which
"work"...but none of that will be in your model here.
-David Molnar
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Why public key in PGP
Date: Fri, 16 Jul 1999 18:12:33 GMT
In article <7mlv56$eg$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> <snip>
> for symmetrical schemes. The idea in PKC is that I can give you my
> public key and you can send me messages without a secure medium. I
> could publish my public key on a server (whoa neato idea) and others
> could pluck it off when they need it.
Could you elaborate on that? Why a public key helps protecting
without a secure medium? And why it saves you anything to publish the
key?
Your help is highly appreciated.
Thanks.
Weedlet
>
> Tom
>
> Sent via Deja.com http://www.deja.com/
> Share what you know. Learn what you don't.
>
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Password generation question
Date: Fri, 16 Jul 1999 19:01:42 GMT
In article <[EMAIL PROTECTED]>,
Medical Electronics Lab <[EMAIL PROTECTED]> wrote:
> Phillip George Geiger wrote:
> > Large Assumption: /dev/random gets its bits from periodic keyboard
> > hits, mouse movements, etc, and not some stupid deterministic
> > pseudo random number generator. I read that on the
alt.linux.advocacy
> > group once, so it must be true.
>
> You can also point it at a hardware device, but that's the default.
Like your smoke detector random thingy?
> > The above procedure seems to my semi-crypto-literate mind to be a
> > pretty good way to generate a key that nobody could guess or somehow
> > generate with the same procedure, provided my Large Assumption
holds.
> > Does it?
>
> It would be hard to guess :-)
As long as the inputs are good...
> Sure. But they won't guess. They'll hire on as a cook, mount a
> camera over your keyboard and get it directly. Don't hire too many
> "cooks" :-)
They are called cooks now?
> Don't give anybody any ideas!!!
> If you can actually memorize that garbage, you've got a good password.
> But if you've got competition at that level, a password is the
> least of your worries!
Well if you really want to keep your unix login password private...
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Free PRNG C++ lib:
'http://mypage.goplay.com/tomstdenis/prng.html'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
** 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
******************************
