You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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!
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.
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
+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.
Reacted by Alexander Herranz, James Young and piotr-roslaniec
+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:
Activity
axic commentedon 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 commentedon 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 commentedon Apr 6, 2016
I would recommend just adding a whole suite of bigint arithmetic precompiles then; more generalized that way.
coder5876 commentedon 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!
murraci commentedon Apr 28, 2016
This would be very sweet.
Gustav-Simonsson commentedon 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 commentedon 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 commentedon 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 commentedon 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 commentedon 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:
And the following, if you're supporting decimals:
The above primitives can be used to trivally construct all of the following algorithms supporting numerous cryptographic applications:
Alexander-Herranz commentedon May 6, 2017
Great idea!
adrianbrink commentedon Jun 26, 2017
Is this still in active development and what is the status of its implementation?
riordant commentedon Jul 8, 2017
@adrianbrink see #101
noxonsu commentedon Sep 20, 2017
Any updates? :(
Arachnid commentedon Sep 20, 2017
Modular exponentiation was implemented instead. Expect an RSA verification solidity library some time soon.
adria0 commentedon Sep 25, 2017
A small implementation of RSA signatures with Pkcs1.5 padding and SHA256 digest in https://github.com/adriamb/SolRsaVerify
Remove contracts/ethereum#74 code from the proposal.
Restore Contract Code at 0x863DF6BFa4469f3ead0bE8f9F2AAE51c91A907b4 (#…
Restore Contract Code at 0x863DF6BFa4469f3ead0bE8f9F2AAE51c91A907b4 (e…
axic commentedon Mar 1, 2019
This has been obsoleted by https://eips.ethereum.org/EIPS/eip-198.
update SFI definition based on ACDT#74
Update EIP-7723: update SFI definition based on ACDT#74 (#11475)