[p2p-hackers] P2P Authentication

[Alen Peacock]

On 10/26/05, Antoine Pitrou <solipsis at pitrou.net> wrote:
>
> How do A and B know their counterpart's public keys for sure?
> And if they do, then why reinvent the wheel? Traditional public key
> signing works well for these cases.

  I wanted to revisit this, since I didn't address it previously.

  Signing alone is insufficient for identity verification due to
replay attacks.  You could use a nonce, but then the recipient has to
guarantee that no nonce is ever reused, which usually reduces either
to a massive database lookup problem, or a clock synchronization
problem -- neither of which are easily solvable in an untrusted p2p
environment (let alone in a trusted network application, where
suppress-replay attacks are likely still possible).

  Of course, if you aren't worried about replay attacks (and certainly
the severity of such attacks varies widely depending on the protocol),
then this isn't an issue and you might be able to get by with simple
signatures.

  As far as I can tell, the rudimentary scheme I outlined previously
eliminates man-in-the-middle and replay attacks using
challenge/response, but it does introduce a certain amount of
hand-shaking overhead.  (there is actually still one replay attack
possible by a man-in-the-middle in what I sketched, but it is solvable
by withholding Ra until the data response is sent, and signing it as
part of that payload).

  Expensive for short messages? yeah.  But it doesn't require any centrality.

  Alen