Hello Yulia,

Can you tell us a bit about what is driving this effort?

From a high level lets' dig into one of your notes:

For now, the first fragment seems to be correct, but the second fragment contains some garbage value (partially from the previous fragment of the Server Certificate message).

WHERE in the second fragment are the garbage values? Are they at the head or the tail of the message?

If they are at the HEAD don't forget the first 5-bytes of any TLS packet are the header denoting what kind of message (a handshake message in this case), the protocol version (TLS 1.3 in this case) and the length of the packet to follow (up to 16k). You'll need to change the length value to reflect the remainder that wasn't sent in the first fragment.

If the garbage values are at the TAIL of the message that might mean you didn't XMEMSET the transmit buffer before copying in the remainder. IE if you copied 16Kb in for the first fragment and the remainder is only 2Kb lets' say, and you just copy it in without clearing the first fragment you'll just be updating the first 2Kb and the final 14Kb will be from the first fragment if that makes sense.

Hope this helps get you on the right track, let me know if you have any followup questions.

- KH

2

(7 replies, posted in wolfCrypt)

Can only attach 1 file at a time, here is screen shot 2 mentioned in last post

3

(7 replies, posted in wolfCrypt)

@Vitus,

One thing I noted, you are building on windows which does not support <wolfssl/options.h>. <wolfssl/options.h> is for use on *NIX systems where the ./configure script was run and options.h was auto-generated.

On windows please replace all occurrances of <wolfssl/options.h> with:

#include <wolfssl/wolfcrypt/settings.h>
#ifndef WOLFSSL_USER_SETTINGS
    #error "Sanity Check: Please add the PreProcessor setting WOLFSSL_USER_SETTINGS to the project"
#endif

If the above sanity check is seen please right-click on the project in the solution explorer window and open "Properties" ->C/C++ -> "Preprocessor" -> "Preprocessor Definitions" and add "WOLFSSL_USER_SETTINGS" to the project pre-processor settings. (See attached screen shot 1)

If you then get an error about "user_settings.h" not being found go to "Properties" ->C/C++ -> "General" -> "Additional Include Directories" and add a path to "C:\path-to-wolfssl-root\IDE\WIN" where the windows user_settings.h header resides. (See attached screen shot 2)

Warm Regards,

K

4

(7 replies, posted in wolfCrypt)

Hi @Vitus,

Can you tell us a bit about your project and what the end goals are? This helps us to better qualify the inquiry, thank you!


Can you double check that <wolfssl/options.h> is included in any .c source files running wolfSSL operations BEFORE all other wolfSSL headers? This ensures the application and library have the same settings. If this does not resolve the issue you are seeing let us know and we can dig deeper.

Warm Regards,

K

P.S. take care to pass by REFERENCE when buffer is going to be updated with new values and those values need to persist beyond scope of the called function. A simple sanity check:

1) Run the app before it is split up, dump out buffer contents and relevant size values
2) Run the app after it is split up, dump out buffer contents and relevant sizes FROM MAIN ONLY.
3) Do the buffers contain the expected information in case 2 and are the relevant length values correct?

Scotty,

Just wanted to be clear on how it decided the TLS version and picking the cipher.
A client wanted to use the elliptical ciphers  (TLS_ECDHE_* ) , but neither Chrome no Firefox is showing it as being selected. 
I do have it enabled.  I suppose to verify I would need to remove all the other ones and see if it connects.

Understood. Also be aware that in the selection process the certs are part of the decision. If the server has both an ECC cert chain and an RSA cert chain it should be able to connect with either ECDHE_RSA or ECDHE_ECDSA. If the server has algorithmic support for ECC but only has RSA certificates it will only be able to negotiate ECDHE_RSA.

Yes a good test would be to limit the client ciphers to only one at a time and then test if each connects. If the client only presents a single option to the peer the peer will either have to select that option or tell the client it can't negotiate that option (by severing the connection). In this way you can determine what all would be supported, as I mentioned the only control the client has over the selection process is in what it presents to the server.

You can present a single cipher with:

wolfSSL_CTX_set_cipher_list(ctx, "ECDHE-ECDSA-AES128-SHA");

OR

You can present two or more with a colon delimited list:

char cipherList[] = "ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA256";
wolfSSL_CTX_set_cipher_list(ctx, cipherList);

OR

You can not use that API at all and wolfSSL will always send a list of all ciphers supported by the current build configuration.


Warm Regards,

K

In this case the server IS a WolfSSL based app...   So the server will try to negotiate that when?

It will happen during the wolfSSL_accept call, that is correct.

Or is there another call that should be made to tell it to do so?
Or is it automatic?

Yes it will happen automatically.

We have an excellent (yet simple) basic server example here to show the process: https://github.com/wolfSSL/wolfssl-exam … rver-tls.c

Assuming somewhere prior in your code you configured your server with a cert and key etc.

Warm Regards,

K

Scotty2541,

Is this any priority?  Or does the client have total control over which one is preferred and will be used?

The server ALWAYS gets to pick what it prefers based on what the client sends. The client only has contol in that it can LIMIT the options available to the server to pick from.

does it make any difference what order they are?

The order in which they arrive does not matter. The server is configured how it is configured.

In MOST cases a server will try to pick the STRONGEST cryptographic option but some might be configured to consider run-time resource requirements or some other governing factor in the decision making process for which cipher it selects from the client offered list.

Warm Regards,

- K

8

(1 replies, posted in wolfSSL (formerly CyaSSL))

Hi @jainprince1995,

Can you send an email with this summary to support [at] wolfssl [dot] com so our team can review it in more detail and assign a support resource, thanks so much!

- KH

9

(3 replies, posted in wolfSSL (formerly CyaSSL))

Checking if an internal example exists, will get back to you shortly!

- KH

10

(5 replies, posted in wolfCrypt)

Abulafia,

We have a few separate requests in to add support for EC_POINT_set_compressed_coordinates (not yet available). We tend to work on new feature additions that are not tied to a funded effort in our spare time but as such we don't have a fixed timeline associated with their implementation. If a customer needs a new feature right away they can partner with us on the effort to get it implemented in a finite timeline. If this is a show-stopper for you be sure to contact the business manager for your region. If you are not sure who the business manager would be you can send a general inquiry to facts [at] wolfssl [dot] com to figure out who to connect with for your region.

Warm Regards,

K

Hi Octopus01,

Thanks so much for your question. Can you compare your setup to our very simple example at the below link to see if there are any differences?

https://github.com/wolfSSL/wolfssl-exam … rver-tls.c

Also I would suggest double-checking the scope of the structures, when configuring a WOLFSSL_CTX in a function a typical flow would be like below.

int functionA(WOLFSSL_CTX* ctx) {
   // configure context
   // return success/fail code
}

int functionB(WOLFSSL* ssl) {
    // configure ssl object
    // return success/fail code
}

void functionMain(void)
{
    WOLFSSL_CTX* ctx;
    WOLFSSL* ssl;
    int return_code;

    return_code = functionA(ctx);
    return_code = functionB(ssl);
}

Warm Regards,

K

12

(1 replies, posted in wolfSSL (formerly CyaSSL))

Could a sporadic crytpo operation failure cause this behavior?

Yes it could be, you mentioned using an Atmel chip, we have seen cases where if data is not specifically aligned offloading to hardware can lead to issues.

If the WolfSSL peer is only receiving corrupt messages, would that exonerate our WolfSSL peer from blame?

If the messages are corrupted on arrival at the wolfSSL end then yes that would exonerate wolfSSL from being the culprit of the corruption.

Any tips on pinpointing the culprit?

You mentioned this happens very frequently from $jobs network (50%) and very infrequently from a private network. Is it possible the IT department in $jobs network is monitoring, decrypting and re-encrypting information for the sake of protection proprietary/trade secrets?

Warm Regards,

K

Thomas,

Thank you so much for your questions. There is no patch for the mentioned attributes at the moment. We can address it in one of two ways.

One, we can take this down as a feature request. We work on feature requests internally between other funded projects so there isn't a timeline guarantee on any new features unless a customer decides to fund the effort for a guaranteed implementation timeline.

Two, as you suggested you can make the changes yourself and submit those changes as a pull request against https://github.com/wolfssl/wolfssl.git.

In order to accept changes from individuals that are not employees of wolfSSL we have to work through some legal paperwork to get you set up as an approved contributor under the wolfSSL Incorporated organization. To start that process go ahead and open your pull request when ready and then send an email to "support [at] wolfssl [dot] com" with the subject line referencing the pull request number and request a contributor agreement to go over with your own legal department before returning a signed copy to wolfSSL for review by our legal department.

If your contributor status is approved we can then begin reviewing the proposed changes for acceptance and ultimately merging into the wolfSSL master code branch.

Warmest Regards,

K

14

(5 replies, posted in wolfCrypt)

Hi @eyrmin,

Thanks for your question, please checkout the sections of code wrapped by the setting HAVE_COMP_KEY (Short for HAVE COMPRESSED KEY).

Can you tell us a bit about what it is you are working on and which organization you are with? For a more private venue to share this information you can reach us at support [at] wolfssl [dot] com also.

Warm Regards,

K

@srihari,

wolfMQTT uses wolfSSL_write. wolfSSL_write ultimately uses the default custom callback for sending (EmbedSend()) which is found in wolfssl-root/src/wolfio.c. wolfSSL uses a custom I/O callback solution allowing our users to over-ride the default if necessary (for more on this checkout https://www.wolfssl.com/wolfssl-alterna … support/).

Warm Regards,

K

16

(1 replies, posted in wolfCrypt)

Hi @strow089,

1) There are two separate wrappers, one for SSL/TLS and one for crypto. https://github.com/wolfSSL/wolfcrypt-py
Documentation for the crypto wrapper can be found here: https://wolfssl.github.io/wolfcrypt-py/
For AES see: https://wolfssl.github.io/wolfcrypt-py/symmetric.html

2) https://wolfssl.github.io/wolfcrypt-py/digest.html SHA3 has not been added yet unfortunately.

3) There are examples of setting up ones' keys in a buffer here: https://wolfssl.github.io/wolfcrypt-py/asymmetric.html

Warm Regards,

K

@remix,

Try adding dash capitol c (-C) to disable the requirement to load a certificate revocation list. Let us know if this resolves the CRL check failing.

Warm Regards,

K

18

(1 replies, posted in wolfSSL (formerly CyaSSL))

Larry,

Thanks for your question. I just got your case through our Zendesk system and will be addressing it there. The short answer is yes wolfSSL has been ported and shown to work on 16-bit architectures. There are some customizations that need to happen but it is possible.

Looking forward to working with you more through "support [at] wolfssl [dot] com".

Warm Regards,

KH

19

(1 replies, posted in wolfCrypt)

Hi Tagazop,

Thank you for reaching out. Can you tell us a bit about your project and end goals? We are always eager to hear about the new ways in which wolfSSL is being used.

To turn on features not enabled by default please checkout the wolfSSL manual https://www.wolfssl.com/documentation/w … Manual.pdf Chapter 2, section 2.4.4 Enabling Features Disabled by Default.

The only one not documented (because it is considered unsafe for use) is ECB mode, please check the source file in wolfssl/wolfcrypt/src/aes.c for the option to turn on "direct" encryption.

Warm Regards,

KH

Buoy,

This would be managed by the transport layer. TCP for example is a transport layer that guarantees message delivery. If you are using some other transport layer check the documentation for your transport layer to see how to implement message delivery guarantee.

- KH

Typically a front end serving the proxy will have a server name indication to direct traffic to the proxy. You can specify a server name indication with the client by configure with --enable-sni and setting parameter -S <target server name>

- KH

Please checkout:

wc_ecc_encrypt(): https://www.wolfssl.com/doxygen/group__ … a32b9795b2
wc_ecc_decrypt(): https://www.wolfssl.com/doxygen/group__ … 804aca27e6


- KH

karanbanthia,

Are you using the USE_FAST_MATH setting? If so you should configure more stack, try around 23k and make sure you have ALT_ECC_SIZE defined when USE_FAST_MATH is also defined.

Heap you should only need 16-30k depending on optimizations. If you don't want to set the stack higher you can try using the setting WOLFSSL_SMALL_STACK to shift memory usage to the HEAP and remove the setting USE_FAST_MATH and compile integer.c instead of tfm.c to use mostly HEAP.

- KH

@he1n,

Which client_method() are you using?

wolfSSLv23_client_method() -> starts with highest protocol version and downgrades if server doesn't support that version
wolfTLSv1_2_client_method() -> Only supports TLS 1.2
wolfTLSv1_3_client_method() -> Only supports TLS 1.3
... etc.

- KH

Some useful reading:

https://whatis.techtarget.com/definitio … -vector-IV

...The ideal IV is a random number that is made known to the destination computer to facilitate decryption of the data when it is received. The IV can be agreed on in advance, transmitted independently or included as part of the session setup prior to exchange of the message data. The length of the IV (the number of bits or bytes it contains) depends on the method of encryption. The IV length is usually comparable to the length of the encryption key or block of the cipher in use...

https://security.stackexchange.com/ques … encryption

... Knowing the IV doesn't get an attacker anywhere, because the IV is only there to ensure non-equality of ciphertexts. The secret key is what protects the actual data...

- KH