minimal stand-alonekey generation utility request

[Tectract]

Hi guys,

I'm looking to generate the smallest possible stand-alone passphrase / key-pair generator for my basecoin asset class, for users, and also so it can be integrated with a web-wallet via javascript, ideally, and run in a web-browser.

Can anyone help point me in the right direction? I see that 'basecli new key' seems to call into the tendermint/go-crypto repo. Could a simple go script just load tendermint/go-crypto and somehow call in to generate the passphrase, then get the privkey / pubkey associated with that and display them nicely for a user? Is there a way to generate these passphrases and keypairs in javascript right now or is that only coded up in GoLang?

Thanks!

[Tectract]

I see some code here for generating bip39-compliant passphrases and keypairs, but the go-crypto library seems to imply I need EDDSA keys instead of ECDSA keys for my basecoin asset classes, can someone clear that up?

https://github.com/cosmos/fundraiser-lib/blob/master/src/wallet.js

Could I use the linked toolset here as part of a standalone key-pair gen tool?

[ethanfrey]

basecli keys XYZ just defers to the command in go-crypto/cmd/keys, which can be called as keys XYZ. The only difference is the default directory it stores in, but that can be overriden with the --home flag to specify a dir.

That should clear up the standalone utility part of the question.

As to integration with javascript side, can @mappum please chime in here? Or @ebuchman ?

I don't know how the javascript side works and maybe someone can document how you planned to integrate them with go-crypto.

[Tectract]

My goal here is to make a simple web-wallet functionality that will allow users to generate passphrases and keypairs within the browser, which are encrypted client-side and then sent to EnLedger servers, so they can have an encrypted wallet backup on our servers. So I will use the JS code in fundraiser-libs, probably hard-copying instead of forking some of it to prevent eventual breakage. I will use the passphrase generation and derivePriv/PubKey functions, make a simple node.js script that does these functions, and then integrate that script into our Ruby-On-Rails React web stack, so it gets served to web clients. This way we can actually send EECoin to those accounts in EnergyChain, and users should (eventually) be able access node accounts with those funds, signing rights, token-access systems, with their pre-generated keypairs.

For a standalone passphrase generation tool, we'd like to just have a simple node script with a package.json file, and two simple commands to generate passphrase / keypairs, like "npm i" and "standalonePassGenerate". So users won't need a full GoLang compiler on their system, but they would still need node and npm at least.

The EnLedger website repos are not open-source but I could contribute this code back somewhere for you guys :)

[Tectract]

I guess we could open-source just this piece of our website...

[ethanfrey]

This is a very good question and at the very least we need to document our approach and design better to help out developers on this platform.

First, we had a discussion on secure distribution. If the wallet code is somehow compromised, then even if the private keys are securely stored, the corrupt wallet could steal them when you use them.

If you have a web wallet, you trust whatever server has the ssl certificate every time you visit the site. We considered an electron app, which is gpg signed and verified once upon download much more secure. A Chrome app which is cached locally is another alternative with security and ease of use between the other two options.

The first approach to js coding was to implement go-crypto and Go-wire in Javascript and create proper binary transactions and sign them. This was time consuming, but has been done and exists in two repos, js-crypto and js-wire.

However, they don't implement light client proofs and trust whatever query results come from the node. That has been resolved in go code, zero trust needed after the initial trust of the proper genesis file. But porting that logic to Javascript has been put on hold for the moment, as it was blocking all ui development.

The current approach, and unti we stabilize the entire client api cosmos-sdk and port it to Javascript, the recommended approach, is to use an electron app with a pure JavaScript Ui that talks to a local api server. The light client exposes a rest api to perform key management, building and signing transactions, light client proofs for all queries, parsing and displaying TX on the chain and binary state in the app.

There is also a Basecoin wallet ui that is almost complete for some time now and some js libraries to help.

As to compatibility with the fundraiser keys, that should be supported in go-crypto but I don't know the details. @mappum and @ebuchman designed and implemented that part. And @mappum should be able to add much more info on the js libs and current development.

All this needs to go into some docs as well.

[Tectract]

You're right that there some security considerations with web-wallets, specifically the trust in TLS certificate layer, trust in the company, trust that their web-server / CDN layer has not been comprimised.

That's why we like the standAlonePassGenerate option for the users. We have written one now based on the fundraiser-libs, here:

https://github.com/enledger/standAlonePassGenerate

We'd love any feedback on that. The keys are just displayed in hex, there was some discussion over whether some format like WIF might eventually be supported and I think it's likely a good idea :)

Note, there are some security considerations even with the standAlonePassGenerate tool, and that is that it relies on node submodules. It should be packaged up into a zip/tar file probably.

[mappum]

@Tectract I'm glad you were able to working, but just wondering why you copied the code into your repo rather than just using fundraiser-lib as a dependency?

[Tectract]

To prevent possible future breakage or deletion.

[ebuchman]

relevant for #324 .

Seems like a good idea to have standalone keys tho

[jackzampolin]

We have a number of javascript and golang libs that do this. I'm going to go ahead and close this issue. Please reopen if you think I have done so in error.