After re-reading through the first post:
Please check that the correct private key is being loaded for the client, matching the certificate loaded.

For building tests:
For building the examples it may be best to either use user_setttings.h or compile them separately. A user_settings.h file is one created by the user to hold settings such as the macros WOLFSSL_USER_IO and NO_WRITEV. What I suspect is happening here is that the -D macros set during "make" are not getting pulled into the examples when they are compiled with autotools/libtools. You can create a static wolfSSL library with adding "--enable-static" to the configure line. This gets placed into the directory wolfssl-root/src/.libs/ which could then be linked to when building wolfcrypt/test/test.c.

Regards,
Jacob

I'm sorry to insist, if I remove "--disable-crypttests" I get these errors even with the macros NO_FILESYSTEM  and USE_CERT_BUFFERS_2048:

/opt/Xilinx/SDK/2014.4/gnu/arm/lin/bin/../lib/gcc/arm-xilinx-eabi/4.8.3/../../../../arm-xilinx-eabi/lib/libc.a(lib_a-sbrkr.o): In function `_sbrk_r':
sbrkr.c:(.text+0x1c): undefined reference to `_sbrk'
/opt/Xilinx/SDK/2014.4/gnu/arm/lin/bin/../lib/gcc/arm-xilinx-eabi/4.8.3/../../../../arm-xilinx-eabi/lib/libc.a(lib_a-writer.o): In function `_write_r':
writer.c:(.text+0x24): undefined reference to `_write'
/opt/Xilinx/SDK/2014.4/gnu/arm/lin/bin/../lib/gcc/arm-xilinx-eabi/4.8.3/../../../../arm-xilinx-eabi/lib/libc.a(lib_a-closer.o): In function `_close_r':
closer.c:(.text+0x1c): undefined reference to `_close'
/opt/Xilinx/SDK/2014.4/gnu/arm/lin/bin/../lib/gcc/arm-xilinx-eabi/4.8.3/../../../../arm-xilinx-eabi/lib/libc.a(lib_a-fstatr.o): In function `_fstat_r':
fstatr.c:(.text+0x20): undefined reference to `_fstat'
/opt/Xilinx/SDK/2014.4/gnu/arm/lin/bin/../lib/gcc/arm-xilinx-eabi/4.8.3/../../../../arm-xilinx-eabi/lib/libc.a(lib_a-isattyr.o): In function `_isatty_r':
isattyr.c:(.text+0x1c): undefined reference to `_isatty'
/opt/Xilinx/SDK/2014.4/gnu/arm/lin/bin/../lib/gcc/arm-xilinx-eabi/4.8.3/../../../../arm-xilinx-eabi/lib/libc.a(lib_a-lseekr.o): In function `_lseek_r':
lseekr.c:(.text+0x24): undefined reference to `_lseek'
/opt/Xilinx/SDK/2014.4/gnu/arm/lin/bin/../lib/gcc/arm-xilinx-eabi/4.8.3/../../../../arm-xilinx-eabi/lib/libc.a(lib_a-readr.o): In function `_read_r':
readr.c:(.text+0x24): undefined reference to `_read'
collect2: error: ld returned 1 exit status
make[1]: *** [wolfcrypt/test/testwolfcrypt] Error 1

I'm using the following commands:

./configure --host=arm-xilinx-eabi --enable-debug --enable-static --disable-shared --enable-singlethreaded --disable-examples --disable-filesystem  --enable-ecc --enable-curve25519=small --enable-tls13 --enable-fastmath "CC=/opt/Xilinx/SDK/2014.4/gnu/arm/lin/bin/arm-xilinx-eabi-gcc"

make CFLAGS="-DNO_FILESYSTEM=1 -DWOLFSSL_USER_IO=1 -DNO_WRITEV=1 -DNO_MAIN_DRIVER=1 -DNO_DEV_RANDOM=1 -DTIME_OVERRIDES=1  -DHAVE_ECC=1 -DHAVE_CHACHA -DHAVE_POLY1305 -DHAVE_CURVE25519 -DWOLFSSL_LOG_PRINTF=1 -DDEBUG_WOLFSSL=1 -DSINGLE_THREADED=1 -DWOLFSSL_USER_IO -DFP_MAX_BITS=8192 -DUSE_CERT_BUFFERS_2048" TARGET_CFLAGS_ARCH='-mfloat-abi=softfp'  CC="/opt/Xilinx/SDK/2014.4/gnu/arm/lin/bin/arm-xilinx-eabi-gcc"

It looks that the library is still having dependences related to file system despite of the macros.

Thanks for your time,

Ramón.

Any difference in build options has the potential to cause issues.

Regards,
Jacob

I have options.h included in first place.

I have the following options.h:

/* wolfssl options.h
 * generated from configure options
 *
 * Copyright (C) 2006-2015 wolfSSL Inc.
 *
 * This file is part of wolfSSL. (formerly known as CyaSSL)
 *
 */

#ifndef WOLFSSL_OPTIONS_H
#define WOLFSSL_OPTIONS_H


#ifdef __cplusplus
extern "C" {
#endif

#undef  HAVE_FFDHE_2048
#define HAVE_FFDHE_2048

#undef  WOLFSSL_TLS13
#define WOLFSSL_TLS13

#undef  HAVE_TLS_EXTENSIONS
#define HAVE_TLS_EXTENSIONS

#undef  HAVE_SUPPORTED_CURVES
#define HAVE_SUPPORTED_CURVES

#undef  SINGLE_THREADED
#define SINGLE_THREADED

#undef  HAVE_THREAD_LS
#define HAVE_THREAD_LS

#undef  TFM_TIMING_RESISTANT
#define TFM_TIMING_RESISTANT

#undef  ECC_TIMING_RESISTANT
#define ECC_TIMING_RESISTANT

#undef  WC_RSA_BLINDING
#define WC_RSA_BLINDING

#undef  HAVE_AESGCM
#define HAVE_AESGCM

#undef  HAVE_HKDF
#define HAVE_HKDF

#undef  NO_DSA
#define NO_DSA

#undef  HAVE_ECC
#define HAVE_ECC

#undef  TFM_ECC256
#define TFM_ECC256

#undef  CURVE25519_SMALL
#define CURVE25519_SMALL

#undef  HAVE_CURVE25519
#define HAVE_CURVE25519

#undef  WC_RSA_PSS
#define WC_RSA_PSS

#undef  NO_RC4
#define NO_RC4

#undef  NO_HC128
#define NO_HC128

#undef  NO_RABBIT
#define NO_RABBIT

#undef  HAVE_POLY1305
#define HAVE_POLY1305

#undef  HAVE_ONE_TIME_AUTH
#define HAVE_ONE_TIME_AUTH

#undef  HAVE_CHACHA
#define HAVE_CHACHA

#undef  HAVE_HASHDRBG
#define HAVE_HASHDRBG

#undef  NO_FILESYSTEM
#define NO_FILESYSTEM

#undef  HAVE_EXTENDED_MASTER
#define HAVE_EXTENDED_MASTER

#undef  NO_PSK
#define NO_PSK

#undef  NO_MD4
#define NO_MD4

#undef  NO_PWDBASED
#define NO_PWDBASED

#undef  USE_FAST_MATH
#define USE_FAST_MATH

#undef  WC_NO_ASYNC_THREADING
#define WC_NO_ASYNC_THREADING

#undef  NO_DES3
#define NO_DES3


#ifdef __cplusplus
}
#endif


#endif /* WOLFSSL_OPTIONS_H */

However in order to compile succesfully I need to add -DNO_WRITEV=1 to de compile options, and also when compiling the application. Could this be the problem?

I'll try to run the tests I'm thinking about copying only the RSA test and removing the parts that depend on the file system or trying to compile the full test with Xilinx Memory File System.

The next thing to check would be that the application running the RSA operations is being compiled with the exact same settings as wolfSSL. When using autotools (./configure) a file called wolfssl/options.h is created after the library is compiled. This file should be included first before any other wolfSSL header files. i.e.

#include <wolfssl/options.h>
#include <wolfssl/wolfcrypt/rsa.h>
...

If having the exact same options (macros) set with the application as when compiling the library does not resolve the issue, then we would need to run the tests from wolfcrypt/test/test.c to verify that the default unit tests for RSA pass on the system. It is a good idea to run these tests in any case.

Regards,
Jacob

I've been trying to figure out what is going wrong, and definitely something inside wc_RsaFunctionSync() doesn't work. In the end the RSA integer operations don't end with an appropriate result.

Regards,
RGnzlzRz

I wrote this as a quick way to get a random source:

int wc_GenerateSeed(OS_Seed* os, byte* output, word32 sz)
    {
    int i=0;
    
    srand(0);
    for(i=0;i<sz;i++){
    output[i]=rand()%0xFF;
    }
        return 0;
    }

I've disabled -DWOLFSSL_STATIC_MEMORY=1 and -DBUILD_TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256=1 and it seems to make no difference.

RGnzlzRz

Thank you for sending across the build options. There is a couple of things that stand out to me with them.

1) Please remove -DBUILD_TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256=1 . This macro should only be set by internal code if it finds that the required algorithms RSA, CHACHA, POLY1305, and ECC are available at build time.

2) The macro -DWOLFSSL_STATIC_MEMORY=1 will be setting the static memory feature which can make the use case more complicated. To begin with and to make sure the default build works please remove this to test.

3) With having -DNO_DEV_RANDOM=1  it could be an issue with random number generation. Please add a source of entropy to the project. A good place for information about it would be to view the documentation on porting wolfSSL here https://www.wolfssl.com/docs/porting-guide/

Regards,
Jacob

It seems that the function that is giving different results with the same input is mp_to_unsigned_bin() in rsa.c line 1317. The result of this operation is later processed by RsaUnPad().

In PC the result starts this way:0x0,0x1,0xff,0xff... which seems to have the correct format.
In the embedded platform, however is: 0x0c,0xaf,0xaf,0xd9... which sets inmediatly the invalid flag to 1 because it dones't start with 0x0 and moreover doesn't lead to a correct size because it is not padded with 0xff.

It seems to be a difference in the variable tmp, but I can't figure out what makes this happen.

I'll try to run the test in the device to see the results, I think I disabled  them because I was getting compilation errors, due to not having file system, I think. If I enable the tests I get:

/opt/Xilinx/SDK/2014.4/gnu/arm/lin/bin/../lib/gcc/arm-xilinx-eabi/4.8.3/../../../../arm-xilinx-eabi/lib/libc.a(lib_a-sbrkr.o): In function `_sbrk_r':
sbrkr.c:(.text+0x1c): undefined reference to `_sbrk'
/opt/Xilinx/SDK/2014.4/gnu/arm/lin/bin/../lib/gcc/arm-xilinx-eabi/4.8.3/../../../../arm-xilinx-eabi/lib/libc.a(lib_a-writer.o): In function `_write_r':
writer.c:(.text+0x24): undefined reference to `_write'
/opt/Xilinx/SDK/2014.4/gnu/arm/lin/bin/../lib/gcc/arm-xilinx-eabi/4.8.3/../../../../arm-xilinx-eabi/lib/libc.a(lib_a-closer.o): In function `_close_r':
closer.c:(.text+0x1c): undefined reference to `_close'
/opt/Xilinx/SDK/2014.4/gnu/arm/lin/bin/../lib/gcc/arm-xilinx-eabi/4.8.3/../../../../arm-xilinx-eabi/lib/libc.a(lib_a-fstatr.o): In function `_fstat_r':
fstatr.c:(.text+0x20): undefined reference to `_fstat'
/opt/Xilinx/SDK/2014.4/gnu/arm/lin/bin/../lib/gcc/arm-xilinx-eabi/4.8.3/../../../../arm-xilinx-eabi/lib/libc.a(lib_a-isattyr.o): In function `_isatty_r':
isattyr.c:(.text+0x1c): undefined reference to `_isatty'
/opt/Xilinx/SDK/2014.4/gnu/arm/lin/bin/../lib/gcc/arm-xilinx-eabi/4.8.3/../../../../arm-xilinx-eabi/lib/libc.a(lib_a-lseekr.o): In function `_lseek_r':
lseekr.c:(.text+0x24): undefined reference to `_lseek'
/opt/Xilinx/SDK/2014.4/gnu/arm/lin/bin/../lib/gcc/arm-xilinx-eabi/4.8.3/../../../../arm-xilinx-eabi/lib/libc.a(lib_a-readr.o): In function `_read_r':
readr.c:(.text+0x24): undefined reference to `_read'
collect2: error: ld returned 1 exit status
make[1]: *** [wolfcrypt/test/testwolfcrypt] Error 1

I'm compiling using these options:

./configure --host=arm-xilinx-eabi --enable-debug --enable-static --disable-shared --enable-singlethreaded --disable-examples --disable-filesystem --disable-crypttests --enable-ecc --enable-curve25519=small --enable-tls13 --enable-fastmath "CC=/opt/Xilinx/SDK/2014.4/gnu/arm/lin/bin/arm-xilinx-eabi-gcc"
 
make CFLAGS="-DNO_FILESYSTEM=1 -DWOLFSSL_USER_IO=1 -DNO_WRITEV=1 -DNO_MAIN_DRIVER=1 -DNO_DEV_RANDOM=1 -DTIME_OVERRIDES=1 -DBUILD_TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256=1 -DHAVE_ECC=1 -DHAVE_CHACHA -DHAVE_POLY1305 -DHAVE_CURVE25519 -DWOLFSSL_LOG_PRINTF=1 -DDEBUG_WOLFSSL=1 -DSINGLE_THREADED=1 -DWOLFSSL_USER_IO -DFP_MAX_BITS=8192" TARGET_CFLAGS_ARCH='-mfloat-abi=softfp'  CC="/opt/Xilinx/SDK/2014.4/gnu/arm/lin/bin/arm-xilinx-eabi-gcc"

make install CFLAGS="-DNO_FILESYSTEM=1 -DWOLFSSL_USER_IO=1 -DWOLFSSL_LOG_PRINTF=1 -DDEBUG_WOLFSSL=1 -DNO_WRITEV=1 -DNO_MAIN_DRIVER=1 -DWOLFSSL_STATIC_MEMORY=1 -DNO_DEV_RANDOM=1 -DTIME_OVERRIDES=1 -DBUILD_TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256=1 -DHAVE_ECC=1 -DHAVE_CHACHA -DHAVE_POLY1305 -DHAVE_CURVE25519 -DWOLFSSL_LOG_PRINTF=1 -DDEBUG_WOLFSSL=1 -DSINGLE_THREADED=1 -DWOLFSSL_USER_IO -DFP_MAX_BITS=8192" TARGET_CFLAGS_ARCH='-mfloat-abi=softfp'  CC="/opt/Xilinx/SDK/2014.4/gnu/arm/lin/bin/arm-xilinx-eabi-gcc"

I already noticed an issue with the stack while debugging errors in RSA and increased it from 8 KB to 128 KB. Further increasing it doesn't seem to solve this problem, I already tried with 0xF0000, which should be 983040 bytes.
The key is 2048 bit.

Thank you,

RGnzlzRz

Many times in embedded, and on resource constrained devices, issues with RSA operations are due to the amount of stack available. A good test for eliminating if memory availability is an issue, is to run the wolfCrypt tests. This test app is located in wolfssl-root/wolfcrypt/test/ directory.

Can you tell us some about the projects use case and the size of the RSA key in the certificate.

Regards,
Jacob

I'm having problems verifying client RSA certificates in a bare metal server on an embedded platform. I have a PC client that verifies properly the certificate, to discard possible errors we have set the client to use the same certificate as the server, and we have verified in Wireshark that sent certificates are the same in both ends, so certificate should not be the issue.

Doing some debugging I've observed that the error is generated in RsaUnPad(), in the first block.

if (pkcsBlock[0] != 0x0) { /* skip past zero */
        invalid = 1;
    }
This statement already sets invalid to 1.

   if (padValue == RSA_BLOCK_TYPE_1) {
        while (i<pkcsBlockLen && pkcsBlock[i++] == 0xFF) {/* Null body */}
    }
    else {
        while (i<pkcsBlockLen && pkcsBlock[i++]) {/* Null body */}
    }

    if (!(i==pkcsBlockLen || pkcsBlock[i-1]==0)) {
        WOLFSSL_MSG("RsaUnPad error, bad formatting");
        return RSA_PAD_E;
    }

With this I get i=2, while debugging in PC I obtained "i" around 500 (near the block size) if I recall correctly. Therefore I think that the block passed to the function is corrupted.

I've tried to trace where the error is but I'm getting lost among the calls and parameter changes.

In ProcessPeerCerts() the actual correct certificate is in the variable "input" so initially the correct certificate is read, somewhere in the middle it must be corrupted.

I'm using wolfssl 3.13.0.
log:

received record layer msg
wolfSSL Entering DoHandShakeMsg()
wolfSSL Entering DoHandShakeMsgType
processing certificate
wolfSSL Entering ProcessPeerCerts
Loading peer's cert chain
        Put another cert into chain
Verifying Peer's cert
wolfSSL Entering GetExplicitVersion
wolfSSL Entering GetSerialNumber
Got Cert Header
wolfSSL Entering GetAlgoId
wolfSSL Entering GetObjectId()
Got Algo ID
Getting Cert Name
Getting Cert Name
Got Subject Name
wolfSSL Entering GetAlgoId
wolfSSL Entering GetObjectId()
Got Key
Parsed Past Key
wolfSSL Entering DecodeCertExtensions
wolfSSL Entering GetObjectId()
wolfSSL Entering DecodeAuthInfo
wolfSSL Entering GetObjectId()
wolfSSL Entering GetObjectId()
wolfSSL Entering GetObjectId()
wolfSSL Entering DecodeAuthKeyId
wolfSSL Entering GetObjectId()
wolfSSL Entering DecodeBasicCaConstraint
wolfSSL Entering GetObjectId()
wolfSSL Entering DecodeCrlDist
wolfSSL Entering GetObjectId()
wolfSSL Entering DecodeExtKeyUsage
wolfSSL Entering GetObjectId()
wolfSSL Entering GetObjectId()
wolfSSL Entering GetObjectId()
wolfSSL Entering DecodeKeyUsage
wolfSSL Entering GetObjectId()
wolfSSL Entering DecodeSubjKeyId
wolfSSL Entering GetObjectId()
wolfSSL Entering DecodeAltNames
        Unsupported name type, skipping
wolfSSL Entering GetAlgoId
wolfSSL Entering GetObjectId()
About to verify certificate signature
wolfSSL Entering ConfirmSignature
RsaUnPad error, bad formatting
wolfSSL Leaving ConfirmSignature, return -155
Confirm signature failed
Failed to verify Peer's cert
        No callback override available, fatal
wolfSSL Leaving ProcessPeerCerts, return -155
wolfSSL Leaving DoHandShakeMsgType(), return -155
wolfSSL Leaving DoHandShakeMsg(), return -155
wolfSSL error occurred, error = -155

I'd appreciate some help, maybe this data is helpful to fix my problem. Tell me if more there is more useful information that I can add.