Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement getsharedsecret #3490

Merged
merged 2 commits into from
Feb 28, 2020

Conversation

ZmnSCPxj
Copy link
Collaborator

@ZmnSCPxj ZmnSCPxj commented Feb 7, 2020

Closes #3486

Alternate solution, where we use the exact same Lightning BOLT standard of hashing the point and returning that from hsmd.

I strongly disagree with this approach:

  • If multiplying a secret scalar by an arbitrary SECP256K1 point and publicly revealing the resulting product risked revealing the secret scalar, then we should remember that the generator point G itself is an arbitrary SECP256K1 point (equal to 1 * G i.e. having a "secret" scalar of 1) and public-private cryptography would not be secure in the first place.
  • We can implement getsharedsecret in terms of getecdh (Implement getecdh #3486) but not vice versa. With getecdh exposed we can implement using ECIES and the Lightning BOLT (Bitcoin-ish?) ECDH key agreement standards, with only getsharedsecret like this we can only implement the Lightning BOLT key agreement and we would need to implement something else in hsmd if we want to support ECIES and other EC encryption standards as well (Lightning BOLT seems the only one that does not use X-coordinate-of-ECDH-product). I strongly prefer to keep the interface of hsmd small to facilitate fully implementing it in an actual hardware module.

@ZmnSCPxj ZmnSCPxj mentioned this pull request Feb 7, 2020
@rustyrussell
Copy link
Contributor

ECIES is kind of a broken "standard" right now (with differences in implementation leading to incompatibilities), and anyway we'd be using a totally weird EC curve. Best practice also seems to be https://link.springer.com/article/10.1007/s10623-019-00685-y?wt_mc=alerts.TOCjournals&utm_source=toc&utm_medium=email&utm_campaign=toc_10623_88_2 to hash the ECDH output.

Given the issues in ECIES interop, I'd really prefer a secp256k1 implementation we can all use, given their expertise in these matters.

@ZmnSCPxj
Copy link
Collaborator Author

This uses the default ECDH behavior of libsecp256k1, which is what is used consistently elsewhere in Lightning.

@ZmnSCPxj ZmnSCPxj added this to the 0.8.2 milestone Feb 16, 2020
Copy link
Contributor

@rustyrussell rustyrussell left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ack a088425

ChangeLog-Added: New `getsharedsecret` command, which lets you compute a shared secret with this node knowing only a public point. This implements the BOLT standard of hashing the ECDH point, and is incompatible with ECIES.
@rustyrussell
Copy link
Contributor

Trivial rebase...

@rustyrussell rustyrussell merged commit d9b2482 into ElementsProject:master Feb 28, 2020
@ZmnSCPxj ZmnSCPxj deleted the getsharedsecret branch March 2, 2020 01:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants