Due to some considering NIST curves insecure and
Golang having ed25519 native support, there was
not a reason for not implementing in Fabric.

Tests cases for ed25519 were also added. Since
ed25519 key derivation is not called by any
function, I left as a TODO.

As I am working on ed25519 support for node fabric-gateway,
I needed to add ed25519 support for cryptogen also,
aiming to pass tests with certificates containing
ed25519 keys. Since the node fabric-gateway tests
generate their crypto material with cryptogen, I
adapted cryptogen to support ed25519 keys.

Signed-off-by: Johann Westphall <johannwestphall@gmail.com>

Based on the raft integration test, they are
mainly the same tests, but executed in a network created with
ed25519 crypto material.

Note that in this commit we did not added the ed25519 integration
test network creation, implemented in the "integration/nwo" folder.
The present commit only add the tests.

Signed-off-by: Johann Westphall <johannwestphall@gmail.com>

This commit has the changes in the channel capabilities,
introducing channel capabilities version V2_0,
which invokes a new msp version "MSPv_1_4_4". This is
the only msp version which accepts ed25519 identities.

This ensures that, during the upgrade process to support
ed25519, the blockchain will not become inconsistent.

Signed-off-by: Johann Westphall <johannwestphall@gmail.com>

This commit will be forcibly squashed afterwards, but it is
intended to save partially capabilities enhancements and
ed25519 integration tests.

About Channel capabilities, I renamed the Channel capabilities that
support ed25519 from v2_1 to v2_4. Likewise, the MSP version was also
renamed to MSPv2_4.

Integration tests and the needed modifications were also added,
to ensure proper behavior of the Channel v2_4 capabilities.
The test's main goal was to prove that a peer without ed25519
support will stop validating blocks for the a channel with
v2_4 capabilities.

Cryptogen flag "--keyalg" was removed from my previous commit
to keep it simple. I also added a field on the parsed crypto-
config.yaml to generate ed25519 keys.

Signed-off-by: Johann Westphall <johannwestphall@gmail.com>

On previous commits, I made a changed on the vendored package
"vendor/github.com/hyperledger/fabric-config/configtx/signer.go",
since the tests on "integration/ed25519" required such change.

However, since this folder is being deleted and changes to the vendored
package would require another pull request, I decided to revert the
changes on the file.

Signed-off-by: Johann Westphall <johannwestphall@gmail.com>

As requested by the fabric Code Owner yacovm, the
capabilities and the msp version name must be renamed
to V3_0, because the ed25519-support will probably
enter as a feature in Fabric 3.0.

Signed-off-by: Johann Westphall <johannwestphall@gmail.com>

Signed-off-by: Johann Westphall <johannwestphall@gmail.com>

Due to the renaming of the ed25519 Channel capabilities
to "v3_0" and other requests by fabric Code Owner yacovm,
the ed25519 integration test had to be updated.

Now the ed25519 integration test cases use a raft network with
three orderers.

Signed-off-by: Johann Westphall <johannwestphall@gmail.com>

Signed-off-by: Johann Westphall <johannwestphall@gmail.com>

Signed-off-by: Johann Westphall <johannwestphall@gmail.com>

Previously, the golang ed25519 library was being used to
sign hashes. However, the golang ed25519 library must have
the full message as parameter and it calculates the hash
in the "ed25519.Sign()" function.

To solve that problem, the Sign and Verify methods in
"msp/identities.go" calculate the hash only if the
certificate does not have a ed25519 key.

Some parameters' names were also changed to keep the
coherence with the ed25519 Sign and Verify methods.

Signed-off-by: Johann Westphall <johannwestphall@gmail.com>

This is an implementation correction. Since the methods
to store keys deals with interfaces, the ed25519 pointers
were not causing errors on compilation. However, ed25519
key pointers would cause errors in execution time.

Even though these methods to store keys are not used in
production, they might be one day.

Golang deals with ECDSA keys as pointers but not with
ED25519 and I cannot see a reason for that. However,
I believe that dealing with pointers, when it is possible,
is better for memory performance.

Signed-off-by: Johann Westphall <johannwestphall@gmail.com>

Signed-off-by: Johann Westphall <johannwestphall@gmail.com>

Signed-off-by: Johann Westphall <johannwestphall@gmail.com>

Signed-off-by: Johann Westphall <johannwestphall@gmail.com>

Signed-off-by: Johann Westphall <johannwestphall@gmail.com>

Changes regarding dealing with pointers to
ed25519 keys versus the values. This is a
concern because golang generally deals
with ed25519 keys by value.

This causes a difference between the default
way to deal with ecdsa keys (pointers) and
ed25519 ones (values).

As I implemented, the ed25519 keys storing and parsing
follow the general rules:

1) Ed25519 keys are parsed from files as values (ed25519.PrivateKey or
ed25519.PublicKey) but are eventually converted to pointers
to fit the structs ed25519PrivateKey and ed25519PublicKey.

2) To store ed25519 keys in the fileks, they are dealt with as pointers
until the marshalling method, from the x509 golang library. This fits
test cases for storing "nil" keys, that would cause panic if the key
were treated as value.

Fileks test cases for ed25519 were added.

Signed-off-by: Johann Westphall <johannwestphall@gmail.com>

Signed-off-by: Johann Westphall <johannwestphall@gmail.com>

Signed-off-by: Johann Westphall <johannwestphall@gmail.com>

Signed-off-by: Johann Westphall <johannwestphall@gmail.com>

The warning in the logs when a key algorithm was not
supported was to big. Only the common names are used
now, instead of the whole subject and issuer.

Signed-off-by: Johann Westphall <johannwestphall@gmail.com>

Signed-off-by: Johann Westphall <johannwestphall@gmail.com>

Signed-off-by: Johann Westphall <johannwestphall@gmail.com>

Signed-off-by: Johann Westphall <johannwestphall@gmail.com>

Some tabs were introduced on previous commits
causing a parsing error on the defaultConfig.
A test was added to prevent this error from
happening again.

Signed-off-by: Johann Westphall <johannwestphall@gmail.com>

This commit adds the field PublicKeyAlgorithm to
cryptogen's default config. CAs crypto-material keys
might be generated using ed25519 or ecdsa.

Signed-off-by: Johann Westphall <johannwestphall@gmail.com>

Signed-off-by: Johann Westphall <johannwestphall@gmail.com>

Since the last merge of this working with the main
branch (ff4eb12), the recent commit (14c3a0c) introduced
new calls for the function nwo.UpdateConfig(). We fix these new calls
by passing a 'nil' ordererSigners argument.

Signed-off-by: Johann Westphall <johannwestphall@gmail.com>

Signed-off-by: Johann Westphall <johannwestphall@gmail.com>

Signed-off-by: Johann Westphall <johannwestphall@gmail.com>

Signed-off-by: Johann Westphall <johannwestphall@gmail.com>

Signed-off-by: Johann Westphall <johannwestphall@gmail.com>

Signed-off-by: Johann Westphall <johannwestphall@gmail.com>

    - instead of changing cryptogen config, we
    give ed25519 keys by changing the certificate
    and the keys.
    - Now, the test is compatible with a network without
    a system channel.
    - Other improvements were made

Signed-off-by: Johann Westphall <johannwestphall@gmail.com>

Signed-off-by: Johann Westphall <johannwestphall@gmail.com>

Signed-off-by: Johann Westphall <johannwestphall@gmail.com>

Signed-off-by: Johann Westphall <johannwestphall@gmail.com>

Signed-off-by: Johann Westphall <johannwestphall@gmail.com>

Signed-off-by: Johann Westphall <johannwestphall@gmail.com>

Signed-off-by: Johann Westphall <johannwestphall@gmail.com>

Signed-off-by: Johann Westphall <johannwestphall@gmail.com>