| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
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@.
|
|
|
|
|
|
|
|
spotted by jsing
|
|
|
|
|
|
These functions are no longer shared between multiple files, so they can
be static in ecp_methods.c and the long list of prototypes can go away.
|
|
|
|
|
|
While not the greatest of names, ecp_methods.c is better than ecp_smpl.c.
It matches the naming ecx_methods.c and in a subsequent commit it will
become the new home of the stuff in ecp_mont.c as well.
discussed with jsing
|
|
It is impossible to use EVP_DigestInit_ex(3) for CMAC.
Besides, EVP_PKEY_CTX_new_id(3) does not produce an EVP_MD_CTX object.
Instead, mention the easiest way to actually get the job done
using EVP_PKEY_new_CMAC_key(3) and EVP_DigestSignInit(3).
OK tb@
|
|
|
|
|
|
This is relevant because EVP_EncryptInit(3) takes a "key" argument,
and users need to consider the size of that argument.
While here, also mention whether ciphers are stream ciphers
or block ciphers and what the block size is.
|
|
function EVP_MD_CTX_init(3) and talk about EVP_MD_CTX_new(3) instead.
This is similar in spirit to OpenSSL commit 25191fff (Dec 1, 2015),
but i'm also mentioning EVP_MD_CTX_reset(3), slightly reordering some
sentences in a more systematic way, and improving some related wordings
to be more precise and read better.
|
|
This calls init() with the default method, so EC_KEY_copy() gets a chance
to call finish() if the source's method doesn't match. But no init() call
is made in EC_KEY_copy(). Of course the source method's copy() needs to be
able to cope. The great news is that ssh uses this. Sigh.
ok beck jsing
|
|
This is a special snowflake. Its logic is such that it only overwrites
things on the target that are available in the source. So if the source
has no group (yes, that's possible), the destination's group will remain.
Even better: if you copy a public key over what was previously a private
key, the private scalar will remain. That's almost never going to result
in a valid key. If you copy from a larger group to a smaller group the
private scalar will most likely be out of range [1, order).
Use dup functions instead of reimplementing badly and add a snarky comment
courtesy of beck to one of those silly const annotations (there's a small
addendum by me).
ok beck jsing
|
|
r is a silly name for an EC_KEY and it is silly to assign the refcount
to a variable i (short for uninspired) when you can check the function
return directly. Tweak sizeof in freezero to jsing's liking.
ok beck jsing
|
|
Use a better variable name, simpler error handling. This could be
simplified further if we decide to have an ec_key_set0_group() that
avoids a copy.
ok beck jsing
|
|
mentioned in NAME and described in DESCRIPTION and RETURN VALUES.
|
|
Replace the perlasm generated SHA-256 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. Performance
is similar (or even better) on modern CPUs, while somewhat slower on older
CPUs (this is in part due to the wrapper, the impact of which is more
noticable with small block sizes).
Thanks to gkoehler@ and tb@ for testing.
ok tb@
|
|
Rewrite bn2binpad, removing some OpenSSL specific behaviour and unnecessary
complexity. Our BN_num_bytes() does not return bogus lengths, so we don't
need to see if things work out with nominated outputs. Swipe away some
endianness_t, but continue to ignore negatives and don't dare give away
padded zeroes.
Implement a more readable constant time conversion. In particular, the
little endian is the less common use case, which we can implement by
reversing the padded output in place, rather than complicating all of the
conversion code.
ok beck@ tb@
|
|
These will be used in an upcoming change.
ok beck@ tb@
|
