You are not logged in. Please login or register.
Please post questions or comments you have about wolfSSL products here. It is helpful to be as descriptive as possible when asking your questions.
ReferenceswolfSSL - Embedded SSL Library → Posts by Kaleb J. Himes
Hi Ajay,
_open and _gettimeofday are usually part of the rdimon spec library. This can be resolved typically in a cross-compile build by adding the following:
# WHERE ${LIBS} is any other libraries you might need
WOLF_OPTS := --specs=rdimon.specs -Wl,--start-group ${LIBS} -lgcc -lm -lc -lrdimon -Wl,--end-groupThen add ${WOLF_OPTS} to your build rule for the object.
Warmest Regards,
Kaleb
Hi Ajay,
To test these yourself you can do the following:
cd wolfssl
./configure --enable-trackmemory
make
./examples/server/server -l <cipher suite to test> -c <certs/server-cert.pem or correct cert or -s w/ nothing instead of -c for PSK> -k <key or nothing for PSK> -d &
./examples/client/client -l <cipher suite to test> -c <certs/rsa or ecc cert.pem or -s with nothing instead of -c for PSK> -k <key or nothing for PSK> -A <certs/cert authority file>EXAMPLE:
PSK:
./examples/server/server -l DHE-PSK-AES256-GCM-SHA384 -s -d &
./examples/client/client -l DHE-PSK-AES256-GCM-SHA384 -sRSA: (default certs used here)
./examples/server/server -l DHE-RSA-AES128-SHA256 -d &
./examples/client/client -l DHE-RSA-AES128-SHA256ECC:
./examples/server/server -l ECDHE-ECDSA-AES128-GCM-SHA256 -c certs/server-ecc-self.pem -k certs/ecc-key.pem -d &
./examples/client/client -l ECDHE-ECDSA-AES128-GCM-SHA256 -c certs/client-ecc-cert.pem -k certs/ecc-client-key.pem -A certs/server-ecc-self.pem
# SERVER
SSL version is TLSv1.2
SSL cipher suite is TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
SSL curve name is SECP256R1
# CLIENT
SSL version is TLSv1.2
SSL cipher suite is TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
SSL curve name is SECP256R1
# SERVER
Client message: hello wolfssl!
total Allocs = 74
I hear you fa shizzle!
total Deallocs = 74
total Bytes = 77118
peak Bytes = 32731
current Bytes = 0
# CLIENT
total Allocs = 131
total Deallocs = 131
total Bytes = 192979
peak Bytes = 76275
current Bytes = 0NOTE: if you define ALT_ECC_SIZE that last one get's highly optimized to just:
# SERVER
total Allocs = 74
total Deallocs = 74
total Bytes = 25822
peak Bytes = 12315
current Bytes = 0
# CLIENT
total Allocs = 131
total Deallocs = 131
total Bytes = 51835
peak Bytes = 19355
current Bytes = 0Regards,
Kaleb
Hi ajay,
PSK cipher suites will always use less resources due to the fact they do not need to send and process certificates for peer verification.
ECC cipher suites (ECDSA) would be the next smallest and then RSA the largest.
Here are some quick tests I ran with our example client/server. Pay attention to the "PEAK BYTES". The top results are the server-side usage and the bottom are the client-side usage in each sub-section.
Let me know if you have any other questions on these!
testing cipher suite DHE-PSK-AES256-GCM-SHA384 -s
SSL version is TLSv1.2
SSL cipher suite is TLS_DHE_PSK_WITH_AES_256_GCM_SHA384
SSL DH size is 2048 bits
Client message: hello wolfssl!
total Allocs = 40
total Deallocs = 40
total Bytes = 14294
peak Bytes = 8595
current Bytes = 0
SSL version is TLSv1.2
SSL cipher suite is TLS_DHE_PSK_WITH_AES_256_GCM_SHA384
SSL DH size is 2048 bits
I hear you fa shizzle!
total Allocs = 45
total Deallocs = 45
total Bytes = 11124
peak Bytes = 9763
current Bytes = 0
---------------------------------------------------
testing cipher suite DHE-PSK-AES128-GCM-SHA256 -s
SSL version is TLSv1.2
SSL cipher suite is TLS_DHE_PSK_WITH_AES_128_GCM_SHA256
SSL DH size is 2048 bits
Client message: hello wolfssl!
total Allocs = 40
total Deallocs = 40
total Bytes = 14294
peak Bytes = 8595
current Bytes = 0
SSL version is TLSv1.2
SSL cipher suite is TLS_DHE_PSK_WITH_AES_128_GCM_SHA256
SSL DH size is 2048 bits
I hear you fa shizzle!
total Allocs = 45
total Deallocs = 45
total Bytes = 11124
peak Bytes = 9763
current Bytes = 0
---------------------------------------------------
testing cipher suite DHE-PSK-AES256-CBC-SHA384 -s
SSL version is TLSv1.2
SSL cipher suite is TLS_DHE_PSK_WITH_AES_256_CBC_SHA384
SSL DH size is 2048 bits
Client message: hello wolfssl!
total Allocs = 36
total Deallocs = 36
total Bytes = 14286
peak Bytes = 8595
current Bytes = 0
SSL version is TLSv1.2
SSL cipher suite is TLS_DHE_PSK_WITH_AES_256_CBC_SHA384
SSL DH size is 2048 bits
I hear you fa shizzle!
total Allocs = 41
total Deallocs = 41
total Bytes = 11123
peak Bytes = 9763
current Bytes = 0
---------------------------------------------------
testing cipher suite DHE-PSK-AES128-CBC-SHA256 -s
SSL version is TLSv1.2
SSL cipher suite is TLS_DHE_PSK_WITH_AES_128_CBC_SHA256
SSL DH size is 2048 bits
Client message: hello wolfssl!
total Allocs = 36
total Deallocs = 36
total Bytes = 14270
peak Bytes = 8595
current Bytes = 0
SSL version is TLSv1.2
SSL cipher suite is TLS_DHE_PSK_WITH_AES_128_CBC_SHA256
SSL DH size is 2048 bits
I hear you fa shizzle!
total Allocs = 41
total Deallocs = 41
total Bytes = 11107
peak Bytes = 9763
current Bytes = 0
---------------------------------------------------
testing cipher suite DHE-RSA-AES128-GCM-SHA256
SSL version is TLSv1.2
SSL cipher suite is TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
SSL DH size is 2048 bits
Client message: hello wolfssl!
total Allocs = 57
total Deallocs = 57
total Bytes = 50061
peak Bytes = 23544
current Bytes = 0
SSL version is TLSv1.2
SSL cipher suite is TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
SSL DH size is 2048 bits
I hear you fa shizzle!
total Allocs = 92
total Deallocs = 92
total Bytes = 64959
peak Bytes = 24343
current Bytes = 0
---------------------------------------------------
testing cipher suite DHE-RSA-AES256-GCM-SHA384
SSL version is TLSv1.2
SSL cipher suite is TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
SSL DH size is 2048 bits
Client message: hello wolfssl!
total Allocs = 57
total Deallocs = 57
total Bytes = 50061
peak Bytes = 23544
current Bytes = 0
SSL version is TLSv1.2
SSL cipher suite is TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
SSL DH size is 2048 bits
I hear you fa shizzle!
total Allocs = 92
total Deallocs = 92
total Bytes = 64959
peak Bytes = 24343
current Bytes = 0
---------------------------------------------------
testing cipher suite ECDHE-RSA-AES128-GCM-SHA256
SSL version is TLSv1.2
SSL cipher suite is TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
SSL curve name is SECP256R1
Client message: hello wolfssl!
total Allocs = 74
total Deallocs = 74
total Bytes = 86151
peak Bytes = 35345
current Bytes = 0
SSL version is TLSv1.2
SSL cipher suite is TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
SSL curve name is SECP256R1
I hear you fa shizzle!
total Allocs = 99
total Deallocs = 99
total Bytes = 102834
peak Bytes = 46123
current Bytes = 0
---------------------------------------------------
testing cipher suite ECDHE-RSA-AES256-GCM-SHA384
SSL version is TLSv1.2
SSL cipher suite is TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
SSL curve name is SECP256R1
I hear you fa shizzle!
total Allocs = 99
total Deallocs = 99
total Bytes = 102834
peak Bytes = 46123
current Bytes = 0
SSL version is TLSv1.2
SSL cipher suite is TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
SSL curve name is SECP256R1
Client message: hello wolfssl!
total Allocs = 74
total Deallocs = 74
total Bytes = 86151
peak Bytes = 35345
current Bytes = 0
---------------------------------------------------
testing cipher suite ECDHE-RSA-AES128-SHA256
SSL version is TLSv1.2
SSL cipher suite is TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
SSL curve name is SECP256R1
Client message: hello wolfssl!
total Allocs = 70
total Deallocs = 70
total Bytes = 86127
peak Bytes = 35345
current Bytes = 0
SSL version is TLSv1.2
SSL cipher suite is TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
SSL curve name is SECP256R1
I hear you fa shizzle!
total Allocs = 95
total Deallocs = 95
total Bytes = 102817
peak Bytes = 46123
current Bytes = 0
---------------------------------------------------
testing cipher suite ECDHE-RSA-AES256-SHA384
SSL version is TLSv1.2
SSL cipher suite is TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
SSL curve name is SECP256R1
Client message: hello wolfssl!
total Allocs = 71
total Deallocs = 71
total Bytes = 86239
peak Bytes = 35345
current Bytes = 0
SSL version is TLSv1.2
SSL cipher suite is TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
SSL curve name is SECP256R1
I hear you fa shizzle!
total Allocs = 95
total Deallocs = 95
total Bytes = 102833
peak Bytes = 46123
current Bytes = 0
---------------------------------------------------
testing cipher suite ECDHE-RSA-CHACHA20-POLY1305
SSL version is TLSv1.2
SSL cipher suite is TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
SSL curve name is SECP256R1
Client message: hello wolfssl!
total Allocs = 71
total Deallocs = 71
total Bytes = 85709
peak Bytes = 35345
current Bytes = 0
SSL version is TLSv1.2
SSL cipher suite is TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
SSL curve name is SECP256R1
I hear you fa shizzle!
total Allocs = 96
total Deallocs = 96
total Bytes = 102392
peak Bytes = 46123
current Bytes = 0
---------------------------------------------------
testing cipher suite ECDHE-RSA-CHACHA20-POLY1305-OLD
SSL version is TLSv1.2
SSL cipher suite is TLS_ECDHE_RSA_WITH_CHACHA20_OLD_POLY1305_SHA256
SSL curve name is SECP256R1
I hear you fa shizzle!
total Allocs = 96
total Deallocs = 96
total Bytes = 102392
peak Bytes = 46123
current Bytes = 0
SSL version is TLSv1.2
SSL cipher suite is TLS_ECDHE_RSA_WITH_CHACHA20_OLD_POLY1305_SHA256
SSL curve name is SECP256R1
Client message: hello wolfssl!
total Allocs = 71
total Deallocs = 71
total Bytes = 85709
peak Bytes = 35345
current Bytes = 0
---------------------------------------------------
testing cipher suite DHE-RSA-CHACHA20-POLY1305-OLD
SSL version is TLSv1.2
SSL cipher suite is TLS_DHE_RSA_WITH_CHACHA20_OLD_POLY1305_SHA256
SSL DH size is 2048 bits
Client message: hello wolfssl!
total Allocs = 63
total Deallocs = 63
total Bytes = 49819
peak Bytes = 23744
current Bytes = 0
SSL version is TLSv1.2
SSL cipher suite is TLS_DHE_RSA_WITH_CHACHA20_OLD_POLY1305_SHA256
SSL DH size is 2048 bits
I hear you fa shizzle!
total Allocs = 89
total Deallocs = 89
total Bytes = 64547
peak Bytes = 24343
current Bytes = 0
---------------------------------------------------
testing cipher suite ECDHE-PSK-AES128-CBC-SHA256 -s
SSL version is TLSv1.2
SSL cipher suite is TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA256
SSL curve name is SECP256R1
Client message: hello wolfssl!
total Allocs = 54
total Deallocs = 54
total Bytes = 50880
peak Bytes = 30820
current Bytes = 0
SSL version is TLSv1.2
SSL cipher suite is TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA256
SSL curve name is SECP256R1
I hear you fa shizzle!
total Allocs = 48
total Deallocs = 48
total Bytes = 48982
peak Bytes = 31076
current Bytes = 0
---------------------------------------------------
testing cipher suite PSK-CHACHA20-POLY1305 -s
SSL version is TLSv1.2
SSL cipher suite is TLS_PSK_WITH_CHACHA20_POLY1305_SHA256
Client message: hello wolfssl!
total Allocs = 41
total Deallocs = 41
total Bytes = 8338
peak Bytes = 7079
current Bytes = 0
SSL version is TLSv1.2
SSL cipher suite is TLS_PSK_WITH_CHACHA20_POLY1305_SHA256
I hear you fa shizzle!
total Allocs = 36
total Deallocs = 36
total Bytes = 6691
peak Bytes = 5850
current Bytes = 0
---------------------------------------------------
testing cipher suite ECDHE-PSK-CHACHA20-POLY1305 -s
SSL version is TLSv1.2
SSL cipher suite is TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256
SSL curve name is SECP256R1
Client message: hello wolfssl!
total Allocs = 55
total Deallocs = 55
total Bytes = 50462
peak Bytes = 30820
current Bytes = 0
SSL version is TLSv1.2
SSL cipher suite is TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256
SSL curve name is SECP256R1
I hear you fa shizzle!
total Allocs = 49
total Deallocs = 49
total Bytes = 48557
peak Bytes = 31076
current Bytes = 0
---------------------------------------------------
testing cipher suite DHE-PSK-CHACHA20-POLY1305 -s
SSL version is TLSv1.2
SSL cipher suite is TLS_DHE_PSK_WITH_CHACHA20_POLY1305_SHA256
SSL DH size is 2048 bits
Client message: hello wolfssl!
total Allocs = 46
total Deallocs = 46
total Bytes = 14052
peak Bytes = 8795
current Bytes = 0
SSL version is TLSv1.2
SSL cipher suite is TLS_DHE_PSK_WITH_CHACHA20_POLY1305_SHA256
SSL DH size is 2048 bits
I hear you fa shizzle!
total Allocs = 42
total Deallocs = 42
total Bytes = 10712
peak Bytes = 9763
current Bytes = 0Hi ajay,
VERY INTERESTING!
Ok first the fix, then the details. Since you are building on a 32-bit system ECC is disabled by default so only DHE_RSA cipher suites are on by default.
The short-term solution is to do this:
git clone <wolfssl>
cd wolfssl
./autogen.sh
./configure --enable-ecc
make
./examples/client/client -h device.instamsg.io -p 8883 -x -d -gDetails:
Ok so after doing some more tests against that endpoint here's what I've found.
If you use a DHE_RSA cipher suite rather than sending back a "Server Hello Done" message at the end of the handshake, that endpoint responds with this plaintext message.
use only10UVeriSign Trust NetworkN0L10 UFR10U
KEYNECTIS1
0UROOT10UKEYNECTIS ROOT CASo wolfSSL, which is looking for a TLS packet that is encoded as the SERVER HELLO DONE message, thinks it is a malformed message. Even though it is plaintext the TLS record indicates it is an "Encrypted Hanshake Message" which is in fact technically a malformed buffer at that point in the handshake so the error is correct.
The reason openSSL s_client is able to recover from this is some form of renegotiation. We see the following:
WOLFSSL - reports error at this point and aborts the connection
OPENSSL - Sees strange packet and re-sends Certificate, Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message all over again.
device.instamsg.io replies to this with - Change Cipher Spec, Hello Request, Hello Request (These are "finished" messages).
If instead we connect to that end-point with an ECDHE_RSA cipher suite (instead of DHE_RSA) then everything is normal. We are unsure why that end-point is failing to send a SERVER HELLO DONE, our best guess would be an implementation bug of some sort except that it is a plain text message so it seems to have a purpose.
It is almost as if this is a custom protocol similar to start-TLS or something along those lines where the plain text message has some design behind it. OpenSSL either supports this custom protocol or is able to get around it by doing some sort of re-negotiation.
You stated this is a proprietary server of yours so perhaps you can shed some light on the matter. Can you explain what this replacement message is for the SERVER HELLO DONE message and what it's purpose might be?
For your use I am attaching two wireshark traces showing our findings.
This is the openSSL command we used for testing:
openssl s_client -connect device.instamsg.io:8883 -cipher DHE-RSA-AES128-GCM-SHA256Everything will work fine with an ECDHE cipher suite, it's only the DHE cipher suites that are behaving abnormally in a manner we do not yet support.
Warmest Regards,
Kaleb
Hi fvillaf,
No problem as far as the NDA goes. Glad to hear the solution worked for you!
Let us know if anything else comes up.
Warm Regards,
Kaleb
Hi ajay,
Could you tell me which configuration you are using when building wolfSSL? Also can you confirm if I am getting routed to the correct IP: 104.130.68.125
Here are the tests I ran quickly:
ping device.instamsg.io
PING device.instamsg.io (104.130.68.125): 56 data bytes$ nmap -Pn --script ssl-enum-ciphers -p 8883 device.instamsg.io
Starting Nmap 7.60 ( https://nmap.org ) at 2017-11-21 12:02 MST
Nmap scan report for device.instamsg.io (104.130.68.125)
Host is up (0.064s latency).
PORT STATE SERVICE
8883/tcp open secure-mqtt
| ssl-enum-ciphers:
| TLSv1.0:
| ciphers:
| TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 1024) - D
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 1024) - A
| TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (secp160k1) - D
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp160k1) - A
| TLS_ECDHE_RSA_WITH_RC4_128_SHA (secp160k1) - D
| TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
| TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_RC4_128_MD5 (rsa 2048) - C
| TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - C
| compressors:
| NULL
| cipher preference: client
| warnings:
| 64-bit block cipher 3DES vulnerable to SWEET32 attack
| Broken cipher RC4 is deprecated by RFC 7465
| Ciphersuite uses MD5 for message integrity
| Key exchange (dh 1024) of lower strength than certificate key
| Key exchange (secp160k1) of lower strength than certificate key
| TLSv1.1:
| ciphers:
| TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 1024) - D
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 1024) - A
| TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (secp160k1) - D
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp160k1) - A
| TLS_ECDHE_RSA_WITH_RC4_128_SHA (secp160k1) - D
| TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
| TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_RC4_128_MD5 (rsa 2048) - C
| TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - C
| compressors:
| NULL
| cipher preference: client
| warnings:
| 64-bit block cipher 3DES vulnerable to SWEET32 attack
| Broken cipher RC4 is deprecated by RFC 7465
| Ciphersuite uses MD5 for message integrity
| Key exchange (dh 1024) of lower strength than certificate key
| Key exchange (secp160k1) of lower strength than certificate key
| TLSv1.2:
| ciphers:
| TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 1024) - D
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 1024) - A
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (dh 1024) - A
| TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 1024) - A
| TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (secp160k1) - D
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp160k1) - A
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp160k1) - A
| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp160k1) - A
| TLS_ECDHE_RSA_WITH_RC4_128_SHA (secp160k1) - D
| TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
| TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 2048) - A
| TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A
| TLS_RSA_WITH_RC4_128_MD5 (rsa 2048) - C
| TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - C
| compressors:
| NULL
| cipher preference: client
| warnings:
| 64-bit block cipher 3DES vulnerable to SWEET32 attack
| Broken cipher RC4 is deprecated by RFC 7465
| Ciphersuite uses MD5 for message integrity
| Key exchange (dh 1024) of lower strength than certificate key
| Key exchange (secp160k1) of lower strength than certificate key
|_ least strength: D
Nmap done: 1 IP address (1 host up) scanned in 72.66 seconds$ git clone https://github.com/wolfssl/wolfssl.git
$ cd wolfssl
$ ./autogen.sh
$ ./configure
$ make
$ ./examples/client/client -h device.instamsg.io -p 8883 -x -d -g
SSL version is TLSv1.2
SSL cipher suite is TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
SSL curve name is SECP160R1
SSL connect ok, sending GET...
(Eventually times out as it appears that server doesn't actually return anything but the connection was successful)
SSL_read reply error 6, peer sent close notify alert
wolfSSL error: SSL_read failedWarm Regards,
Kaleb
Hi fvillaf,
Thank you for using the wolfSSL support forums. If you perform a search in the file <wolf-root>/wolfcrypt/src/rsa.c for the define HAVE_CAVIUM you will see how we went about adding support for the CAVIUM hardware RSA API calls. We would recommend one of two methods when adding support for hardware crypto:
#1 Add your own new pre-processor macro such as HAVE_VAULTIC405 and #ifndef out the wc_Rsa... API's you wish to replace.
Create a new directory such as <wolf-root>/wolfcrypt/src/port/vaultic405
Create a new file such as <wolf-root>/wolfcrypt/src/port/vaultic405/vaultic-rsa.c
Implement your own version of the wc_Rsa... API's that you #ifndef'd out and have these API's call to the hardware directly.
#2 Add your own new pre-processor macro such as HAVE_VAULTIC405 and
follow the method we used with HAVE_CAVIUM define and place the hardware API calls directly into wolfcrypt/src/rsa.c
We have used #2 in the past but as we add support for more devices we have started to abstract that support by using the <wolf-root>/wolfcrypt/src/port/<new device> setup as it is cleaner and easier to maintain. Also if you do this solution then every time we put out a new release you would simply have to add back in the select few #ifndef HAVE_VAULTIC405 rules to rsa.c and then copy/paste your port directory into the new release. You can also submit your work back to us under a contributor agreement if you wish for us to maintain your port through release cycles.
Let us know if you have any questions on this.
Warm Regards,
Kaleb
Hi ajay,
You said:
wolfSSL_CTX_set_verify(ssl, SSL_VERIFY_NONE, 0);I can't see your source code but that indicated you may have called a wolfSSL_CTX api with an SSL object and NOT a ctx object. Also that should be called prior to the SSL object creation.
We would expect to see:
wolfSSL_CTX_set_verify(ctx, SSL_VERIFY_NONE, 0);here instead.
Best Regards,
- K
Being handled via support@wolfssl.com will post an update here once resolution is identified.
- Kaleb
Hi Ravi,
Could you please contact Rich Kelm (rich@wolfssl.com) to move this inquiry forward?
Warm Regards,
Kaleb
Hi Shuangc,
I see. I would recommend just placing wolfSSL in your working directory if that is the case. This will be the easiest solution. The other quick solution would be to download the examples from https://github.com/wolfssl/wolfssl-examples.git and build/run those instead.
See <wolfssl-examples>/tls/ directory for TLS client/server examples.
Warm Regards,
Kaleb
Hi Shuangc,
Could you explain the reasoning behind this?
Our default examples are not designed to be used in this way and would require several factorizations to get it working. We have examples that do NOT have a location dependency at https://github.com/wolfssl/wolfssl-examples.git if that would be better for you.
Another solution would be to
mv wolfssl/ /home/xx/temp
cd /home/xx/temp/wolfssl
./examples/client/client <args>Warm Regards,
Kaleb
Hi Ravi,
The log did not come through. Could you please try to resend it?
- Kaleb
Hi muyouyuwan,
Yes wolfSSL uses the system time to check the validity date. Please set your system clock to todays date to validate a certificate.
Warm Regards,
Kaleb
Hi cxdinter,
I just opened the pull request which you are free to reference. I'm just waiting for a peer review to merge it into our examples master repo.
https://github.com/wolfSSL/wolfssl-examples/pull/80
Warmest Regards,
Kaleb
Hi ravi.kumar,
If you copied your commands into the question as you entered them then that would explain the issue, please use a colon delimited list like below:
khimes$ ./examples/server/server -v 4 -l TLS13-AES128-GCM-SHA256:TLS13-AES256-GCM-SHA384 &
[1] 6563
khimes$ ./examples/client/client -v 4 -l TLS13-AES128-GCM-SHA256:TLS13-AES256-GCM-SHA384
SSL version is TLSv1.3
SSL cipher suite is TLS_AES_128_GCM_SHA256
SSL curve name is SECP256R1
SSL version is TLSv1.3
SSL cipher suite is TLS_AES_128_GCM_SHA256
SSL curve name is SECP256R1
Client message: hello wolfssl!
I hear you fa shizzle!
[1]+ Done ./examples/server/server -v 4 -l TLS13-AES128-GCM-SHA256:TLS13-AES256-GCM-SHA384Also if you were using a colon dilimited list did you make sure to first configure wolfSSL with the correct settings:
./configure --enable-tls13 && makeWarm Regards,
Kaleb
Hi cxdinter,
I see! Since the input will always be a fixed length (AES KEY SIZE). Then what you are asking for is entirely possible with wolfSSL. The API name may be misleading but if you were to use:
wc_RsaSSL_Sign = RsaPrivateEncrypt without hashing, just padding.
Then on the other end:
wc_RsaSSL_Verify = RsaPublicDecrypt without hash, will do the un-pad for you.
In this way you could use RsaSSL_Sign to encrypt the AES key and RsaSSL_Verify to decrypt the aes key when it arrives on the target device for firmware update.
Due to this question I am working on an example that I will try to get up on github soon. I will push it to here: https://github.com/wolfssl/wolfssl-examples.git
Let me know if you have any questions on that!
Warmest Regards,
Kaleb
Hi cxdinter,
While possible due to the math, this is entirely impractical in practice. This functionality is not supported by wolfSSL so it is expected that you would not find API's such as "wc_RsaPrivateEncrypt" and "wc_RsaPublicDecrypt".
The reason we SIGN and do not ENCRYPT data with RSA is because we can first HASH the input to a fixed length and then pad it to the expected input length for the given RSA key size. The way the RSA algorithm works, your key must be as long as the data being encrypted so if you wanted to encrypt a file that was 1GB you would need to generate a 1 GigaByte RSA key!
Then if you wanted to encrypt the next item and it was 500KB you would need to generate a brand new RSA key that was only 500 KB long OR pad out your input file/data to 1GB in order to use your previously generate private key of 1GB.
You would end up in either a scenario with a ridiculous number of private/public key pairs that would need to be maintained in order to decrypt your data in the future OR if you failed to maintain those keys you would end up with a bunch of encrypted data that could never be decrypted.
If instead you SIGN the data by first hashing it to a fixed length and then padding to an expected length you can re-use the same RSA key pair for everything that needs SIGNED.
Can you explain what it is you are attempting to accomplish? Perhaps there is a better way to do it or a better algorithm to use for encrypting your data rather than RSA?
Warm Regards,
Kaleb
Hi gussabina,
This error typically stems from the FP_MAX_BITS not being set large enough. Since the fast math library uses STACK we hard code that value for a fixed length buffer. By default it is set to 4096 which will allow for up to a 2048-bit rsa key (RSA KEY SIZE * 2). My suspicion is that the endpoint you are connecting to is sending a larger RSA key, perhaps a 4096-bit RSA key. Could you try adding this to your settings:
#undef FP_MAX_BITS
#define FP_MAX_BITS 8192 /* Set to largest RSA key size times 2 IE 4096*2 = 8192 */Does that resolve the issue?
Warmest Regards,
Kaleb
Hi AEL,
I see you are working with Bluetooth.
First I will address your question but then I would like to suggest an alternate approach for your consideration.
For the DHAgree you will want to look at the API's
wc_DhAgreeExcerpt from our manual chapter 10 here: https://www.wolfssl.com/docs/wolfssl-manual/ch10/
After sideB sends their public key (pubB) to sideA, sideA can then generate the mutually-agreed key(agreeA) using the wc_DhAgree() function.
wc_DhAgree(&dhPublicKey, agreeA, &agreeASz, privA, privASz,
pubB, pubBSz);OK. Now for something to consider.
When working with bluetooth you can easily take advantage of the TLS functionality completely. wolfSSL has implemented an I/O abstraction layer that allows for plug and play of any I/O medium. We have examples of doing TLS connections in memory, through files on a PC, over a USB Serial connection, and we have even done Bluetooth solutions for some of our customers through our consulting service. If you would prefer to take the route of using straight up TLS in place of the Bluetooth specs please let me know and I'd be happy to shed some more light on registering a custom send/receive callback to allow for using TLS over bluetooth.
Warm Regards,
Kaleb
Hi dragem,
the RSA_BUFFER_E description is: RSA buffer error, output too small OR input too large!
The signature is hashed to a fixed length using one of the hashing algorithms. If you are using SHA-256 for example you would want to set output_len to 256.
We have done this intentionally (forced user to use exact length) to prevent buffer over-flows or underflows.
Warmest Regards,
Kaleb
Hi uzairo89,
Whenever you use hardware over software you can expect significant performance increases. Have you had a chance to review our benchmarking page here:https://www.wolfssl.com/docs/benchmarks/
You can see for example on the STM32F2 (which has onboard acceleration like the STM32F437 but unlike the STM32F427):
Software Crypto: wolfCrypt Benchmark, Normal Big Integer Math Library
AES 1024 kB took 0.822 seconds, 1.22 MB/s
STM32F2 Hardware Crypto: wolfCrypt Benchmark, Normal Big Integer Math Library
AES 1024 kB took 0.105 seconds, 9.52 MB/sHave you also considered using the STM32F437 that has on-board acceleration?
The STM32F437 also integrates a crypto/hash processor providing hardware acceleration for AES-128, -192 and -256, with support for GCM, CCM, Triple DES, and hash (MD5, SHA-1 and SHA-2)
REFERENCE: http://www.st.com/en/microcontrollers/s … tId=LN1789
You asked specifically about setup time and resources freed up on the main MCU, If you were to use the ATECC508A AND you were using ECC based cipher suites then absolutely you could expect speed up in connection time and also reduced run-time memory as the ECC keys could be offloaded to the key store in the ATECC508A module.
wolfSSL has not yet added support for the ATSHA204 module but that is something we could do. If that is something you would like to see added I would encourage you to shoot an email to rod@wolfssl.com or rich@wolfssl.com to discuss how that might be achieved!
Warmest Regards,
Kaleb
Hi sanjay,
Could you tell us a little about the project you are working on? Is this an old solution you are bringing up to date or is this a new project?
Warm Regards,
Kaleb
Hi Guit,
While we wait to hear back from you on the port number could you tell us a little more about the project you are working on and the need your solution will address? Is this a new project or an update to an old project?
If we can better understand your use-case and end goals we can likely point to the best source of documentation to assist you in getting up and running more smoothly!
Warm Regards,
Kaleb
Hi Sanjay,
Could you send us your test code so we can see what the issue might be.
Also as a note the certs you sent required me to test this with
-A ./certtest/CA_Root.pem. Comodo_Root.pem was not present as your command showed.
Warm Regards,
Kaleb
wolfSSL - Embedded SSL Library → Posts by Kaleb J. Himes
Powered by PunBB, supported by Informer Technologies, Inc.
Generated in 0.027 seconds (59% PHP - 41% DB) with 5 queries