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

77

(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

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

79

(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

80

(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

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

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

83

(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

84

(5 replies, posted in wolfSSL)

Hi sbernard,

To answer the question about Supported Elliptic Curves after enabling them as a configure option they then need to be added to the client ssl struct. In example,

code to init ssl struct ....

    if (wolfSSL_UseSupportedCurve(ssl, WOLFSSL_ECC_SECP160R1) != SSL_SUCCESS)
        printf("handle error\n);

   ...code to make connection and then clean up

If using the example wolfSSL client this function call can be added in at line 788 of the current one. As soon as one has been added then the client sends out the ECC curve extension. With wireshark there should then be Extension: elliptic_curves when looking at the client hello. Just as farther info when using, all available curve options are

WOLFSSL_ECC_SECP160R1 = 0x10,
WOLFSSL_ECC_SECP192R1 = 0x13,
WOLFSSL_ECC_SECP224R1 = 0x15,
WOLFSSL_ECC_SECP256R1 = 0x17,
WOLFSSL_ECC_SECP384R1 = 0x18,
WOLFSSL_ECC_SECP521R1 = 0x19

Unfortunately the ECC Point Format Extension has not yet been added. There is some internal code started for it but it has gotten pushed to the back burner.

Regards,
Jacob

Hi Amir,
Sorry, yeah looks like that function only exports to ANSI X9.63 format.
I did some farther resarch into possible ways for wolfSSL to convert an ECC key to DER format. We currently don't have a function or process that can convert ECC keys to DER format to then be used in wolfSSL_CTX_use_PrivateKey_buffer(). Thanks for bringing it to our attention though, it's now been added to the feature list for looking into adding a future ECC to DER function.

Regards,
Jacob

Hello Amir
Let me know if this is what you are looking for http://www.yassl.com/forums/topic518-co … o-der.html
If not could you tell us some more about the project and the use case?
Thanks,
Jacob