The Ed25519 signature algorithm is becoming more widely used as there are concerns about the specific curves selected by NIST. In addition, instead of standard ECDSA, this curve is commonly used with EdDSA, resulting in Ed25519.
There are some distinct advantages to this signature algorithm, such as deterministic signatures, high performance, and resilience against weaknesses in the underlying hash function. Unfortunately, in the constrained environment of mcuboot, these are not likely to be advantages, although there still will be benefit to making this algorithm available.
I have done some basic benchmarking of two implementations. The reference implementation takes 21ms to verify a signature (on FRDM K64F). However, the code is over 100KB, which is too large to be practical for the bootloader. The tweetnacl implementation is only a few KB, but it takes about 760ms to verify the same signature.
As a consequence, this algorithm is only likely to be useful in situations where a slow verification is acceptable. In this case, we can get rid of the dependencies on both mbed TLS and tinycrypt.
In order to implement Ed25519, we need to do:
Implement (or find) a storage format for the private/public keyfile. There are extensions defined for PKCS#8 to do this, but the only implementation I can find is in Rust. This would need to be implemented in both Python and Go, for imgtool and the newt tool.
Define how the public key will be stored. This can be incorporated in other changes that will improve the format of the header/TLV.
Define how the signature will be stored. The Ed25519 code expects the signature to be prepended to the data (in this case the hash), but since the hash can be computed, this can be done in a buffer as part of verification.
Note that we need to use the Prehash variant of Ed25519. Neither the reference implementation nor tweetnacl support detached signatures, and the current code would require a RAM buffer 64+flash-image-size to be able to compute a direct signature. Libsodium implements detached signatures, but it is based largely on the >100KB reference code. It would be possible to modify tweetnacl to support detached signatures, but there is considerable risk to doing this.
Using pre-hashing bypasses the efforts taken by the Ed25519 to protect against weaknesses in the underlying hash function. This effectively lowers the security of the signature to be comparable to the other signing algorithms in use.