The code-path via the `ed25519ph_*()` APIs would have allowed to get here
and de-reference `ctx` even if it is `NULL`.
Signed-off-by: Steffen Jaeckel <s@jaeckel.eu>
It's a compile-only test, but we run it anyways so we can finally get
`crypt_fsa()` included in the coverage report. It's not really useful but
also doesn't hurt.
Signed-off-by: Steffen Jaeckel <s@jaeckel.eu>
A user isn't guaranteed to use the `der_..._multi()` in a correct fashion.
Therefor change the pattern in the library and terminate further vararg
processing immediately after the `EOL` marker is hit.
The previous changes introducing the function-`attribute(sentinel)` would
allow detecting this, but not all compilers have support for the attribute.
Signed-off-by: Steffen Jaeckel <s@jaeckel.eu>
`NULL` as defined by the standard is not guaranteed to be of a pointer
type. In order to make sure that in vararg API's a pointer type is used,
define our own version and use that one internally.
Signed-off-by: Steffen Jaeckel <s@jaeckel.eu>
* The RFC doesn't limit the context to be a string.
It talks about `octets` which means it could be any binary data.
* Move the context-preprocessing function out of tweetnacl.c
* Fix potential segfaults when Ed25519 signature verification fails and
`LTC_CLEAN_STACK` is enabled.
* Fix all the warnings.
* Update documentation.
Signed-off-by: Steffen Jaeckel <s@jaeckel.eu>
In case when the signature is not verified the "mlen" variable
is equal to ULONG_MAX. When LTC_CLEAN_STACK has been defined
this results in a segmentation fault.
Signed-off-by: Valerii Chubar <valerii_chubar@epam.com>
Signed-off-by: Sergiy Kibrik <Sergiy_Kibrik@epam.com>
Previously it was not detected if `inlen` itself was too big and would
overflow the multiplication by 8.
Related to #592
Signed-off-by: Steffen Jaeckel <s@jaeckel.eu>
Sometimes it's hard to reproduce an issue as they happen on CI, so let's
pack-up what we can on failure and upload it as artifact.
Signed-off-by: Steffen Jaeckel <s@jaeckel.eu>
When compiling with clang (9-12) and then running the tests in
valgrind (I tested 3.13.0 and 3.15.0) the following error was created:
```
Conditional jump or move depends on uninitialised value(s)
at 0x47761F: ecc_ssh_ecdsa_encode_name (ecc_ssh_ecdsa_encode_name.c:38)
...
Uninitialised value was created by a stack allocation
at 0x477570: ecc_ssh_ecdsa_encode_name (ecc_ssh_ecdsa_encode_name.c:21)
```
This silences this error by initialising the stack-array on creation.
Signed-off-by: Steffen Jaeckel <s@jaeckel.eu>
* ensure base64 encode in&out buffers aren't the same
* allow calling any of the encode functions with `out` being a
NULL-pointer, to be able to determine the size for storing
the output.
Signed-off-by: Steffen Jaeckel <s@jaeckel.eu>
Function rsa_make_key() limits the RSA key generates to a public
exponent of type long (32 bits or 64 bits).
RSA standard specify that public exponent e can be between 65537 (included)
and 2^256 (excluded).
Add function rsa_make_key_ubin_e to use a hexadecimal public exponent.
Add function rsa_make_key_bn_e to use a bignumber public exponent
(op-tee).
Signed-off-by: Cedric Neveux <cedric.neveux@nxp.com>
The endianness fallback in tomcrypt_cfg.h lacked a check for the gcc
define for m68k. I discovered this while building dropbear on A/UX
3.1.1 on a Macintosh Quadra 700 (yes, in 2021). Adding the check for
the gcc __m68k__ define gets everything building.
Signed-off-by: David Cantrell <david.l.cantrell@gmail.com>
