51 Reply by dgarske

(11 replies, posted in wolfCrypt)

Hi Alessandro,

I assume your key size is 2048-bit. The RsaPublicEncrypt uses PKCSV15, so the max input is not the key size. To public encrypt an already padded 256-byte you would want to use `wc_RsaDirect`.

/* Function that does the RSA operation directly with no padding.
 *
 * in       buffer to do operation on
 * inLen    length of input buffer
 * out      buffer to hold results
 * outSz    gets set to size of result buffer. Should be passed in as length
 *          of out buffer. If the pointer "out" is null then outSz gets set to
 *          the expected buffer size needed and LENGTH_ONLY_E gets returned.
 * key      RSA key to use for encrypt/decrypt
 * type     if using private or public key {RSA_PUBLIC_ENCRYPT,
 *          RSA_PUBLIC_DECRYPT, RSA_PRIVATE_ENCRYPT, RSA_PRIVATE_DECRYPT}
 * rng      wolfSSL RNG to use if needed
 *
 * returns size of result on success
 */
int wc_RsaDirect(byte* in, word32 inLen, byte* out, word32* outSz,
        RsaKey* key, int type, WC_RNG* rng);

Thanks,
David Garske, wolfSSL

Go to forum: wolfCrypt

52 Reply by dgarske

(16 replies, posted in wolfTPM)

Hi Grace,

What are you comparing to confirm the key? I would suggest using the public portion of the key to confirm its valid/matching.

If you need to import with a custom see that is supported, see https://github.com/wolfSSL/wolfTPM/blob … l_import.c

Can you share more about your project? Feel free to email support at wolfssl dot com directly if you'd like to take the conversation private.

Thanks,
David Garske, wolfSSL

Go to forum: wolfTPM

53 Reply by dgarske

(3 replies, posted in wolfSSL)

Hi Febin,

That is a generated file. Have you followed the instructions here?
https://github.com/wolfSSL/wolfssl/tree/master/tirtos
https://www.wolfssl.com/documentation/U … I-RTOS.pdf

I recently did build TI-RTOS for a project successfully, but it was difficult getting the packages setup.

I also recently pushed some fixes for the TM4C here: https://github.com/wolfSSL/wolfssl/pull/7018
Those are in the latest v5.6.6 release.

Thanks,
David Garske, wolfSSL

Go to forum: wolfSSL

54 Reply by dgarske

(3 replies, posted in wolfTPM)

Hi Resarf,

Not sure it will help, but there are some Raspberry Pi Pico examples the Japan team put together here: https://github.com/wolfssl-jp/RPi-pico-w

Seems like it would be easy to adapt building wolfTPM on there. I do have a Pi RP2040 and would be happy to help you through getting wolfTPM working on it.

Thanks,
David Garske, wolfSSL

Go to forum: wolfTPM

55 Reply by dgarske

(8 replies, posted in wolfSSL)

Hi Ethan and John,

Its difficult getting the environment setup. Would one of you mind sharing a CCS project with me?

I've got wolfSSL building using the instructions at https://www.wolfssl.com/documentation/U … -RTOS.pdf, but having trouble importing the TLS echo example. I may just end up creating a simple wolfCrypt_test project from scratch.

So far I've pushed my cleanups to: https://github.com/dgarske/wolfssl/tree/ti_aes , however no real fixes in AES GCM yet.

Feel free to email support at wolfssl dot come directly with any examples and reference this forum link.

Thanks,
David Garske, wolfSSL

Go to forum: wolfSSL

56 Reply by dgarske

(8 replies, posted in wolfSSL)

Hi Ethan and John,

Thank you both for the report of the TM4C issues with AES GCM. I've got a TM4C129XL board here and will see if I can reproduce and fix. Hopefully this board has the AES GCM feature (enabled with `WOLFSSL_TI_CRYPT`).

It sounds like the ti-aes.c isn't properly handling the IV.

Thanks,
David Garske, wolfSSL

Go to forum: wolfSSL

57 Reply by dgarske

(3 replies, posted in wolfCrypt)

Hi RCuller,

The input password will need to be padded to block size before being encrypted. The block should still decrypt properly even if you use a larger size. If you can explain how the encryption works it will help us guide you. Hopefully the example will provide some clues.

If you'd like to take this to a private channel you can email support at wolfssl dot com and we'll provide free pre-sales support.

Thanks,
David Garske, wolfSSL

Go to forum: wolfCrypt

58 Reply by dgarske

(3 replies, posted in wolfCrypt)

Hi RCuller,

Your example looks valid. The key size passed in sizeof(key) is 32 so it will use AES 256-bit. The AES CBC requires the input to be block aligned at 16 bytes. Is there a reason you are using 1024 bytes? I assume your encrypt routine looks similar and takes in a null terminated string and also uses 1024 bytes?

We have a good AES CBC file encryption example here:
https://github.com/wolfSSL/wolfssl-exam … -encrypt.c

Another thing to coding is making sure you include wolfssl/options.h above the other wolfSSL header includes. See FAQ 1: https://www.wolfssl.com/docs/frequently … r_wolfSSL?

Thanks,
David Garske, wolfSSL

Go to forum: wolfCrypt

59 Reply by dgarske

(11 replies, posted in wolfCrypt)

Hi mnzdbz,

Because you are using WOLFSSL_SMALL_STACK it uses heap instead. If you remove the small stack option it will use stack and not heap.

Which mode of AES? There are AES tables as you found. Not using the tables slows down the operation because it must compute values. Are you building the .c code with optimizations enabled like "-Os" or "-O2"? Those make a big different.

Besides WOLFSSL_AES_SMALL_TABLES you can also play with WOLFSSL_AES_NO_UNROLL to see how that impacts performance and code size.

Thanks,
David Garske, wolfSSL

Go to forum: wolfCrypt

60 Reply by dgarske

(16 replies, posted in wolfTPM)

Hi Richeal C,

This is a Nuvoton NPCT750 TPM2.0. Check wait state is required.

Here is what the working output for TPM2_GetCapability should look like:

Command: 22
    80 01 00 00 00 16 00 00 01 7a 00 00 00 06 00 00 | .........z......
    01 05 00 00 00 08                               | ......
Response: 83
    80 01 00 00 00 53 00 00 00 00 01 00 00 00 06 00 | .....S..........
    00 00 08 00 00 01 05 4e 54 43 00 00 00 01 06 4e | .......NTC.....N
    50 43 54 00 00 01 07 37 35 78 00 00 00 01 08 22 | PCT....75x....."
    21 21 34 00 00 01 09 72 6c 73 00 00 00 01 0a 00 | !!4....rls......
    00 00 00 00 00 01 0b 00 07 00 02 00 00 01 0c 00 | ................
    02 00 00                                        | ...
Command: 22
    80 01 00 00 00 16 00 00 01 7a 00 00 00 06 00 00 | .........z......
    01 2d 00 00 00 01                               | .-....
Response: 27
    80 01 00 00 00 1b 00 00 00 00 01 00 00 00 06 00 | ................
    00 00 01 00 00 01 2d 00 00 00 01                | ......-....
Mfg NTC (4), Vendor NPCT75x"!!4rls, Fw 7.2 (131072), FIPS 140-2 1, CC-EAL4 0

The first command is TPM2_GetCapability with TPM_PT_MANUFACTURER.
The second command is TPM2_GetCapability with TPM_PT_MODES.

Can you try this patch and see how much further you can get?

diff --git a/src/tpm2.c b/src/tpm2.c
index 4c04770..c502e35 100644
--- a/src/tpm2.c
+++ b/src/tpm2.c
@@ -891,7 +891,6 @@ TPM_RC TPM2_GetCapability(GetCapability_In* in, GetCapability_Out* out)
                     printf("Unknown capability type 0x%x\n",
                         (unsigned int)out->capabilityData.capability);
             #endif
-                    rc = -1;
                     break;
             }
         }

Thanks,
David Garske, wolfSSL

Go to forum: wolfTPM

61 Reply by dgarske

(11 replies, posted in wolfCrypt)

Hi mnzdbz,

How is your stack configured? Fast math (tfm.c) uses stack not heap. The correct size for FP_MAX_BITS is your maximum key size * 2 (for multiplication of two big integers).

You would likely need about 8KB of stack with your configuration. If you would like to use heap I recommend the following build settings.


#define WOLFSSL_SP_MATH_ALL
#define WOLFSSL_SP_SMALL
#define WOLFSSL_SMALL_STACK

This will use our sp_int.c with heap allocations.

Thanks,
David Garske, wolfSSL

Go to forum: wolfCrypt

62 Reply by dgarske

(16 replies, posted in wolfTPM)

Looks like it is all working normal. I would recommend trying to run examples/wrap/wrap_test to verify.

It looks like the unit test makes an assumption about parsing capabilities. I will investigate tomorrow.

Go to forum: wolfTPM

63 Reply by dgarske

(16 replies, posted in wolfTPM)

Hi Richeal C,

Have you tried adjusting the TPM2_SPI_MAX_HZ to a lower value?

Can you try building wolfTPM like:

./configure --enable-infineon=slb9670 CFLAGS="-DTPM2_SPI_MAX_HZ=33000000"

Note you can add --enable-debug=io to see the raw output. Some of the self-test and key creation routines take a while. You might consider looking at XTPM_WAIT.

Can you tell us more about your project? Feel free to email support @ wolfssl.com directly.

Thanks,
David Garske, wolfSSL

Go to forum: wolfTPM

64 Reply by dgarske

(11 replies, posted in wolfCrypt)

Hi mnzdbz,

1) If you are using wolfCrypt only (no TLS) and do not want to do any X.509 you should be able to use NO_CERTS. We did have some fixes around this recently. But you should be able to use NO_CERTS, WOLFCRYPT_ONLY and WOLFSSL_ASN_TEMPLATE.

2) That is a great question! We have several math options with varying memory use. You are using fast math which uses math variables on the stack. Those sizes are max key size * 2. Example #define FP_MAX_BITS (2*2048)". If you have only 3KB of RAM it is unlikely you'll be able to do any asymmetric operations RSA or ECC. For example a 2048-bit RSA key requires multiple 512 byte math variables and the underlying modulus exponent uses several more.  Do you really only have access to 3KB of RAM?

Thanks,
David Garske, wolfSSL

Go to forum: wolfCrypt

65 Reply by dgarske

(11 replies, posted in wolfCrypt)

Hi mnzdbz,

For validation of certificate begin/end dates we need a time source/RTC. If this is not available you can bypass date checking by adding NO_ASN_TIME to your user_settings.h. If you have an RTC, but your stdlib doesn't expose time() then you can define your own API.

Example:

/* user_settings.h - Override Current Time */

/* Allows custom "custom_time()" function to be used for benchmark */
#define WOLFSSL_USER_CURRTIME
#define WOLFSSL_GMTIME
#define USER_TICKS
extern unsigned long my_time(unsigned long* timer);
#define XTIME my_time

/* example code */

/* This is used by wolfCrypt asn.c for cert time checking */
unsigned long my_time(unsigned long* timer)
{
    (void)timer;
    return hw_get_time_sec();
}

Thanks,
David Garske, wolfSSL

Go to forum: wolfCrypt

66 Reply by dgarske

(11 replies, posted in wolfCrypt)

Hi mnzdbz,

To me it looks like you are running out of flash space. Its not a 32-bit/16-bit issue. Your 32-bit MCU has support for the 64-bit type (word64) using "long long".

I suggest you review our low resource build options and user_settings template here:
* https://github.com/wolfSSL/wolfssl/blob … template.h
* https://github.com/wolfSSL/wolfssl/blob … e.ac#L1962

You would likely benefit from the following:
* USE_SLOW_SHA512

Which C files are you building? Some of the algorithms are on by default and require a NO_ build option (example NO_SHA).

Thanks,
David Garske, wolfSSL

Go to forum: wolfCrypt

67 Reply by dgarske

(4 replies, posted in wolfCrypt)

Hi Wangzihao,

Can you share the build settings you are using to compile wolfSSL (like the ./configure or user_settings.h)?

Thanks,
David Garske, wolfSSL

Go to forum: wolfCrypt

68 Reply by dgarske

(4 replies, posted in wolfCrypt)

Hi Wangzihao,

The `wc_ecc_get_generator` is wrapped with the `OPENSSL_EXTRA`. Make sure when building you include `./configure --enable-opensslextra`.

However normally someone would export the private or public key using a different function after a make_key. See `wc_ecc_export_x963`, `wc_ecc_export_private_only`, `wc_ecc_export_point_der`, `wc_ecc_export_public_raw`, etc.


Thanks,
David Garske, wolfSSL

Go to forum: wolfCrypt

69 Reply by dgarske

(4 replies, posted in wolfMQTT)

Hi Sebastian,

Building our libraries for bare-metal is the easy part. Both wolfSSL and wolfMQTT are pure C libraries designed for portability and even bare-metal use.

For building you have a few options:
1) Use ./configure and cross-compile the libraries for your target. Something like: 

./configure --host=arm-none-eabi CC=gcc AR=ar --disable-shared --disable-examples --disable-crypttests --disable-asm --disable-rsa --disable-dh --enable-tls13 --disable-tlsv12 CFLAGS="-mcpu=cortex-m0 -mthumb" LDFLAGS="-mcpu=cortex-m0 -mthumb"

. The result is a .a static library. You can use --prefix= to specify a custom install path used with "make install". This generates a wolfssl/options.h with the build options used. You'll need to include this in your application 

#include <wolfssl/options.h>

.

2) Use our example GCC Makefiles in IDE/GCC-ARM which can be easily setup for Cortex M0

3) Use your own IDE: Import the src/*.c and wolfcrypt/src/*.c files into your project and build directly. Add include to the wolfSSL/wolfMQTT root. Add pre-processor WOLFSSL_USER_SETTINGS and add your own user_settings.h file (examples here: https://github.com/wolfSSL/wolfssl/tree … s/configs)

You'll likely have to do some investigating on how to use LWIP on bare-metal. I don't know of an example we have for this. But google turned up this nice article: https://lwip.fandom.com/wiki/LwIP_with_ … ing_system

Perhaps a short technical call might help you get started?

Thanks,
David Garske, wolfSSL

Go to forum: wolfMQTT

70 Reply by dgarske

(4 replies, posted in wolfMQTT)

Hi Sebastian,

Yes it is very possible to do MQTTS on bare-metal.

Can you tell us more about the compiler/IDE, hardware and reason for bare-metal requirement? Have you selected a network stack and confirmed it can be used in bare-metal?

You might find this MQTT over UART example useful for understanding how to customize the network IO layer: https://github.com/wolfSSL/wolfMQTT/blo … mqttuart.c

The wolfSSL FAQ covers some useful topics like build configuration: https://www.wolfssl.com/docs/frequently … tions-faq/

For building wolfSSL (TLS) you just need to build with SINGLE_THREADED, NO_FILESYSTEM, etc...

Let me know if you have any specific questions or build issues.

Thanks,
David Garske, wolfSSL

Go to forum: wolfMQTT

71 Reply by dgarske

(6 replies, posted in wolfCrypt)

Hi Shammon,

Each asymmetric algorithm has different total memory requirements. We have several build options for altering where this memory comes from. For example you can put on heap, stack or static memory.

By default the memory comes mostly from the stack. If you'd prefer to use the heap then I would should consider updating to the latest wolfSSL in GitHub and using the `WOLFSSL_SP_SMALL_STACK` option, which is new. Or you could just try `WOLFSSL_SMALL_STACK` with your current release.

The RSA/DH algorithms have a much lager key size and generally use more memory. The ECC (ECDHE/ECDSA) and ED25519 algorithms use much less memory and can also be used with TLS v1.2 and v1.3.

Perhaps you can tell me more about your configuration such as RTOS/bare-metal, available heap/stack and TLS requirements?

Thanks,
David Garske, wolfSSL

Go to forum: wolfCrypt

72 Reply by dgarske

(6 replies, posted in wolfCrypt)

Hi Shammon,

I still suspect you are running out of memory because DH uses a large amount from the stack. Have you considered using ECDHE?

You might also consider trying a different math library option. We have several (see https://github.com/wolfSSL/wolfssl/blob … .ftl#L202)

I recommend you try with a small math implementation like `3=Single Precision C (only common curves/key sizes)`.

Thanks,
David Garske, wolfSSL

Go to forum: wolfCrypt

73 Reply by dgarske

(6 replies, posted in wolfCrypt)

Hi Shammon,

This sounds like a stack issue. Please try increasing your stack memory for the thread or adjust in the linker script if using bare-metal. What size DH key are you trying to generate? Have you tried running the wolfCrypt tests first? Make sure you have the right DH parameters enabled via `HAVE_FFDHE_2048`, `HAVE_FFDHE_3072`, `HAVE_FFDHE_4096`, etc.

Thanks,
David Garske, wolfSSL

Go to forum: wolfCrypt

74 Reply by dgarske

(2 replies, posted in wolfTPM)

Hi Geoff,

It is great to hear from you. This is a very interesting use-case.

For the TLS use case we have lots of examples for this in wolfTPM:
https://github.com/wolfSSL/wolfTPM/tree … s-examples
https://github.com/wolfSSL/wolfTPM/tree … amples/tls

In wolfSSL we support consuming a PKCS11 interface. We also have a wolfPKCS11 provider that uses wolfCrypt on the backend. It would be possible to take our wolfPKCS11 and use a TPM under it. We've discussed doing this, but is a decent effort. https://github.com/wolfSSL/wolfpkcs11

Let's have a call with Rich and I to discuss.

Thanks,
David Garske, wolfSSL

Go to forum: wolfTPM

75 Reply by dgarske

(4 replies, posted in wolfTPM)

Hi Luizg473,

I think your issue is not using `wolfTPM2_Init` and `wolfTPM2_Cleanup`. Have you tried that?

wolfTPM should have the WinAPI option enabled by default for windows: https://github.com/wolfSSL/wolfTPM/blob … ts.txt#L86

You can use `WOLFTPM_INTERFACE=WINAPI` to force it.

The build settings for wolfTPM come from here: https://github.com/microsoft/vcpkg/blob … file.cmake

Thanks,
David Garske, wolfSSL

Go to forum: wolfTPM