Skip to content

RSA ECDSA signature support

Jump to bottom
Arnold Daniels edited this page Oct 12, 2020 · 3 revisions

Transactions on the LTO Network are signed using ED25519. We want to make it possible for users to use existing key pairs to sign transactions, by supporting multiple algorithms. These keys might come from other blockchains or X.509 certificates.

We want the following protocols to be supported

  • RSA (X.509)
  • Curve25519
    • ED25519 (default, LTO)
    • X25519 (Waves)
  • ECDSA
    • SECP256K1 (ETH, BTC)
    • SECP256R1 / NIST-P256 (X.509)
    • SECP384R1 / NIST-P384 (X.509)

Transaction data structure

The initial idea to implement this was to add a key type field to the data structure for all transactions. However, this has some drawbacks:

  1. Changing the data structure of all transaction types is a major undertaking, requiring to update all client libs.
  2. RSA public keys are a lot bigger than ED25519 keys, increasing the size of a transaction.
  3. It doesn't cover smart accounts, as the tx only contains the proof and not the signature.

Smart accounts

By using smart accounts, the data structure of transactions doesn't need to change. If the smart account script returns true, the transaction is accepted. It uses the proofs array and runs sigVerify() to check against the public key.

Other cryptographic algorithms can be supported by implementing functions to verify the signature. Using these algorithms requires the use of a smart account. Normal accounts are still expected to sign with ED25519.

Unsolved issue ❗

How to create the smart account? At that point, the tx requires an ED25519 signature, but we don't have an ED25519 private key.

Yes, we'd have to introduce a new register public key tx type to register an RSA key and that you can sign with RSA. So that would be a modification in the consensus model similar to a smart account, for address the based on sha256(Blake2b256(sha256(RSA pub key))).

There are 2 options:

  1. A new version of the smart account tx that can be signed with RSA / EdDSA.
  2. Add a new tx type specifically for publishing the public key.

With 1 the changes required for are minimal; for all tx type besides setting a script, the current smart account logic would be used. However, 2 could be combined with a future feature of publishing X.509 certificates. It also enforces that the RSA key that signs the tx is the one that is registered (may differ with smart accounts).

Address

Addresses are calculated based on a hash of the public key sha256(Blake2b256(...)). The cryptographic algorithm or the size of the public key is not important. For instance, it's possible to calculate a valid address for an RSA public key.

Transactions have a PublicKeyAccount field, which is used to calculate the address. This field is 32 bytes long and thus won't fit an RSA key. As an alternative, we can use the SHA256 hash of the RSA public key as a pseudo-public key.

Note that unlike with ED25519, there won't be a hardcoded relationship between the address and the public key. The smart account could potentially contain a public key that doesn't correspond with the address. However, this isn't something that would lead to an exploit, as a valid key pair is required to create the smart account in the first place.

Clone this wiki locally