Secure Bootstrapping
Opened this issue · 5 comments
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)
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 :-)
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.
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...
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.
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
#85 (comment).