Ability to sign arbitrary text with cli

[jackzampolin]

Summary

Users sometimes want to use their keys to sign arbitrary text that is not transactions. They would also like to be able to prove a signature is associated with a pubkey if there is signed arbitrary text. I propose two new cli functions:

gaiacli keys sign [file] --from [key_name] > signed_file.json
gaiacli keys verify [file]

The first call would output a json blob something like:

{
  "text": "arbitrary text from the file",
  "pub": "cosmos1....."
  "sig": "signature"
}

and the verify call would take that json and verify the signature.

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned

[vshvsh]

There should be a default option to add some predermined text to a sig text to reduce the attack surface. It should be at gaiacli and other key managing software layer so that different ui levels would know to trust key management to add a prefix right from the start.

[vshvsh]

Related eip: ethereum/EIPs#191

[alessio]

Can do 👍

[alexanderbez]

This needs to follow the ICS 15 spec, which is incomplete atm.

[sahith-narahari]

Hey guys,was just scrolling through this.I worked on something like this already.

Should this be an on-chain thing,if it is so shouldn't it be more like gaiacli tx keys sign .I can make few modifications and raise a PR if there's some more information

[alessio]

Would something like this work?

$ gaiacli keys sign foo
actus me invito factus
non est meus actus
Password to sign with 'foo':
{"text":"actus me invito factus\nnon est meus actus\n","pub":{"type":"tendermint/PubKeySecp256k1","value":"AkBNV2wxwQf2924yhmZ/skks2z20PFqlO19msap/N3EZ"},"sig":"3d6T8x+1pVn6vQ0zo2tHiu5X/nBXeYckzBzNMRkrWDU+9qBEZtP/Dusq4l0a1InVfj3C6WZD/f3+KETJ9uSE3Q=="}

[jnaviask]

that'd be fine so long as we can use echo "message" | gaiacli keys sign foo in addition to a text input prompt

[jnaviask]

I would also suggest upgrading the gaiacli tx sign interface to accept this sort of command -- it seems clunky to have users save the transaction to a file first, and then run the command on it.

Ideally we could output a one-liner for the user that would generate a signature without them having to save files (maybe we could save to a temp file as part of the command, but still feels off).

[alexanderbez]

This requires a larger discussion around standards and integration with Ledger. See ICS 15.

[alessio]

Unassagning as per #5066 (comment)

[tnachen]

@cwgoes @alexanderbez can one of you help clarify where we are with this? Do we have pending discussions on the IBC spec side to work out first, or we can take @alessio changes as-is? The conclusion on the surface from ics#33 seems to suggest it’s a sdk only issue

[cwgoes]

@cwgoes @alexanderbez can one of you help clarify where we are with this? Do we have pending discussions on the IBC spec side to work out first, or we can take @alessio changes as-is? The conclusion on the surface from ics#33 seems to suggest it’s a sdk only issue

This is unrelated to IBC (applications on top of IBC might also use it, but the standards are independent). I moved it out of the ICS repository since that ended up being solely for IBC-related specifications, which this is not.

That said, I think the ICS 15 spec @alexanderbez started is a good start. We should have a document somewhere (probably this repo) that defines how things are signed, at least.

[fedekunze]

Tbh I wouldn't consider this as a priority. At least for the core SDK team. There needs to be more discussion around this feature + an ADR.

[alexanderbez]

At this point, we can proceed with an ADR and coordination between @jleni and @alessio to make sure proper Ledger support is enabled.

[jleni]

Sure, happy to move forward when you are ready @alessio Let's discuss it this week

[alessio]

@jleni and I had a quick catch up re: this matter. You'll hear from us soon 😎 👍

[alessio]

Limitations

• Messages are restricted to a maximum of 256 bytes?
• UTF8 is not supported
• Only representable ASCII characters (32..127) can be used. The plain message will be shown in the screen.
• If binary content is required, it will need to be base64 encoded. The user interface will show base64.

Cryptography

• Nothing changes with respect to normal Cosmos messages

• Secp256k1
• Sha256

Questions

Is there a well defined schema for this kind of messages?

AFAIK no, there isn't (@alessio)

Will this ever be used to transfer funds?

If this is the case, users will not be able to see what is actually being signed. The purpose of a well structured data format is to allow users to review what they are signing.

Risks

Ledger review may not like the idea. This increases the risk of the app staying in developer mode.

[jaekwon]

I didn't read the whole thread, just responding to what I see above from @alessio ...
I'm not sure if we should allow the ledger to sign any (JSON) document... but I think we should be able to let the ledger sign a special document that is intended to not have any side effects in transactions... see https://github.com/cosmos/ledger-cosmos/issues/160#issuecomment-568811460

[njmurarka]

Hello everyone.

I was talking to @alessio and in fact, this feature is something we really need right now.

To give some background...

We spent sometime here at Bluzelle trying to work the Peggy project, so that we could move tokens back and forth between Ethereum and COSMOS. But as you probably know, it is far from ready for production and we hit many blockers.

We have since decided and built a much simpler (and quite centralized) bridge to move tokens between the two networks. If popular and warranted, we could make this available to the community. I think it is highly valuable to bridge the networks.

One of the key things we need to be able to do is map which "sending" ETH address maps to which "beneficiary" COSMOS address. This is so that when ERC20 is received in our "inbox" address on Ethereum, we can map that sender to a corresponding COSMOS address on our chain, and send the corresponding # of tokens to them in COSMOS.

We allow users to provide a pre-set mapping so they can indicate which COSMOS address should receive these tokens, based on the Ethereum wallet they own. But to minimize attack vectors, we require that the mapping from A => B (A is Ethereum address and B is COSMOS address) also comes with a signature, signed by A's private key.

With this signature, we can verify that A indeed is mapped to B and that some imposter B' has not tampered with and changed the mapping to be A => B'. More specifically, we can ask the Ethereum API's to confirm that the signature indeed belongs to A.

In the same way, we need to do the opposite direction... B => A. We need to store with this mapping a signature, signed by B, using B's private key. So we absolutely need a way to sign an arbitrary string in COSMOS and then later on, verify who it was signed by.

I was going to draw a diagram but I figured it was pretty straightforward to describe it here.

Please advise how we can fast track this? I can foresee lots of uses for a COSMOS public/private keypair beyond just signing transactions... the ability to sign arbitrary messages opens up alot of scope. I can see for example the possibly to have a chat program where each message can be signed by the COSMOS owner of the address of the message sender. This is another program we are building that this could be useful for.

Thanks.

[romeo4934]

Hi Guys,
We would need to have this feature as well :)

[romeo4934]

@alessio any help :) ?

[jleni]

This is planned as part of the next release, however, we are working with Ledger on some additional features that require some bigger changes, so it will take a bit of time.

[romeo4934]

Great!

One question,

are we going to have signed message spec like Ethereum where we can verify the signed message against the address and not the full pubkey? That would be great :)

[romeo4934]

@jleni

[tac0turtle]

talking with zondax we decided to move the adr to the cip repo and then work on this story on the client side

[maxim-uvarov]

@tac0turtle thanks for the update. Is there a link to track the progress?

[robert-zaremba]

@maxim-uvarov https://github.com/cosmos/cips/pull/22/files

[alexanderbez]

Glad to see this come through!!!

[npinto]

Thanks for this folks!