-
Notifications
You must be signed in to change notification settings - Fork 5.4k
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
Comments
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. |
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. |
I would recommend just adding a whole suite of bigint arithmetic precompiles then; more generalized that way. |
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! |
This would be very sweet. |
+1 for bigint arithmetic precompiles from which RSA can be easily be built without significant overhead compared to direct RSA op codes |
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. |
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 |
+1. Had a cool idea for a microtipping service for developers using ssh keys. I would love to do |
+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:
|
Great idea! |
Is this still in active development and what is the status of its implementation? |
@adrianbrink see #101 |
Any updates? :( |
Modular exponentiation was implemented instead. Expect an RSA verification solidity library some time soon. |
A small implementation of RSA signatures with Pkcs1.5 padding and SHA256 digest in https://github.com/adriamb/SolRsaVerify |
…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
…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
This has been obsoleted by https://eips.ethereum.org/EIPS/eip-198. |
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
andmod
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)
, wheremsg
is the message hash,N
is the public key modulus,e
is the public key exponentS
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.The text was updated successfully, but these errors were encountered: