| Commit message (Collapse) | Author | Files | Lines |
|---|
|
It's so non-obvious that even i had to do some research to find out.
Source: The file "doc/ssleay.doc" from SSLeay 0.8.1b,
see for example OpenSSL commit d02b48c6 on Dec 21, 1998.
|
|
Looks like I applied the diff to a dirty tree and didn't notice.
|
|
|
|
We match curve parameters against the builtin curves and only accept
them if they're encoding a curve known to us. After getting rid of the
wtls curves, some of which used to coincide with secp curves (sometimes
the wrong ones), the nid is unambiguous. Setting the nid has no direct
implications on the encoding.
This helps ssh avoid doing ugly computations during the key exchange
for PEM keys using this encoding.
ok djm joshua jsing
|
|
|
|
Rename it to DSA_prime_checks and add an XXX comment mentioning that
we could reduce the number of rounds thanks to BPSW. There are no
plans of changing that as DSA is on its way out.
discussed with miod
|
|
It aliases BN_is_prime(), which was removed in April 2023.
makes sense to miod
|
|
|
|
constants after these have been marked as intentionally undocumented;
they are internal to the library and unused in the wild
|
|
that are internal to the library and unused in the wild
|
|
that are only intended for internal use and unused in the wild
|
|
|
|
Makes the setting and getting of detached signatures more symmetric
and avoids a NULL access.
ok jsing
|
|
This matches the other members of X509 and is what's used everywhere else.
ok miod
|
|
|
|
As already done for SHA-256 and SHA-512, replace the perlasm generated
SHA-1 assembly implementation with one that is actually readable. Call the
assembly implementation from a C wrapper that can, in the future, dispatch
to alternate implementations. On a modern CPU the performance is around
5% faster than the base implementation generated by sha1-x86_64.pl, however
it is around 15% slower than the excessively complex SSSE2/AVX version that
is also generated by the same script (a SHA-NI version will greatly
outperform this and is much cleaner/simpler).
ok tb@
|
|
This should really have been using SECP 160R2, not SECP 160R1. Of course
this means in particular that nobody ever used this curve, at least not
against another implementation than OpenSSL. Quasi-monocultures are
poisonous whether the monopolist is benevolent and competent or not.
|
|
Upstream decided that this nonsense was worth an ABI break and added stuff
to the X509_CTX so they could hang the issuer's public key off it so that
they could adjust the key identifiers as needed. Let's avoid that and do
it the slightly less nasty way by updating the AKI and SKI as needed.
We only do this when force pubkey is in place so we don't change the
semantics of the batshit crazy config language that nobody understands.
ok job
|
|
from Kenjiro Nakayama
|
|
|
|
|
|
with job
|
|
Like most of the "group" methods these are shared between Montgomery
curves and simple curves. There's no point in five methods hanging off
the EC_METHODS struct whne they can just as well be inlined in the
public API. It makes all files involved shorter...
ok jsing
|
|
While there likely won't be enough BNs already available in the ctx, and
thus it won't greatly reduce the amount of allocated BNs, it simplifies
the exit path quite a bit.
review feedback from jsing
|
|
It is unclear how the original code was supposed to work. It clearly
missed a few corner cases (like handling points at infinity correctly)
and the badly mangled comment that was supposed to display a binary
search tree didn't help at all.
Instead do something much more straightforward: multiply all the non-zero
Z coordinates of the points not at infinity together, keeping track of the
intermediate products. Then do a single expensive modular inversion before
working backwards to compute all the inverses. Then the transformation from
Jacobian coordinates to affine coordiantes (x, y, z) -> (x/z^2, y/z^3, 1)
becomes cheap. A little bit of care has to be taken for Montgomery curves
but that's very simple compared to the mess that was there before.
ok jsing
This is a cleaned up version of:
commit 0fe73d6c3641cb175871463bdddbbea3ee0b62ae
Author: Bodo Moeller <bodo@openssl.org>
Date: Fri Aug 1 17:18:14 2014 +0200
Simplify and fix ec_GFp_simple_points_make_affine
(which didn't always handle value 0 correctly).
Reviewed-by: emilia@openssl.org
|
|
secp160r1 and nistp192 are no longer available in libcrypto. Should have
been committed along with disabling these curves, but was missed.
ok jsing
|
|
ok beck miod
|
|
In the unlikely event that we should ever decide to implement this after
a quarter century of not needing it, we can readily put this back. Until
then this is dead weight.
prompted by a question by djm
ok jsing
|
|
because that makes it easier to see the big picture
of how EVP_PKEY_new_raw_private_key(3) is supposed to be used.
Feedback and OK tb@.
|
|
that are only intended for internal use, do very little (only validity
checking), are unused in the wild, and marked obsolete in OpenSSL 3.
|
|
Fix related indentation while here.
|
|
the weird thing it was supposed to be doing couldn't possibly work.
ok jsing
|
|
$i386only never existed, it should be $x86only. Replace des asm file
example with an aes one since we're firmly in the third millenium.
ok sthen
|
|
There are only two flag values that libcrypto understands and the default
value is 1 while, helpfully, the undesirable non-default is 0. The few
existing callers set OPENSSL_EC_NAMED_CURVE or OPENSSL_EC_EXPLICIT_CURVE.
Nevertheless, the flag should be checked properly as a flag. The recent
upstream checks for EC_GROUP_get_asn1_flag(group) == OPENSSL_EC_NAMED_CURVE
don't look right either...
ok jsing
|
|
such that it becomes intelligible but not too long or prominent.
In particular, don't talk about EVP_PKEY_CTX_new(3), don't forget to
mention EVP_PKEY_keygen(3), mention EVP_PKEY_OP_KEYGEN, and mention
how to proceed once you have the desired EVP_PKEY object in hand.
Substantial feedback and OK tb@.
|
|
|
|
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.
|
|
|
