1 Reply by Jacob

(5 replies, posted in wolfSSL)

Old forum thread... but for anyone coming here looking for OpenCL support, we recently added in some support in this github pull request (https://github.com/wolfSSL/wolfssl/pull/7436). david.ruiz if you still have the pet project going please give that a shot.

Go to forum: wolfSSL

2 Reply by Jacob

(3 replies, posted in wolfCrypt)

Hi Iycboy,

Eric is correct that, the public key portion is necessary in addition to the private key for signing. Just as a side note though you can generate the public portion given the private portion of the key. Check out the API wc_ed25519_make_public and wc_ed25519_import_public.

The question is if we should be trying to do this automatically in wolfSSL given a sign request where the public portion of the key is not set, just the private key. Will discuss that internally, in the mean time though generating and importing the public key is how you could avoid having to send / store the public key portion. Or if you could send /store the public key portion with the private key then altering the DER being passed to wc_Ed25519PrivateKeyDecode to also contain the public key would avoid the public key generation step.

Regards,
Jacob

Go to forum: wolfCrypt

3 Reply by Jacob

(15 replies, posted in wolfSSL)

Hi Scott,

Will forward the thread on to the support channel (support@wolfssl.com) using the 'user' email we have register to you on the forums here. That way we can be sure to handle it in a timely manner under the support contract and provide any optimization settings support specific to the use case.

Regards,
Jacob

Go to forum: wolfSSL

4 Reply by Jacob

(15 replies, posted in wolfSSL)

Not sure, maybe OpenSSL key generation on Windows is just slow.....

Mac i7 with wolfSSL does around 6 generations per second for an average of 178.508 ms per generations. Without disabling any safe guards.

./wolfcrypt/benchmark/benchmark
...

RSA     2048 key gen         6 ops took 1.071 sec, avg 178.508 ms, 5.602 ops/sec
...

For the 20 seconds on the device there could be multiple factors 32bit vs 64bit for one, have ran into that previously or optimizations with the build flags. We would have to do some optimization investigations under a support contract for faster speeds.

Regards,
Jacob

Go to forum: wolfSSL

5 Reply by Jacob

(15 replies, posted in wolfSSL)

Adding the macros;

#define USE_FAST_MATH
#define TFM_TIMING_RESISTANT
#define WC_RSA_BLINDING
#define ECC_TIMING_RESISTANT

and including wolfcrypt/src/tfm.c in the build should build it.

Regards,
Jacob

Go to forum: wolfSSL

6 Reply by Jacob

(15 replies, posted in wolfSSL)

I don't see any benchmark values internally for the AM3352. We have a benchmark for a Rasperry PI at 1500 MHz with a 2048 bit RSA key generation. It took a little under a second at 700 ms. That was with --enable-fastmath and --enable-sp --enable-sp-asm.

Go to forum: wolfSSL

7 Reply by Jacob

(15 replies, posted in wolfSSL)

Heres the setting broken down into the individual parts for you:


    newCert.beforeDate[0] = ASN_UTC_TIME;
    newCert.beforeDate[1] = ASN_UTC_TIME_SIZE - 1;
    newCert.beforeDate[2] = '2';   //year 2022
    newCert.beforeDate[3] = '2';   //year 2022
    newCert.beforeDate[4] = '0';   //month 02
    newCert.beforeDate[5] = '2';   //month 02
    newCert.beforeDate[6] = '1';   //day 15
    newCert.beforeDate[7] = '5';   //day 15
    newCert.beforeDate[8] = '0';   //hour 06
    newCert.beforeDate[9] = '6';   //hour 06
    newCert.beforeDate[10] = '0';  //minute 00
    newCert.beforeDate[11] = '0';  //minute 00
    newCert.beforeDate[12] = '0';  //second 01
    newCert.beforeDate[13] = '1';  //second 01
    newCert.beforeDate[14] = 'Z';
    newCert.beforeDateSz = 15;

    newCert.afterDate[0] = ASN_UTC_TIME;
    newCert.afterDate[1] = ASN_UTC_TIME_SIZE - 1;
    newCert.afterDate[2] = '2';   //year 2024
    newCert.afterDate[3] = '4';   //year 2024
    newCert.afterDate[4] = '0';   //month 02
    newCert.afterDate[5] = '2';   //month 02
    newCert.afterDate[6] = '1';   //day 15
    newCert.afterDate[7] = '5';   //day 15
    newCert.afterDate[8] = '0';   //hour 06
    newCert.afterDate[9] = '6';   //hour 06
    newCert.afterDate[10] = '0';  //minute 00
    newCert.afterDate[11] = '0';  //minute 00
    newCert.afterDate[12] = '0';  //second 01
    newCert.afterDate[13] = '1';  //second 01
    newCert.afterDate[14] = 'Z';
    newCert.afterDateSz = 15;

Having set the before and after you can remove the set of dayValid.

Regards,
Jacob

Go to forum: wolfSSL

8 Reply by Jacob

(15 replies, posted in wolfSSL)

Hi Scotty2541,

The function wc_SetDatesBuffer takes in a DER formatted certificate to use the date from it.

There is two main options for setting the date:

1) Set it directly in the Cert structure using the current API's you have listed. This is setting beforeDate, beforeDateSz, afterDate, afterDateSz, daysValid.

2) Use the compatibility layer APIs and create the certificate using WOLFSSL_X509 structure. This has the API's wolfSSL_X509_set_notBefore and wolfSSL_X509_set_notAfter. The function test_wolfSSL_X509_sign2 in tests/api.c has code testing the setting of a certificate date when creating it.

Regards,
Jacob

Go to forum: wolfSSL

9 Reply by Jacob

(11 replies, posted in General Inquiries)

Here is an example of static rsa build and use with wolfssl-py.

mkdir test && cd test
git clone --depth=1 git@github.com:wolfssl/wolfssl-py.git
git clone --depth=1 git@github.com:wolfssl/wolfssl.git

cd wolfssl
./autogen.sh && ./configure CPPFLAGS=-DWOLFSSL_STATIC_RSA --enable-sni --enable-opensslextra --enable-opensslall --enable-debug --prefix=`pwd`/../wolfssl-install && make && make install

cd ../wolfssl-py
USE_LOCAL_WOLFSSL=`pwd`/../wolfssl-install/ pip install .
export LD_LIBRARY_PATH=`pwd`/../wolfssl-install/lib
python3 ./examples/server.py -l AES256-SHA256

Regards,
Jacob

Go to forum: General Inquiries

10 Reply by Jacob

(2 replies, posted in wolfSSL)

Hi Donnie.dump,

Can you tell us some about the background of how wolfSSL is being used? If the details can not be put on a public forum like this please contact us through support @ wolfssl.com.

wolfSSL natively does support unnammed and custom curves when compiled with ./configure --enable-ecccustcurves. The JSSE wrapper does not support custom curves though.

Regards,
Jacob

Go to forum: wolfSSL

11 Reply by Jacob

(11 replies, posted in General Inquiries)

Please double check that wolfSSL was built with static RSA suites enabled. To do this run the example client bundled with wolfSSL with -e "./examples/client/client -e". One of the cipher suites output should be AES256-SHA. It's easy to get a typo on the macro or any number of other things that would cause wolfSSL to build but not include the static RSA cipher suites.

Go to forum: General Inquiries

12 Reply by Jacob

(11 replies, posted in General Inquiries)

The wolfssl-py if being used looks at the default location of /usr/local when built by running "pip install". A couple ways to go about it would be to install wolfSSL at that default location having been compiled with the static RSA macro or to build wolfssl-py using the environment variable USE_LOCAL_WOLFSSL=/wherever/wolfssl/install/is/

To build wolfSSL with static RSA enabled go to the wolfSSL directory "cd wolfssl/" and run "./configure CPPFLAGS=-DWOLFSSL_STATIC_RSA --prefix=/wherever/wolfssl/install/is/  && make install".

Regards,
Jacob

Go to forum: General Inquiries

13 Reply by Jacob

(11 replies, posted in General Inquiries)

Hello DLLegend,

At a certain version of wolfSSL static RSA cipher suites were disabled by default. The cipher suite TLS_RSA_WITH_AES_256_CBC_SHA is going to be less secure then those using ephemeral keys like TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384. To turn static cipher suite support on use the macro WOLFSSL_STATIC_RSA. If adding that macro to the build does not resolve the issue then send of the build options being used with wolfSSL and we can debug farther.

Warm Regards,
Jacob

Go to forum: General Inquiries

14 Reply by Jacob

(1 replies, posted in wolfSSL)

The main wolfSSL library will need compiled with SNI and Supported curves enabled. If adding in the functions enc_wolfSSL_CTX_UseSupportedCurve and enc_wolfSSL_set_SNI it looks like by default those are off with the library build and the example. SNI is enabled with the HAVE_SNI macro and supported curves are enabled with the HAVE_SUPPORTED_CURVES and HAVE_TLS_EXTENSIONS macros.

Regards,
Jacob

Go to forum: wolfSSL

15 Reply by Jacob

(8 replies, posted in wolfCrypt)

Hi Kannan,

Thanks for double checking that. I re-read through the "Purpose" you listed in the first message. It looks like you are concerned for just ECDSA and HASH-DRBG? (note that you will need some form of entropy to seed the HASH-DRBG) These two algorithms do not benefit from xilsecure use of RSA, AES-GCM, and SHA3. To that end lets first try without the macro WOLFSSL_XILINX_CRYPT defined in user_settings.h. A helpful write up with adjusting the user_settings.h is located at "Xilinx/FreeRTOS/README.pdf" in the pull request David sent earlier.

Regards,
Jacob

Go to forum: wolfCrypt

16 Reply by Jacob

(8 replies, posted in wolfCrypt)

Hi Kannan,

Just to double check possible places that could cause the undefined issue. Did you build the BSP after xilsecure was added?

Regards,
Jacob

Go to forum: wolfCrypt

17 Reply by Jacob

(3 replies, posted in wolfSSL)

Hi Andres,

I confirmed what you are seeing by writing a simple test case using the order of function calls listed. This may be a feature gap (being that AES-GCM use with EVP is relatively new and developed for a specific use case) or it's an unintended restriction with AES-GCM use with EVP. It's under further review.

Regards,
Jacob

Go to forum: wolfSSL

18 Reply by Jacob

(1 replies, posted in wolfSSL)

Hi Abbey,

There may be an options.h or some settings in the way. Please try from a fresh directory with the following commands on Linux (plus the one change you did in the Makefile).


(download and unzip wolfssl 4.1.0)
cd wolfssl-4.1.0/IDE/LINUX-SGX
make -f sgx_t_static.mk HAVE_WOLFSSL_TEST=1 HAVE_WOLFSSL_BENCHMARK=1 all
cd ../..

git clone [url]https://github.com/wolfssl/wolfssl-examples[/url]
cd wolfssl-examples/SGX_Linux
#(if SGX_SDK is not already set then)
export SGX_SDK=/opt/intel/sgxsdk
make SGX_MODE=HW SGX_PRERELEASE=1 SGX_WOLFSSL_LIB=../../IDE/LINUX-SGX/ WOLFSSL_ROOT=../../ SGX_DEBUG=0 HAVE_WOLFSSL_TEST=1
./App -t

If the issue persists after a fresh attempt using the above commands let me know and we can dig into it more to debug what is going on.

Regards,
Jacob

Go to forum: wolfSSL

19 Reply by Jacob

(1 replies, posted in wolfSSL)

Hi hzwssl,

The RSA operations can be sped up using --enable-sp and --enable-sp-asm when building wolfSSL. The bulk of the time taken during TLS connections is due to public key operations.

To have packets bundled together the option -f can be used on the example wolfSSL client located at ./examples/client/client

```
-f          Fewer packets/group messages
```

Regards,
Jacob

Go to forum: wolfSSL

20 Reply by Jacob

(1 replies, posted in wolfSSL)

Hi subale255,

X509_sign() is not yet part of the compatibility layer, to get wolfSSL to replace OpenSSL in this case it would require expanding the compatibility layer to support X509_sign(). I'll add the API to our desired feature request list, but that has no start time and could be speed up through consulting or by a contribution. Can you tell us some about the project?

A way around it would be signing a certificate through wolfSSL's native API currently and replacing the call to X509_sign in the project. More info on signing certificates with wolfSSL can be found in chapter 7 of the manual https://www.wolfssl.com/docs/wolfssl-manual/ch7/ and an example of using the native wolfSSL API here https://github.com/wolfSSL/wolfssl-exam … r/certgen.

Regards,
Jacob

Go to forum: wolfSSL

21 Reply by Jacob

(4 replies, posted in wolfSSL)

rrsuj,

As with many programing solutions there is multiple ways to go about it. One thing that may be useful for your case though is the user context provided for the IO callbacks. This can be set with the functions wolfSSL_SetIOReadCtx and wolfSSL_SetIOWriteCtx. When used, the 4th argument (void* ctx) in the callbacks gets set to the pointer passed into the wolfSSL_SetIO*Ctx functions. This could be anything including a structure that has a buffer used for storing extra data.

Regards,
Jacob

Go to forum: wolfSSL

22 Reply by Jacob

(4 replies, posted in wolfSSL)

Hi rrsuj,

How is the client receive callback function set up or is it the default wolfSSL one reading from a TCP/UDP socket?

One thing to check for is that if a callback receive function gets more bytes than what was requested of the callback it needs a mechanism to store the extra bytes for the next call. Unless this is being handled by libxbee3 and the callback is only reading the requested amount. A scenario is wolfSSL requests 5 bytes (for packet header) and the callback ends up reading the whole packet not just the first 5. When wolfSSL calls the receive callback function again it is expecting to get the rest of the packet (everything after the first 5 bytes).

Regards,
Jacob

Go to forum: wolfSSL

23 Reply by Jacob

(1 replies, posted in wolfSSL)

Hi sidsinhad,

Signature algorithm extensions will not be sent if you can use a PSK cipher suite. There is no run time option to disable the signature algorithms extensions completely with non PSK cipher suites. You can though disable some at build time by --disable-rsa (turns off all rsa ones) --disable-ecc (turns off all ecc ones) --disable-sha512 (turns off all SHA 512 ones) --disable-sha (disables all SHA1 ones).

To disable the ec curve extensions wolfSSL can be compiled with --disable-supportedcurves.

Regards,
Jacob

Go to forum: wolfSSL

24 Reply by Jacob

(12 replies, posted in wolfSSL)

Case was handled in more detail through support channel.

Updating the version of IAR IDE used and starting with a fresh copy of wolfSSL 3.15.3 helped resolve the issue.

~Jacob

Go to forum: wolfSSL

25 Reply by Jacob

(12 replies, posted in wolfSSL)

How large is the memory buffer being passed in? Adding --enable-debug to the wolfSSL build and calling wolfSSL_Debugging_ON() at the beginning of your application will print out debug messages. Can you add in the debugging messages to see if the static memory feature is running out of memory? An error message of "ERROR ran out of static memory" will be printed out if no more memory buckets were available.

Regards,
Jacob

Go to forum: wolfSSL