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

Expand supported cryptography primitives to include industry standards #972

Closed
canesin opened this issue Jul 31, 2019 · 4 comments · Fixed by #1419
Closed

Expand supported cryptography primitives to include industry standards #972

canesin opened this issue Jul 31, 2019 · 4 comments · Fixed by #1419
Labels
Discussion Initial issue state - proposed but not yet accepted Feature Type: Large changes or new features VM New features that affect the Neo Virtual Machine or the Interop layer

Comments

@canesin
Copy link
Contributor

canesin commented Jul 31, 2019

Hi,

This can be tagged for NEO3 but might still beneficial to NEO2 projects building like SeraphID, Bridge and Nash.

The request is to add all supported Bitcoin (secp256k1) and Ethereum (keccak256) primitives for encryption, signing and hashing algorithms. In addition to those if possible also add X509v3 RSA primitives to allow to interact with digital identity cards like from Estonia or Finland from smart contracts.

@lock9 lock9 added the Discussion Initial issue state - proposed but not yet accepted label Jul 31, 2019
@igormcoelho
Copy link
Contributor

igormcoelho commented Jul 31, 2019

@canesin I fully agree, could you support this Issue here on vm? neo-project/neo-vm#176

I believe the best way to do it is to put crypto primitives as neo-vm extensions... this way, we enforce neo-vm as a crypto computing machine (for blockchain and verifiable computing), and since it's low level implementation, it's outside the scope of blockchain interops, so it's better as computing extensions. VM extensions can grow in the future, without harming blockchain states or protocol.

We could draft a NEP for it, what do you think?

@lllwvlvwlll
Copy link
Member

This could also be helpful for Moonlight. @birmas

@lock9
Copy link
Contributor

lock9 commented Jul 31, 2019

@igormcoelho how these extensions would work? What would happen if someone does not have the extension? Are extensions mandatory for all nodes? So why is it called an extension? Why not add it directly to the NEO VM or use it as an Interop service?

@igormcoelho
Copy link
Contributor

The proposed idea for extensions is to extend VM operations in time, without creating new opcodes. Since EXTENSION code is incremental (differently from Interops, which are free on every neo-based blockchain platform), we can control it over time, without needing to version the whole thing.
As long as we reject scripts that try to use unexisting extensions in the present, this won't cause problems to be future, when new extensions are added (this is a simple numeric comparison, but requires tx opcodes to be parsed on node).

@lock9 lock9 added Feature Type: Large changes or new features VM New features that affect the Neo Virtual Machine or the Interop layer labels Aug 9, 2019
@shargon shargon mentioned this issue Jan 15, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Discussion Initial issue state - proposed but not yet accepted Feature Type: Large changes or new features VM New features that affect the Neo Virtual Machine or the Interop layer
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants