| Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
Again, we know their sizes (always 2), so we can avoid allocating and
freeing them. Also remove the extra "pivot" element. It's not needed.
ok djm
|
|
pointed out by jsing
|
|
ok djm
|
|
This makes the mess a bit more readable.
ok jsing
|
|
All the EC_POINT_* API has a fast path for the point at infinity. So we're
not gaining more than a few cycles by making this terrible mess even more
terrible than it already is by avoding calls ot it (it's also incorrect as
it is since we don't know that the point is no longer at infinity when it
is unset). Simplify and add a comment explaining what this mess is doing.
ok jsing
|
|
|
|
|
|
Use better variable names (cf. https://jmilne.org/math/tips.html#4) and
avoid the weird style of assigning to r (what does r stand for anyway?)
and short circuiting subsequent tests using if (r || ...). Also, do not
reuse the variables for order and cofactor that were previously used for
the curve coefficients.
ok jsing
|
|
The only caller passes in num = 1 and is itself called in a path that
ensures that the multiplier of the generator is != NULL. Consequently
we don't need to deal with an array of points and an array of scalars
so rename them accordingly.
In addition, the change implies that numblocks and num_scalar are now
always 1, so inline this information and take a first step towards
disentangling this gordian knot.
ok jsing
|
|
This provides a SHA-256 assembly implementation for amd64, which uses
the Intel SHA Extensions (aka SHA New Instructions or SHA-NI). This
provides a 3-5x performance gain on some Intel CPUs and many AMD CPUs.
ok tb@
|
|
Now that we have replacement SHA-256 and SHA-512 assembly implementations
for amd64, sha512-x86_64.pl can go the way of the dodo.
|
|
Replace the perlasm generated SHA-512 assembly with a more readable
version and the same C wrapper introduced for SHA-256. As for SHA-256,
on a modern CPU the performance is largely the same.
ok tb@
|
|
This also provides a crypto_cpu_caps_amd64 variable that can be checked
for CRYPTO_CPU_CAPS_AMD64_SHA.
ok tb@
|
|
Missing sizes spotted by guenther@
|
|
|
|
|
|
|
|
(Many examples in this directory are really bad. This is no exception.)
|
|
|
|
As most other objects, EC_KEYs can be as sparsely and invalidly populated
as imagination permits and the competent designers of EC_KEY_copy() chose
to just copy over what's available (yeah, what kind of copy is that?) and
leave in place what happens to be there. In particular, if the dest EC key
was used with a different group and has a private key, but the source key
doesn't, the dest private key remains intact, as invalid, incompatible and
unusable as it may be. Fix this by clearing said private key.
ok jsing
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"A return statement with an expression shall not appear in a function
whose return type is void."
ok deraadt miod
|
|
A certificate must have a subject, so X509_get_subject_name() cannot
return NULL on a correctly parsed certificate, even if the subject is
empty (which is allowed). So if X509_get_subject_name() returns NULL,
error instead of silently ignoring it in tls_check_common_name().
This is currently no issue. Where it matters, the match against the
common name will fail later, so we fail closed anyway.
ok jsing
|
|
and purge the superseded information from the algorithm-independent
page EVP_PKEY_new(3).
|
