ecc_valid_public_key() function not in master about micro-ecc HOT 5 CLOSED

It's not really necessary anymore because the functions that accept public keys work with any possible input (and the choice of public key does not leak timing information).

I can add it into master if you need it.

from micro-ecc.

It's good to know that uECC has addressed potential side channel timing attacks from an attacker with a carefully malformed public key.

Verifying the public key with an extremely low overhead function like ecc_valid_public_key() helps avoid attacks where an attacker can cause a remote system to expend significant processing cycles in an ECDH key exchange by sending garbage data without having to expend any effort generating keys on the correct curve. (This is still a problem when using compressed keys, as the decompress function requires a lot of processing power and will always be followed by another ECC operation that is also cpu intensive. And the single axis will be expanded to valid point that always validates, so no help in that regard, except to use full size keys.)

It's also useful to validate the signature and underlying public key in a signed key cert prior to checking the cert signature to minimise processing when the public key is invalid and not on the curve (due to either general errors, malformed certs or an intentional simplistic attack).

And of course it helps in debugging with a more specific error.

I've ported it across from the 'old' branch, but it would still be useful to have it in 'master'.

from micro-ecc.

I added uECC_valid_public_key() to master. Note that just checking for a valid public key is not a full defense against denial-of-service attacks, since an attacker could generate a single valid public key and use it repeatedly.

from micro-ecc.

Thanks. Works perfectly.

This is great for running regression tests and for sanity checking during debugging. And you're right, it doesn't help in targeted denial of service attacks, but is handy in the generic sense where a broken transmitter (or an attacker) is just sending lots of random data. We already detect single element replay to detect problems with broken repeaters. But a targeted attack will still be able to cause an ECDHE + ECDSA procedure before the attacker is rejected.

BTW, do you have a contact email address or website? If so please email me directly.

from micro-ecc.

I don't have your contact info to email you directly :-)

You can contact me at [email protected].

from micro-ecc.