Cryptography-Digest Digest #824, Volume #9 Fri, 2 Jul 99 18:13:05 EDT
Contents:
Re: Posting on sci.crypt.research ([EMAIL PROTECTED])
Re: The One-Time Pad Paradox (Patrick Juola)
Re: I don't trust my sysadmin ("David N. Murray")
Re: Quantum Computers (Patrick Juola)
Re: BLT update (long) with (rec) ciphertexts (wtshaw)
Re: Standard Hash usage (Keith A Monahan)
Re: Standard Hash usage (Keith A Monahan)
Re: How do you make RSA symmetrical? ([EMAIL PROTECTED])
Re: Quantum Computers (Greg Ofiesh)
Re: The One-Time Pad Paradox (S.T.L.)
Re: Quantum Computers (Greg Ofiesh)
Re: Decorelation again ([EMAIL PROTECTED])
Re: Quantum Computers (David A Molnar)
Re: Quantum Computers ([EMAIL PROTECTED])
Re: Quantum Computers ([EMAIL PROTECTED])
Re: Quantum Computers (David Hamilton)
Re: I don't trust my sysadmin ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Posting on sci.crypt.research
Date: Fri, 02 Jul 1999 19:12:56 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (John Savard) wrote:
> Under "e-mail encryption method", there is a posting of a patent
> application for a method of encryption that is supposed to give
> "perfect" security...
>
> and it uses a random table with 65,536 16-bit entries.
>
> Could someone be trying to steal Scott16u?
That or somebody created a 16-bit version of RC4.
>
> John Savard ( teneerf<- )
> http://members.xoom.com/quadibloc/crypto.htm
>
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: The One-Time Pad Paradox
Date: 2 Jul 1999 15:17:54 -0400
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>Coen Visser wrote:
>> > If the statistics of all M's differ much, that means that in the
>> > best situation the analyst could recover all M's (each completely).
>> > Now how does he, having achieved this, decide which is the real
>> > message?
>>
>> Theoretically, I don't know. It is an interesting idea to hide
>> fake data in your encryption. But practically
>> speaking you can count on the adversary to select the most
>> usefull information. Consider an encrypted file which, after being
>> cracked, gives us 10 chapters of the Koran and 1 chapter describing
>> the design of an experimental nuclear warhead. What would be the
>> secret? The strength of your scheme lies in the strength of the OTP.
>> You just need OTP (+) M_fake (+) M_secret. Adding more than 1 M_fake
>> doesn't make things much safer. Improving the OTP does.
>
>I can use M_i such that they may all plausibly be the real message.
>How large is the chance that the analyst be able to obtain all the
>n+1 messages completely, if n is, say, of the order of 10, instead
>of getting probably none, even if the keystream is quite a bit less
>perfect than an ideal OTP (e.g. from a PRNG)? I wonder if anyone has
>considered this problem realistically instead of basing arguments on
>words which cannot be quantified.
As a back-of-the-envelope estimate, this method might be (relatively)
secure if you had nine or more texts. My reasoning being : the
estimated information content of unrestricted English is about 1 bit/letter,
so XORing together eight dummy texts should produce something with
about 8bits of randomness/character, which in turn would yield something
akin to a "real" pad.
*BUT*, I distrust this reasoning as anything more than a WAG for
several reasons. First, XOR doesn't necessarily retain all the
randomness in an English text; in particular, for instance, about
20% of the characters are spaces. This means that if you used two dummy
texts and one true one, about 4% of the time the (true) plaintext letter
would be passed through unchanged because the two pads were both spaces.
Second, you claim that you can use nine plausible dummy texts. But
this means that you're not using *unrestricted* English, which means
in turn that it's less informative than 1 bit/letter, and therefore
eight dummy texts will be insufficient. In particular, if you are
using plausible texts, then the recovery of any one text will suggest
cribs for the other N.
-kitten
------------------------------
From: "David N. Murray" <[EMAIL PROTECTED]>
Subject: Re: I don't trust my sysadmin
Date: Fri, 02 Jul 1999 19:08:16 GMT
I'm not sure I presented my problem correctly.
I have a completely automated process (e.g. a cron job)
that needs to connect to a DBMS (e.g. Oracle). The DBMS
requires a username and password to connect to the database
in order to do any meaningful work.
If I were to use a form of trusted access (implemented by
the DBMS), then the sysadmin could simply login as that
user. Instead, I configure the DBMS to accept uname/password
and have the program login that way.
How do I protect the uname/password that the app needs to
connect with?
Thanks again,
Dave
[EMAIL PROTECTED] wrote:
>
>
> Hash the password and store the hash on the protected side. So you
> type the password on Machine A, it gets hashed goes thru the middle man
> and compared with the HASH on Machine B.
>
[snip]
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: Quantum Computers
Date: 2 Jul 1999 14:38:44 -0400
In article <7liv85$5cf$[EMAIL PROTECTED]>,
John Curtis <[EMAIL PROTECTED]> wrote:
>In article <7lgi06$p9r$[EMAIL PROTECTED]> [EMAIL PROTECTED] (Patrick Juola)
>writes:
>>>>
>>>> There is recently published in the Springer Lecture Notes a
>>>proceedings
>>>> of a conference on quantum computing. It should reflect the state
>>>> of the art quite well.
>>>
>>>In the public sector?
>>
>>On what basis do you assert a difference between the public and
>>secret sectors? The public sector is better funded....
>
> Why do you believe that public sector research on
> quantum computing is better funded than secret sector
> research on the same topic?
>
> I'm not disagreeing, I am just interested in the source
> of your knowledge.
Just my knowledge of government funding policies; the government
doesn't tend to fund large amounts of secret, blue-sky research
when there is a well-developed body of public researchers. It's
too hard to get and keep the top people when MIT is publically
bidding against you and allows you to publish what you find.
N.b. this doesn't apply as much to *engineering* projects; if
the government wants a super-secret bomber built, it doesn't
really need to worry about Boeing building a competing bomber.
Similarly, it doesn't apply to technologies *so* secret that
there are no large-scale public research mills. Cryptography,
pre-DES, was in that situation; there weren't a lot of academic
cryptographers around, so the NSA could afford to hire the top ones
and keep them in house. But with the amount of public research being
done on quantum cryptography -- *and* the distance the public sector
is from developing a practical quantum computer -- there's little point
in spending lots of money trying to muzzle the research scientists.
-kitten
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: BLT update (long) with (rec) ciphertexts
Date: Fri, 02 Jul 1999 13:51:54 -0600
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (wtshaw) wrote:
> In article <[EMAIL PROTECTED]>, Mok-Kong Shen
> <[EMAIL PROTECTED]> wrote:
> > My WEAK4-EX, for example, (which is a probabilistic algorithm)
> > produces ciphertexts whose length is the length of the plaintexts
> > multiplied by a factor ( >= 1 ) that the user can arbitrarily choose
> > to suit his desired level of security. See my web page.
>
> I got error 04 trying to connect.
That was a 404, not found.
>
--
Rest sometimes allows you to find new things to worry about but should give you the
patience to do something about them.
------------------------------
From: [EMAIL PROTECTED] (Keith A Monahan)
Subject: Re: Standard Hash usage
Date: 2 Jul 1999 20:02:28 GMT
Tom,
Thanks for the quick and helpful response(as usual).
[EMAIL PROTECTED] wrote:
: Well the range of the key is limited to the range of the input.
: However hashes are good to turn a somewhat limited key (i.e ASCII
: chars) into a output which is not strictly limited. This will mean
: that the keys in the cipher are not limited to a certain range. It all
: depends on the length of the passwd though.
: No it doesn't. It just 'randomizes' it so that it's harder to predict
: the range of the actual output of the hash. If you use 4 chars
: (assuming 95 printables...) your password is among one of 95^4 or 2^26
: others... It's a small range, however attacking the hash will require
: on average O(2^159). So guessing the key actually used in the cipher
: is difficult, so guessing the input (passwd) becomes the focus point.
: > I noticed that SHA-1 outputs a hash result of 160 bits. What if
: > the result you need is larger than that, say 256 bits? (ie, for
: > Blowfish perhaps) And if the answer is, "Just run SHA-1, twice", then
: > how much data do you pipe in from the original key the first run, and
: the
: > second run? Do you just concatenate the 2nd results to the first?
: Normally It would be this
: H1 = H(P)
I understand this. Hash the entire password and store result in H1.
: H2 = H(P||H1)
Help me with the notation there. Is that '||' a logical OR? Or does that
just mean I first pipe the entire password in the 'to be hashed bucked' and
then add the results of the first hash in after that?
An example could be
P = ABCDEF1234
H1 = OIU.9Q!
then....
H2 = Hash of (ABCDEF1234OIU.9Q!)
right?
: Where P is the input and H1/H2 is the output (would be 320 bits with
: SHA).
I'm missing something. If a hash typically puts out a fixed size, wouldn't
H2 be only 160 bits?
: Well all you have todo is make a program to check keys, it is
: independant of the hash and block cipher (unless the output of the hash
: is less then the input in size...)
The problem is, I know some of the original KEY data (prior to the HASH) but
I have no idea what the input to the encryption algorithm is,
ie I don't know the output of the hash(because I don't know
all of the original KEY data). Sooo, wouldn't
I have to brute the original input, using what I know, with added data,
(ie add data = the actual brute searches here)
pipe it through the hash, and do the check at that point??
: Tom
: --
Thanks for your help,
Keith
------------------------------
From: [EMAIL PROTECTED] (Keith A Monahan)
Subject: Re: Standard Hash usage
Date: 2 Jul 1999 20:06:29 GMT
Hi Joe,
JPeschel ([EMAIL PROTECTED]) wrote:
: Good luck with the cracker, and don't forget to send it to me if it works! :-)
: Is your cracker for Blowfish, or for BestCrypt?
Yeah, it is for BestCrypt, specifically BestCrypt containers using the
Blowfish Algorithm.
As I recall from a previous
: thread
: you had forgotten your BC password. If the cracker is for BestCrypt
: you'll need to be sure about the way in which they've implemented
: Blowfish -- if that is what it really is. Does the company make the source
: code available?
Yeah, Joe, they do. They have an awesome BestCrypt Development Kit available
including source of the keygeneration and the actually blowfish code.
: I hope you're writing this cracker in C and using PCL. Don't forget to give
: Pavel
: some credit.
I'm not using PCL although I'm still considering it. The cracker is going
to be in C. My real task is to find my password, once that happens (
probably 2^2873 years from now <grin>), then I can adapt and play around
with it. I won't be distributing it for quite some time...
: Joe
: __________________________________________
: Joe Peschel
: D.O.E. SysWorks
: http://members.aol.com/jpeschel/index.htm
: __________________________________________
Thanks for your help,
Keith
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: How do you make RSA symmetrical?
Date: Fri, 02 Jul 1999 20:11:03 GMT
Gilad Maayan wrote:
> David A Molnar wrote:
> >Can you tell us about your application?
> Naturally, I can't give any explicit details, but in general, this is
> what I'm trying to do:
> Take a function of the time (output: 20 bits), encrypt it using a
> large e (around 70-80 bits), and a 96-bit modulus.
I suggest you describe what you want to acheive and the
resources you have, rather than the cryptographic scheme
you intend to use.
--Bryan
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Greg Ofiesh <[EMAIL PROTECTED]>
Subject: Re: Quantum Computers
Date: Fri, 02 Jul 1999 20:15:56 GMT
> Finally, NSA has very few phyisicists on staff that I know of. They
> hired mathematicians, not physicists. Making a QC is still a physics
> problem not a math problem.
What is your source of NSA employees and what is your own professional
field?
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (S.T.L.)
Subject: Re: The One-Time Pad Paradox
Date: 02 Jul 1999 19:53:38 GMT
<<Even in the more likely
case that he got a *wrong* idea, he still joins it with me and
possibly acts upon it.>>
Scenario:
Alice and Bob are busy using a true, working OTP to send secret messages to
each other. Eve L. and N. O. Good are independent Adversaries trying to crack
them. One day, by sheer chance, Alice's OTP produces _some_ key that results in
an intelligible ciphertext. Eve L. sees it, and "joins it" with Alice, and
"possibly acts upon it." N. O. Good never sees the ciphertext. He doesn't even
know that Alice and Bob are communicating. Rather, he is quite psychotic and
has a delusion that he has seen the message "Attack At Dawn." Now, when N. O.
Good is a bit less psychotic, he joins that with Alice and "possibly acts upon
it". See?
There is no difference between Eve L. and N. O. Good. No information is STILL
leaked. It doesn't matter if the Adversary acts upon the ciphertext. The
Adversary is just as stuck as another one making blind guesses as to what Alice
and Bob are doing. If you want to prevent the Adversaries of the world from
possibly doing ANYTHING to you, then don't be a target for them. :-D The
stuff I've said about detecting a broken OTP still holds.
-*---*-------
S.T.L. ===> [EMAIL PROTECTED] <=== BLOCK RELEASED! 2^3021377 - 1 is PRIME!
Quotations: http://quote.cjb.net Main website: http://137.tsx.org MOO!
"Xihribz! Peymwsiz xihribz! Qssetv cse bqy qiftrz!" e^(i*Pi)+1=0 F00FC7C8
E-mail block is gone. It will return if I'm bombed again. I don't care, it's
an easy fix. Address is correct as is. The courtesy of giving correct E-mail
addresses makes up for having to delete junk which gets through anyway. Join
the Great Internet Mersenne Prime Search at http://entropia.com/ips/ Now my
.sig is shorter and contains 3379 bits of entropy up to the next line's end:
-*---*-------
Card-holding member of the Dark Legion of Cantorians, the Holy Order of the
Catenary, the Great SRian Conspiracy, the Triple-Sigma Club, the Union of
Quantum Mechanics, the Polycarbonate Syndicate, and People for the Ethical
Treatment of Digital Tierran Organisms
Avid watcher of "World's Most Terrifying Causality Violations", "When Kaons
Decay: World's Most Amazing CP Symmetry Breaking Caught On [Magnetic] Tape",
"World's Scariest Warp Accidents", "World's Most Energetic Cosmic Rays", and
"When Tidal Forces Attack: Caught on Tape"
Patiently awaiting the launch of Gravity Probe B and the discovery of M39
Physics Commandment #8: Thou Shalt Conserve Lepton Number.
------------------------------
From: Greg Ofiesh <[EMAIL PROTECTED]>
Subject: Re: Quantum Computers
Date: Fri, 02 Jul 1999 20:12:34 GMT
> If we use cryptosystems "orthogonal" or independent of those
> QC-acceptable algorithms attacks, then our cryptosystems are immune.
> QCs pose no threat if we are careful.
So, would you say that either DLP or ECDLP problems are immune from
QCs? How about the idea that QCs once developed sufficiently can
perform massive parallel computations? Then does any algorithm appear
immune to a QC? Just want to get your feel on this.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Decorelation again
Date: Fri, 02 Jul 1999 21:12:45 GMT
In article <[EMAIL PROTECTED]>,
Medical Electronics Lab <[EMAIL PROTECTED]> wrote:
> Check out the NIST AES papers and attacks.
> You should find some answers to these questions
> there.
I have some papers on decorelation, I just wanted to ask questions
before I dive in (kinda backwards no?).
Hmm I will read the papers then. Thanks anyways.
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
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: Quantum Computers
Date: 2 Jul 1999 21:14:34 GMT
Greg Ofiesh <[EMAIL PROTECTED]> wrote:
>> If we use cryptosystems "orthogonal" or independent of those
>> QC-acceptable algorithms attacks, then our cryptosystems are immune.
>> QCs pose no threat if we are careful.
> So, would you say that either DLP or ECDLP problems are immune from
> QCs?
Well, the standard DLP is not immune to a QC. There's
an algorithm described in Peter Shor's paper which
takes polynomial time (or maybe I should say a
polynomial number of
measurements).
I would have to go look at Shor's paper and subsequent
papers, plus some material on elliptic curves, in
order to see if this algorithm applies to the ECDLP.
>How about the idea that QCs once developed sufficiently can
> perform massive parallel computations?
This is where Scientific American and other popular
explanations of quantum computing have done us
all a disservice. About a year ago I tried to
explain QC to someone using the rhetoric of
"then it's put in a superposition of ALL POSSIBLE
STATES", after which the operation works on
"ALL OF THEM AT ONCE!!" leading to "INSTANT
computation of the answer!"
I was ripped apart and rightly. i
Also annoying
is the metaphor of "imagine you are looking for
someone in a hotel. Now say you could clone yourself
and search all the rooms at once!" This was
actually used in a "Philosophy of Quantum Mechanics"
class a friend of mine took.
There is a kernel of truth to the first
metaphor - you can create a "Cntrolled-U"
operator which either applies an operation U
to a qubit or does not, depending on whether
the state satisfies some test. This is used
in Grover's algorithm to pick out the
correct state from all the rest.
It indeed exhibits "parallelism" in that
it "checks" all the states it's applied to
in one operation.
Unfortunately, even with this "parallelism"
this operator must still be applied about
O(sqrt(n)) times before an answer is
apparent.
Here's a short and sloppy explanation.
Everyone else jump on me if I'm
screwing up.
Let's say we want to search an array.
We begin by preparing a vector of N quantum bits.
Each of these has a quantity referred to as "amplitude."
We start with all of the qubits at the same
amplitude. Say 1/sqrt(2).
|
|
|********************** Each * represents a qubit's amplitude.
|
-----------------------
|
|
|
We have two things we can do :
1) Apply a "Controlled-U" operator which makes the "correct"
qubit's amplitude slightly larger
2) Invert all of the amplitudes of the qubits around the average.
We do 1), and get
|
| *
|*********** ***********
|
------------------------
|
|
|
Now the "right" qubit stands out a little bit. Not enough
to notice yet, though. So invert everything with 2)
|
|
|
|
---------------------------
|************ *************
|
| *
The average changed when the "right" qubit's amplitude
increased, to the effect is to make the "right" one
a bit higher and the "wrong" ones a bit lower.
Then do 1) again, then 2), then 1), and so on.
Even though you get "parallelism" in step 1), you
still need to do this about sqrt(n), where n is the
number of qubits, times before you can definitively
state which is the "right" answer.
This is the best _general-purpose_ quantum algorithm
I know. Better ones exist for very special problems,
but not for, say, block ciphers.
>Then does any algorithm appear
> immune to a QC? Just want to get your feel on this.
Symmetric algorithms for which no attack is more
efficient than brute force simply double their keylength
for the same security. That's been pointed out elsewhere
in this thread.
RSA, Diffie-Hellman, and all others based on factoring
or discrete log fail. Maybe elliptic curve fails, but
I don't know.
IF BQP does not include NP, then maybe we can build
a public-key cryptosystem which depends solely on the assumption
P != NP. Current research in this area has focused on
the difficulty of approximating the length of vectors
in what is called a "lattice." So far all the public-key
systems I know of which have tried this route have
been cryptanalysed (Ajtai-Dwork died at Crypto '98,
Goldwasser et. al. will be analysed at Crypto '99),
but it's a neat idea.
Anyway, such a public-key system would possibly not
fall to a quantum computer.
So short answer : you can keep your block ciphers, but
public key crypto dies. Very sad.
-David Molnar
------------------------------
Date: Thu, 01 Jul 1999 20:12:06 -0400
From: [EMAIL PROTECTED]
Subject: Re: Quantum Computers
Mok-Kong Shen wrote:
>
> Douglas A. Gwyn wrote:
> >
>
> > One does need to keep in mind that the normal laws of
> > arithmetic need to be modified for infinities, and in
> > particular, infinity/infinity is indefinite, not 1.
> > The floating-point implementations are responsible for getting
> > such details right.
>
> I tend to think that the application of infinity is to cater for cases
> such as where something is divided by sin(x) where x becomes 0 due
> to rounding errors which could in turn be due to using some
> bad parameters in the algorithm or other causes in input values.
> Cases where some values become exactly 0 should appropriately
> be considered as such, since they very often have special meanings
> associated with them. Lumping that together with the normal
> case simply because the availability of 'infinity' allows one to do
> that so that codes can be shorter is something I personally wouldn't
> recommend to others who program.
Do you use separate rounding rules for even and odd numbers?
------------------------------
Date: Thu, 01 Jul 1999 20:10:34 -0400
From: [EMAIL PROTECTED]
Subject: Re: Quantum Computers
Douglas A. Gwyn wrote:
>
> Mok-Kong Shen wrote:
> > Maybe I misunderstood. But this appears to be something very
> > curious for giving to the hands of a practical programmer. If
> > one wants to 'catch' the case that 'quantity_seen' never gets
> > out of its initial value 0, one should check that directly. A
> > programmer that stays away from the so-called tricks wouldn't
> > code as above, I believe.
>
> For something like two decades now, there has been a very
> active numerical programming community that wants precisely
> this ability, namely to code a single formula without having
> to insert such special-case tests (which slow down the
> computation, are error-prone, and cause more work for the
> programmer).
>
> In complex analysis, the Riemann sphere is introduced (usually
> in connection with rational functions), which treats the
> "point at infinity" the same as any other point in the complex
> plane. This unifies the treatment and eliminates the need for
> special consideration of such things as:
> What happens to f(z) = (1-z)/(1+z) when z is -1?
> By allowing the "infinite" value to be treated consistently
> with other values, a great simplification is achieved, and all
> the formulas work *even in the "exceptional" cases*.
>
> Now, IEEE/IEC f.p. is strange in that it tries to assign
> *signs* to *distinct* values of infinity (also to distinct
> values of zero), which makes sense in some contexts but not
> in others. There have been great debates over the signedness
> issue, but not over the wisdom of computing with infinities
> (where appropriate). Mathematically, +0 and -0 are equal,
> and there is but a *single* "point at infinity" in the
> Riemann scheme, so whatever information the sign of zero or
> infinity is supposed to convey, it is not arithmetic information.
One reason for preserving the sign of a value as the magnitude goes to
infinity is to preserve the sign as an ordering criteria. In ascending
order minus infinity preceeds all other values and plus infinity
succeeds the rest.
>
> One does need to keep in mind that the normal laws of
> arithmetic need to be modified for infinities, and in
> particular, infinity/infinity is indefinite, not 1.
> The floating-point implementations are responsible for getting
> such details right.
------------------------------
From: [EMAIL PROTECTED] (David Hamilton)
Subject: Re: Quantum Computers
Date: Fri, 02 Jul 1999 21:45:54 GMT
=====BEGIN PGP SIGNED MESSAGE=====
Greg Ofiesh <[EMAIL PROTECTED]> wrote:
(Bill Unruh wrote)
>> Finally, NSA has very few phyisicists on staff that I know of. They
>> hired mathematicians, not physicists. Making a QC is still a physics
>> problem not a math problem.
>
>What is your source of NSA employees and what is your own professional
>field?
Greg, with your questions above, you picked up on the last quarter of Bill's
posting. But, you haven't replied to/commented on the majority of what he
said. The only thing I want to follow up on is Bill's first point about
whether your assertions have any basis in fact.
So, have you any facts to support your assertions? My reason for asking is
that there is one idiot in this newsgroup who asserts all manner of
ridiculous things without any evidence at all. There are others, though, who
can and do support their assertions if asked.
>Share what you know. Learn what you don't.
A laudable viewpoint.
David Hamilton. Only I give the right to read what I write and PGP allows me
to make that choice. Use PGP now.
I have revoked 2048 bit RSA key ID 0x40F703B9. Please do not use. Do use:-
2048bit rsa ID=0xFA412179 Fp=08DE A9CB D8D8 B282 FA14 58F6 69CE D32D
4096bit dh ID=0xA07AEA5E Fp=28BA 9E4C CA47 09C3 7B8A CE14 36F3 3560 A07A EA5E
Both keys dated 1998/04/08 with sole UserID=<[EMAIL PROTECTED]>
=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 5.5.3i for non-commercial use <http://www.pgpi.com>
Comment: Signed with 2048 bit RSA key
iQEVAwUBN30yUMo1RmX6QSF5AQGQrQgAqBMUPiegCyFV67RF3xSZ+3ouY8UcTQ48
KrXsuvYpeDw0Rpv6YRfbonxdbD/H9X0ahQhku7DrgEHbvWMs0fQZoK5qhgaVa65d
gV06//QRVzvsewbJDlmyQeQsyoaxvoT1JWsTzHRnZ1nCz8q7XxoKhGZcqDGEtTES
6fvGNijEifZoCh7UvfkWYQW8JMWzP3lKdX6GlTpZxNcupLj3KG//q4m0peEZ4gla
5HxLwJVXBLqzhm8ER60BrdpE3AxdOhxRP3r2zK46QqSdFPI0eyNV9BIWGzlM31Xm
3DVXfLj+RG77v23mzE6H3W3nJuK26MYb5TptfYqbMDQQeBkm3L0fFQ==
=bGB2
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: I don't trust my sysadmin
Date: Fri, 02 Jul 1999 21:10:58 GMT
<snip>
What are you trying to protect against? Man in the middle type
things? Or is the uname/pword logged?
tom
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
******************************
