Add RSA signature protection for DHT records

[borzunov]

This PR introduces a notion of protected DHT records whose key/subkey contains substring [owner:ssh-rsa ...] (the format can be changed) with an RSA public key of the owner. Changes to such records always must be signed with the corresponding private key (so only the owner can change them). This protects from malicious nodes trying to spoil the DHT contents (see the list of attack vectors).

TODO:

• Save the signature and make the DHT readers check it (so malicious DHT nodes won't be able to fake the contents of such records)
• Write unit tests
• Check time of signing/signature validation (if it is > 100 ms, consider moving it to a separate thread)
• Check whether the cryptography module has heavy dependencies and whether we can choose a better alternative

[borzunov]

For RSASignatureValidator (backed by the cryptography module) and a record of size > 1 KiB, sign_value(), validate(), and strip_value() take < 1 ms each:

In [21]: validator = RSASignatureValidator()

In [23]: record = DHTRecord(b'key', b'subkey' + validator.ownership_marker, b'value' + b'X' * 1000, get_dht_time())

In [30]: %timeit protected_record = dataclasses.replace(record, value=validator.sign_value(record))
852 µs ± 8.94 µs per loop (mean ± std. dev. of 7 runs, 1000 loops each)

In [35]: %timeit validator.validate(protected_record)
180 µs ± 3.06 µs per loop (mean ± std. dev. of 7 runs, 10000 loops each)

In [36]: %timeit record = dataclasses.replace(protected_record, value=validator.strip_value(protected_record))
10.9 µs ± 105 ns per loop (mean ± std. dev. of 7 runs, 100000 loops each)

So, using the validator won't interfere with the asyncio event loop.

Generating a private-public key pair (happens once before starting the node) takes ~101 ms:

In [38]: %timeit validator = RSASignatureValidator()
101 ms ± 10.9 ms per loop (mean ± std. dev. of 7 runs, 10 loops each)

[mryab]

AFAIK, this field is optional

[borzunov]

It is not optional here, at the protocol layer. In case of a non-dictionary value or a whole dictionary, the subkey contains a special bytes value.

[mryab]

Suggested change

	self._our_marker = marker_format.replace(b'_key_', serialized_public_key)
	self._marker = marker_format.replace(b'_key_', serialized_public_key)

[borzunov]

Renamed it to self._ownership_marker, is it okay?

[mryab]

I still think we need the following test: writing in a protected key with a different signature should be possible after the previous record expires

[justheuristic]

[based on discussion with @borzunov ]
Alas, this functionality is not supported and we will likely have to do without it.

The validation of (key, subkey, value, expiration) tuple does not depend on whether or not there is a previous value under that key.

Unfortunately, conditioning the validator on currently stored entries would not be insecure:

• not all DHT peers that are supposed to have a given value will actually have it at any given moment in time. An attacker can use this to bypass the protection.
• DHT peers sometimes need to pass information to new nodes e.g. welcome_if_new.

Fortunately, it seems that there is a workaround that will allow us to secure all hivemind components with the current validator interface.

• Averager/metadata: all secret keys are unique and tied to peer identity. No two peers will even need (or be allowed to write) to the same (key, subkey) pair
• Experts / beam search: an authority (server or blockchain) will lease a separate security key for each expert that gives the use permission to declare this expert. This security key will be tied to (expert uuid, peer_id/endpoint, max expiration).