Key management

[Eknir]

User-story

As a node operator, I don't want the Swarm node to directly manage my private keys, such that it is easier to validate what is done with my private keys and when.

Background

• whiteboarding

[ralph-pichler]

Current status on this:

The codebase has been adapted to pass around a crypto.Signer interface instead of private keys for the overlay. For now the only implementation of this is for in memory private keys. All signers are expected to return signatures in exactly the same format (compatible with btcec compact signatures).

crypto.Signer is currently not used for the underlay libp2p key. If required this should be possible in theory with the current abstraction.

Several external signers were looked at:

• clef

  • does not work for the overlay due to automatically inserted Ethereum prefix
  • successfully tested for transaction and cheque signing for swap
  • quite nice for ethereum transactions and cheque signing due to programmable rules
  • the idea of modifying clef was abandoned since adding raw signing to it would break its security model and adding swarm-specific mime-types would break our abstraction

• pgpme

  • also includes further data prior to signing
  • further investigation needed if this can be avoided by going lower the gpg stack

• ethsigner

  • also only supports Ethereum Signed Message prefix
  • doesn't expose signTransaction

Other signers which were looked at require user interaction on any signature (and most of them also add the Ethereum Prefix). Signing services outside the blockchain ecosystem usually don't support our curve.

Current plan forward:

• with the crypto.Signer interface in place not much more effort will be put into external overlay signing until a proper signer is found. if nothing pops up until we get closer to release we could write a small signer binary or fork clef to support raw signing.
• further investigation of gpg for raw signing
• clef will be supported from the start for ethereum keys (but not for overlay/underlay) when settlement gets implemented.

[ralph-pichler]

Update regarding gpg-agent as a signer:

• Raw signing theoretically possible by using the agent directly.
• The agent seems to return different signatures for some hashes than other secp256k1 implementations. The cause of this is still unknown.
• The agent does not return the v value necessary for recovery. This is strictly necessary as there might be multiple public keys for the same signature. As there are only a small number of possible values for v (most likely 2 although I saw mentions of 4 somewhere) one (admittedly hackish) way around this would be to try to recover with the different possible values on the bee side. However that implies at least 1-2 recover operations per signing operation.
• The signature has to be converted to bitcoins compact format (described here). In addition to v it also includes wether the public key is compressed. If this is relevant if one does not derive btc addresses from the pub key is not clear yet.