51 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

52 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

53 Reply by Jacob

(6 replies, posted in wolfSSL)

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

Go to forum: wolfSSL

54 Reply by Jacob

(6 replies, posted in wolfSSL)

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

Go to forum: wolfSSL

55 Reply by Jacob

(6 replies, posted in wolfSSL)

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

Go to forum: wolfSSL

56 Reply by Jacob

(4 replies, posted in wolfSSL)

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

Go to forum: wolfSSL

57 Reply by Jacob

(4 replies, posted in wolfSSL)

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

Go to forum: wolfSSL

58 Reply by Jacob

(4 replies, posted in wolfSSL)

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

Go to forum: wolfSSL

59 Reply by Jacob

(4 replies, posted in wolfSSL)

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

Go to forum: wolfSSL

60 Reply by Jacob

(4 replies, posted in wolfSSL)

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

Go to forum: wolfSSL

61 Reply by Jacob

(4 replies, posted in wolfCrypt)

Hello kranthi0032,

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

Thank you,
Jacob

Go to forum: wolfCrypt

62 Reply by Jacob

(4 replies, posted in wolfCrypt)

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

Go to forum: wolfCrypt

63 Reply by Jacob

(4 replies, posted in wolfCrypt)

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

Go to forum: wolfCrypt

64 Reply by Jacob

(1 replies, posted in wolfCrypt)

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

Go to forum: wolfCrypt

65 Reply by Jacob

(4 replies, posted in wolfSSL)

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

Go to forum: wolfSSL

66 Reply by Jacob

(6 replies, posted in wolfSSL)

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

Go to forum: wolfSSL

67 Reply by Jacob

(1 replies, posted in wolfSSL)

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

Go to forum: wolfSSL

68 Reply by Jacob

(1 replies, posted in wolfCrypt)

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

Go to forum: wolfCrypt

69 Reply by Jacob

(1 replies, posted in wolfCrypt)

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

Go to forum: wolfCrypt

70 Reply by Jacob

(4 replies, posted in wolfSSL)

Hi Steffen,

Make sure to be careful on the format of the string being used to set the cipher suites. An example of a setting a cipher suite would be DHE-RSA-AES256-SHA256 and is delimitated by : for example a valid string would be "AES256-SHA256:DHE-RSA-AES256-SHA256". Is the return value of set cipher suite being looked at? In this case the function could be returning SSL_FAILURE due to not being able to set a cipher suite from the list. More in detailed reading about the set cipher suite function can be found at https://www.wolfssl.com/documentation/w … index.html . Let us know if changing the format of the string does not help.

Regards,
Jacob

Go to forum: wolfSSL

71 Reply by Jacob

(6 replies, posted in wolfSSL)

Hi Alper,

OAEP though not supported is currently on the feature list for future projects. Can you tell me some about your project and time frames / deadlines? It may speed things up to have one of our team members contact you directly to work out an alternative, then they could set up a call with you to discuss the possibility of speeding up the process of adding in OAEP padding?

Regards,
Jacob

Go to forum: wolfSSL

72 Reply by Jacob

(6 replies, posted in wolfSSL)

Hi Alper,

We currently do not have support for OAEP padding but support PKCS #1v1.5. Is OAEP padding something that you need for your project?

Regards,
Jacob

Go to forum: wolfSSL

73 Reply by Jacob

(1 replies, posted in wolfSSL)

Hi andersanxily,

Does having a specific suite set on the linux server have the same issue. For example starting the server with
./examples/server/server -l DHE-RSA-AES256-SHA256 -b
Setting the example server to have only the preferred suite the client wants available. (TLS_DHE_RSA_WITH_AES256_SHA256) This suite should be enabled with the default wolfSSL configuration
./configure
make

Regards,
Jacob

Go to forum: wolfSSL

74 Reply by Jacob

(1 replies, posted in wolfSSL)

Hi cfarrin,

If looking to get the clients session ID the function wolfSSL_get_sessionID(WOLFSSL_SESSION* session) could be used. As a note the session ID returned is always going to be 32 bytes long. And is going to be the session id that the server created to send over to the client.
If looking to do resumption using a clients ID an example of this can be found in examples/server/server.c . If invoked with -r a resumption connection is created.

Regards,
Jacob

Go to forum: wolfSSL

75 Reply by Jacob

(5 replies, posted in wolfSSL)

Hi Simon,

I tried connecting to the example Scandium server using Eclipse across a local host connection and saw Scandium send all of DTLS 1.2 flight 4 at once for a grand size of 1,985 bytes. Then the scenario you described earlier. The reason for this is our MTU size for DTLS is set to a conservative 1,500 but is not large enough to handle that size. This is a larger size than what is expected to be sent. A temporary fix for this is to adjust the size in wolfssl/internal.h about line 811 setting MAX_MTU to be 2500 rather than 1500. After doing that I was then able to get farther in the handshake.

Regards,
Jacob

Go to forum: wolfSSL