37 lines
2.0 KiB
Markdown
37 lines
2.0 KiB
Markdown
|
# The Keyfork Server
|
||
|
|
|
||
|
|
The server uses a `keyfork_frame`'d `bincode`'d request+response format and can
|
||
|
|
be interacted with by using the `keyforkd_client` crate.
|
||
|
|
|
||
|
|
All requests made to Keyfork are required to list at least two derivation
|
||
|
|
paths. This helps prevent cases where the master seed or the general protocol
|
||
|
|
seed are leaked by a client. An example is BIP-0044, where the path used is
|
||
|
|
`m/44'/0'` for Bitcoin, and often `m/44'/60'` is used for Ethereum. To prevent
|
||
|
|
an Ethereum wallet from deriving the Bitcoin coin seed, and to prevent leaking
|
||
|
|
the master seed in general, all requests must contain at least two paths.
|
||
|
|
|
||
|
|
Additionally, this ensures that keys are not reused across separate purposes.
|
||
|
|
Because keys are required to have at least two indexes, they are drawn to the
|
||
|
|
pattern of using the first index as the key's purpose, such as `m/ pgp'` for
|
||
|
|
OpenPGP.
|
||
|
|
|
||
|
|
## Usage
|
||
|
|
|
||
|
|
The Keyfork server can be started by running the `keyfork recover` porcelain
|
||
|
|
binary or by running `keyforkd` directly and entering a mnemonic. Once started,
|
||
|
|
the Keyfork server will bind to a socket in `XDG_RUNTIME_DIR` by default, or
|
||
|
|
`KEYFORK_SOCKET_PATH` pointing directly to where a socket will be bound. Upon
|
||
|
|
the server's termination, the socket will be removed. The socket will not be
|
||
|
|
removed by default when the server is starting.
|
||
|
|
|
||
|
|
Once started, the Keyfork server can be interacted with using the `keyfork
|
||
|
|
derive` subcommand or individual `keyfork-derive` commands, such as
|
||
|
|
`keyfork-derive-openpgp`. The former offers a more intuitive interface, but the
|
||
|
|
latter may offer a lower dependency surface. These clients will connect to the
|
||
|
|
server, typically using the `keyforkd-client` crate, and request a derived key.
|
||
|
|
Once the server has received the derivation request, the server will log the
|
||
|
|
request, as well as its best-effort guess on what path is being derived (using
|
||
|
|
the `keyfork-derive-path-data` crate), to inform the user of what keys are
|
||
|
|
requested. Once the server sends the client the new extended private key, the
|
||
|
|
client can then choose to use the key as-is, or derive further keys.
|