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

Support RSA signature verification #74

Open
axic opened this Issue Mar 9, 2016 · 16 comments

Comments

Projects
None yet
@axic
Member

axic commented Mar 9, 2016

I propose to support RSA signature verification through a precompiled contract with appropriate fees.

With the current EVM, verification for very low key lengths is trivially implemented using the native 256 bit arithmetic, although it is useless due to inadequate security. Supporting bigger key lengths is prohibitive cost wise. (Requires implementing a bignum library for mul and mod on top of EVM. Alternatively it can be offloaded to an oracle, where trust can be a problem and is also suboptimal.)

Motivation: many PKI schemes, including those employed by government ID cards, rely on RSA. Supporting an easy way to verify a signature would mean to support authentication/authorization using those schemes in a smart contract.

High level method: rsaverify(msg, N, e, S, paddingScheme), where

  • msg is the message hash,
  • N is the public key modulus,
  • e is the public key exponent
  • and S is the signature.

Returns a boolean.

Regarding padding schemes I would definitely include an option none, where no padding would be applied and the caller would be expected to handle that.

Challenges: Where this gets complex is defining which key lengths and padding schemes to support and how to define the API. Size of N could be used to determine key length. Possibly the fee would depend on the key length.

@axic

This comment has been minimized.

Member

axic commented Apr 6, 2016

Here is a sample implementation: https://github.com/axic/ethereum-rsa

And a blog post explaining the situation (a few use cases) a bit more.

@pipermerriam

This comment has been minimized.

Member

pipermerriam commented Apr 6, 2016

This would be pretty excellent. I've been mulling over how to build an identity bridge between ethereum and keybase and this sort of signature verification would help enable that.

@vbuterin

This comment has been minimized.

Collaborator

vbuterin commented Apr 6, 2016

I would recommend just adding a whole suite of bigint arithmetic precompiles then; more generalized that way.

@christianlundkvist

This comment has been minimized.

christianlundkvist commented Apr 6, 2016

This is very cool! We're going to be linking RSA keys to uPort identities probably at first using an external oracle that verifies the signature, but this would be very nice!

@wanderer wanderer added EVM EIP labels Apr 14, 2016

@murraci

This comment has been minimized.

murraci commented Apr 28, 2016

This would be very sweet.

@Gustav-Simonsson

This comment has been minimized.

Member

Gustav-Simonsson commented May 24, 2016

+1 for bigint arithmetic precompiles from which RSA can be easily be built without significant overhead compared to direct RSA op codes

@Renaud-V

This comment has been minimized.

Renaud-V commented Jun 16, 2016

I add my vote to this proposal. The support of RSA signature verification will be a bridge to all applications build on electronic Identity Cards. Estonia, Germany and Belgium already use electronic ID card.
This support will ease/automate lots of administrative processes in countries having eID.

@whitj00

This comment has been minimized.

whitj00 commented Jun 28, 2016

Hi there,

I was wondering what the status is on this EIP is and how I would be able to help. This is something that would be very useful for a project I'm working on

@aakilfernandes

This comment has been minimized.

aakilfernandes commented Jul 21, 2016

+1. Had a cool idea for a microtipping service for developers using ssh keys.

I would love to do npm install some-project --thankyou. Npm or whatever package manager would look at the repo, see whos been making commits, and then send som eth to a smart contract. The smart contract would require an rsa signature based on the ssh keys used in the project in order to claim the funds.

@tristanhoy

This comment has been minimized.

tristanhoy commented Oct 20, 2016

+1 for generic bigint capability! This would allow the implementation of just about any crypto on the Ethereum network.

The particular use-case I'm looking at is where an Ethereum contract is an "oblivious witness" to a particular type of transaction - it can verify the authenticity/integrity of the transaction, but doesn't know the contents of the transaction. Without bigint support, I can't cryptographically verify the transactions within the contract, which means I can't guarantee the state of the contract, which means the state becomes "optimistic" - ALL transactions are accepted and it's up to the client connecting to the contract to figure out which ones are actually valid. Nightmare.

Absolutely critical bigint methods:

  • add/sub/mul/div
  • pow
  • mod
  • modExp
  • eq/gt/gte/lt/lte

And the following, if you're supporting decimals:

  • floor/ceil

The above primitives can be used to trivally construct all of the following algorithms supporting numerous cryptographic applications:

  • GCD/EGCD
  • LCM
  • modInv
  • isPrime
  • nthRoot
@Alexander-Herranz

This comment has been minimized.

Alexander-Herranz commented May 6, 2017

Great idea!

@adrianbrink

This comment has been minimized.

adrianbrink commented Jun 26, 2017

Is this still in active development and what is the status of its implementation?

@riordant

This comment has been minimized.

riordant commented Jul 8, 2017

@noxonsu

This comment has been minimized.

noxonsu commented Sep 20, 2017

Any updates? :(

@Arachnid

This comment has been minimized.

Collaborator

Arachnid commented Sep 20, 2017

Modular exponentiation was implemented instead. Expect an RSA verification solidity library some time soon.

@adriamb

This comment has been minimized.

adriamb commented Sep 25, 2017

A small implementation of RSA signatures with Pkcs1.5 padding and SHA256 digest in https://github.com/adriamb/SolRsaVerify/blob/master/SolRsaVerify.sol

5chdn added a commit to 5chdn/EIPs that referenced this issue Apr 11, 2018

Arachnid added a commit that referenced this issue Apr 16, 2018

Restore Contract Code at 0x863DF6BFa4469f3ead0bE8f9F2AAE51c91A907b4 (#…
…999)

* Claim a random number

* Add specification

* Add rationale

* Improve wording

* Improve formatting

* Improve wording

* Specify the account values for balance, nonce, code, and storage

* Be more specific about a hard-fork

* Add poc implementation for Parity

* Improve formatting

* Improve formatting

* Make sure the total supply will be unchanged.

* Point to relevant changes in chain spec.

* Remove contracts/#74 code from the proposal.

* Use the old but patched library

* Highlight differences to the initially deployed contract

* Add code and storage for the stateDiff

* Update resources

* Update resources

* Add correct discussion URL

* Standard Track -> Standards Track

* Link the PR for Parity

* Rationale on unchanged Ether supply

* Split specification alternatives via bytecode vs. codehash

Arachnid added a commit to Arachnid/EIPs that referenced this issue May 2, 2018

Restore Contract Code at 0x863DF6BFa4469f3ead0bE8f9F2AAE51c91A907b4 (e…
…thereum#999)

* Claim a random number

* Add specification

* Add rationale

* Improve wording

* Improve formatting

* Improve wording

* Specify the account values for balance, nonce, code, and storage

* Be more specific about a hard-fork

* Add poc implementation for Parity

* Improve formatting

* Improve formatting

* Make sure the total supply will be unchanged.

* Point to relevant changes in chain spec.

* Remove contracts/ethereum#74 code from the proposal.

* Use the old but patched library

* Highlight differences to the initially deployed contract

* Add code and storage for the stateDiff

* Update resources

* Update resources

* Add correct discussion URL

* Standard Track -> Standards Track

* Link the PR for Parity

* Rationale on unchanged Ether supply

* Split specification alternatives via bytecode vs. codehash

johnhforrest added a commit to codex-protocol/EIPs that referenced this issue Jul 10, 2018

Restore Contract Code at 0x863DF6BFa4469f3ead0bE8f9F2AAE51c91A907b4 (e…
…thereum#999)

* Claim a random number

* Add specification

* Add rationale

* Improve wording

* Improve formatting

* Improve wording

* Specify the account values for balance, nonce, code, and storage

* Be more specific about a hard-fork

* Add poc implementation for Parity

* Improve formatting

* Improve formatting

* Make sure the total supply will be unchanged.

* Point to relevant changes in chain spec.

* Remove contracts/ethereum#74 code from the proposal.

* Use the old but patched library

* Highlight differences to the initially deployed contract

* Add code and storage for the stateDiff

* Update resources

* Update resources

* Add correct discussion URL

* Standard Track -> Standards Track

* Link the PR for Parity

* Rationale on unchanged Ether supply

* Split specification alternatives via bytecode vs. codehash
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment