26 Reply by Jacob

(11 replies, posted in wolfCrypt)

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

Go to forum: wolfCrypt

27 Reply by Jacob

(11 replies, posted in wolfCrypt)

To avoid using a file system, the macro NO_FILESYSTEM can be used in conjuncture with USE_CERT_BUFFERS_1024. This will make the RSA tests use buffers instead of a file system.

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

Regards,
Jacob

Go to forum: wolfCrypt

28 Reply by Jacob

(11 replies, posted in wolfCrypt)

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

Go to forum: wolfCrypt

29 Reply by Jacob

(11 replies, posted in wolfCrypt)

Hi 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

Go to forum: wolfCrypt

30 Reply by Jacob

(11 replies, posted in wolfCrypt)

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

Go to forum: wolfCrypt

31 Reply by Jacob

(1 replies, posted in wolfSSL)

Hi junaid4118,

There is also an open pull request that may help with using native LWIP api located here https://github.com/wolfSSL/wolfssl/pull/599. For making wolfSSL work with no heap there is a couple of solutions possible; one is to write a custom XMALLOC and XFREE and handle cases where wolfSSL would use a malloc or free, the other is to use --enable-staticmemory (macro of WOLFSSL_STATIC_MEMORY) when configuring wolfSSL. More information on static memory feature can be found here https://www.wolfssl.com/docs/wolfssl-ma … location/.

Regards,
Jacob

Go to forum: wolfSSL

32 Reply by Jacob

(2 replies, posted in wolfCrypt)

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

Go to forum: wolfCrypt

33 Reply by Jacob

(1 replies, posted in wolfSSL)

Hi zheng6686,

This could be due to the TLS version supported by OpenSSL. When using the OpenSSL server try connecting the wolfSSL client to it using -v 1 "client.exe -v 1". If using the default authentication then the OpenSSL server will have to be set to use the wolfSSL example server-cert.pem and server-key.pem to allow for the client to authenticate the server using its default CA.

"openssl s_server -port 11111 -cert .\certs\server-cert.pem -key .\certs\server-key.pem"
"client.exe -v 1"

To use the wolfSSL client with SMTP the flag -M smtp should be used. If the client is not ready for the STARTTLS protocol it will try to parse it as a TLS handshake packet.

Regards,
Jacob

Go to forum: wolfSSL

34 Reply by Jacob

(8 replies, posted in wolfCrypt)

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

Go to forum: wolfCrypt

35 Reply by Jacob

(8 replies, posted in wolfCrypt)

Hi Michela,

That is correct. There currently is not API for generating a public key from a private key. Or an automated derivation of the public key from an imported private key. Will add this functionality to the desired feature list.

Can you share some about the project and use case?

Regards,
Jacob

Go to forum: wolfCrypt

36 Reply by Jacob

(3 replies, posted in wolfCrypt)

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

Go to forum: wolfCrypt

37 Reply by Jacob

(1 replies, posted in wolfSSL)

Hello Prateek,

I think we are actively engaged with you through the support@wolfssl.com channel? For this issue though a wolfSSL library should be created and then linked to in order to resolve the "undefined reference" error. There is a couple ways that wolfSSL can be compiled; one is cross compiling for the intended platform, another is including all source files needed from wolfssl-root/src and wolfssl-root/wolfcrypt/src into a project. The easiest method is if ./configure && make can be ran on the system that the wolfSSL library will be used on.

Regards,
Jacob

Go to forum: wolfSSL

38 Reply by Jacob

(3 replies, posted in wolfSSL)

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

Go to forum: wolfSSL

39 Reply by Jacob

(5 replies, posted in wolfSSL)

Hello eques,

After investigating it, the difference between the success case and failure is the ec_point_format extension being sent with client hello. wolfSSL currently does not support the ec_point_format and it looks like the server is not allowing ECDHE cipher suite without that extension.

Regards,
Jacob

Go to forum: wolfSSL

40 Reply by Jacob

(5 replies, posted in wolfSSL)

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

Go to forum: wolfSSL

41 Reply by Jacob

(1 replies, posted in wolfCrypt)

Hi Manoj,

I think the API you are looking for is wc_EccKeyToDer for private key and wc_EccPublicKeyToDer for public key located in wolfssl/wolfcrypt/asn_public.h. Example uses of these function can be seen in wolfcrypt/test/test.c around line 9935 in the function ecc_test_key_gen.

Regards,
Jacob

Go to forum: wolfCrypt

42 Reply by Jacob

(1 replies, posted in wolfCrypt)

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

Go to forum: wolfCrypt

43 Reply by Jacob

(2 replies, posted in wolfSSL)

Hi eques,

I personally have not built wolfSSL for Esp-idf but this looks like the include path needs updated. If it is an IDE based off of Eclipse then you should be able to do something like "right click on the project -> Properties -> C/C++ General -> Paths and Symbols" for adding include paths.

With the second issue the unknown type pthread_mutex_t looks like the macro FREERTOS from settings.h may not be getting included. This could be a side effect of the include paths needing to be updated.

For the last error listed, sys/uio.h dependency can be removed by defining the macro NO_WRITEV. This can be defined in wolfssl/wolfcrypt/settings.h or better yet in a user_settings.h file.

Can you tell us some about the project and use case with wolfSSL?

Regards,
Jacob

Go to forum: wolfSSL

44 Reply by Jacob

(8 replies, posted in wolfCrypt)

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

Go to forum: wolfCrypt

45 Reply by Jacob

(8 replies, posted in wolfCrypt)

Hi Michela,

Which APIs are being used with wolfSSL to generate a public key from the private key? One thing to keep in mind is that wolfSSL's export/import curve25519 key functions use Big Endian format. It can optionally be selected big or little endian with *_ex functions

Regards,
Jacob

Go to forum: wolfCrypt

46 Reply by Jacob

(10 replies, posted in wolfSSL)

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

Go to forum: wolfSSL

47 Reply by Jacob

(10 replies, posted in wolfSSL)

Hey duckula,

Thanks for the project information, it sounds interesting.

Is the disposed error always at the same time when the program is executed ie always at Client Key Exchange? Those two previous API will be helpful if having problems with the parameter "ctx" in the IO callbacks. I'm not sure if that is the case here.

Which cipher suite is the client and server agreeing on? PSK could run into issues at the client key exchange portion if no psk callback is set.

It sounds like this will take some debugging though and stepping through the Recv callback function to narrow down which object is trying to be accessed while having been disposed of.

Regards,
Jacob

Go to forum: wolfSSL

48 Reply by Jacob

(10 replies, posted in wolfSSL)

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

Go to forum: wolfSSL

49 Reply by Jacob

(10 replies, posted in wolfSSL)

Hello duckula,

This looks like wolfSSL_new is returning NULL. One reason for that could be if no certificate/key was set in WOLFSSL_CTX and PSK is not used.

To set key and certificate use

wolfssl.CTX_use_certificate_file
wolfssl.CTX_use_PrivateKey_file

The return value for these should also be checked to make sure the file could be read.

Alternatively to set PSK use

wolfssl.CTX_use_psk_identity_hint
wolfssl.CTX_set_psk_server_callback

Another thing to be conscious of when build the C# wrapper is that it should have the same settings as what was used when building the wolfSSL library. By default the Visual Studio solution packaged with wolfSSL in wolfssl/wrapper/CSharp/ takes care of this. The preprocessor defines used or macros in user_settings.h should be used for both building wolfSSL and building the C# application.

For wolfSSLCbIOSend and wolfSSLCbIORecv you can log custom call backs to handle sending and receiving data over TCP. See wolfSSL-Example-IOCallbacks.cs for an example of this. The use of custom IO callbacks was added for users who want to use their own TCP calls without modifying the C# wrapper. This allows for a users application to be maintained more easily with future wolfSSL updates.

Regards,
Jacob

Go to forum: wolfSSL

50 Reply by Jacob

(2 replies, posted in wolfSSL)

Hello Dirk,

We have some support for parsing a PKCS12 file that has a matching private key and certificate stored. This code is in our main github repo and scheduled to be in the next release. https://github.com/wolfSSL/wolfssl. Currently only supporting parsing of the file and not creating it. To get the most use out of it wolfSSL should be configured with "./configure --enable-opensslextra --enable-des3 --enable-arc4". We do not currently support RC2, so encryption done with RC2 can not be decrypted by the API.

Command line to create a pkcs12 certificate to use.
$ openssl pkcs12 -des3 -descert -inkey certs/server-key.pem -in certs/server-cert.pem -CAfile certs/server-cert.pem -out pkcs12.p12 -export


Sudo code for reading WC_PKCS12 from WOLFSSL_BIO and parsing it

WC_PKCS12* pkcs
WOLFSSL_BIO* bio
WOLFSSL_X509* cert
WOLFSSL_EVP_PKEY* pkey
STACK_OF(X509) certs

//bio loads in PKCS12 file
wolfSSL_d2i_PKCS12_bio(bio, &pkcs)
ret = wolfSSL_PKCS12_parse(pkcs, “a password”, &pkey, &cert, &certs)
//check ret value
wc_PKCS12_free(pkcs)

//use cert, pkey, and optional certs stack

Parsing can be done without using WOLFSSL_BIO by calling wc_PKCS12_parse directly with the DER PKCS12 buffer. Sorry we don't have better documentation of it up yet online, these functions were added just recently. If further questions on use come up feel free to contact us through support@wolfssl.com and we can dedicate an engineer to helping out.

Regards,
Jacob

Go to forum: wolfSSL