[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: RFC2409
The essence of attack is following:
Initiator(chess Grandmaster#1) and Responder(chess Grandmaster#2) trust
Cheater(chess novice) and vice versa, however they don't trust each other.
Grandmaster#1 and Grandmaster#2 are convicted that they play chess with
novice and are surprised by novice's phenomenal chess proficiency, but have
not understood that they actually play each other. In this type of attack
novice play pipe role with some cryptographic transformations as decryption
of IDi (IDr) and Ni (Nr), encryption IDc and Ni(Nr) with other's Grandmaster
public key and forwarding with KEi (KEr).
Ivars
<
< How can the cheater convince the Initiator to use his public key
< instead of the responder? If the Initiator uses Responders public key
< the C cannot know the value of Ni, thus it cannot calcute the Hash
< payload, because the Ni is needed there. I don't think this "attack"
< would work.
< --
< kivinen@iki.fi Work : +358-9-4354 3218
< SSH Communications Security http://www.ssh.fi/
< SSH IPSEC Toolkit http://www.ssh.fi/ipsec/
<
I don't understand what the attack is, I'm sorry. It appears
that both the Initiator and Responder believe that they
are talking to the cheater, so what is failure? If the
Initiator and Cheater are collaborators, then can share
signing keys as easily as decryption keys, so the "fix"
doesn't make sense to me, either.
It's possible that there is a flaw, given that the two
sides don't ever prove that they can compute the shared key,
but I don't exactly see what's wrong. Please explain.
Hilarie
Follow-Ups: