[p2p-hackers] P2P Authentication

[Alen Peacock]

On 10/26/05, Alex Pankratov <ap at hamachi.cc> wrote:
>
> It's nearly as inefficient as it gets. It might be suitable for low
> traffic applications like instant messaging, and that's about it.
> You may want to look at how TLS, SSH and IPsec handle bulk traffic
> security - they all utilize symmetric encryption for this purpose
> and generate and use shared encryption and authentication keys.


I won't argue about the inefficiency -- you are absolutely right. 
TLS, SSH, and IPsec all do bulk transfers far, far more efficiently. 
The purpose of the protocol I outlined is not for bulk traffic
security - it is to verify the claimed identities of the participants
in a completely decentralized fashion (though, to be fair, I didn't
make that clear) before making the transfer, which can then be made
either insecurely or securely using one of the methods you mentioned.

I would also point out that there are a class of applications for
which the noted inefficiency is amortized so as to not make too large
of a difference (I don't think that IM is one of them).  If the
transfer stage moves a large amount of data over a higher-layer
protocol, such as http, and if such transfers happen rarely (rarely
defined as less often than the session timeout length), then the
scheme is almost as efficient as any other -- there is an initial
setup cost which is dwarfed by the amount of data which is moved as a
result of the setup.  Granted, this is still vulnerable to session
hijacking, but that can be dealt with in any number of ways
(including, if you want, using TLS / https instead of http).

TLS, SSH, and IPsec don't solve the identity problem.  If 'A' wants to
participate in an overlay network where nodes are not only transient,
but can migrate their identities from one machine to another, then the
fact that the network is written using TLS doesn't really play into
the decision of how much to trust node 'B' or node 'C'.  As a matter
of definition, 'B' and 'C' are default untrusted, and the fact that
'A' uses TLS to talk with 'B' and 'C' doesn't help 'A' increase its
trust in either.  The only way 'A' can increase trust in either 'B' or
'C' is by interacting with them, keeping some history of the results
(trust), and then using that history to make future decisions about
desirable and undesireable interactions.  And the only way to make
trust reliable is to ensure that imposters are unsuccessful -- that a
node who says it is 'B' really is 'B'.  Again, I'm not talking about
session hijacking, I'm talking about long term identities and being
able to prove that a node is who it says it is, without relying on a
third party.  Self-chosen assymetric keys provide a mechanism for
accomplishing this, and I was just trying to outline one obvious and
simple approach.

  Alen