GitLab

Makes secp256k1 about 4x faster

Only affects curves with nbits != pbits (currently only secp224k1)

The issue would happen for curves whose bitlength is not a multiple of eight
(the only case is NIST P-521) with hashes that are longer than the bitlength
of the curve: since the wides hash is 512 bits long, this can't happen.
Fixing however as a matter of principle and readability.

rsa_rsassa_pss_verify()

Also document speed/memory trade-offs better.

Cuts peak usage by 25% :)

case

The actual input / output buffer overhead is only 301 instead of 512.
This requires a proper check on the padding_idx to prevent out of bounds
reads.

Previously a remote party could potentially trigger an access error and
thus stop the application when sending a malicious packet having
MAX_CONTENT_LEN of data, 32 bytes of MAC and a decrypted padlen of .
This would result in reading from in_ctr + 13 + 32 + MAX_CONTENT_LEN - 1 - 1
for 256 bytes (including fake padding check). Or 13 + 32 bytes over the
buffer length.

We now reset padding_idx to 0, if it's clear that it will never be a
valid padding (padlen > msg_len || msg_len + padlen + 256 > buffer_len)