Cryptography-Digest Digest #498, Volume #10 Wed, 3 Nov 99 01:13:02 EST
Contents:
Re: Compression: A ? for David Scott (CoyoteRed)
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column ("Trevor
Jackson, III")
Re: Scientific Progress and the NSA (was: Bruce Schneier's Crypto ("Douglas A.
Gwyn")
Re: cryptohoping ("Douglas A. Gwyn")
Re: Doesn't Bruce Schneier practice what he preaches? (John Kennedy)
Re: announcement: steganography program "steghide" (John Kennedy)
Re: Compression: A ? for David Scott (CoyoteRed)
An encryption proposal from a Newbie... (CoyoteRed)
Re: announcement: steganography program "steghide" (CoyoteRed)
Re: announcement: steganography program "steghide" (David A Molnar)
Re: An encryption proposal from a Newbie... ("Douglas A. Gwyn")
Re: What is the deal with passwords? (Tom St Denis)
Re: What is the deal with passwords? (Tom St Denis)
Re: Incompatible algorithms (Tom St Denis)
Re: Your Opinions on Quantum Cryptography (Tom St Denis)
Re: What is the deal with passwords? ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (CoyoteRed)
Subject: Re: Compression: A ? for David Scott
Date: Tue, 02 Nov 1999 23:54:22 GMT
Reply-To: CoyoteRed (at) Bigfoot (dot) com
On Mon, 1 Nov 1999 22:03:09 GMT, Tim Tyler <[EMAIL PROTECTED]> wrote:
>This would only work if random files typically didn't decompress.
>David has said that this is not true for his technique.
>
>AFAICS, it isn't true for the method I describe either - random files are
>likely to expand significantly when decompressed.
>
>: (It was mentioned something about output of /random data in/ (an
>: unsuccessful decryption) would be /random data out/ which, in turn, doesn't
>: compress well.)
>
>It was /mentioned/, but AFAIK, it isn't true, for either routine.
If you take relatively random data (the kind one may get from an
improperly decrypted file) and expand, what kind of data do you do get
out? Random, structured?
Also, if it expands out, how do the ratios of /invalid/ data expansion
compare to that of /valid/ data?
BTW: I'm a newbie to this group, what is AFAICS and AFAIK? Also,
where do you recommend on the web for independent reading on crypto.
Such as, is an OTP the same as the "random file the length of the
message that's used only once" we've been talking about?
>
>It /may/ even be possible to rule out keys based on decompressing
>only *part* of the file. This depends on the compression routine, and how
>"local" it is.
I agree, because if a decompression routine relies on some /expected/
input and fails to get it, then we can assume that the attempted key
is wrong or the sender used a different compressor and that test is
over. But if we can decompress completely with any file this removes
this sort of test. And, I like the triple-pass scheme of compression
someone described of David's routine.
>
>There's still the question of where do you get the "random" file from?
I gave a tongue-in-cheek response to 'Proposal: Inexpensive Method of
"True Random Data" Generation', but the more I think about it the more
I like some of those answers. I believe the important thing is
/gather/ the random data rather than /generate/ it. Generating
implies some sort mathematical formula or manipulation and any such
could possibly be figured out and duplicated.
>
>This is the same problem as I mentioned before. If you have an
>encrypted file (with random contents) and a message encrypted by
>XORing with those same random contents, then an attack considering both
>the message and the encrypted random data has some chance of success.
I'm not sure how. Because of the unpredictive nature of the a random
file, even if the attacker correctly guessed part of the file, is
there a way for him to predict the rest? (Other than simple
syntactics...) Because the random file is "random" he could make the
plain text say anything he want's, but where's the test to see if he's
right?
>It may be possible for the analyst to use this information to concoct
>an attack on the encryption of the message with the random data.
Hmmm... I'm sure you're right, but it may be easier to attack the
public key. If he was successful then he could decrypt the random
file at will and thus the ciphertext.
>For example, a known-plaintext attack is unaffected by the use of your
>approach - except in so far as the file size has been reduced by the
>compression.
>
>*If* such a scheme proves more resistant to attack than plain
>compress/encrypt then it /may/ be an interesting way of trying
>to increase security at the expense of bandwidth.
And speed. Because, from what I understand asymmetric encryption is
complex and slow. We're encrypting a /much/ larger key (our random
file the length of the message). Granted the XOR will take a blink of
the eye...
But we're getting far away from the discusion of compression...
--
CoyoteRed
CoyoteRed <at> bigfoot <dot> com
http://go.to/CoyoteRed
PGP key ID: 0xA60C12D1 at ldap://certserver.pgp.com
------------------------------
Date: Tue, 02 Nov 1999 19:32:32 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
SCOTT19U.ZIP_GUY wrote:
> In article <[EMAIL PROTECTED]>, "Trevor Jackson, III" <[EMAIL PROTECTED]>
>wrote:
> >[EMAIL PROTECTED] wrote:
> >
> >> In article <[EMAIL PROTECTED]>,
> >> [EMAIL PROTECTED] (Stefek Zaba) wrote:
> >>
> >> >The ciphersuite negotiation has been simplified from the
> >> >SSL2.0 days: it's now as brutal as: initiator (client) sends ordered
> >> >list (which, to David W's point later in the message excerpted above,
> >> >had better contain ONLY algorithms the client considers adequate for
> >> >its interaction); responder (server) picks exactly one, or aborts.
> >> >There is *no* renegotiation or independent negotiation of particular
> >> >attributes - cihpersuites come as a particular package of <key-
> >> >agreement, bulk-cipher, MAC>. And the negotiation messages are
> >> >themselves MAC'ed, defeating the simple active attack which SSLv2 was
> >> >open to. Protection against protocol version rollback attack is also
> >> >incorporated.
> >>
> >> In another message (see:
> >> http://www.deja.com/threadmsg_ct.xp?AN=540914195" ) I suggested to send
> >> a list of only *one* ciphersuite, i.e. not to send a list at all. If I
> >> send a message containing my information, it should be I who defines
> >> how to encrypt it - not the other party in some way. Security should
> >> not be negotiable.
> >
> >Why do you care? If you choose a set of ciphers in which you trust you
> >*are* defining how to encrypt your information.
> >
> >If you are stuck at 3DES and the other person insists upon AES_1, will you
> >prefer to not communicate rather than communicate with a cipher other than
> >your favorite?
> >
> >Do you also have a preference for particular keys?
> >
> >
>
> I know I am getting in this late but if one person has his heart set on
> 3DES and another AES_! why not allow them to use both in series so
> that both methods can be used at once.
I believe that cipher stacking or layering is an appropriate solution to this kind of
dispute. But I suspect you still need to resolve the original issue, selecting ciphers
dynamically, because I may decide that to change the cipher that I selected. In order
to do
so I have to make a new selection from within the intersection of the cipher I'm
willing or
able to use and the cipher's my respondent is willing to use.
Layering helps by preventing arguments, but it still leaves the original issue open
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Scientific Progress and the NSA (was: Bruce Schneier's Crypto
Date: Wed, 3 Nov 1999 00:59:19 GMT
"SCOTT19U.ZIP_GUY" wrote:
> But what are these important and difficult tasks.
Gee, an easy question! Basically, to obtain information
useful to the US executive branch (including defense) by
the analysis of foreign signals, and to protect the
security of official US communications. There have been
extensions of this fundamental mission, but that's the
gist of it.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: cryptohoping
Date: Wed, 3 Nov 1999 01:01:57 GMT
> Your "hopping" will have to depend on the key, so all you're
> doing is making the key a bit bigger. A brute-force search for
> and n-bit key is still a brute-force search for an n-bit key,
> no matter how weird the algorithm is.
But that's only relevant when no other attack than brute-force
key-space search is possible.
------------------------------
From: John Kennedy <[EMAIL PROTECTED]>
Subject: Re: Doesn't Bruce Schneier practice what he preaches?
Date: Tue, 02 Nov 1999 21:12:33 -0500
On Tue, 2 Nov 1999 13:14:28 -0500, "Adam Durana" <[EMAIL PROTECTED]>
wrote:
>> Cryptographic software is a special case.
>>
>> If you want to use high quality cryptographic software with released
>> source your are in fact not living in a dream world, but this one. You
>> can even get it for free.
>> PGP
>>
>
>I am sure we can all list software which is open source that uses
>cryptography. I am restricting what I said just to software built for
>cryptographic purposes.
But that IS what I am talking about.
> What you are saying is you don't want to trust
>anything you can't have the source code to.
Not at all.
> But I am sure you are using
>something right now you don't have the source code to, maybe your news group
>reader? (Please don't post and say 'Ha I'm using an open source news
>reader', think of something else you don't have the source to) How do you
>know your news group reader isn't logging all your posts and sending them to
>some secret server that does something bad with them?
It may for all I know. But if my crptographic software is secure I
need not expose any of my secrets to it.
Again, cryptographic software is a special case. I have no interest in
the soure to my mail reader.
> My point being you
>put trust in software design everyday. Its silly to say things are any
>different for software which uses cryptography.
No, it absolutely is not.
> There are millions of
>applications which use cryptography which are not open source, probably more
>than the number of open source programs using cryptography. And another
>thing, even with open source how many people mime through the source code
>before using it? Source code is not usually consulted until a problem
>arises.
>
>-- Adam
>
-
John Kennedy
The Wild Shall Wild Remain!
http://members.xoom.com/rational1/wild/
------------------------------
From: John Kennedy <[EMAIL PROTECTED]>
Subject: Re: announcement: steganography program "steghide"
Date: Tue, 02 Nov 1999 21:07:31 -0500
On 2 Nov 1999 00:16:12 GMT, David A Molnar <[EMAIL PROTECTED]>
wrote:
>John Kennedy <[EMAIL PROTECTED]> wrote:
>>>
>>>Assuming you can guarantee that an adversary who inspects what you're
>>>sending can't figure out the receiver, of course. :-)
>
>> That's not traffic analysis.
>
>If an adversary can see that Alice is sending a message, guesses the
>message is to Bob, can verify his guess, but can't
>tell what the contents of the message are, that's not traffic
>analysis? What is traffic analysis?
Upon reconsideration, I retract my objection.
Carry on sir!
-
John Kennedy
The Wild Shall Wild Remain!
http://members.xoom.com/rational1/wild/
------------------------------
From: [EMAIL PROTECTED] (CoyoteRed)
Subject: Re: Compression: A ? for David Scott
Date: Wed, 03 Nov 1999 02:22:10 GMT
Reply-To: CoyoteRed (at) Bigfoot (dot) com
On Wed, 03 Nov 1999 00:10:10 GMT, [EMAIL PROTECTED]
(SCOTT19U.ZIP_GUY) wrote:
> I think you still miss the point. That was not that o-o-o makes an
>encryption system impossilbe to attack. But that it adds no information
>to the encryption system that a non o-o-o would add. The non o-o-o
>compression leaves info that allows attacks. But let me know what you
>get when you run the tests.
Okay, but it will take awhile for me to gather everything I need...
--
CoyoteRed
CoyoteRed <at> bigfoot <dot> com
http://go.to/CoyoteRed
PGP key ID: 0xA60C12D1 at ldap://certserver.pgp.com
------------------------------
From: [EMAIL PROTECTED] (CoyoteRed)
Subject: An encryption proposal from a Newbie...
Date: Wed, 03 Nov 1999 02:17:34 GMT
Reply-To: CoyoteRed (at) Bigfoot (dot) com
Yes, I can hear the groans already, but...
Okay, let's first assume that this form of encryption will be used for
relatively small messages AND this will be for one-to-one two-way
highly-secure communications.
First, we need a random number that is 64k in size. (Never mind where
we get this number, that's for another discussion, but it must be
random, not pseudo-random.) And we need to have both parties have
this number.
We will both generate new key pairs that we will use for communicating
with each other. These pairs are shared with each other in an
encrypted form so they are never open to the public.
(A side note: to distribute this number, have one party come up with
the number and the other generate a large key pair and send his
partner the public key, encrypted, and the random number can be sent
back and the public key destroyed. We would have only one message
with that key out there.)
Once both parties have this number, it is divided into 64 1k files.
To encrypt a file, we generate a random 64 bit key (which will really
be an index) by what ever means at our disposal. Each bit of this
index represents one of those 64 1k files.
For each bit that is "on" XOR the 1k random file with the next file
that is "on", continue until each bit that is "on" and it's
corresponding file has been XOR'ed in. This is our pseudo-random
number generator, but because it does not rely on any mathematical
computations it should not be able to be guessed.
Next, XOR your plaintext with this number. If we run out of room in
our 1024 bit number, we back up 65 bits. Generate a new 64 bit index
key and add a "1" bit to our previous index (to be a 64bit key plus a
"1"bit). We generate a new pseudo-random number with this key and
continue with ciphering until we run out of plain text.
Next, we use our partners public key to encrypt our 65 bit index key
and add it to the beginning of our ciphertext.
Our partner just strips off the first 65 bits, decrypts it with his
key and reverses the above process.
The advantages of this scheme that I see are:
It has nearly the security of a OTP, it's not as secure because of the
off chance of a number being repeated.
Once we both have the number, we should be able to generate 2^64 OTP's
if we choose. The off chance of a duplicate should be remote in the
extreme if our 64 bit index key is chosen randomly.
A successful attack on the asymmetric keys will only reveal our 64 bit
index, the attacker would still have to analyze the 64 1k files and
these are publicly defended by a different key that was used only once
(and that key was encrypted.)
The ciphertext is small with only 65 bits overhead per 960 bits per
data.
It is FAST!
I know a main weakness will be the 64 bit key that is generated for
our index. So we must concenrate on it's randomness. Of course, we
could build a list of used indexes and never use the same one twice,
this /would/ make it a OTP.
A disadvantage is it's setup, you can't just grab someone's key and
send away.
So... what do you think? How secure? Aside from a physical attack,
what are it's weaknesses?
Thanks, in advance, for your kindly input.
--
CoyoteRed
CoyoteRed <at> bigfoot <dot> com
http://go.to/CoyoteRed
PGP key ID: 0xA60C12D1 at ldap://certserver.pgp.com
------------------------------
From: [EMAIL PROTECTED] (CoyoteRed)
Subject: Re: announcement: steganography program "steghide"
Date: Wed, 03 Nov 1999 02:53:37 GMT
Reply-To: CoyoteRed (at) Bigfoot (dot) com
On Wed, 03 Nov 1999 01:42:20 GMT, [EMAIL PROTECTED] (jerome) wrote:
>Moreover probably very few website have as much readers
>than picture newsgroups.
True, one would only need to pose as a flooder and bury a steg'ed
file in with the pix. ...or warez and cracks.
And the observer would have to have access to alot of servers to find
out the reader.
If neither of the parties are known then one of those free picture
album sites would be good. Take a few nice pix and post them on this
site. Go to a photography NG, boast about your prowess and bang you
have traffic. After a while the site should have been archived and
you can start using it for communications. Take one of those files
and steg it. Your partner will know to check your album and how to
get the stegg'ed file. If none of the files are steg'ed then there
isn;t a message, etc. This way your binary doesn't go away after a few
days. Also, replace your steg'ed file with a non-steg'ed file after a
few days. I presume that crawlers only archive a file once, so if it
doesn't /appear/ to have changed then it wouldn't re-archive it.
A few schemes like this in place should be suffecient.
--
CoyoteRed
CoyoteRed <at> bigfoot <dot> com
http://go.to/CoyoteRed
PGP key ID: 0xA60C12D1 at ldap://certserver.pgp.com
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: announcement: steganography program "steghide"
Date: 3 Nov 1999 03:09:27 GMT
jerome <[EMAIL PROTECTED]> wrote:
> - The aim is to make the message looks like random so no known
> patterns/caracteristics.
maybe if we XORed the message with the output of a pseudo-random
generator ? there are PRGs floating around which can be proved to pass
all polynomial time statistical tests and are hard to predict...at least
for "large enough" parameters...
then it seems that distinguishing the encrypted message from random
would imply predicting the PRG. which is supposed to be hard. and if we
have confidence that the message is random, it becomes easier to find
places to put it in the carrier file.
-David
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: An encryption proposal from a Newbie...
Date: Wed, 03 Nov 1999 03:50:06 GMT
CoyoteRed wrote:
> It has nearly the security of a OTP, it's not as secure because ...
Your example had a lot of discrepancies, but it didn't seem
very "secure" to me... How are you determining its "security"?
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: What is the deal with passwords?
Date: Wed, 03 Nov 1999 03:35:40 GMT
In article <[EMAIL PROTECTED]>,
"Trevor Jackson, III" <[EMAIL PROTECTED]> wrote:
> Actually the chance is much smaller. Zero to be precise. OTOH, the
chance
> of someone _copying_ your floppy is much higher. Idle cusriosity on
the
> part of an "opponent" or even a f(r)iend, and a moment's inattention
by you
> is all it takes.
>
> And you would never know.
I knew you would say that. hehehe.
Ok well, believe what you want. First off my friends would not really
have the time alone to steal info off my computer, they are not that
versed. Second they wouldn't. So I don't need to worry, I don't know
what your friends are like though...
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: What is the deal with passwords?
Date: Wed, 03 Nov 1999 03:41:47 GMT
In article <[EMAIL PROTECTED]>,
John Kennedy <[EMAIL PROTECTED]> wrote:
>
> Okay, that was a very poor choice of words on my part and I can see
> why it would tick you off. That was not my intent. I should have said
> you could easily disable a security measure in PGP, one that you might
> not need, and achieve the same effect as PeekBoo. That's why I
> wouldn't exactly consider it an innovation. It does indicate some
> out-of-the-box thinking, which is good. Security should be talored to
> the application.
>
> Any requirement for encrypting the private key is specific to what you
> intend to do with it.
Ah ok. Well I think encrypting the pgp keys is a good idea, but
frankly most newbie users would not figure it out easily enough
anyways...
> Well for one thing, I sometimes miss what's right in front of me,
> believe it or not I had not made the connection that you were the
> author. I guess I've been skimming.
Well I think I have plugged peekboo enough. It's ok it so happends I
make mistakes too [and if you read the usenet you will note often].
> I have not spread any lies, I speculated out loud in a newsgroup. I
> thought 41k seemed awfully small for the functionality claimed but I
> don't have anything hard to base that on. I've done lots of DOS and
> Widows programming but no crypto programming to speak of. I know
> there are versions of PGP available that are only a few hundred K so
> 105K sounds more plausible.
Well just because I code well doesn't mean it's a bad program. Yes at
first glance I would probably think the same, but I know people who
have written 23k compilers that run on 6809s ... so that's nothing big.
> As you say, the proof is in the source. I have no inclination to look
> at it since PeekBoo is probably not an application that's a good fit
> for me. It may well be for many other people. They'll judge. PeekBoo
> sounds to me like it would be good for some. The web page says the
> right things about crypto, not the wrong things. I have no qualms
> about encouraging people to explore PeekBoo if it sounds like a good
> fit for them.
It would be funny to see the two of us in a room. I think we have lots
of communication skills to work on :)
> The reason you gave for PGP being more than 7mb in size is simply
> wrong, it has nothing to do with encrypting private keys. There's a
> command line version of PGP 6.51 that fits on a floppy and the older
> DOS versons are quite a bit smaller.
Not to mention perfectly ill suited for the purpose at hand. I
personally view pgp as a more static program. Usefull for once in a
while things (xcept maybe with email plug ins).
>
> >Otherwise keep shut.
>
> I didn't intend to rub you the wrong way, but frankly I'm going to
> post here any damn time I please, and speak my mind as I see fit.
Your right, I should have not said that.
> >btw when I said 41kb vs 7500kb I am talking about alot of extra
things
> >they don't need todo. I would admit I should add file encryption to
> >peekboo, but that doesn't have to make it 7mb in size...
>
> Thats different from what you originally said. And its true, PGP does
> not have to be anything like 7mb to offer the encryption it does.
Bingo. The install is 7.5mb. Even if I only want to encrypt a silly
message or email or something.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Incompatible algorithms
Date: Wed, 03 Nov 1999 03:44:16 GMT
Refer to the MARS AES submission, and do not reply until you know why I
said that.
Tom
In article <[EMAIL PROTECTED]>,
Max Polk <[EMAIL PROTECTED]> wrote:
> I have a question about the existance of what I call "incompatible"
> algorithms.
>
> If a plaintext message M is encrypted with algorithm E to produce
> ciphertext C, i.e.:
>
> E(M)=C
>
> then there are many algorithms E1, E2, E3, etc. that are "compatible"
> with algorithm E such that the time complexity of breaking E1(E(M))
is
> the same order of magnitude as breaking E(M). That is to say, you
aren't
> adding security by encrypting a message twice when the algorithms are
> "compatible". If "T" is the time to break ciphertext, then:
>
> T(E1(E(M))) is approximately equal to T(E(M))
>
> and if we use "big-oh" notation O as the order of magnitude of the
time
> complexity to break ciphertext, then
>
> O(E1 x E) = O(E).
>
> For example, algorithm E is a simple letter substitution, and
algorithm
> E1 is a different simple letter substitution. In this case, E1 and E
are
> 100% compatible in both order of magnitude of time complexity as well
> as time complexity itself. There is an algorithm E2 that is a simple
> letter substitution representing the combination of E1 and E.
>
> My question is whether there exists "incompatible" algorithms E and
E1
> such that there exists no E2 that is a composite of E1 and E:
>
> E2(M) = E1(E(M))
>
> whose order of magnitude to break the ciphertext is the same as the
order
> of magnitude to break the ciphertext produced by applying E then E1
to
> the plaintext. That is:
>
> O(E2) != O(E1 x E)
>
> If there exists such a pair of algorithms E and E1, then encrypting a
> message with one then the next algorithm is an order of magnitude
more
> difficult to break than any existing equivalent composite algorithm.
>
> If these algorithms exist, then they are "incompatible" in the sense
that
> one cannot obtain a composite algorithm equally difficult to break.
> Stated another way, applying incompatible algorithms make breaking
the
> resulting ciphertext at least an order of magnitude higher.
>
> Furthermore, if it can be proven that such "incompatible" algorithms
> exist, then we can explore the possibility of finding a mathematical
> inductive proof to show the existence of a chain of incompatible
> algorithms. For example, there exists no E3 such that
>
> O(E2) > O(E1 x E)
> and
> O(E3) > O(E2 x E1).
>
> Any attempt to break a chain of such "incompatible" algorithms then
grows
> in order of magnitude at each step to such a degree of complexity as
to
> make the ciphertext arbitrarily secure.
>
> If this is all true, it may be possible to make the time complexity
of
> breaking the ciphertext 10 to the power of n where n equals the
number of
> steps in the chain.
>
> In this case, each additional algorithm applied makes the solution
grow
> very rapidly. Only 10 algorithms applied successively, each taking
10
> seconds to break, results in a solution time of 10 to the power of 10
> seconds, or about 316 years.
>
> Has any research been done on the existence of "incompatible"
algorithms,
> especially in the context of producing arbitrarily secure ciphertext?
>
--
damn windows... new PGP key!!!
http://people.goplay.com/tomstdenis/key.pgp
(this time I have a backup of the secret key)
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Your Opinions on Quantum Cryptography
Date: Wed, 03 Nov 1999 03:48:01 GMT
In article <7vnnus$l2e$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Dear All,
>
> I am preparing a short paper on Quantum Cryptography. I would be most
> grateful if you could give your opinion/thought/knowledge on the
> following points:
>
> 1. Is there a need for Quantum Cryptography?
No. Modern cryptography is strong enough. Quantum key exchange might
prove usefull.
> 2. Will Quantum Cryptography reach a phase where it can be implemented
> over long distances successfully?
Probably. Will martians invade earth at the same moment all three laws
of thermodynamics are broken?
> 3. Will Quantum Cryptography become a neccesity against increasing
> advanced crypto attacks?
I thought quantum computers were used TO BREAK modern cryptography...
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: What is the deal with passwords?
Date: Wed, 03 Nov 1999 03:54:10 GMT
I have recently been playing with peekboo, and find it to be a neat way
of encrypting email with minimum overhead. However, I questioned Tom
about the lack of password protection, and am pleased that he is
considering implementing one. I like PGP and use it, but it is pretty
heavy duty (and requires an install) for what I need. peekboo might be
a good additional product.
My reason: I want to be sure that people with access to my computer
(either at work or at home) cannot simply run peekboo to decrypt my
email. My work computer is connected to a network and therefore I
consider it insecure. I *could* put it on a floppy, but, frankly,
can't stand the idea!
My solution: the program and .dat file are stored on a PGPDisk, so
that a password is needed to access the disk and therefore the
program. I close the disk whenever I am away from my computer. I
realised this does not help on my work computer, but it's a risk I can
live with.
Regards,
Brendan.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
** 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
******************************
