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

Created on 26 Apr 2020  Â·  13Comments  Â·  Source: neo-project/neo

Currently, we already have support:

  • [x] SHA256
  • [x] RIPMED160
  • [x] Base64
  • [x] Base58
  • [x] Secp256r1 Verify and CheckMultiSig
  • [x] Secp256k1 Verify and CheckMultiSig

There are some usage scenarios that we need to support

Case 1: Cross-chain

  • [x] Ecrecover #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?

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

image

As you can see, speck256k1 and Curve25519 are widely used.

All 13 comments

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

image

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

  • 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

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.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

brianlenz picture brianlenz  Â·  37Comments

deanpress picture deanpress  Â·  39Comments

erikzhang picture erikzhang  Â·  31Comments

erikzhang picture erikzhang  Â·  72Comments

SueNEO picture SueNEO  Â·  30Comments