Key management / signing

[JoshOrndorff]

From @crypto-coder on October 4, 2018 6:22

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?

Copied from original issue: JoshOrndorff/RChain-API#26

[JoshOrndorff]

From @dckc on October 4, 2018 16:30

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]

Signing, that is: using off-chain tech to make signatures for verification by on-chain rholang, is what got me started on this project in the first place.

I suppose we could draw the line at serialization as in testRHOCore.js and tell users to "now sign the bytes as usual".

But "as usual" took several hours of research for me to get right. It turned out to be an entirely straightforward use of tweetnacl... my research was mostly wild goose chases that ended up being serialization problems... but still... I have walked at least one other developer through the off-chain-sig, on-chain-verify stuff, and if only for documentation purposes, it seems cost-effective to keep it here. Stuff like "DSP - like digital signal processor - is a handy mnemonic for remembering that the args to @"ed25519Verify" are data, signature, pubKey".

And I think testSigning.js is quite useful.

Recall that I originally developed the chrome extension as part of Rchain-Status. Then made RSign its own thing. At that point, there was a lot of overlap between the three of them. Getting it all DRY took me the better part of a week. The result is that both Rchain-Status and RSign depend on rchain-api for signing. If we move signing out of this project, I'd have to either copy the signing stuff back into Rchain-Status and RSign or make another tiny package. Neither alternative looks inviting.

I have not had a similar experience with key management (i.e. persistence).

Actually, in one of my dApps, addition to signBytes() and signText() I added a signData function that combines RHOCore.fromJSData() and signBytes(). I'm inclined to push that down into this package.