751 Reply by Kaleb J. Himes

(2 replies, posted in wolfSSL)

Hi again blink,

Upon further discussion we've realized what you accomplished by modifying our values. By changing those pre-defined values that define a specific Elliptic Curve you have in fact invented your own custom Elliptic Curve that works with itself however will not be interoperable with anyone else using ECC as they will not be using the same Elliptic Curve that you are.

Essentially you have created a bug that will be exposed between yourself and any other version of ECC out there, but you will never see an error in local testing as the bug exists internally in your library and therefore is picked up by any program using that library.

I hope this helps you understand the results you were seeing.

Kind Regards,

Kaleb

Go to forum: wolfSSL

752 Reply by Kaleb J. Himes

(4 replies, posted in wolfSSL)

Hi again ciruzzo,

Just as a follow up we are curious what your project entails. We ask because DTLS is a beast in and of it's own. Furthermore multi-threading in DTLS is a problem not easily solved. It has peaked both mine, and others interests here at wolfSSL and we'd enjoy further information regarding your project motivation.

Kind Regards,

Kaleb

Go to forum: wolfSSL

753 Reply by Kaleb J. Himes

(4 replies, posted in wolfSSL)

Hi ciruzzo,

I am currently exploring what the issue might be here. If windows does not support SO_REUSEPORT have you considered using the client-dtls-nonblocking in conjunction with the normal server-dtls?

The reason I ask is the non-blocking client will continue to attempt to write until it succeeds and the normal server-dtls runs in an infinite loop just watching for messages on the open socket. Due to the nature of DTLS potentially infinite clients could connect to the server-dtls and send a message/get a response from the server. The server would eventually get the Datagrams out of the file descriptor when it looped back around and handle each request in turn.

Kind Regards,

Kaleb

Go to forum: wolfSSL

754 Reply by Kaleb J. Himes

(2 replies, posted in wolfSSL)

Good Morning blink,

If that is the case it is indeed something we want to narrow down. Is there any way you could send us a list of your configure options (<wolfssl_root>/wolfssl/options.h) and where in the code you are modifying the values. Has your testing shown that modifying them in "one place only" gives these results or modifying in many different locations gives these results. How are you modifying them etc.

I ask because there are multiple ways of modifying them:

1. through importing with the pre-processor definition HAVE_COMP_KEY turned on

2. Manually changing the values in ecc.c where you mentioned const ecc_set_type ecc_sets[] however modifying in only one place may be wrapped in an #ifdef that is actually not defined therefore appearing to not influence the results when in fact that code is not getting compiled. Thus the request for your options.h

3. By hard coding them in ecc.h where they would be overwritten with the intended values at run-time.


More specifics would be highly helpful in exploring this behavior. Thank you so much for your post. I look forward to working with you to narrow this down.

Kind Regards,

Kaleb

Go to forum: wolfSSL

755 Reply by Kaleb J. Himes

(1 replies, posted in wolfCrypt)

1. Ok so you have a public/private key pair. Notice in my response to your other question I mentioned chapter 7 of the manual. If you reference chapter 7.7.1 you'll see we currently have no way of storing the public key separate from the private key (as there is no agreed upon specification for doing this).

2. Moving on to section 7.8 we do support certificate Generation. The format you are looking for to send to your peer is in the form of an X.509 certificate. Chapter 7 Section 8 will guide you through generating a Certificate using the RSA key structure you just created.

3. Extracting the public key from the X.509 certificate can be accomplished with RsaPublicKeyDecode() as mentioned in 7.7.1 in reference to loading a public key.
an example:

wc_RsaPublicKeyDecode(cert.publicKey, &idx, &pubKey, cert.pubKeySize);

where cert.publicKey is the public RSA Key you want to get from your embedded platform to your peer.

4. Your assumptions are correct.

For further Documentation see:
http://wolfssl.com/wolfSSL/Docs-wolfssl-manual-toc.html

Go to forum: wolfCrypt

756 Reply by Kaleb J. Himes

(1 replies, posted in wolfCrypt)

Hi lk,

The following link is to our wolfssl users manual. Chapter seven talks about certificates and key generation. Specifically Chapter 7 section 7 (7.7) directly addresses your concerns regarding RSA keys.

http://wolfssl.com/wolfSSL/Docs-wolfssl … cates.html

Example code of generating the "der":


byte der[4096];
int  derSz = RsaKeyToDer(&genKey, der, sizeof(der));
if (derSz < 0)
   /* derSz contains error */;

The buffer der now holds a DER format of the key.

Go to forum: wolfCrypt

757 Reply by Kaleb J. Himes

(1 replies, posted in wolfSSL)

Hi nesnub,

I recently (Mar 18) went through and fixed several issues with the Visual Studio Solutions.

I also was compiling in VisualStudio 2013. I identified the following issue that may help out in your case:

Known Issues: When porting our .sln project file to a version of VS 2012 or later a dialog will appear after a
"One-Way Upgrade" Notification. If the user selects "YES" here our property sheet will be over-written with one that
will enable SAFESEH and also enable EDITANDCONTINUE even though these two settings are not compatible.
I have added a setting in our property sheet to disable SAFESEH and we will get a no-warnings build if the user
selects "no" on this option.

NO_PSK also was not set in the flags which was breaking each solution we had.
See: https://github.com/wolfSSL/wolfssl/comm … 642623fb32
These fixes will be in the next stable release 3.4.6 however were not in previous releases.

For the current development head you can always reference https://github.com/wolfSSL/wolfssl.

If these fixes do not help you on your project please do not hesitate to respond here or email me kaleb@wolfssl.com. I will try to assist you in getting your project going.

Go to forum: wolfSSL

758 Topic by Kaleb J. Himes

(0 replies, posted in Announcements)

Friday, August 15, 2014

CyaSSL now has example projects that can be compiled in Code Composer Studio (CCS) and debugged on the Tiva™ C Series TM4C1294NCPDT (1294XL) Connected Launchpad. Please see the README under wolfSSL / wolfssl-examples / tirtos_ccs_examples on www.github.com for instructions on building CyaSSL with Texas Instruments-Real Time Operating System (TI-RTOS). Please visit http://www.ti.com/tool/sw-tm4c for all other things Tiva C.

For questions or comments, please email us at info@wolfssl.com.

Go to forum: Announcements