What cryptography methods do you think we should support in syscalls?

[Tommo-L]

Currently, we already have support:

• SHA256
• RIPMED160
• Base64
• Base58
• Secp256r1 Verify and CheckMultiSig
• Secp256k1 Verify and CheckMultiSig

There are some usage scenarios that we need to support

Case 1: Cross-chain

• Ecrecover [neox-2.x] add interop services #1597

TODO

• Curve25519
• Sha3
• ModPow

---------------------------- Updated at 9 June ------------------------------
Privacy crypto algorithm:

• ecc add
• ecc scalarmul
• ecc pairing

What other cryptography methods do you think we should add?

[Tommo-L]

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.

[shargon]

MODPow?
neo-project/neo-vm#77

[doubiliu]

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

[EdgeDLT]

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.

[Tommo-L]

MODPow?
neo-project/neo-vm#77

I think we can add it.

[Tommo-L]

@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.

[shargon]

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();
            }

[Tommo-L]

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

• ecc curve and point
• ecc add operation
• ecc scalarmul operation
• ecc pairing operation
• pow mod

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

[vncoelho]

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.

[igormcoelho]

@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).

[Tommo-L]

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.

[ixje]

@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.

[Tommo-L]

@ixje I think it is enough now, mainly from the needs of some project parties.