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

Support RSA signature verification #74

Closed
axic opened this issue Mar 9, 2016 · 17 comments
Closed

Support RSA signature verification #74

axic opened this issue Mar 9, 2016 · 17 comments

Comments

@axic
Copy link
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
Copy link
Member Author

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
Copy link
Member

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
Copy link
Contributor

vbuterin commented Apr 6, 2016

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

@coder5876
Copy link

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!

@murraci
Copy link

murraci commented Apr 28, 2016

This would be very sweet.

@Gustav-Simonsson
Copy link

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

@Renaud-V
Copy link

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
Copy link

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
Copy link

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
Copy link

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
Copy link

Great idea!

@adrianbrink
Copy link

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

@riordant
Copy link

riordant commented Jul 8, 2017

@adrianbrink see #101

@noxonsu
Copy link

noxonsu commented Sep 20, 2017

Any updates? :(

@Arachnid
Copy link
Contributor

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

@adria0
Copy link

adria0 commented Sep 25, 2017

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

5chdn added a commit to 5chdn/EIPs that referenced this issue Apr 11, 2018
Arachnid pushed a commit that referenced this issue Apr 16, 2018
…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 pushed a commit to Arachnid/EIPs that referenced this issue May 2, 2018
…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
@axic
Copy link
Member Author

axic commented Mar 1, 2019

This has been obsoleted by https://eips.ethereum.org/EIPS/eip-198.

@axic axic closed this as completed Mar 1, 2019
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

No branches or pull requests