Currently, we already have support:
Verify and CheckMultiSigVerify and CheckMultiSigThere are some usage scenarios that we need to support
Case 1: Cross-chain
TODO
---------------------------- Updated at 9 June ------------------------------
Privacy crypto algorithm:
What other cryptography methods do you think we should add?
Some privacy project need us to add ecc pairing methods.
Some basic cyrpto methods like base58, base64, and hash160, I think we can add them.
I made a summary of EOS and ETH related algorithms:
ETH
Name| Usage
-- | --
ecrecover | Ecc
secp256k1 | Ecc
Bn256 | Ecc
sha3 | Hash
sha256 | Hash
ripemd160 | Hash
Blake2 | Zcash
EOS
Name | Usage
-- | --
secp256k1 | Ecc
secp256r1 | Ecc
ripemd160 | Hash
sha1 | Hash
sha256 | Hash
sha512 | Hash
base58 | Encode/Decode
I remember @vncoelho talking about possibly allowing users to select which curve to use. If this is possible, I'd like to see Curve25519 (Ed25519) support, as there is justified suspicion around the curve parameters used in secp256r1 that I would want to avoid.
The seed (which is supposed to be generated randomly) was not generated verifiably, and has no justification for it. See safecurves for reference. There's also a post from Vitalik on this topic and how Bitcoin may have evaded the problem by using k1.
MODPow?
neo-project/neo-vm#77
I think we can add it.
@EdgeDLT I think it's good for us add Curve25519. Here is a statistical graph that describes the curves used by the other chains, provided by @wanglongfei88

As you can see, speck256k1 and Curve25519 are widely used.
In fact you can use now speck256k1 in neo3
using (ScriptBuilder sb = new ScriptBuilder())
{
sb.EmitPush(publicKey.EncodePoint(true));
sb.Emit(OpCode.PUSHNULL);
sb.EmitSysCall(InteropService.Crypto.VerifyWithECDsaSecp256k1);
return sb.ToArray();
}
Some zkp projects, like Origo, Loopring, hope to access neo. But at present, we do not have complete support for zkp, mainly lacking support for ECC curve operations, including the following aspects:
1) add new opcode and syscalls
2) need to increase vm/compiler performance
For computational contracts, VM is currently very time consuming to run. This will be discussed at neo-devpack later.
3) need to reduce cost
Congratulations for pushing this discussion forward, @Tommo-L. Count with our support.
Perhaps it is important to have these ones as special opcodes and syscalls.
But it also looks crucial for NEO to make one step forward and allow us to deploy experimental curves and test them with callbacks (what we mentioned as opeval in a first moment). If that becomes feasible we can play with many other emerging technologies such as quantum security.
@Tommo-L nice initiative! there's a fundamental thing to mention here, regarding SHA3...
There are two SHA3! I guess we need to support both, or at least enforce very clearly which one is chosen... looks like one was supposed to be standard, but there were some changes from the adopted versions, known as Keccak.
On https://github.com/neoresearch/libcrypton we support both, if you need test vectors for both I can put here (Ethereum uses SHA3 Keccak version).
I think NIST-SHA3 is enough, which is more widely used. And Keccak is not a standard version and is rarely used, including eth2, which will be deprecated.
@Tommo-L Is there a timeline when we expect this list to be frozen? I'd like to start looking at available libraries that cover (hopefully) all needs.
@ixje I think it is enough now, mainly from the needs of some project parties.
Most helpful comment
@EdgeDLT I think it's good for us add Curve25519. Here is a statistical graph that describes the curves used by the other chains, provided by @wanglongfei88
As you can see, speck256k1 and Curve25519 are widely used.