Hi janyman,

There is actually a PR open for this here: https://github.com/wolfSSL/wolfssl-examples/pull/135

I have some updates that need to be made to it before it gets merged but you can use the PR as a reference to get started.


Warm Regards,

K

Hi johncarroll944,

Thanks for reaching out about this issue. Did you build the Visual studio projects in release mode or in debug mode? There are a few items here that would impact performance.

1) Cygwin might be detecting the Intel assembly and turning it on.
1) Windows will not auto-detect any environment stuff since it doesn't use autoconf you could try manually define the AES_NI setting in wolfssl/IDE/WIN/user_settings.h and then add the windows assembly file to the build.

2) Cygwin build is likely setting -O[value], windows might be setup to build for size over speed.

3) Cygwin is likely NOT building in debug mode, windows by default uses the WIN32 | Debug configuration which should be set to either x64 | Release or WIN32 | Release mode for better performance.

Warm Regards,

K

Hi niemilkm,

We are actually in the process of updating that VS guide. Could you try following the guide but where it says to use "wolfssl.sln" could you instead try using the "wolfssl64.sln" and see if you experience the same issues?

Warm Regards,

K

254

(4 replies, posted in wolfSSL)

Hi vladr,

Thank you for reaching out to wolfSSL. Just to confirm, you are working with the Microchip_ATECC_Demos.zip from our more downloads page at the following link correct? https://www.wolfssl.com/download/downloadMoreForm.php

As noted in the README for the tls_demo the following Atmel Studio versions are supported:

## Prerequisites for this demo

Software:

  - Atmel Studio 6.2 or
  - Atmel Studio 7
  
Hardware:

  - Atmel SAMD21 Xplained Pro(2 pcs)
  - Atmel CryptoAuth Xplained Pro extension board(2 pcs)
  - Atmel WINC1500 extension board(2 pcs)

Does your setup match the pre-reqs for the demo? Also if you can share exactly what it is you are seeing that would be helpful for us to assist in diagnosing the issue, thanks!

- K

255

(5 replies, posted in wolfSSL)

Hi @rahuld3919,

Browsers come with entire stores of certificates which they load hundreds or thousands of every time they are launched. Whenever they connect to a server the browser will use every cert in it's store to try and verify that server until the store is exausted without a successful verify at which point the browser would report an error and refuse to connect to the server unless you manually add a security exception to the browser for that server. If your server certificate is signed by a CA authority and your browser connects without any issues then your browser is loading a copy of the CA that signed your server cert or it would report an error when connecting to the server.

Warm Regards,

K

256

(5 replies, posted in wolfSSL)

Hi @rahuld3919,

Can you tell us a bit about your current effort and what it is you are trying to do specifically? Why would you want to connect to a server without first loading a certificate with which to validate the server? If you do not load a certificate to validate the peer you might be connecting to any malicious server out there. This would not be a good thing. Please explain the motivation behind the inquiry. As Chris suggested when using a self signed cert just load it on both side of the connection! The client can use the self-signed cert to validate the peer.


Warmest Regards,

K

257

(10 replies, posted in wolfSSL)

Hi @Sen,

Thanks for reaching out. Please find our porting guide here: https://www.wolfssl.com/docs/porting-guide/

We provide many useful tips for building in non-standard environments including how to resolve or port time functionality and other common errors experienced when porting. We also do provide a basic wolf tm struct that can be enabled with

USE_WOLF_TM setting

Please let us know if you have any other questions.

- K

258

(1 replies, posted in General Inquiries)

Hi gaconvn1106,

As mentioned on issue #1335:

wolfSSL maintains a custom port to haproxy, if you email us at support@wolfssl.com or use the zendesk portal at https://wolfssl.zendesk.com we should be able to get you an evaluation version of our port.

We are happy to assist any users via github issues or here on the forums but our engineers utilize zendesk mainly and are more responsive via the official support channel. If you ever notice delayed response times in github or here on the forums please use support@wolfssl.com or the zendesk portal to move your issue forward in a more expedient manner!

Regards,

K

259

(2 replies, posted in wolfSSL)

Hi srikbn,

Can you capture a wireshark trace of the connection so we can see the certs coming back from the server? The -328 is a malformed buffer error indicating there is an issue with the cert. If you can capture a wireshark trace and send it to us we can check to see if the cert is corrupted in any way or if the cipher suite list (which is ONLY static cipher suites) is causing an issue with the cert chain in question.

Can you also send us the build options you are using?


- K

260

(1 replies, posted in wolfSSL)

Hi ervin.oro,

Thank you for contacting us via the forums. Yes as you noted an editors draft is fairly early to jump on but we will continue to monitor and once more matured consider adding an updated API based on a more mature, or better yet, final draft.

- K

261

(2 replies, posted in wolfSSL)

UPDATE:

wolfSSL has tested on a PIC24 using the custom I/O Callbacks to perform a TLS connection over UART Serial.

The changes necessary to get the test running are in a temporary branch here:
https://github.com/wolfSSL/wolfssl/comp … g?expand=1

PIC24 is not supported out-of-the box at this time but if there are any customers interested in seeing out of the box support added for pic24 or 16-bit MCU please shoot us an email at support@wolfssl.com or info@wolfssl.com to let us know about your need.

Test was performed on an EXPLORER 16/32 using a PIC24FJ1024GB610 Plug in Module (PIM).

Cipher suites that were successfully tested are:

ECDHE-ECDSA-AES128-SHA256 - (TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256)
DHE-PSK-AES128-CBC-SHA256 - (TLS_DHE_PSK_WITH_AES_128_CBC_SHA256)
AES128-SHA - (Static RSA cipher suite: TLS_RSA_WITH_AES_128_CBC_SHA)

Test scenario was:

Client running on the PIC24
Server running on a host machine connected by UART Serial full-duplex
Client and server were able to successfully perform a TLS handshake and pass encrypted application data over the UART serial connection.

- KH

@CGH,

Please avoid using any defines of the nature #define BUILD_TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, those defines are detected and set internally within the library and not intended for users to define. To see which rules govern that define look at the header wolfssl-3.15.7/wolfssl/internal.h

 516     #if (defined(HAVE_ECC) || defined(HAVE_CURVE25519)) && !defined(NO_TLS)
 517         #if !defined(NO_AES)
 518             #if !defined(NO_SHA) && defined(HAVE_AES_CBC)
 519                 #if !defined(NO_RSA)
 520                     #ifdef WOLFSSL_AES_128
 521                         #define BUILD_TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
 522                     #endif
...

So to activate that specific cipher suite you would want to use these settings:

#undef HAVE_ECC
#define HAVE_ECC
// Make sure that NO_TLS is not defined
// Make sure the NO_AES is not defined
// Make sure that NO_SHA is not defined
// HAVE_AES_CBC should be automatically enabled but if it isn't go ahead and define it.
// Make sure that NO_RSA is not defined

If all of the above conditions are met then that cipher suite will be available.

- KH

263

(11 replies, posted in wolfSSL)

Hi @valcroft,

You have made good progress. Failure to allocate the SSL object usually indicates insufficient memory. What is your heap and stack available on the device?

- K

264

(11 replies, posted in wolfSSL)

Hi @valcroft,

How was wolfSSL configured? Did you forcefully define WOLFSSL_USER_SETTINGS at the top of wolfssl/wolfcrypt/settings.h and declare the extern gettimeofday prototype in user_settings.h?

Warm Regards,

K

Hi @pkolte,

Thank you for reaching out to wolfSSL about the issue you have encountered. We have not previously had a report of this nature and there is no such limitation at the C level so it is most likely stemming from the custom I/O callbacks at the Java level. We will investigate and post our findings here as soon as possible.

Can you tell us a bit about what you are working on? If you are unable to share details of that nature on a public forum feel free to send us more details at support@wolfssl.com.


Warm Regards,

K

Hi @CGH,

Thank you for contacting wolfSSL with your issue. I have requested that one of our developers (who was working on that API last year, around July, to make it constant time for side channel attack prevention) take a look at your report.

Please expect an update from Sean in the next few days sometime.

In the meantime can you tell us what it is you are working on and which organization you are with?


Warm Regards,

K

267

(2 replies, posted in wolfSSL)

Update:

Also ran a test of 10,000 rounds with no repeat password by compiling the test app with:

gcc test.c -o run -I/usr/local/include -L/usr/local/lib -lwolfssl

Then executing this script to check for duplicates:

#!/bin/sh

echo "" > output.txt

for i in {1..10000}
do
    ./run >> output.txt
done

sort output.txt | uniq -d | grep -nFxf output.txt

Warm Regards,

- K

268

(2 replies, posted in wolfSSL)

Hi @yvelumani,

I modified your code snippet and tested it on a desktop system which uses the /dev/random for an entropy source and in 100 rounds I do not see a repeating password. Here is your modified code with correct header includes:

#include <stdio.h>


#include <wolfssl/options.h>
#include <wolfssl/ssl.h>
#include <wolfssl/wolfcrypt/random.h>

int getRandomBytes(unsigned char* buffer, int count);
int GetRandomCharacters(char* buffer, int count);

int GetRandomCharacters(char* buffer, int count)
{
   unsigned char* t_buffer = (unsigned char*)buffer;

    char convert[] = "ABCEFGHQJKLMNOPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz923456"
                     "789ABCEFGHQJKLMNOPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz923456789ABCE"
                     "FGHQJKLMNOPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz923456789ABCEFGHQJKL"
                     "MNOPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz923456789ABCEFGHHJKLMNOPQRSTU";

//    assert(257 == sizeof(convert));

    if (getRandomBytes(t_buffer, count)) {
        for (int i = 0; i < count; ++i) { buffer[i] = convert[t_buffer[i]]; }

        return 1;
    }

    return 0;
}

int getRandomBytes(unsigned char* buffer, int count)
{
    return SSL_SUCCESS == wolfSSL_RAND_bytes(buffer, count);
}

#define PASSWORD_LEN 26

int main(void)
{
    int i;
    int count = PASSWORD_LEN;
    char buffer[PASSWORD_LEN] = {0};

    GetRandomCharacters(buffer, count);

    printf("Password = ");
    for (i = 0; i < count; i++)
        printf("%c", buffer[i]);
    printf("\n");

    return 0;
}

Can you tell us which system you are testing on and if you have any settings like

#define NO_DEV_RANDOM

or

#define USE_GENSEED_FORTEST

set as those WOULD be poor entropy sources for seeding the DRBG.


Here are my results with 100-rounds:

Password = g29LzioeSfMmsczF3iKhOnxfPb
Password = FtvKPRo9E9yrnpP6HSQ59YoHw2
Password = kLHQCU6CEOrXFNeTT4mMTY9B3q
Password = rr2TUEpQ3LOK7gkQdxyP4ERZxR
Password = Zjf43YrTeUh92iKe8FtNBeZQWL
Password = htL7NPFWvBkoPNL5e4KUEFXQoC
Password = CafYWojacfqPRckPrVfAAnVfNw
Password = 2FTuNcL3WWhEqMHQWtjBFq6LXx
Password = ZznFH2W9M2vgMdkoTE9maGJQrh
Password = EPgjivLv76mYaRQNnEH9kHn9qv
Password = Xyw5eMQbWYvX9jcGL69LeUM2Qj
Password = XW6TMzJPvTLFSrXP9dmBi9Sk9Q
Password = HOrF6pOJVBhjtUW7JOb4HEvYh3
Password = NCqoFVFgzQ8OApFHsOJpx8sR6C
Password = vQtzCH9cg6ZYjTWd3Kv9T9U8zC
Password = dCxQMMo2Abz9BPAYktejVQ8K6K
Password = r9GndBmVp6XHUaaHrJMmpRYRjs
Password = REYgMOQdEQ97EBPK8UPhmcPbE9
Password = J7R9ztrsg9AmLSKTRZY8bsPiC2
Password = o59ssa96vJdLr397nQ6GX2SMgJ
Password = MJk9ko8XfuS9OdXF6zG2sq2Kcv
Password = QoTeM9UEwBLA4PgQwmLWmysTQO
Password = pwCvN4R5hLqZbTtKyuwQt6fN9V
Password = xrcYyknt2ZcrP3ZaMJWTq8GSqB
Password = nuLaTjoV55VdcqfsHAmktHTukK
Password = 59dX64UPmWMhQmJnqtoBGbFwdL
Password = xBWYt7u6Qycn9HHX9vOMhVNUPj
Password = HqpvKsGqmFyr8QiNOc2mZNCtNK
Password = dpzeoPuC3LyVLK2v8uMax7Hw7i
Password = TN5WQwzM5PHOY9OVVbGOYcV4gF
Password = oUNgxWAeNt79NTdWbFftQhQeKs
Password = HKwnQQwbN9M5SaPKAUQYGF9uR4
Password = WZxefQUCKGCQMSQR2qOcxaN8Cs
Password = UfVRWRRR8zLnaSckfwkncoRLTi
Password = xNOyTXy96EvHQSXQQuacXU4k38
Password = 8zP9kp8JULxWwUg9bNFLgVyJyw
Password = EC6G4kiYEPV4vHURajhwUXE34n
Password = nLoiGPzsqCjjQg99FM7VQiT2zb
Password = pojgKJTFj3O4mL9T3eQ3czCGVz
Password = 7sq7YGxfnCAoSZgdvs8bE5EPRP
Password = VQV29UTFMLKjjcms9paSCCBFgd
Password = PcQ4QmHfxeHKJNXOqczej3jXve
Password = y4nhTf2MVPLwEQtraqi7AHxidM
Password = 8R79RFOpzsnXsQNTCPu5X9MhVE
Password = xT7iLOQyaFmwPVmCvSeNKB9fUN
Password = KbO7vWCcBsWQwkyRaxYiN2cfps
Password = XhjaL3JMwb3PosUoSGdP64gJW3
Password = sGOekTNTVf99fOA7wSBpTWEwAU
Password = Ub8eFQxE79ZWGQ9kkFJKRW9SUX
Password = 63meb9K2mArYZdgPeuxsN28KQe
Password = RjRjLM8HPPNyqQSxoQJ58CkqJF
Password = ck8XtFeON3Z6OATCRLOf3dZ56s
Password = eSx2NRqrRjGyzoUpOEoh2M9Jta
Password = RHcAGRhMMuHKeH7L5tp4JrH8pK
Password = NLjeoYxjP7YX8ELLzT4F7Aqn2x
Password = JrFbKFBpNNOmLwqMCrHTf7aCOT
Password = iZnYwpSVZwB6npS6KFsYRqTBRs
Password = S8LE3uKmLCrqnUPN7iWtZF3Y2t
Password = cRAHfJGmUh9JASKqVuahbdS2m9
Password = QTjcavaK6sRXRLCLaXwKvAOQyk
Password = Qq5AtB9RNeyn8GQqh65WWBf6A9
Password = eoO2KYhRcTQAMyBLmYOUAOfcVp
Password = 8ttOPzydHbPEiWBReMSB7XEvgP
Password = v3WzGjHaBLQVT9kKavMrse9Cvg
Password = SHNb3MQgNm4BufHW6OqXMRiwfc
Password = OMtNQ6dbFYp8ByJcqXpiyNmU9v
Password = ZoyswkUp2GqHGCMH5mnfdrMw4E
Password = gahu6MfKwtQQbGdQxerLOtQMXO
Password = QqQEP9RXQyOAkKNhjQbuo5phRy
Password = JGFEFW6fEFupEMJojS99j3PoWC
Password = YSAd6kuFeTQRfPQFdxeg6H6yU9
Password = 3QCiFEgpZ4cKtsotKtVQ2SAB34
Password = uHqoRA6Yea4nWqAhVQ9gRHHuho
Password = ETTKQ87vPta6A2Y9XbQLVbgjyw
Password = 8AQNwVSJRCL3Qgc2jUQKQUSwtW
Password = ydSg5azw4T4o6dz5FyBQh6BecP
Password = w9yKLOk9uWer93nKLCQUsscyPt
Password = 8QJd29Qg9MAuOx7B85SZLPNvvJ
Password = ON9eQKQGbRMCOnEK3MQAuajSW4
Password = gc9L33cXcveQ4gH7nQHaMggT92
Password = aYTORdPMNbAmORPJRnL9FK5wNp
Password = AzQa6Qz4mpKSNcR78SbEPAQnmn
Password = Qdy5AbBKVAnnXwqhCfTgLLTON9
Password = O336fGRh6EaNyr9GxQLTSASQ6R
Password = KLbbycMC3vQOP8s4krNQ2NHqcA
Password = Kfih2625PFBYhB5NPRi6WBTTeL
Password = Eitn9xceNwZSCFCPOFFn9NYAPq
Password = WfVpAEqhYMw2NkCpsO97VyemcQ
Password = tdg23sQbsquSOKC9u2gZUo9K3K
Password = V9L4sQYkN3rXKsaYRLRfUnRctm
Password = bGXeMJaSfCZ77sMY5HQ4yTqgjJ
Password = AmqAAzBnvhOiPwoRoW3bOpoEiL
Password = gQPPCJfQriby5FdgiqMExxzc3H
Password = YPF4R9zb7Ab6FA3kOTfMBvan2j
Password = k4aZAAiQPj5KassSiBAnxy9tBu
Password = WB2yq4objBtSCM9R8WO7UbAYn9
Password = EnBzPyQnrcQhbs5Mfsotox4qsb
Password = asUOkuQhacNYOMTYYfzHm83uye
Password = y8BcSBVOy929mF7tiL5K8fMhPu
Password = kU4Y8bXJ562EJPPGryEUkx2v4N

Warm Regards,

- K

269

(2 replies, posted in wolfMQTT)

eli.hughes,

Thank you so much for sharing your findings and we apologize for the delayed responses as the whole company was traveling to our annual meeting and back here at the beginning of the year. In the future for best response times please feel free to shoot an email to support@wolfssl.com if you don't see an update in a timely manner here on the forums.

Thanks!

Warm Regards,

- K

Gene,

Thanks for reaching out. We have not heard of anyone setting up something like this yet no. If this is something you would like to explore further feel free to shoot us an email at support@wolfssl.com for best response times and if you can include some details about your organization, the regulations coming your way that you mentioned, and any other details to help us best qualify the support case that is always helpful.

Thanks!

- K

271

(1 replies, posted in wolfSSL)

Hi meobeou,

I ran some test with our sha algortihm and can find no such limiting factor. Can you share your application code for review? We suspect the issue is likely at the application level.

Can you tell us a bit about what you are working on and which organization you represent?

Warm Regards,

K

272

(1 replies, posted in wolfSSL)

For a reference see: wolfssl-3.15.7/IDE/GCC-ARM/Header/user_settings.h.

Look for the section:

/* ------------------------------------------------------------------------- */
/* RNG */
/* ------------------------------------------------------------------------- */

- K

273

(3 replies, posted in wolfSSL)

eli.hughes,

Not a problem, it's our pleasure to help out! Let us know if anything else comes up. Also as a side note if you ever have a question that needs answered quickly feel free to contact us at support@wolfssl.com email for best turn-around times!

- K

274

(3 replies, posted in wolfSSL)

Hi eli.hughes,

Thank you for contacting wolfSSL via the forums. With your same settings I had the following results for heap/stack:

stack used = 62784
peak Heap Bytes = 71296

By adding the following one setting I got the heap down to just under 18k and the stack down to 45k:


#define ALT_ECC_SIZE

stack used = 45392
peak Heap Bytes = 17944

Next test I ran was to use the single precision math library for performance improvements since you noted the long run times and this not only reduced the speed of the tests by about a factor of 4.3 but also further drops the resource usage where heap is now just of 9k (stack usage remained the same at 45k):

#define ALT_ECC_SIZE
#define WOLFSSL_SP
#define WOLFSSL_HAVE_SP_ECC
#define WOLFSSL_HAVE_SP_DH
#define WOLFSSL_HAVE_SP_RSA

stack used = 45392
peak Heap Bytes = 9272

Finally I am aware that ECC Shamir uses more heap but is also faster so you can disable that setting to further reduce heap usage to about 8.7k (stack usage again is unaffected but likely the stack is mostly, like you noted, due to the FOURK_BUFs being set aside on the stack throughout the tests:

#define ALT_ECC_SIZE
#define WOLFSSL_SP
#define WOLFSSL_HAVE_SP_ECC
#define WOLFSSL_HAVE_SP_DH
#define WOLFSSL_HAVE_SP_RSA
#undef ECC_SHAMIR

stack used = 45392
peak Heap Bytes = 8792

With this last test a client/server use the following during a connection using the cipher suite TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

SERVER RESOURCES:

stack used = 22048
peak Heap Bytes = 22244

CLIENT RESOURCES:

stack used = 20624
peak Heap Bytes = 20563

In this test the client and server were both doing authentication (mutual auth) so they were both sending cert chains and verifying eachother. If not doing mutual auth you could expect lower resource use for the connections.

Warm Regards,

K

275

(2 replies, posted in wolfSSL)

Hi xyz,

Can you tell us what you are working on and the end goals for your project? Can you tell us which organization you represent and why you need to find these specific details? Thanks!

Warm Regards,

K