SKS - Soma Key Service

A secure key store with signing capabilities

A private server for managing private keys and performing cryptographic operations. The server is to be controlled by a single user or entity. The server provides an interface through which clients, which may be untrusted, can interact with a set of private keys, without viewing them.

Requirements

The application:

• Must be open source.

• Must never leak private keys.

• Should provide methods to restrict which kinds of operations can be performed.

  • An example is to only allow a signature to be created if the content being signed is prepended with a pre-approved byte sequence to prevent cross-context misuse. An example of this is Ethereum's personal_sign (https://eips.ethereum.org/EIPS/eip-191).

• Should log operations.

• May provide a way to encrypt the private keys.

Cryptographic capabilities

The application may provide the ability to:

• Store private keys, potentially encrypted

• Generate random private keys

• Deterministically generate private keys from user-supplied data

According to an elliptic curve algorithm chosen by the user from a suite of available algorithms, the application may also provide the ability to:

• Derive a public key

• Create a public signature

• Perform a Elliptic Curve Diffie-Hellman (ECDH) exchange

Useful elliptic curves which the application may provide support for are:

• secp256k1 for interoperability with Bitcoin and Ethereum technology

• Curve25519 and Curve448-Goldilocks for their strong cryptographic properties

Rationale

By having keys be managed by a perfectly transparent application, one removes the necessity of trusting browser JavaScript code with one's secrets. Using the signer application, a user can confidently use any private key of their choosing, such as an Ethereum private key or a Bitcoin private key, or a key generated with more entropy than via a password piped through scrypt, as in SomaChat's default key generation scheme.

Technical details

In order to use the application together with SomaChat or other services that might want to depend on its capabilities, it should run as a locally or remotely hosted web server. If run remotely, some kind of authorization scheme should protect access.

Whenever possible, client should prefer to use Curve25519 or Curve448-Goldilocks over secp256k1 for security and performance reasons.

The application would have a very minimal interface. In the proposal below, kid is a "key id" which is a memorable name, chosen by the user upon configuration, which represents a private key.

POST /gen
  params
    cur - A list of curves to generate public keys with
  return
    privateKey - Randomly generated private key
    publicKeys - List of { curve, public key }

GET /ids
  returns
    ids - a list of key ids

GET /keys
  params
    ids - List of { key id, curve }
  returns
    keys - List of { key id, curve, public key }

GET /sign
  params
    kid - Key id
    enc - Encoding method
    msg - The message to sign
    cur - Curve for signing
  returns
    kid - Key id
    cur - Curve
    enc - Encoding
    sig - The signature in hex format

GET /ecdh
  params
    kid - Key id
    cur - Curve
    pub - Other key
  returns
    sec - Shared secret