Identity Key used for Encryption and Signature Creation

## Overview

Edited 11/1/19

Right now the identity key (secp256k1 keypair) is used in multiple locations for different purposes.

The `Pool` uses it for `brontide`. It is used for encryption and authentication in this context. See [bolt #8](https://github.com/lightningnetwork/lightning-rfc/blob/master/08-transport.md) for more details. The codepath:

https://github.com/handshake-org/hsd/blob/155051f7f9af115dc2b8a7bef90963e54e87c5ed/lib/node/fullnode.js#L84-L93

https://github.com/handshake-org/hsd/blob/155051f7f9af115dc2b8a7bef90963e54e87c5ed/lib/net/pool.js#L1112

https://github.com/handshake-org/hsd/blob/155051f7f9af115dc2b8a7bef90963e54e87c5ed/lib/net/peer.js#L64

https://github.com/handshake-org/hsd/blob/155051f7f9af115dc2b8a7bef90963e54e87c5ed/lib/net/peer.js#L310

---

Both the `RootServer` and the `RecursiveServer` use the key for authentication, signing messages for [SIG0](https://tools.ietf.org/html/rfc2931). The codepath:

https://github.com/handshake-org/hsd/blob/155051f7f9af115dc2b8a7bef90963e54e87c5ed/lib/node/fullnode.js#L145-L147

https://github.com/handshake-org/hsd/blob/155051f7f9af115dc2b8a7bef90963e54e87c5ed/lib/dns/server.js#L584

---

I have [read](https://security.stackexchange.com/questions/99779/how-to-encrypt-with-ecdsa) that it is not the best idea to use the same key for both encryption and in digital signature algorithms as it exposes interactions between the algorithms. The attacker can choose the text that is signed and collect many signatures, since every DNS request that they send will be signed with the key. It is possible that a side channel attack is possible here, such as the recently discovered [Minerva](https://minerva.crocs.fi.muni.cz/). If such a side channel existed, it would be bad if the attacker was able to decrypt the p2p messages between two nodes. I believe an attacker may be able to do this if they were able to collect all traffic between the two nodes and pull the side channel attack on both of the nodes.

## Proposal

- Use different key pairs for `SIG0` and for brontide.
- Allow them to be separately configured at runtime.
- ~~Both the `SIG0` key and the brontide key returned for a DNS request to the Handshake root `.` for the resource record type `KEY` (`SIG0` specifies that in its RFC).~~
- Only the `SIG0` key is returned for a DNS request to the Handshake root for RR type `KEY`
- Figure out way to deprecate `SIG0` for something better long term (leaning towards DNS over HTTPS personally)

cc: @chjj @boymanjor @kilpatty @pinheadmz