Key management / signing

[crypto-coder]

Making a general suggestions that we include a convenience feature in the NPM package for managing aliased pub-priv keypairs in a file, that can be loaded and used to sign transactions. Functions would include things like:

Create new KeyPair: myNode.createKeyPair( alias, add_to_keystore=true ); Get Public Key by Alias: myNode.getPublicKey( alias ); Sign a transaction: myNode.signTransaction( alias, DeployData );

The current API provides the ability to dynamically generate a keypair and sign text.

const seed = randomBytes(32); const pair1 = keyPair(seed);

console.log('public key:', pair1.publicKey()); console.log('signature:', pair1.signTextHex('hello world'));

We can use this internally, but if we want to reuse these generated keys, we will need a way to persist, and retrieve them later. Since this NPM package will be used for backend applications, there are some situations where reused keys will need to either be passed into the NPM package, or managed internally by the NPM package.

Do we have a preference?

[dckc]

Is there a handy precedent in the ethereum world or something?

I'm hesitant to take responsibility for secure storage of private keys. Libraries that do it typically do special memory mapping stuff to keep the keys out of swap space and such. But I suppose we're already taking on the relevant risks with pair1.signTextHex('hello world'). Meanwhile... atomic file updates in a cross-platform fashion seems like another challenge.

When I made a dApp using RChain-API that needed a key store, I made it part of an overall object persistence mechanism in that app: https://github.com/dckc/rchain-dbr/blob/master/o2r/gateway/server/keyPair.js

The only other experience that comes to mind is with using Desktop keychain stuff (freedesktop secret service over dbus https://github.com/dckc/finquick/blob/master/desktop/server/main.js#L108 ).

[JoshOrndorff]

I'm not convinced that keys and signing are in scope for this project at all. There are good general-purpose key management tools that Dan mentioned (although someone would have to provide integration), and RChain specific ones like RSign.

[dckc]

#57 heads in this direction in an rclient sub-project.

[dckc]

I'm inclined to close this based on the key management support in rclient, but rclient isn't part of the travis testing and such (except the flow check, which is almost an accident).

Thoughts?

• declare victory based on what we have now
  • if it breaks, put more work into tests then
• wait until it's a 1st class part of the tests to declare victory
• move secretStore.js up from rclient/src into src
• other?