If we allow the length to be 0, we should also prepare for the case where
the user doesn't want to provide a valid input-data pointer.
Signed-off-by: Steffen Jaeckel <s@jaeckel.eu>
In case of EME-PKCS1-v1_5 decoding, the encoded message
format is as follow : EM = 0x00 || 0x02 || PS || 0x00 || M.
When using an empty message, the 0x00 octet that separates
the padding string and message is located at the end. Thus,
update the condition to pass the check in case of empty message.
This fixes the following AOSP cts test:
Module: CtsKeystoreTestCases
Test: testEmptyPlaintextEncryptsAndDecrypts
Link: https://android.googlesource.com/platform/cts/+/refs/tags/android-cts-12.0_r6/tests/tests/keystore/src/android/keystore/cts/CipherTest.java
Signed-off-by: Safae Ouajih <souajih@baylibre.com>
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>
