Hello Ramon,

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

Hi RGnzlzRz,

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

Hi 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

Hi Colin,

For setting up the RSA key a call to wc_InitRsaKey(RsaKey* rsa, void* heap) should be made before the call to wc_RsaPublicKeyDecodeRaw. This will initialize the RSA structure values to there default for future use. My guess on the reason this worked in an earlier version and not in the more recent version is because of added elements in the RSA structure for additional features that have been added since the earlier wolfSSL version 3.9.6. Let us know if adding the wc_InitRsaKey function call does not resolve the issue.

Kind Regards,
Jacob

Hi Michela,

Thank you for the information. It would be good to have the public key generation for testing purposes. Generation of public keys from private curve25519 keys has been added to the desired feature list.

The output for key generation of Ed25519 is in little endian. In the case of curve25519 there was some drafts out at the time of implementation that were using a big endian format. To have the curve25519 implementation interop with some of the early TLS curve25519 drafts the use of exporting/importing big endian keys was enabled.

Regards,
Jacob

Hello colin.foster,

Recently there was an addition to expose mp_init and mp_read_unsigned_bin by using the macro WOLFSSL_PUBLIC_MP (it is in the most recent release v3.12.0). An example of compiling wolfSSL with that feature is "./configure C_EXTRA_FLAGS=-DWOLFSSL_PUBLIC_MP".

Can you tell us some about the project and the reason for not using the functions wc_RsaKeyToDer and wc_RsaPrivateKeyDecode for working with loading and exporting an RSA key?

Regards,
Jacob

Hi Ivanchez,

There is not yet a wrapping of the function wolfSSL_set_using_nonblock in the C# wrapper. It would be similar to how the function wolfSSL_get_error is wrapped in wolfSSL.cs but would the function would need to be added in. With the C# wrapper the examples are currently set up to use blocking sockets (https://github.com/wolfSSL/wolfssl/blob … SL.cs#L454) so the IO callbacks would also need to be set up for the project. An example of setting the IO callback can be found here https://github.com/wolfSSL/wolfssl/tree … Callbacks.

What are the time frames with building the game for when it would be needed?

Regards,
Jacob

Hi eques,

Thank you for sending the code to review and get a good idea of what is happening. After glancing over it I see that a certificate and private key is not being loaded? Adding a function calls for loading a certificate and private key should resolve the issue.

```
wolfSSL_CTX_use_certificate_buffer or wolfSSL_CTX_use_certificate_file
wolfSSL_CTX_use_PrivateKey_buffer or wolfSSL_CTX_use_PrivateKey_file
```

Regards,
Jacob

Hi gruppelli,

That sounds like an interesting thesis! Thanks for considering using wolfSSL when building it. What issues or errors are being reported when including DES files? des3.c and aes.c are able to be compiled on their own so this may be memory size or macros needed, but a list of the errors thrown will help with narrowing it down.

Regards,
Jacob

That's great! Glad to help.

Thanks for asking the question. This will be a good resource for others that may encounter the same thing.

Regards,
Jacob

Hey duckula,

That's great!! I have been thinking some about the generate seed function in this case. Finding a good source of entropy is in many ways the building block for network security. I can't think of one to suggest off the top of my head but do suggest that it is one that has had a lot of third party analysis done on it.

There is a couple spots in the code for creating custom random seed generation functions. These two spots are with the macro CUSTOM_RAND_GENERATE_SEED and CUSTOM_RAND_GENERATE_SEED_OS currently around about line 1146 in random.c.

Regards,
Jacob

Hi duckula,

That's good news that it is past wolfSSL_new. What behavior is StreamSockets having? I recommend using the overloaded read/write that accept byte arrays as a parameter if not using them currently.

Something to consider with the custom IO call backs is that the set_fd function is creating an association between the socket object and the ssl object. Then each time the ssl is passed to the custom callback the associated socket object is also passed. If not being able to use socket objects the following two functions may need to be wrapped with C# code to replace that association and use a StreamSocket object instead.

wolfSSL_SetIOWriteCtx(sslCtx, ptr); //pass along the socket for writing to
wolfSSL_SetIOReadCtx(sslCtx, ptr); //pass along the socket for reading from

C# wrappers for these functions are not currently in wolfSSL.cs but use of the functions can be seen in set_fd.

Can you tell us some about your project and use case? It is the first case I've seen with the C# wrapper on a Raspberry PI.

Regards,
Jacob