search

spacemeshos / SMIPS

Spacemesh Improvement Proposals
https://spacemesh.io
Creative Commons Zero v1.0 Universal
7 stars 1 forks source link

SMIP-0009: Add support for ED25519 transactions signature scheme #12

Closed lrettig closed 1 year ago

lrettig commented 4 years ago

Opening an issue on @avive's behalf so we have a place to discuss this SMIP! Source: https://github.com/spacemeshos/SMIPS/blob/SMIP-0004/SMIP-0004.md

Add support for ED25519 transactions signature scheme

This is an early wip draft

Goals and Motivation

We would like to enable users to use popular hardware wallets and mobile wallets to protect their Spacemesh account and smart wallet private keys and to be able to easily and safely sign transactions using hardware wallets and popular mobile wallets.

We would like to enable users of Smapp and CLIWallet, the reference Spacemesh wallets, to use popular hardware wallets to securely sign transactions.

We want to have a simple and straight-forward integration story with 3rd party wallet developers and hardware wallets makers so they can add support to Spacemesh transactions quickly post Spacemesh mainnet genesis.

We would like to minimize the amount of work that Spacemesh hardware wallets and mobile wallets partners need to invest in order to support Spacemesh.

We would like to reduce the security risk which is involved in introducing a new signature scheme which is not yet audited by the security community.

Tech Background

Ed25519 is an EdDSA signature scheme using SHA-512 (SHA-2) and Curve25519. See: https://en.wikipedia.org/wiki/EdDSA#Ed25519, https://tools.ietf.org/html/rfc8032 and https://tools.ietf.org/html/rfc8709. Several modern blockchains (such as Polkadot) use this signature scheme for transactions. See: https://www.susanka.eu/coins-crypto/ . The scheme doesn't support public key extraction from a message and a signature. ED25519 scheme is part of the go standard lib: https://golang.org/pkg/crypto/ed25519/

Go-spacemesh, the full node implementation of the Spacemesh protocol, currently only supports a new custom signature scheme we call ED25519++ which is based on the ED25519 scheme and in addition supports extraction of public keys from signatures and messages. Reference: https://github.com/spacemeshos/ed25519

ED25519++ allows Spacemesh to reduce transaction size which is important as it lowers the mesh growth rate, as less bytes need to be stored on the mesh per transaction.

ED25519 and ED25519++ support the same private and public key pairs but have different logic for sign() and verify(). ED25519++ adds an extract(message, signature) => pub_key methods which only works on signatures generated with ED25519++ (and not signatures generated using ED25519).

If we keep only supporting the ED25519++ signature scheme then any hardware wallet or mobile wallet product will need to implement this scheme in order to support signing Spacemesh transactions.

For hardware wallets, the scheme will have to be developed, tested and secured for the device firmware and distributed to customers via a firmware update.

The Proposed Solution

Overview

Add support for the standard ED25519 signature scheme for Spacemesh transactions to the Spacemesh full node and specifications.

Spacemesh wallets such as Smapp and CLIWallet will use the ED25519++ scheme by default to sign transactions (when used as hot-wallets) and these wallets will create transaction data which excludes the signer's public key.

When a user signs a Spacemesh transaction using a hardware wallet or use a third party mobile wallet, the standard ED25519 signature scheme will be used and the transaction will include the signer's public key.

When hardware wallets and mobile wallets add support for ED25519++, Spacemesh wallet front-ends will be updated and use this signature scheme for signing and legacy ED25119 signature scheme usage should be gradually phased out.

Pros

Once this support is added, adding support for Spacemesh signatures in all major hardware wallet becomes a trivial integration project as ED25119 capabilities are already well supported and tested on all major hardware wallets. The integration becomes much more straight-forward as there's no need to implement and to secure a new signature scheme on the device.

Similarly, integration with any 3rd party wallets which support other major cryptocurrencies becomes trivial as it is highly likely that these wallets already support ED25519 as it is becoming a popular scheme for use with cryptocurrencies.

Having this simpler integration can ensure that major wallets will quickly add support for Spacemesh mainnet.

In addition, this design also enables Spacemesh to quickly add hardware wallet support to its own reference wallets, Smapp and CLIWallet, and to have more time to test these integrations prior to mainnet launch.

Users of planned Smart Wallet features enabled by SVM will be able to use any major hardware wallet to manage their master wallet keys and to use hardware wallet for multi-sig signing which adds an important additional layer of security to this important capability.

From a partnership perspective, choosing a simple integration instead of a highly complex one as proposed here dramatically increases the chances of a partnership materializing quickly which is important for Spacemesh.

Cons

  1. Accounts which use hardware wallet can be singled out. Note that this doesn't materially decrease security as account balances are already visible, so it's trivial to detect accounts with large balances.

  2. Transaction size is bigger for ED25519 transaction due to inclusion of public key.

  3. Increased transaction processing logic implementation complexity.

Dependencies and Interactions

Pending research

Interaction with existing code

Implementation details

side notes

Open questions

lrettig commented 4 years ago

From a partnership perspective, choosing a simple integration instead of a highly complex one as proposed here dramatically increases the chances of a partnership materializing quickly which is important for Spacemesh.

What sort of partnership?

lrettig commented 4 years ago

Some links that I found helpful, for reference:

Also, BIP32-style deterministic key derivation doesn't work out of the box for ed25519 since the curve has a non-linear key space. I found this: https://github.com/islishude/bip32 and this paper: https://github.com/islishude/bip32/blob/master/spec/Ed25519_BIP.pdf.

avive commented 4 years ago

Possible partnerships: mobile wallet makers, Samsung built-in galaxy phones wallets, ledger. Regarding bip32 and ed25519: Research should comment on it and have reviewed our bitp-32 style key derivation function currently used in the reference desktop wallet.

avive commented 4 years ago

Also, BIP32-style deterministic key derivation doesn't work out of the box for ed25519 since the curve has a non-linear key space. I found this: https://github.com/islishude/bip32 and this paper: https://github.com/islishude/bip32/blob/master/spec/Ed25519_BIP.pdf.

Interesting. @tal-m - curious if this also applied to the custom Spacemesh ED25519++ scheme. We will need to have a secure key derivation scheme for the Spacemesh wallets and do a fuller review of the current ED25519++ derivation in the Spacemesh desktop App - which is implemented.

Note that Ledger already implements improved ED25519 key derivation. See: https://www.ledger.com/ledger-releases-a-new-nano-s-firmware-update/

avive commented 4 years ago

Correction: ED25519++ sign method is based on an algorithm in paper: https://eprint.iacr.org/2017/985.pdf

avive commented 4 years ago

Regarding bip32 and ED25519. Ledger implemented this: https://ieeexplore.ieee.org/document/7966967 as well as some other blockchain projects. I guess we can use the same algorithm for key derivation in Spacemesh wallets even with ED25519++ because the key pairs in it are standard ED25519 key pairs.

lrettig commented 4 years ago

Note that Ledger already implements improved ED25519 key derivation. See: https://www.ledger.com/ledger-releases-a-new-nano-s-firmware-update/

The link in this article to the relevant paper is broken:

New derivation schemes Bip32-ed25519: this enables the future support of Cardano and new Tezos derivation paths.

But it refers to the paper I linked above (https://github.com/islishude/bip32/blob/master/spec/Ed25519_BIP.pdf), which seems to be the same paper at https://ieeexplore.ieee.org/document/7966967. I'd be curious to see an implementation of this code. There's https://github.com/islishude/bip32 (golang) and https://github.com/ilap/BIP32-Ed25519 (JS) but I'm not sure if either is complete.

avive commented 4 years ago

Anyone has any additional comments post design review on the implementation details. e.g. the proposed design for this feature? If yes, please voice them now before this goes into development....

lrettig commented 4 years ago

I want to be on record as saying that I don't like the idea of multiple signature schemes. It will slow down adoption (e.g., the hardware wallets issued described above), adds complexity, and can lead to confusion, and there are privacy concerns (as discussed above, and on the call). And, like any piecemeal fix, it doesn't really solve the problem of mesh growth, which would be better solved by a more holistic, first principles approach such as stateless clients. In other words it's a premature optimization.

A better approach, borrowed from Ethereum, is account abstraction: rather than a discrete number of signature schemes, each account can choose whatever signature scheme it likes, from a menu of templates/options, or else it can roll its own.

avive commented 4 years ago

Lane - this smipp - support for a signature shceme in tx will enable support basic account abstraction but only using signature schemes we support - I feel that supporting roll your own sig schemes at this stage is very premature for spacemesh. If we have a type filed in tx that specifies the scheme then we can add additional supported schemes in the future - so the first step, which is not assume 1 sig scheme and to support 2 is the step we need to take now + it solves the hardware wallet problem. I don't understand your argument about why multiple schemes will slow down adoption - it will speed up adoption by 6-12 months.

avive commented 4 years ago

There's already SMIP-0002 - renaming to 0009.

lrettig commented 4 years ago

Re: account abstraction and multiple signature schemes, see https://github.com/spacemeshos/product/issues/86.

I don't understand your argument about why multiple schemes will slow down adoption

We talked about this on a design review call - rolling our own standards risks slowing adoption because, e.g., we might not have hardware wallet support out of the gate, it might make lives harder for exchanges, it limits the existing tooling that can work with Spacemesh, etc.

I assume you're referring to adding standard ED25519 support on top of our "++" version - that partially addresses the issue but I think it risks leading to confusion, making the tooling harder to build, etc.

avive commented 4 years ago

To clarify, the variant of ED25519 and ED25519++ we use is SHA-512 for the hash function, and ECDSA for signing algorithm. This is the same variant used in the GO ED25519 standard crypto lib.

countvonzero commented 1 year ago

closed as it's implemented