Welcome to the wolfSSL Forums!

2017-06-27 14:39:33

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

2017-06-13 09:10:03

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

2017-06-02 14:42:53

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

2017-01-13 09:37:47

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

2017-01-06 16:14:10

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

2017-01-05 11:30:36

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

2017-01-04 13:47:04

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

2016-11-17 10:29:39

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

2016-09-15 08:00:31

Hi cxdinter,

As an update on the segfault issue we had a code fix to account for longer then expected buffer sizes with this pull request on GitHub https://github.com/wolfSSL/wolfssl/pull/542. It should now return an error code.

Regards,
Jacob

2016-09-08 14:22:36

Hi cxdinter,

I still have it on my list to review this in more detail, thanks for trying with using the additional header files. I think there may be a difference here in how the data is set up before being encrypted/decrypted with the RSA key. In wolfSSL signature.c it is just hashing the data with no OID being concatenated, then encrypting the hash. So for SHA256 would be 32 byte digest size and the verify function is expecting the input to be set up this way when trying to verify. That being said, our code should send an error value not a segfault.... I think this may be a bug where unexpected input data (OID + hash) is causing an issue. Will review it farther.

Can you tell me some about your project? Is this dealing with certificate signatures?

Regards,
Jacob

2016-09-06 16:04:30

Hello cxdinter,

With linking to the wolfSSL library with first header file included should be wolfssl/options.h. Not including this file can lead to segfault issues. If building without the autotools then the file wolfssl/wolfcrypt/settings.h needs to be included first. This allows for the next wolfSSL headers being included to see how wolfSSL has been compiled due to macros defined or not defined in options.h/settings.h.

Example
#include <wolfssl/options.h>
#include <wolfssl/wolfcrypt/rsa.h>
....rest of wolfssl header files then code

Regards,
Jacob

2016-09-06 11:33:38

Hello hstr,

Yes there is a trade with table look ups giving speed. The tables take up memory and can be disabled with autoconf using the build ./configure --enable-curve25519=small --enable-ed25519=small or like you mentioned with the macro CURVED25519_SMALL. Our trade off in this is on the extreme side, all or nothing.

For adding custom cipher suites there is a couple places in wolfSSL that code needs added. This is a general overview and good starting point for the code changes.

wolfssl/internal.h (BUILD_TLS_****new cipher suite*** macro. Addition of TLS_*** new cipher suite*** value to be passed on the wire -- example of value being set is around line 827ish.)

src/keys.c (Set up ssl structure with cipher suite info. For sig algo new block of code in src/internal would be needed if using ed25519. If using curve25519 a new specs.kea would need to be added and kea block of code to src/internal.)

src/internal.c (BUILD_TLS_****new cipher suite*** added to cipher_name_idx and cipher_names arrays. Addition of new cipher suite to InitSuites function. Addition of cipher suite requirements to CipherRequires function)

src/ssl.c (addition of cipher suite to get cipher name functions)

If adding in curve25519 and ed25519 the biggest issues and code changes will be the kea and sig blocks needed in src/internal.c along with potentially adding in a mechanism for negotiation of these algorithms.

Regards,
Jacob

2016-08-29 09:37:31

Hi hstr,

It really is just that fast! Check out Daniel Bernstein's white paper on it here (https://ed25519.cr.yp.to/ed25519-20110926.pdf). He lists some cycles taken with the processor being used.

Leaving out sign and verify with curve25519 in benchmarking was intentional. The algorithm is set up to find a shared secret key rather then to sign/verify data. For ECC when doing sign and verify it is performing ECDSA, the equivalent of ECDSA would be setting up an ed25519 key and using it to sign and verify.

For use in TLS connections there was a start to a draft with curve25519 but it has not been finalized leading to potential future interoperability issues if used. Mainly the issue of certificates and which curve to use was handled by TLS extensions in the draft, such as with a namedcurve/ecc point format extension. So at the moment there is not an option to use curve25519/ed25519 in a TLS handshake only at the wolfCrypt level (non-TLS).

Regards,
Jacob

2016-07-27 10:08:41

Oh there is also additional callbacks for setting a user defined ctx that wolfSSL passes around with the WOLFSSL struct when calling the user defined IO callbacks. This can be helpful if needing to keep a state attached to a connection. These functions can be found in wolfssl-root/src/io.c.

wolfSSL_SetIOReadCtx(ssl, users-void-ptr);
wolfSSL_SetIOWriteCtx(ssl, users-void-ptr);

"users-void-ptr" would then be passed from wolfSSL as the 4th argument to a user created IO callback function.

Regards,
Jacob

2016-07-27 09:58:14

Hi dimax.main,

Missed the netcon part in the first post. No we do not have a default mapping to this API that is as easy as defining the WOLFSSL_LWIP macro, porting to the API would be as follows.

For porting to a system without making any changes to wolfSSL code I would recommend using the IO callbacks and defining WOLFSSL_USER_IO. The macro WOLFSSL_USER_IO removes header files and assumptions on IO calls, allowing the user to set their own IO operations. After creating a WOLFSSL_CTX structure in a users application the following functions would be needed to set what IO should be used.

//user application code defining the functions user-io-recv-callback and user-io-send-callback

//user application created ctx with wolfSSL_CTX_new();

wolfSSL_SetIORecv(ctx, user-io-recv-callback);
wolfSSL_SetIOSend(ctx, user-io-send-callback);

wolfSSL at this point is effectively encrypting/decrypting buffers and not worrying about how it is physically being sent or received. An example use of the IO callbacks can be found at https://github.com/wolfSSL/wolfssl-examples in the file tls/server-callback.c.

Regards,
Jacob

2016-07-26 15:24:21

Hello dimax.main,

Thank you for contacting us here on the forums. Yes wolfSSL is set up to be able to use lwIP. In wolfssl/wolfcrypt/settings.h there is a macro flag for using it called "WOLFSSL_LWIP", it's currently around line 70. For some more reading on it there is a previous case where Chris was helping port to an embedded device using lwIP here https://www.wolfssl.com/forums/topic275 … tack.html.

Can you tell us some about the project being worked on?

Regards,
Jacob

2016-07-05 11:05:02

Hello kranthi0032,

Responded to this issue using the support@wolfssl.com channel and will solve what is going on there.

Thank you,
Jacob

2016-06-06 11:06:46

Hi LordCapybara,

We have a pull request on our github account to fix this bug. https://github.com/wolfSSL/wolfssl/pull/436 . After it passes testing and review, it will then be merged into our main code.
Thanks again for reporting the behavior.

Can you tell me some about how RSA OAEP is being used in your project?

Regards,
Jacob

2016-06-02 16:33:45

Hi LordCapybara,

Thanks for sending this in and posting example code. I'll be looking into it shortly. As a side note having #include <wolfssl/options.h> as the first include will pull in the options that wolfSSL was built with.

Regards,
Jacob

2016-04-28 15:55:09

Hi LordCapybara,

With AES used in ECB mode it is only going to encrypt and decrypt one AES block at a time. This would be 16 bytes, the trouble here is that the for loop in your code jumps by 24 bytes or 32 bytes with key size 192 and 256. Changing the loop to do a block at a time fixed the issue.

A suggestion outside of the AES encrypt/decryption is to include the same preprocessor defines from wolfSSL compilation.

Can you tell me some about the reason behind using ECB mode and the project being worked on? For multiple blocks like this, ECB mode is not as secure as other modes available.

Regards,
Jacob

2016-03-22 14:55:33

Hi Frank,

Am going through forum posts looking for RSA OAEP, to announce that we added RSA OAEP in the recent wolfSSL release version 3.9.0. Example code using it can be found in the function rsa_test() located in the file wolfcrypt/test/test.c.

Regards,
Jacob

2016-03-22 14:52:47

Hi Alper and Mark,

Am going through forum posts looking for RSA OAEP to announce that we added RSA OAEP in the recent wolfSSL release version 3.9.0.

Has someone from the wolfSSL team been in contact with you by email Mark? It looks like the conversation at the end of this forum did not get addressed here on the site.

Regards,
Jacob

2016-03-01 10:48:42

Hi Tanmaya,

Thank you for the interest in the wolfSSL C# wrapper. At the moment it will not be able to connect to a SSH server. The current C# wrapper around wolfSSL allows for the use of TLS/SSL connections.

wolfSSL does have the ability to use curve25519 crypto operations but these have yet to be built into a TLS/SSL connection and be wrapped by the C# wrapper.

Will add this to the desired feature list for when wolfSSH is complete for SSH connections. Would you be interested in consulting? We could discuss expediting adding the missing features required and setting completion times.

Regards,
Jacob

2016-01-29 14:00:52

Hi lwatcdr,

There is a couple things to check with the code. The first thing to check for the issue with hard faulting is that "size" is a pointer since being dereferenced and to check "size" is not NULL.

wc_AesCbcDecrypt(&denc,block,cipher,*size);

The next thing to check is that the return value of wc_AesSetKey is equal to 0. If it is not then there is a case where denc has not been set.

The final thing with the hard fault is to make sure that AESSIZE is equal to AES_BLOCK_SIZE from wolfSSL.

Not related to a hard fault but still important is that the iv should be the same as what was used for encryption. Creating a new random iv for the decryption will result in not being able to properly decrypt the information.

An example of using AES can be found at https://github.com/wolfSSL/wolfssl-exam … crypto/aes though it has a little bit more since using the function wc_PBKDF2 to stretch out the key if needed, it allows for seeing the flow of a standard AES encrypt -> decrypt.

Regards,
Jacob

2015-12-08 16:51:32

Hi gawiz,

Yes that will work, and is ok.

For the reason why... the wc_AesSetIV function is for adjusting the IV on the fly after the key has already been set. This is helpful at times in a SSL/TLS connection but is not needed to be explicitly called for use. You are correct that the SetKey allows for setting up the IV in the AES key structure.

Was the documentation looked at for use with a TLS/SSL connection? We have a wolfCrypt one at https://www.wolfssl.com/wolfSSL/Docs-wo … rence.html

As an example:

Aes enc;
Aes dec;
const byte key[] = { // some 24 byte key };
const byte iv[] = { // some 16 byte iv };
byte plain[32]; // an increment of 16, fill with data
byte cipher[32];
// encrypt
wc_AesSetKey(&enc, key, sizeof(key), iv, AES_ENCRYPTION);
wc_AesCbcEncrypt(&enc, cipher, plain, sizeof(plain));

cipher now contains the cipher text from the plain text.
// decrypt
wc_AesSetKey(&dec, key, sizeof(key), iv, AES_DECRYPTION);
wc_AesCbcDecrypt(&dec, plain, cipher, sizeof(cipher));
plain now contains the original plaintext from the cipher text.

Regards,
Jacob

Welcome to the wolfSSL Forums!

Search options (Page 3 of 4)

Posts found: 51 to 75 of 84

51 Reply by Jacob 2017-06-27 14:39:33

Re: [SOLVED] Esp-idf + wolfssl (2 replies, posted in wolfSSL)

52 Reply by Jacob 2017-06-13 09:10:03

Re: Curve25519 implementation (8 replies, posted in wolfCrypt)

53 Reply by Jacob 2017-06-02 14:42:53

Re: Curve25519 implementation (8 replies, posted in wolfCrypt)

54 Reply by Jacob 2017-01-13 09:37:47

Re: Windows Iot Raspberry Pi (10 replies, posted in wolfSSL)

55 Reply by Jacob 2017-01-06 16:14:10

Re: Windows Iot Raspberry Pi (10 replies, posted in wolfSSL)

56 Reply by Jacob 2017-01-05 11:30:36

Re: Windows Iot Raspberry Pi (10 replies, posted in wolfSSL)

57 Reply by Jacob 2017-01-04 13:47:04

Re: Windows Iot Raspberry Pi (10 replies, posted in wolfSSL)

58 Reply by Jacob 2016-11-17 10:29:39

Re: [SOLVED] Does Wolf support PCKS12 PFX Format? (2 replies, posted in wolfSSL)

59 Reply by Jacob 2016-09-15 08:00:31

Re: [SOLVED] meet 'Segmentation fault' when using wc_SignatureVerify() (6 replies, posted in wolfSSL)

60 Reply by Jacob 2016-09-08 14:22:36

Re: [SOLVED] meet 'Segmentation fault' when using wc_SignatureVerify() (6 replies, posted in wolfSSL)

61 Reply by Jacob 2016-09-06 16:04:30

Re: [SOLVED] meet 'Segmentation fault' when using wc_SignatureVerify() (6 replies, posted in wolfSSL)

62 Reply by Jacob 2016-09-06 11:33:38

Re: Questions about supported Elliptic Curves (4 replies, posted in wolfSSL)

63 Reply by Jacob 2016-08-29 09:37:31

Re: Questions about supported Elliptic Curves (4 replies, posted in wolfSSL)

64 Reply by Jacob 2016-07-27 10:08:41

Re: WolfSSL over lwIP netcon API (4 replies, posted in wolfSSL)

65 Reply by Jacob 2016-07-27 09:58:14

Re: WolfSSL over lwIP netcon API (4 replies, posted in wolfSSL)

66 Reply by Jacob 2016-07-26 15:24:21

Re: WolfSSL over lwIP netcon API (4 replies, posted in wolfSSL)

67 Reply by Jacob 2016-07-05 11:05:02

Re: RSA in OAEP mode (4 replies, posted in wolfCrypt)

68 Reply by Jacob 2016-06-06 11:06:46

Re: RSA in OAEP mode (4 replies, posted in wolfCrypt)

69 Reply by Jacob 2016-06-02 16:33:45

Re: RSA in OAEP mode (4 replies, posted in wolfCrypt)

70 Reply by Jacob 2016-04-28 15:55:09

Re: Bug using AES in ECB mode (1 replies, posted in wolfCrypt)

71 Reply by Jacob 2016-03-22 14:55:33

Re: [SOLVED] RSA PUBLIC KEY OPERATIONS (4 replies, posted in wolfSSL)

72 Reply by Jacob 2016-03-22 14:52:47

Re: PrivateDecrypt with OAEP padding (6 replies, posted in wolfSSL)

73 Reply by Jacob 2016-03-01 10:48:42

Re: How to use Wolf SSL C#wrapper (1 replies, posted in wolfSSL)

74 Reply by Jacob 2016-01-29 14:00:52

Re: AesCbcDecrypt hardfaulting on STmicro (1 replies, posted in wolfCrypt)

75 Reply by Jacob 2015-12-08 16:51:32

Re: wc_AesSetIV(...) (1 replies, posted in wolfCrypt)

Posts found: 51 to 75 of 84