Cryptography-Digest Digest #80, Volume #11 Wed, 9 Feb 00 14:13:01 EST
Contents:
Re: I'm returning the Dr Dobbs CDROM ([EMAIL PROTECTED])
Re: New standart for encryption software. (Eric Lee Green)
Re: Blowfish Question (Eric Lee Green)
Re: New standart for encryption software. (David Kessner)
Encryption protocol questions ([EMAIL PROTECTED])
Re: New standart for encryption software (Eric Lee Green)
Re: Guaranteed Public Key Exchanges (Bob Silverman)
Re: Anti-crack (Mike Rosing)
Re: Hill Climbing (Mark VandeWettering)
Re: question about PKI... (Palmpalmpalm)
Re: Continually Secure Password/Pin ([EMAIL PROTECTED])
Re: Guaranteed Public Key Exchanges (Paul Koning)
Re: Guaranteed Public Key Exchanges (No Brainer)
Re: Does hashing an encrypted message increase hash security? (Mike Rosing)
Re: Factorization (Mike Rosing)
Re: Guaranteed Public Key Exchanges (Mike Rosing)
Re: Strip Security ("Steven G. Tyler")
Re: Prior art in science (Mok-Kong Shen)
Re: Guaranteed Public Key Exchanges (No Brainer)
Re: Guaranteed Public Key Exchanges (No Brainer)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: I'm returning the Dr Dobbs CDROM
Date: 9 Feb 2000 17:12:39 GMT
Victor Zandy <[EMAIL PROTECTED]> wrote:
> I am returning the CDROM because it is not suitable for printing.
> For example, to print chapter 1 of the Stinson book (44 pages) Adobe
> acroread (x86/Solaris 2.6) creates a 500MB postscript file. I cannot
> print this file directly, probably because it is too big. Although I
> might be able to find a way to print the file, at 500MB it would take
> too much time.
> I don't know how the PDF files on the CDROM were prepared, but
> they look like they were scanned from physical book pages. For recent
> titles, like Stinson, they should have been generated from the
> computer originals to make a smaller file, with better image quality.
It's pretty clear that the pages are scanned in. I was a little
disappointed by the visual quality this produces -- especially for
Bruce Schneier's book. He does a lot with DDJ, and wrote the
'forward' for the CD-ROM, and his book is placed prominently on the
CD. Surely he has electronic masters that this could have been made
from, rather than the scanned pages they use.
On the other hand, I differ with your final conclusion. I'm very
happy with this CD-ROM. I can't imagine buying this to print out
whole chapters or whatever.... if you want good quality printouts,
buy the books! For quick reference though it's great. In my
briefcase I can carry the DDJ CD-ROM, the about 20 years of CRYPTO and
EuroCrypt proceedings (CD-ROM available through Springer-Verlag), and
about 20 years of IEEE Security and Privacy proceedings (CD-ROM
available through IEEE). That's a hell of a reference library to have
available in such a small space....
--
Steve Tate --- srt[At]cs.unt.edu | Gratuitously stolen quote:
Dept. of Computer Sciences | "The box said 'Requires Windows 95, NT,
University of North Texas | or better,' so I installed Linux."
Denton, TX 76201 |
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: New standart for encryption software.
Date: Wed, 09 Feb 2000 10:24:22 -0700
finecrypt wrote:
> More comments about FineCrypt from crypto gurus will be appreciated.
I suggest that you go to http://www.deja.com and browse the thread about PGP
that was on this group recently. Some people were doubting PGP's security. In
particular, they were doubting the strength of the key generator -- the best
encryption algorithm is useless if the key generator will only generate a
small group of keys. I pointed out that a) the source code to PGP was
available (http://www.pgpi.com ), and that in fact, somebody had cryptanalyzed
the key generator to ascertain its strength and published a paper on the topic
(turns out that it's a decent one).
Key generators are a well-known attack on encryption systems. See, e.g., the
attack on Netscape's SSL implementation (where it was discovered that it would
generate only 2^24 possible keys -- easily attackable even by an Apple II).
There are lots of other attacks on encryption systems that don't require the
encryption algorithm itself to be weak. Then there are weak encryption
algorithms themselves, or mis-implemented ones, that may even leak key data to
attackers (e.g. LCGPRNG-based stream ciphers). None of which can be easily
detected by encrypting and decrypting test vectors with a few keys.
In short: If it ain't source, it ain't secure, as far as most crypto types are
concerned. There's been too many cases of government bodies bribing crypto
companies to put in hidden back doors (See the Crypto A.G. case, for example)
for anybody to trust closed-source crypto nowdays.
--
Eric Lee Green [EMAIL PROTECTED]
Software Engineer Visit our Web page:
Enhanced Software Technologies, Inc. http://www.estinc.com/
(602) 470-1115 voice (602) 470-1116 fax
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: Blowfish Question
Date: Wed, 09 Feb 2000 10:28:07 -0700
Chung W Leong wrote:
> ...on the other hand, it just occur to me that the encryption scheme is
> rather futile. Since credit card numbers have far less entropy than the
> encryption key, one can just brute-force against that.
Well, the point of not brute-forcing credit card numbers is that the credit
card clearing houses will shut down the terminal if you have more than <n> bad
attempts in a row, and won't re-enable the terminal until you call the
clearinghouse and give them a Magic Password".
As for the limited-entropy problem, that can be somewhat resolved by using a
"salt" value and a cipher feedback mode.
None of which is any use if the system can be compromised and the key
retrieved off its hard drive, of course.
--
Eric Lee Green [EMAIL PROTECTED]
Software Engineer Visit our Web page:
Enhanced Software Technologies, Inc. http://www.estinc.com/
(602) 470-1115 voice (602) 470-1116 fax
------------------------------
From: David Kessner <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: New standart for encryption software.
Date: Wed, 09 Feb 2000 10:31:39 -0700
finecrypt wrote:
> More comments about FineCrypt from crypto gurus will be appreciated.
All crypto gurus are in agreement: Johnny Bravo is correct in his
statements.
David Kessner
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED]
Subject: Encryption protocol questions
Date: Wed, 09 Feb 2000 17:53:59 GMT
Hello,
I have a few questions about the proper uses of encryption and the
protocols necessary.
Say I receive an encrypted message over an unsecure channel. I
decrypt it, perform error correction on it, and then re-encrypt it
with the same key and same algorithm. I then transmit it to another
place via another insecure channel. As usual, all algorithms are
public; only the keys are secret.
Is there a "rule" somewhere that says it's not a good idea to this?
What if I re-encrypt using a different key? (NOT encrypt once with
key 1 and then again with key 2) Do the answers here depend on the
strength of the encryption algorithm?
My sense is that in the first case it is not a good idea because the
corrected bit errors could reveal almost directly the underlying data
and thus the cryptographic transformation. This would probably be
fatal in DES (would it?). What about a stream cipher like RC4?
I am not a cryptanalyst, so I don't know if re-encypting with a
different key would help. My suspicion is that it wouldn't, but I
don't know why, except that things that look like simple solutions in
cryptography are usually flawed. I haven't read anything of Bruce's
yet that says this is a bad idea (I have his book and read his
Counterpane articles)..... Pointers to other useful books or web
sites are appreciated.
Thanks for the help,
Charles R. Wright
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: New standart for encryption software
Date: Wed, 09 Feb 2000 10:56:02 -0700
[EMAIL PROTECTED] wrote:
> I wonder if Entrust, Verisign, Data Fellows ...are going to comply with
> your request or suggestion.
First of all, Verisign is a public key repository. They do not themselves
encrypt any of your data, they merely store your public key so that somebody
else can encrypt/decrypt your data.
Secondly, there are many, both overseas and in this country, who believe that
most of the closed-source cryptography products contain "back doors" allowing
law enforcement agencies and "no such agencies" to gain access to the contents
of encrypted communications. Whether this is true or not does not matter. What
matters is that most Europeans will *NOT* use an American-made closed-source
cryptography product, because they view such products as containing NSA back
doors. (Not that closed-source European products are any better... eg. it was
revealed that at least one Swiss cryptography vendor put modifications into
their machines at the behest of the NSA to leak key material as part of the
data stream).
One reason that PGP is so popular (and so hated by most closed-source vendors)
is because you can go to http://www.pgpi.com and download the source code,
examine it yourself, and verify that if there's a back door in there, it's a
mighty subtle one. Not that I, personally, would bother doing so... but you
can bet that all of PGP's competitors are doing so at this very moment, and if
they could find a weakness, there would be papers submitted to various
journals at this very moment demonstrating those weaknesses. That is what
gives me confidence that PGP, if compromised, is not significantly
compromised. I have no such confidence regarding closed-source cryptographic
software.
--
Eric Lee Green [EMAIL PROTECTED]
Software Engineer Visit our Web page:
Enhanced Software Technologies, Inc. http://www.estinc.com/
(602) 470-1115 voice (602) 470-1116 fax
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: Guaranteed Public Key Exchanges
Date: Wed, 09 Feb 2000 17:49:01 GMT
In article <[EMAIL PROTECTED]>,
No Brainer <[EMAIL PROTECTED]> wrote:
> Does anyone know of a secure way to exchange public keys between two
> people via the Internet (e-mail) without using any other form of
> communication?
Public keys are already public. Why is there a
need to exchange them via mail? Or perhaps you mean exchange a
private key USING public keys?
--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: Anti-crack
Date: Wed, 09 Feb 2000 11:53:35 -0600
Vernon Schryver wrote:
>
> In article <AG_n4.142$[EMAIL PROTECTED]>,
> John E. Kuslich http://www.crak.com <[EMAIL PROTECTED]> wrote:
> >I have now read the article and I do NOT recommend it.
> >
> >I found it superficial and sometimes offered silly suggestions...
>
> >There are very excellent sources of better advice and information ...
>
> > ... They require some Net searching skill to find. :--)
> >
> >Anyone with adequate motivation and skill ... ... will
> >easily find them.
>
> That applies to most computer trade rag inter-ad filler on any topic.
> When you find an trade article informative, an alarm should sound warning
> that you probably know even less (i.e. a lot that is false) than the little
> that you knew before reading the article. Only if you started completely
> ignorant, you forget most of what the article says, and you remember that
> you still know practically nothing can you hope to come out ahead.
Ouch. Sorry I suggested it. I didn't read it, usually everything in
Embedded Systems is pretty good. Makes you wonder what they paid to
advertise so they got the article on the cover.
Patience, persistence, truth,
Dr. mike
------------------------------
From: Mark VandeWettering <[EMAIL PROTECTED]>
Subject: Re: Hill Climbing
Date: Wed, 09 Feb 2000 09:52:30 -0800
Michael Darling wrote:
> The Singh book has led to a great deal of interest in GA and Hillclimbing -
> a lot of knowledge being understandably
> jealously guarded while the challenge goes on. I'm looking forward to
> someone completing the challenge. Maybe
> Jim Gillogly who I see has contributed a good post below, or Andrew Plater
> are even now making a breakthrough.
I have no delusions about winning the prize, so I am rather free with
the information that I put out. :-)
Nevertheless, I haven't found any of the stages I've cracked so far to
be
especially difficult. Stage 8 was harder because it took me a while to
get
my enigma simulator fixed, although Jim Gillogly's paper helped
enormously.
Stage 3 was hard because I went down about six wrong paths before
finally
figuring it out. I suspect that anyone who is capable of cracking
stages 5, 9, and 10 to be easily capable of cracking the rest. I'm a
bit
stymied at Stage 7 myself at the moment, but I've been busy with other
things
lately, so it hasn't received the concentration that some of the other
stages have.
I _do_ think there is some interesting discussion that can be had at the
end
of the competition. The use of GA and hillclimbing has been fun to play
with,
and I hope to be able to compare notes with others on it.
All in all, the excursion into "classic" crypto has been rather fun.
Mark
--
Mark T. VandeWettering Telescope Information (and more)
Email: <[EMAIL PROTECTED]> http://raytracer.org
------------------------------
From: [EMAIL PROTECTED] (Palmpalmpalm)
Subject: Re: question about PKI...
Date: 09 Feb 2000 18:03:11 GMT
Hi, thanks for kind answer.
The thing we get a new certificate for each access device; do you mean we make
privite-key/public-key pair and try to connect CA with the public-key? If it
is, how to guarantee that such sensitive values are not stored directly in a
hard disk device?
If CA issues the key pair and its certificate, should we get any hardware token
again?
I would appreciate it if you could kindly let me know how to revoke and how to
get a new certificate without handling the old private-key.
Thanks again.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Continually Secure Password/Pin
Date: Wed, 09 Feb 2000 18:03:48 GMT
Hello,
One problem with this is making sure the user (machine) doesn't forget
the iteration. If the user tries to log in from a different computer
that doesn't have the correct iteration, or if the client computer
forgets the iteration somehow (disk crash, ete.) the user is screwed.
I believe system like this was proposed or tested to prevent AMPS
cell-phone cloning. The main problem was keeping the two ends in sync.
Charles R. Wright
[EMAIL PROTECTED] wrote:
: When creating and using a user/password account on the web why isn't
: the following method used:
: Client types in user name and password, clients computer sends server
: user name and the one millionth iterative one way hash of the password.
: Server creates user name and stores said hash.
: When logging on first time user sends user name and the 999,999th
: iterative hash of the password. Server authenticates by hashing this
: and comparing it to last stored hash. On acceptance it allows access to
: account and updates servers hashed password to the new 999,999th
: iteration.
: Next time user logs on he uses the 999,998th iteration and so on.
: No eavesdropper can imitate the user on future login sessions.
: Server uses little processing time as it only needs to hash once.
: A variation of the system can be used to authenticate non certified
: telephone conversations (secure or insecure). 2^24 iterated hashes of
: passwords and associated user id could be stored on a public server.
: This represents the authenticity of user at the time of posting on the
: server. To authenticate at a time after that, the person wishing to
: confirm their id publishes the (2^24-((time-servertime)seconds))th
: iterative hash. This can be confirmed by access to the public server.
: It also can be used too in credit card/cheque authorisations etc.
: I've searched to see if a similar system has been proposed before but
: couldn't find it. If it does, could someone give me pointers?
: Gary. At ArchRivals.F9.Co.UK
: Sent via Deja.com http://www.deja.com/
: Before you buy.
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: Guaranteed Public Key Exchanges
Date: Wed, 09 Feb 2000 12:07:20 -0500
No Brainer wrote:
>
> Does anyone know of a secure way to exchange public keys between two
> people via the Internet (e-mail) without using any other form of
> communication?
Do you mean secret keys? Public keys need no confidentiality
(though they do need integrity).
There isn't one. If you have no other way of verifying who you're
talking to, clearly a "man in the middle" cannot be distinguished
from your intended recipient.
If you're willing to assume that there isn't a man in the middle,
Diffie-Hellman key agreement will do the job of setting up a shared
secret, which you can then use to protect the additional traffic.
If your threat model is that the *only* attackers you need to worry
about are passive listeners, that would work. I wouldn't want to
run the risk, though.
I remember a snake oil product a few years ago that claimed to
solve this problem. They carefully didn't tell you that they
were assuming no man in the middle.
In general, you *have* to have a "secure out of band channel" to
get started. That may mean face to face contact, a phone call
where you can recognize the other party by voice, or something
similar.
paul
------------------------------
From: No Brainer <[EMAIL PROTECTED]>
Subject: Re: Guaranteed Public Key Exchanges
Date: Thu, 10 Feb 2000 02:09:24 +0800
Bob Silverman wrote:
> In article <[EMAIL PROTECTED]>,
> No Brainer <[EMAIL PROTECTED]> wrote:
> > Does anyone know of a secure way to exchange public keys between two
> > people via the Internet (e-mail) without using any other form of
> > communication?
>
> Public keys are already public. Why is there a
> need to exchange them via mail? Or perhaps you mean exchange a
> private key USING public keys?
I was actually wanting to exchange public keys via e-mail over the Internet
and solve the "man in the middle" attack. Paul's reply provides the answer;
basically I need a secure "out of band channel" to set up the original
secret...however I thought there may be some kind of protocol whereby two
people unknown to each other can exchange public keys and retain integrity.
Oh well, back to the notepad :)
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: Does hashing an encrypted message increase hash security?
Date: Wed, 09 Feb 2000 12:21:25 -0600
Erann Gat wrote:
>
> Suppse I do the following:
>
> 1. Generate a 128-bit MD5 hash of a message.
> 2. Generate a second 128-bit MD5 hash of the same message encrypted
> with (say) Blowfish using an N-bit key.
> 3. Concatenate the results together to form a 256-bit hash.
>
> Does the resulting 256 bit hash have any more security than the
> original 128-bit MD5 hash by itself? How much more? What if
> the Blowfish encryption key is known -- is there still something
> to be gained in terms of hash security by concatenating a hash
> of the cleartext with a hash of the Blowfish ciphertext?
How about xor 1 and 2 to get a 128 bit result? Otherwise, you can
start with with 128 bit MD5 hash and just ignore the rest.
You can also just send 2, since both sides can perform the same
operations.
That would increase your security. If the encryption key is known,
you have a major problem anyway.
Patience, persistence, truth,
Dr. mike
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: Factorization
Date: Wed, 09 Feb 2000 12:24:30 -0600
David Nelson wrote:
>
> On Fri, 4 Feb 2000 21:22:53 -0700, Jerry Coffin <[EMAIL PROTECTED]>
> wrote:
> >The free "factor.exe" used to demo the MIRACL math package.
>
> Where can I download it?
ftp://ftp.compapp.dcu.ie/pub/crypto/
Patience, persistence, truth,
Dr. mike
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: Guaranteed Public Key Exchanges
Date: Wed, 09 Feb 2000 12:28:21 -0600
No Brainer wrote:
>
> Does anyone know of a secure way to exchange public keys between two
> people via the Internet (e-mail) without using any other form of
> communication?
>
> Also, would the proposed system work if *someone* was intercepting and
> modifying the key exchanges?
Nope. You gotta have an out of band exchange to prove no intercept.
For most applications, the probability of an intercept is small so it's
not that big a deal. But if you are going to really worry about it, you
have to assume your line is controlled by the "enemy" and you need more
than one channel of comm-link to ensure the exchange was clean.
Patience, persistence, truth,
Dr. mike
------------------------------
From: "Steven G. Tyler" <[EMAIL PROTECTED]>
Crossposted-To: comp.sys.palmtops.pilot,alt.comp.sys.palmtops.pilot,comp.sys.handhelds
Subject: Re: Strip Security
Date: Wed, 09 Feb 2000 13:26:07 -0500
Veli-Pekka Nousiainen wrote:
> Whenever I start cracking my own forgotten password(s)
> (which usually leads to a lock-up after 3 tries and I have
> to personally visit the bank after that occation) and I don't
> remember the length anymore, I start with the minimum
> length and then, if there is no protection for brute-force
> I go up in the amount of digits required. So would a bandit.
> It is nice to have a 12-digit field with a minimum of 4-digits
> password, but it doesn't help much if it is not used up to the
> max.
That's right, as I acknowledged in my original post. Using more digits
always makes a password harder to crack by brute force. However, a
would-be cracker might try to crack a *known* limited-to-4-digits
password, but might just pass when faced with, say, a *potentially* 12
digit (or more) password.
It's like most security -- you can't ever make your house or car
*completely* burglar-proof, but you *can* try to make it appear so
inconvenient the burglar goes elsewhere! ;-)
--
Steve on Cattail Creek (Steven G. Tyler, Esq.) <[EMAIL PROTECTED]>
The Computer Counselor -- Technology Consulting for the Law Office
Webmaster, Troop 339, BAC, BSA (http://members.aol.com/troop339)
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Prior art in science
Date: Wed, 09 Feb 2000 19:44:12 +0100
Terry Ritter schrieb:
>
> On Tue, 08 Feb 2000 07:25:50 +0100, in
> <[EMAIL PROTECTED]>, in sci.crypt Mok-Kong Shen
> <[EMAIL PROTECTED]> wrote:
>
> >Terry Ritter wrote:
> >>
> >
> >> Indeed, it may be far easier to search for and find something on line
> >> than in a library of individual books and magazine issues. I have
> >> personally conducted a grueling manual search through individual
> >> patent records which took two full man-weeks of time. Nowadays it's
> >> easier, of course.
> >
> >There can be no question that a search (on the same material with
> >the same structure) with the help of computer is far much better than
> >without. That's why patent searches online are nowadays used (this
> >facility has been available for European patents since some time).
> >However, if the material is in a poor state (containing much chaffs,
> >without keywords, etc. etc.) and is in 'extremely' huge volume, which
> >in my humble opinion is the case with newsgroups materials, then a
> >search can't be of superior quality in the first place, whether with
> >or without computer. That's why I suggested in another follow-up
> >that summaries of discussions be written (with classification labels)
> >and searches be done on these.
>
> As far I know, patent examiners do not even attempt to search Usenet
> news conversations. They instead rely upon their knowledge of prior
> patents (the ultimate "prior art") and the fact that each applicant
> puts forth their work and claims and known prior art under an oath of
> truth. Examiners also routinely disallow all claims in the first
> response, and thus require the applicant to discuss the prior patent
> art, and differentiate from it.
In view of the high proportion of chaffs in Usenet conversations,
the attitude of patent examiners to ignore newsgroup articles is fully
justifiable in my humble view. It is up to the newsgroups themselves,
I believe, to provide materials that are of a quality of interest
to them (e.g. good summaries), so that hopefully they might look
into these in the future.
> Attempting to find prior art which invalidates a patent is probably
> one of the very first things done by most licensees before a patent is
> licensed. It is often one of the major issues in any court battle.
> It is thus very important to the applicant that all possible prior art
> be disclosed during the patent prosecution itself, rather than found
> later in a patent infringement lawsuit. The examiners thus have some
> reason to expect the state of the art to be conveyed by applicants.
The European patents are in certain sense in a somewhat better
position, there being public review periods. I learned that the
US patents are going to have public reviews too, though I don't
know whether this has already happened.
> We cannot claim that anything simply "mentioned" on Usenet news (or
> anywhere else) is "prior art." There must be a disclosure of the
> technology -- how to make or do the new -- rather than saying that
> something was made or done. Similarly, the commercial appearance of a
> program which does the "new" may not count as prior art if it does not
> disclose (to the ordinary worker in the field) how the "new" was done.
This is certainly fully true. But the 'spirit' of discussions
in newsgroups does often tend to 'force' the claimer of something
to surrender the details before the claim is accepted, I suppose.
> Of course we know patents are granted for "new," not "good." There is
> little or no attempt to judge the value of the "new," as long as it
> has *some* value. But even if the "new" is only a tiny part of an
> object, as long as the claims definition of the "new" "reads on" the
> object, the patent applies. This means that patents may not --
> perhaps even should not -- contain the ultimate designs, but instead
> just the part which is "new" and protectable.
This is certainly also fully true. It is well-known that certain
very significant patents in technology were 'useless' until long
after their expiration dates. It is only natural that some patents
would have to wait till eternity before being used.
M. K. Shen
------------------------------
From: No Brainer <[EMAIL PROTECTED]>
Subject: Re: Guaranteed Public Key Exchanges
Date: Thu, 10 Feb 2000 02:29:58 +0800
Paul Koning wrote:
> No Brainer wrote:
> >
> > Does anyone know of a secure way to exchange public keys between two
> > people via the Internet (e-mail) without using any other form of
> > communication?
>
> Do you mean secret keys? Public keys need no confidentiality
> (though they do need integrity).
>
> There isn't one. If you have no other way of verifying who you're
> talking to, clearly a "man in the middle" cannot be distinguished
> from your intended recipient.
>
> If you're willing to assume that there isn't a man in the middle,
> Diffie-Hellman key agreement will do the job of setting up a shared
> secret, which you can then use to protect the additional traffic.
> If your threat model is that the *only* attackers you need to worry
> about are passive listeners, that would work. I wouldn't want to
> run the risk, though.
>
> I remember a snake oil product a few years ago that claimed to
> solve this problem. They carefully didn't tell you that they
> were assuming no man in the middle.
>
> In general, you *have* to have a "secure out of band channel" to
> get started. That may mean face to face contact, a phone call
> where you can recognize the other party by voice, or something
> similar
Paul,
Thanks for the reply.
I was hoping there was a new protocol of some type that would allow me to
exchange public keys with integrity and take the middle man "out of the
loop" (without the need for another secure channel of course).
Just think, we fly man to the moon and send missions to mars (we won't
mention the last two "disappearances") and no-one has yet to come up with
this solution :)
Thanks for the reply.
------------------------------
From: No Brainer <[EMAIL PROTECTED]>
Subject: Re: Guaranteed Public Key Exchanges
Date: Thu, 10 Feb 2000 02:32:06 +0800
Mike Rosing wrote:
> No Brainer wrote:
> >
> > Does anyone know of a secure way to exchange public keys between two
> > people via the Internet (e-mail) without using any other form of
> > communication?
> >
> > Also, would the proposed system work if *someone* was intercepting and
> > modifying the key exchanges?
>
> Nope. You gotta have an out of band exchange to prove no intercept.
>
> For most applications, the probability of an intercept is small so it's
> not that big a deal. But if you are going to really worry about it, you
> have to assume your line is controlled by the "enemy" and you need more
> than one channel of comm-link to ensure the exchange was clean.
Oh :(
Cheers :)
------------------------------
** 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
******************************
