Cryptography-Digest Digest #54, Volume #13 Tue, 31 Oct 00 05:13:01 EST
Contents:
Re: XOR based key exchange protocol - flawed? (Mike Connell)
Re: Is RSA provably secure under some conditions? (Mok-Kong Shen)
Re: Q. to Ritter /PKCS cascade/Hybrid PKCS (Mok-Kong Shen)
Re: XOR based key exchange protocol - flawed? (Mike Connell)
Re: XOR based key exchange protocol - flawed? (Mike Connell)
Re: XOR based key exchange protocol - flawed? (David Schwartz)
Re: XOR based key exchange protocol - flawed? (David Schwartz)
Re: XOR based key exchange protocol - flawed? (Mike Connell)
Re: Calculating the redudancy of english? (Mok-Kong Shen)
Re: XOR based key exchange protocol - flawed? (Mike Connell)
Re: XOR based key exchange protocol - flawed? (David Schwartz)
Re: XOR based key exchange protocol - flawed? (David Schwartz)
Re: XOR based key exchange protocol - flawed? (David Schwartz)
Re: XOR based key exchange protocol - flawed? (Mike Connell)
----------------------------------------------------------------------------
From: Mike Connell <[EMAIL PROTECTED]>
Subject: Re: XOR based key exchange protocol - flawed?
Date: 31 Oct 2000 09:23:05 +0100
Benjamin Goldberg <[EMAIL PROTECTED]> writes:
> Mike Connell wrote:
> >
> > Pa, Pb are RSA public keys. (X)Pi means data X encrypted under key Pi.
> > Xa, Xb are random blocks of data of the same size as the public keys.
> >
> > 1. a -> b : Pa
> > 2. a <- a : Pb
> > 3. a -> b : (Xa)Pb
> > 4. a <- b : (Xb)Pa
> >
> > Then a and b compute the XOR of Pa,Pb,Xa,Xb. This gives them a
> > substantional number of shared secret bytes to construct a session key
> > from.
> >
> > I have looked at a MITM attack, including substitution of the blocks
> > in stages 3 and 4, and the replacement of one of the public keys, but
> > cant see how to make it work. Any ideas?
>
> Let's call the attacker c. He sits between a and b, and pretends to be
> each to the other.
>
> 1a. a -> c : Pa
> 2a. a <- c : Pc
> 3a. a -> c : (Xa)Pc
> 4a. a <- c : (Xc)Pa
>
> a and c then encrypt all following data with XOR(Pa,Pc,Xa,Xc)
>
> 1b. c -> b : Pc
> 2b. c <- b : Pb
> 3b. c -> b : (Xc)Pb
> 4a. c <- b : (Xb)Pc
>
> b and c then encrypt all following data with XOR(Pb,Pc,Xb,Xc)
>
> After the setup, everything a sends to c (thinking that c is b), c
> decrypts, stores on his disk, then encrypts and sends to b.
>
Why would A think that C is B? A has Pc, not Pb.
I think I didn't write this in the origional post (oops ;), but I was
coming from a unstated position where either the mapping of public
keys to identities was done beforehand (ie I met Fred Bloggs at a
party and he gave me his public key), or doesn't matter (ie I don't
know who I'm talking to, but they're using the same public key as the
guy that gave me all those handy stock tips, so it must be the same
person).
In this light, the above attack doesn't work, because it reduces to a
case of two correctly authenticated and secured sessions. Of course, A
and B shouldn't be trusting C, but I can't figure out how to code that
;)
best wishes,
Mike.
> Similarly, everything that b thinks he's sending to a, is actually going
> to c, getting decypted, stored, re-encrypted, and forwarded to a.
>
> > I couldn't find a mention of anything like this in either Applied
> > Crypto or Menezes, so it must be very flawed ;) Is there some weakness
> > in using the public keys in the XOR?
>
> It's not more flawed than DH key exchange.
>
> --
> "Mulder, do you remember when I was missing -- that time that you
> *still* insist I was being held aboard a UFO?"
> "How could I forget?"
> "Well, I'm beginning to wonder if maybe I wouldn't have been
> better off staying abo-- I mean, wherever it was that I was
> being held." [from an untitled spamfic by [EMAIL PROTECTED]]
--
Mike Connell [EMAIL PROTECTED] +46 (0)31 772 8572
[EMAIL PROTECTED] http://www.flat222.org/mac/ icq: 61435756
http://www.flat222.org/Paranoia
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Is RSA provably secure under some conditions?
Date: Tue, 31 Oct 2000 09:13:19 +0100
"John A. Malley" wrote:
>
> http://xxx.lanl.gov/abs/cs.CR/0010019
>
> They show a most marvelous thing: There exist signature and encryption
> schemes that are secure in the Random Oracle Model but for which any
> _implementation_ of the random oracle results in insecure schemes. The
> fact that a scheme is secure in the Random Oracle Model cannot be taken
> as evidence or indication to the security of possible implementations of
> this scheme. Evaluating schemes with the Random Oracle Model rules out
> some, but not all, insecure schemes.
>
> Made my jaw drop.
>
> Gosh, the math in the paper itself made my jaw drop. Still reading it,
> do not yet completely understand their proofs but I'm working on it.
Does that imply that the implementation of the idea needs
something that is impossible in practice, like infinite
memory etc.? Otherwise it seems to have some flavour of
Schroedinger's cat (for a layman like me).
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Q. to Ritter /PKCS cascade/Hybrid PKCS
Date: Tue, 31 Oct 2000 09:21:08 +0100
Terry Ritter wrote:
>
> sci.crypt [EMAIL PROTECTED] wrote:
> >It may be interesring for you to write a paper on this subject?
>
> That is always a good idea. The point is not necessarily publication.
> It is often amazing how many new issues appear when one tries to
> explain things to someone else.
If you publish, then you'll get fame and become a guru
or even be immortal (possible in France). Otherwise .....
M. K. Shen
------------------------------
From: Mike Connell <[EMAIL PROTECTED]>
Subject: Re: XOR based key exchange protocol - flawed?
Date: 31 Oct 2000 09:39:01 +0100
[EMAIL PROTECTED] (David Wagner) writes:
> Mike Connell wrote:
> >Pa, Pb are RSA public keys. (X)Pi means data X encrypted under key Pi.
> >Xa, Xb are random blocks of data of the same size as the public keys.
> >
> >1. a -> b : Pa
> >2. a <- a : Pb
> >3. a -> b : (Xa)Pb
> >4. a <- b : (Xb)Pa
> >
> >Then a and b compute the XOR of Pa,Pb,Xa,Xb.
>
> I don't understand the "MITM attacks" others are posting on your scheme.
>
I think I should have made it clearer (ie *written* it ;-) in the
begining that there was no attempt to map the public keys to any other
identity information. I thought that it would be clear from the fact that
no identity information (except the keys themselves) is transmitted.
As I wrote in another post, A and B might either have obtained each
others public keys previously (ie met at a party), or the identity
might not be important (ie A doesn't know who B is except for the fact
that its the same person who A had these previous conversations
with...)
> If you don't have any way to validate the public key that the other
> guy is using, then any authentication protocol you use will be
> susceptible to a MITM attack. That's just unavoidable, and is not
> a flaw of the authentication protocol.
>
> The point is that secure authentication protocols tell you, at the
> end of the protocol run, who you are talking to. An attack is where
> the malicious guy Mallet can get you to think you are talking to Alice
> when in fact you are really talking to Mallet.
>
> It is NOT an attack if at the end of the protocol you think you are
> talking to Mallet and you are correct in this belief. If you send
> secrets to Mallet, knowing that it is her that you're sending them to,
> well, that's not the fault of the authentication protocol.
>
That's what I thought :)
> In this case, when the protocol completes, I think you always know
> the public key of the other person you are talking with. There are
> other issues (like replay attacks), but I don't think MITM attacks
> is one of them.
>
OK, replay attacks. I must admit I hadn't thought too much about
them. Doing it now, I just had a panic attack when I thougt I saw a
problem, but I didn't. C can replay the steps 3 and 4 ( (Xa)Pb and
(Xb)Pa ), but wont be able to compute the correct answer (the XOR) at
the end as they wont know the value of Xa or Xb itself (I think ;)
> Am I missing something?
Probably (and so am I). I'm not very well versed in the literature (I
have Applied Crypto and HOAC, plus random papers), but I thought that
if something this simple didn't have a huge flaw, it would have been
mentioned somewhere. Perhaps I have just missed it, as my eyes
sometimes lose focus when reading Menezes ;)
I am wondering if embedding the value of Pa and Pb into the XOR block
gives some possibility of statistical analysis for an attacker? I
don't even know if this is possible, or how much of a problem it would
be when the data block is reduced down to enough bits for a session
key...
best wishes,
Mike.
--
Mike Connell [EMAIL PROTECTED] +46 (0)31 772 8572
[EMAIL PROTECTED] http://www.flat222.org/mac/ icq: 61435756
------------------------------
From: Mike Connell <[EMAIL PROTECTED]>
Subject: Re: XOR based key exchange protocol - flawed?
Date: 31 Oct 2000 09:45:23 +0100
David Schwartz <[EMAIL PROTECTED]> writes:
> Tom St Denis wrote:
>
> > You're missing the point. Not one step of your protocal stops me from
> > *completely* faking being one party. There is no trusted agent or
> > secret secret shared previously. I.e it's stateless when the protocal
> > begins.
>
> The purpose of this protocol is to wind up with a shared secret between
> the two parties. The only useful attack would be one that resulted in
> the MITM knowing the shared secret. If the MITM winds up with a shared
> secret with A, or the MITM winds up with a shared secret with B, he has
> nothing useful. He can't use these two shared secrets to interfere with
> the communication between A and B.
>
> This assumes, of course, that the protocol later checks to be sure that
> A and B do in fact share a secret.
>
No actually, after they compute this XOR block of Pa Pb Xa Xb, both
parties through it away ;-). I'm just kidding. The idea was that with
(say) 1024bit RSA keys, both parties would end up with (about) that
size of shared secret data. Say they need 128bits for a session key,
and maybe 64bits for an IV, they can do something to this 1024 bits of
data to reduce it to the necessary size (ie hash blocks of it, or just
throw some bits away), and so (finally!) get a session key.
They both use that. If they're getting garbage from the other user,
they know something is wrong ;)
Is there a better way to use the data? There's a lot of 'spare' bits
in the XOR block that aren't really used.
best wishes,
Mike.
--
Mike Connell [EMAIL PROTECTED] +46 (0)31 772 8572
[EMAIL PROTECTED] http://www.flat222.org/mac/ icq: 61435756
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: XOR based key exchange protocol - flawed?
Date: Tue, 31 Oct 2000 00:33:11 -0800
Mike Connell wrote:
> I think I didn't write this in the origional post (oops ;), but I was
> coming from a unstated position where either the mapping of public
> keys to identities was done beforehand (ie I met Fred Bloggs at a
> party and he gave me his public key), or doesn't matter (ie I don't
> know who I'm talking to, but they're using the same public key as the
> guy that gave me all those handy stock tips, so it must be the same
> person).
Your second case doesn't work. The MITM can create any number of
anonymous personas. So he can make you think that he is the person who
gave you all those stock tips even though he isn't. The MITM can create
a one-to-one mapping of his keys to the keys of people you communicate
with. He can then later make you think that any subsequent message came
from any of the poeple he has impersonated to you.
DS
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: XOR based key exchange protocol - flawed?
Date: Tue, 31 Oct 2000 00:36:22 -0800
Mike Connell wrote:
>
> David Schwartz <[EMAIL PROTECTED]> writes:
>
> > Tom St Denis wrote:
> >
> > > You're missing the point. Not one step of your protocal stops me from
> > > *completely* faking being one party. There is no trusted agent or
> > > secret secret shared previously. I.e it's stateless when the protocal
> > > begins.
> >
> > The purpose of this protocol is to wind up with a shared secret between
> > the two parties. The only useful attack would be one that resulted in
> > the MITM knowing the shared secret. If the MITM winds up with a shared
> > secret with A, or the MITM winds up with a shared secret with B, he has
> > nothing useful. He can't use these two shared secrets to interfere with
> > the communication between A and B.
> >
> > This assumes, of course, that the protocol later checks to be sure that
> > A and B do in fact share a secret.
> >
>
> No actually, after they compute this XOR block of Pa Pb Xa Xb, both
> parties through it away ;-). I'm just kidding. The idea was that with
> (say) 1024bit RSA keys, both parties would end up with (about) that
> size of shared secret data. Say they need 128bits for a session key,
> and maybe 64bits for an IV, they can do something to this 1024 bits of
> data to reduce it to the necessary size (ie hash blocks of it, or just
> throw some bits away), and so (finally!) get a session key.
>
> They both use that. If they're getting garbage from the other user,
> they know something is wrong ;)
That's not good enough. That doesn't confirm that A and B share the
secret. That confirms that A shares his secret with someone and that B
shares his secret with someone, but that's not the same thing at all.
DS
------------------------------
From: Mike Connell <[EMAIL PROTECTED]>
Subject: Re: XOR based key exchange protocol - flawed?
Date: 31 Oct 2000 10:01:52 +0100
David Schwartz <[EMAIL PROTECTED]> writes:
> Mike Connell wrote:
>
> > I think I didn't write this in the origional post (oops ;), but I was
> > coming from a unstated position where either the mapping of public
> > keys to identities was done beforehand (ie I met Fred Bloggs at a
> > party and he gave me his public key), or doesn't matter (ie I don't
> > know who I'm talking to, but they're using the same public key as the
> > guy that gave me all those handy stock tips, so it must be the same
> > person).
>
> Your second case doesn't work. The MITM can create any number of
> anonymous personas.
Sure, they can.
> So he can make you think that he is the person who
> gave you all those stock tips even though he isn't.
Now you've lost me. How? In order to do that, they must present the
same public key as the 'real' guy has. For that public key to be
useful, they must compute the secret key that goes with it. Isn't that
hard?
> The MITM can create
> a one-to-one mapping of his keys to the keys of people you communicate
> with. He can then later make you think that any subsequent message came
> from any of the poeple he has impersonated to you.
>
Hey, it's early in the morning for me, so could you explain this?
thanks,
Mike.
--
Mike Connell [EMAIL PROTECTED] +46 (0)31 772 8572
[EMAIL PROTECTED] http://www.flat222.org/mac/ icq: 61435756
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Calculating the redudancy of english?
Date: Tue, 31 Oct 2000 09:46:28 +0100
Simon Johnson wrote:
>
> How does one calculate the redudancy of english?
I suppose that there is a kind of redundancy measure
which has never beed mentioned, namely determining
the average length of strings to express diverse thoughts
in diverse ways. Since a short sentence can be easily
expanded to a paragraph or even pages by experts (politicians,
etc.), that redundancy evades practical computation.
M. K. Shen
------------------------------
From: Mike Connell <[EMAIL PROTECTED]>
Subject: Re: XOR based key exchange protocol - flawed?
Date: 31 Oct 2000 10:11:33 +0100
David Schwartz <[EMAIL PROTECTED]> writes:
> Mike Connell wrote:
> >
> > David Schwartz <[EMAIL PROTECTED]> writes:
> >
> > > Tom St Denis wrote:
> > >
> > > > You're missing the point. Not one step of your protocal stops me from
> > > > *completely* faking being one party. There is no trusted agent or
> > > > secret secret shared previously. I.e it's stateless when the protocal
> > > > begins.
> > >
> > > The purpose of this protocol is to wind up with a shared secret between
> > > the two parties. The only useful attack would be one that resulted in
> > > the MITM knowing the shared secret. If the MITM winds up with a shared
> > > secret with A, or the MITM winds up with a shared secret with B, he has
> > > nothing useful. He can't use these two shared secrets to interfere with
> > > the communication between A and B.
> > >
> > > This assumes, of course, that the protocol later checks to be sure that
> > > A and B do in fact share a secret.
> > >
> >
> > No actually, after they compute this XOR block of Pa Pb Xa Xb, both
> > parties through it away ;-). I'm just kidding. The idea was that with
> > (say) 1024bit RSA keys, both parties would end up with (about) that
> > size of shared secret data. Say they need 128bits for a session key,
> > and maybe 64bits for an IV, they can do something to this 1024 bits of
> > data to reduce it to the necessary size (ie hash blocks of it, or just
> > throw some bits away), and so (finally!) get a session key.
> >
> > They both use that. If they're getting garbage from the other user,
> > they know something is wrong ;)
>
> That's not good enough. That doesn't confirm that A and B share the
> secret. That confirms that A shares his secret with someone and that B
> shares his secret with someone, but that's not the same thing at all.
>
I dont see how. The protocol (in case anyone has missed it) is this:
1. a -> b : Pa [public RSA key of A]
2. a <- b : Pb [public RSA key of B]
3. a -> b : (Xa)Pb [random block encrpyted under Pb]
4. a <- b : (Xb)Pa [random block encrpyted under Pa]
A and B now both compute the XOR of Pa, Pb, Xa, Xb (or whatever they
received if there is an attack going on). They can use this to
construct a session key.
A believes that only B could know the XOR block (and thus the session
key), because it is dependent on Xa, which only A and B can
know. Likewise for B.
best wishes,
Mike.
--
Mike Connell [EMAIL PROTECTED] +46 (0)31 772 8572
[EMAIL PROTECTED] http://www.flat222.org/mac/ icq: 61435756
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: XOR based key exchange protocol - flawed?
Date: Tue, 31 Oct 2000 01:02:32 -0800
Mike Connell wrote:
> > Your second case doesn't work. The MITM can create any number of
> > anonymous personas.
>
> Sure, they can.
>
> > So he can make you think that he is the person who
> > gave you all those stock tips even though he isn't.
>
> Now you've lost me. How? In order to do that, they must present the
> same public key as the 'real' guy has. For that public key to be
> useful, they must compute the secret key that goes with it. Isn't that
> hard?
Not at all, because he can trivially create any number of public keys
and private keys.
> > The MITM can create
> > a one-to-one mapping of his keys to the keys of people you communicate
> > with. He can then later make you think that any subsequent message came
> > from any of the poeple he has impersonated to you.
> >
>
> Hey, it's early in the morning for me, so could you explain this?
Sure. The MITM can create any number of public/private key pairs. Then,
when he detects that A is trying to communicate to someone else, say B,
C, or D, he simply substitutes one of his keys for B, C, or D's key. He
does the same thing in reverse to B, C, or D. Thus A thinks that B's key
is one of the MITM's keys, he always sees B using the same key, and has
no reason not to think that anything using that key came from B.
The MITM sees anything that goes to or from A unencrypted. So he can
intercept all communications.
He can also impersonate B, C, or D to A, and can impersonate A to B, C,
or D.
The only way to fix this is to be sure the protocol actually checks
that A and B share a key. Simply checking that the key works could mean
that A shares one key with the MITM and B shares another key with the
MITM.
DS
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: XOR based key exchange protocol - flawed?
Date: Tue, 31 Oct 2000 01:10:14 -0800
Mike Connell wrote:
> I dont see how. The protocol (in case anyone has missed it) is this:
>
> 1. a -> b : Pa [public RSA key of A]
> 2. a <- b : Pb [public RSA key of B]
> 3. a -> b : (Xa)Pb [random block encrpyted under Pb]
> 4. a <- b : (Xb)Pa [random block encrpyted under Pa]
>
> A and B now both compute the XOR of Pa, Pb, Xa, Xb (or whatever they
> received if there is an attack going on). They can use this to
> construct a session key.
>
> A believes that only B could know the XOR block (and thus the session
> key), because it is dependent on Xa, which only A and B can
> know. Likewise for B.
Now, interpose a MITM. 'mb' is the key the MITM uses to impersonate B
and 'ma' is the key the MITM uses to impersonate A. The MITM creates one
key for every person it wishes to impersonate.
First half =
1. a->MITM : Pa
2. a<-MITM : Pmb
3. a->MITM : (Xa)Pmb
4. a<-MITM : (Xm1)Pa
At this point, A knows it's talking to mb.
Second half =
1. MITM->B : Pma
2. MITM<-B : Pb
3. MITM->B : (Xm2)Pb
4. MITM<-B : (Xb)Pma
At this point, B knows it's talking to ma.
Now the MITM can intercept all the communications between A and B. A
knows it's talking to mb, which it thinks is B. B knows it's talking to
ma, which it thinks is A. The MITM can continue to do this to every
single communication between A, B, C, and others. All along, it can
decode every communication, can modify any communication, and can
impersonate any user to any other user.
So you think the person who sent you all those stock tips is 'mb' (when
it's really B). So when you see a new stock tip from 'mb', you think
it's really B. It might be, or it might not be.
DS
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: XOR based key exchange protocol - flawed?
Date: Tue, 31 Oct 2000 01:22:51 -0800
David Schwartz wrote:
> First half =
> 1. a->MITM : Pa
> 2. a<-MITM : Pmb
> 3. a->MITM : (Xa)Pmb
> 4. a<-MITM : (Xm1)Pa
*sigh* 4 should be:
4. a<-MITM : (Xmb)Pa
> Second half =
> 1. MITM->B : Pma
> 2. MITM<-B : Pb
> 3. MITM->B : (Xm2)Pb
> 4. MITM<-B : (Xb)Pma
*sigh* 3 should be:
3. MITM->B : (Xma)Pb
DS
------------------------------
From: Mike Connell <[EMAIL PROTECTED]>
Subject: Re: XOR based key exchange protocol - flawed?
Date: 31 Oct 2000 11:18:50 +0100
David Schwartz <[EMAIL PROTECTED]> writes:
> Mike Connell wrote:
>
> > I dont see how. The protocol (in case anyone has missed it) is this:
> >
> > 1. a -> b : Pa [public RSA key of A]
> > 2. a <- b : Pb [public RSA key of B]
> > 3. a -> b : (Xa)Pb [random block encrpyted under Pb]
> > 4. a <- b : (Xb)Pa [random block encrpyted under Pa]
> >
> > A and B now both compute the XOR of Pa, Pb, Xa, Xb (or whatever they
> > received if there is an attack going on). They can use this to
> > construct a session key.
> >
> > A believes that only B could know the XOR block (and thus the session
> > key), because it is dependent on Xa, which only A and B can
> > know. Likewise for B.
>
> Now, interpose a MITM. 'mb' is the key the MITM uses to impersonate B
> and 'ma' is the key the MITM uses to impersonate A. The MITM creates one
> key for every person it wishes to impersonate.
>
> First half =
> 1. a->MITM : Pa
> 2. a<-MITM : Pmb
> 3. a->MITM : (Xa)Pmb
> 4. a<-MITM : (Xm1)Pa
>
> At this point, A knows it's talking to mb.
>
> Second half =
> 1. MITM->B : Pma
> 2. MITM<-B : Pb
> 3. MITM->B : (Xm2)Pb
> 4. MITM<-B : (Xb)Pma
>
> At this point, B knows it's talking to ma.
>
> Now the MITM can intercept all the communications between A and B. A
> knows it's talking to mb, which it thinks is B.
That is the sticking point.
I understand what you're sying, and thank you for saying it. However,
I still don't see it as an attack. The question is, why does A think
that mb is the public key of B?
In the case that A,B have exchanged keys beforehand, the attack fails,
as A recognises Pmb!=Pb. The other scenario, is where A knows nothing
about B, except the public key which they've previously used to
communicate with that 'person'.
In that case, A is talking to "the person with public key mb" - that is
all that they know. They get stock tips from mb, and they always get
stock tips from mb. the MITM may be relaying those from user B (Pb), but A
never even knows that: it only sees stocktips coming from mb.
All this reduces to the case of A and B trusting C, when C is not
somebody they should be trusting.
> B knows it's talking to
> ma, which it thinks is A. The MITM can continue to do this to every
> single communication between A, B, C, and others. All along, it can
> decode every communication, can modify any communication, and can
> impersonate any user to any other user.
>
> So you think the person who sent you all those stock tips is 'mb' (when
> it's really B). So when you see a new stock tip from 'mb', you think
> it's really B. It might be, or it might not be.
>
Well, it *is* mb. mb might have gotten them from B, but it was still
mb that sent them to A.
Everytime you get a message from mb, you know it came from the same
person. That person might have gotten the information from anywhere,
you don't know. All you know is that they're telling it to you.
If A is getting anonymous stock tips from Pmb, it isn't a problem,
even if the person using Pmb is actually getting them from B. It only
becomes a problem when the Pmb user says "I am B". At that point A
must say "I dont know that, I need some way to validate that you are
in fact B". That validation clearly cannot take place over the current
channel. B will have to host a party and let A attend. When that
happens, A will see that the MITM is not B.
To put it another way: I think I'm getting helpful comments from David
Schwartz. However, I might be getting them from MITM. This isn't a
problem for me. Maybe you actually don't know anything about
crpytography, you just have a friend at the NSA [0], and you are
relaying his information to me. All I see is that I get this
information from you. I don't know where you get it from...
best wishes,
Mike.
[0] You appear to know lots, but I'm not convinced you're the *real*
David Schwartz. ;-)
--
Mike Connell [EMAIL PROTECTED] +46 (0)31 772 8572
[EMAIL PROTECTED] http://www.flat222.org/mac/ icq: 61435756
------------------------------
** 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
******************************
