| Age | Commit message (Collapse) | Author |
|---|
|
This disables all the curves over fields < 224 bits and a few others.
Specifically:
SECG: 112r1 112r2 128r1 128r2 160k1 160r1 160r2 192k1 192r1 192v{1,2,3}
WTLS: 6 7 8 9 12
Brainpool: P160r1 P160t1 P192r1 P192t1
These are below or at the limit of what is acceptable nowadays. This is
less aggressive than what some enterprise linux distributions are using
in their patched OpenSSL versions where everything over fields < 256 bits
is disabled with the exception of P-224, so interoperability should not
be a problem.
The curves are left in the tree for now and can be re-enabled by compiling
libcrypto with -DENABLE_SMALL_CURVES. They will be fully removed later.
One nice benefit of doing this is that the incorrect parameters for WTLS 7
are fixed (obviously nobody uses this one) and now all the builtin curves
have a unique corresponding OID (nid).
Something like this was suggested a while back by beck, makes sense to sthen
ok jsing
|
|
Rather than having blocks of code that are conditional on
BYTE_ORDER != LITTLE_ENDIAN, use le64toh() and htole64() unconditionally.
In the case of a little endian platform, the compiler will optimise this
away, while on a big endian platform we'll either end up with better code
or the same code than we have currently.
ok tb@
|
|
The big change is that the "rows" are no longer slices of val[] but
that they actually own the points they contain. The price for this
is an extra allocation for val[] and to piece it together from the
two rows. That's ugly, but less ugly than before.
Add a helper for freeing a row of points. It can deal with a NULL
row so, we can remove a couple of complications.
The second change is that the logic for preparing the rows is pulled
back into ec_wNAF_mul[]. This way the m * G + n * P logic is in the
one function that needs to know about it, the rest just deals with
a pair of a point and a scalar.
This starts resembling actual code...
ok jsing
|
|
This is a corner case that isn't really of interest. We're making a few
calculations that don't really hurt, but it's super cheap, so one more
complication bites the dust.
ok jsing
|
|
We can now turn the for loop into a proper for loop for which there is
obviously no out of bounds access. The length can be determined up front
and it's easier to explain what's going on, so expand a few comments.
ok jsing
|
|
This is another micro optimization that introduces needless complications
for the sake of saving a few cycles. Specifically, by ditching the rule
defining the wNAF representation (at most one of w+1 consecutive digits
is non-zero) for the topmost digits, one can sometimes save a few digits
at the cost of crazy loop conditions and other weirdness. That's not worth
it.
ok jsing
|
|
|
|
ok jsing
|
|
It's still horrible, but slightly less so...
ok jsing
|
|
This streamlines this mess and adapts the API better to its only caller.
Nothing much going on here, except that we drop confusing checks and
unhelpful comment, thereby making the algorithm more cleanly visible.
ok jsing
|
|
This matches the ec_wNAF_mul() API better
ok jsing
|
|
As its name indicates, the first, ec_compute_odd_multiples(), fills
point, 3 * point, 5 * point, ..., (2 * len - 1) * point into row[].
In fact, it first computes doubled = 2 * point and then goes on to
set row[i] = row[i - 1] + doubled. That's straightforward enough. One
change here is that this helper allocates row[i] on the fly rather
than preallocating the entire array of points up front.
The second piece is the actual precomputation, ec_wNAF_precompute().
It first computes the wNAF digits of the two scalars n and m (in this
order for now) with appropriate window size and length. Then the above
mentioned val[] array is allocated and populated with odd multiples
of point and generator. Finally, all points in val[] are made affine
in a single step, which means we only need one modular inversion, and
this then allows us to take fast paths in all the computations in the
one remaining loop in ec_wNAF_mul().
ok jsing
|
|
This used to be the case until they were given a 'more meaningful name'
about 20 years ago. We cant fix the public API, but I'm tired of being
confused by this nonsense.
|
|
|
|
|
|
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
|
|
and purge the superseded information from the algorithm-independent
page EVP_PKEY_new(3).
|
|
stand a chance of using the API correctly.
Admittedly, having so much text below EXAMPLES is somewhat unusual.
While all that information is required to use the function correctly,
strictly speaking, it is not part of the specification of what
EVP_PKEY_new_CMAC_key(3) does, so it woundn't really belong
in the DESCRIPTION.
Now, designing an API function in such a way that using it correctly
requires lots of information about *other* functions and such that
all that additional information does not belong into the manual pages
of those other functions (both because that would cause distractions
in various other manual pages and because it would scatter required
information around lots of different pages) is certainly not stellar
API design. But we can't help that because these APIs were all
originally designed by OpenSSL.
Significant feedback and OK tb@.
|
|
|
|
|
|
|
