| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| |
|
|
|
| |
missed in 2022 "remove please from manual pages" commit
ok tb@
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While EC_POINT_set_affine_coordinates() checks that the resulting point
is on the elliptic curve, this is only necessary, but not sufficient, to
ensure that the point can serve as a valid public key. For example, this
does not check for normalized coordinates or exclude that it is zero (the
point at infinity). Such checks, and more, are performed by the similarly
named EC_KEY_set_public_key_affine_coordinates().
This kind of makes sense from the mathematical standpoint as an elliptic
curve point isn't a priori a public key, even if you are not going to use
libcrypto for actual mathematics (or anything really) unless you like pain.
In a cryptographic library such differences are more of a hazard than a
help.
This is exacerbated by the fact that EC_KEY_set_public_key() does almost
no checking (it only checks that the point's EC_POINT method matches the
one of group set of the EC_KEY, which is far from enough). The API expects
that you call EC_KEY_check_key() on your own. This is kind of confusing
since EC_KEY_set_public_key_affine_coordinates() does that for you.
Unfortunately, adding sanity checks to EC_KEY_set_public_key() isn't easy
since it's going to penalize those who already check. Caching the result
of a check is dangerous and fragile if there are a million ways of fiddling
with an EC_KEY.
While the elliptic curve code is really bad, its documentation is worse
(another thing that applies to OpenSSL in general). Try to help that a
little bit by making it more explicit that you are supposed to call
EC_KEY_check_key() after using lower-level EC_KEY setters. Also make it
clearer that the setters copy the data, they don't take ownership (which
isn't obvious from the naming).
If OpenSSL 3 got one thing kind of right, it was to deprecate the EC_KEY
and EC_POINT APIs. But if you are going to deprecate something, you should
either be prepared to remove it or have a reasonable replacement...
Found by Guido Vranken using cryptofuzz
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=66667
ok jsing
|
| |
|
|
|
|
| |
Except if backward compatibility with older LibreSSL and OpenSSL versions
is explicitly needed, ecdsa.h and ecdh.h should no longer be used. They
are now trivial wrappers of ec.h.
|
| | |
|
| |
|
|
| |
wording from jmc
|
| |
|
|
| |
feedback and OK tb@
|
| |
|
|
| |
and mention a trap set by EC_KEY_copy(3)
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
EVP_PKEY_get0_{DH,DSA,RSA}(3), and RSA_{g,s}et0_key(3)
that tb@ just provided.
|
| |
|
|
|
|
| |
Make sure EC_GROUP_new(3) points to all EC manuals and all EC manuals
point back to EC_GROUP_new(3), and add some other useful links as well.
Change all links to ec(3) to point to EC_GROUP_new(3) instead.
|
| |
|
|
| |
to be pointed to from random individual pages.
|
| |
|
|
|
|
|
| |
Mention that EC_KEY_free(3) accepts NULL.
Merge some auxiliary explanations regarding the effects of EC_KEY
encoding flags, lifted from the separate page EC_KEY_get_enc_flags(3)
that OpenSSL split off from EC_KEY_new(3).
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
