Secure Bootstrapping

[nicoruti]

One future enhancement i recommend is a secure bootstrap mechanism. The P2P system should be kind of "sand-boxed" where users can trust each other. This might be the case between small user bases of friends or within a business company. So in case a peer wants to bootstrap, it has to know the network password first.

(moved from hive2hive/Hive2Hive#61)

[ghost]

Rather than a password, you could use Diffie-Hellman handshakes. Or a certificate, that the newly arriving peer must be able to exhibit, i.e. it must have gotten the certificate through another channel. A third possibility is to ask the newly arriving peer to hash a certain string s with a hash function:

byte[] _bytes = s.toByteArray(); int _hash = 0; for( byte _b: _bytes ) { _hash = ( ( g * _b ) + _hash ) % h } return _hash % Integer.MAX_VALUE;

with g and h prime numbers ( g relatively small, h very large ) known within the network, and which must be known ( somehow. How ? ) to the newly arriving peer. Of course, there is a time-out upon the hash function :-)

[tbocek]

I think a certificate would be the easiest way to create a secure DHT. TomP2P already sends public keys around and it would be easy to add a signature to this public key. Since the peerID is derived from the public key, the certificate could have only the public key and encrypted hash of that public key from a trusted CA.

That means the root certificate from the CA needs to be know beforehand and you need to be able to get that certificate from a CA. But this certificate exchange I would see as part of the application and not part of the library.

[ghost]

Major drawback of the CA solution: what if you deploy within a perimeter that is not connected to the internet ? You then need to make sure the certificate is available locally, and that means extra admin work load. In my experience, admins of ( large-ish ) networks are already quite overloaded...

[tbocek]

True, what about extending the signature to also allow something similar to HMAC. This would mean you could provide a password at startup and only those peers with the right password can join.

[ghost]

Simple, but sounds like a good workaround. If and when I go to a company like e.g. Airbus R & D and get - oh miracle ! - the permission to run for a couple of hours on their cluster, that would be acceptable to them.

Fortuna audaces adiuvat - hos solos ?

On 9 February 2015 at 10:38, Thomas Bocek notifications@github.com wrote:

True, what about extending the signature to also allow something similar to HMAC. This would mean you could provide a password at startup and only those peers with the right password can join.

— Reply to this email directly or view it on GitHub https://github.com/tomp2p/TomP2P/issues/85#issuecomment-73480457.