You will need shake 128 and 256

Hi MosheTreutel99 ,

Great questions.  Note that RSA encryption/decryption is considered asymmetric encryption as it involves a pubic key and private key.  Symmetric encryption is when both sides are using the same key.  AES is a good example of this.

There is a theory section at the bottom of this page: https://asecuritysite.com/rsa/ .  There are also lots of references to further topics at that link.

Warm regards, Anthony

I think you might find this useful:

https://github.com/wolfSSL/wolfssl/tree/master/Docker

Let me know if you have further questions.

Can you tell us about your project and goals?

Warm regards, Anthony

Perhaps you would prefer a secure and confidential communication channel.  If so, please start the conversation by sending a message to support@wolfssl.com.

If you would like to try such a project, we would be happy to entertain a contribution.  Let us know if you try to do it.

Warm regards, Anthony

Hi , 

wc_AesGcmEncrypt() is what is known as a "one-shot" API; the whole AES algorithm is run in a single API call. 

The file encryption example does not use that API.  It uses wc_AesGcmEncryptInit(), wc_AesGcmEncryptUpdate(), and wc_AesGcmEncryptFinal(); this  is known as a streaming API which allows the data to be encrypted to be fed in as chunks.  This is useful if you are getting dtata in chunks and don't have the full content in a buffer before hand. 

Warm regards, Anthony

Yes, that should work.  That is to say that WOLFSSL_ALT_NAMES does not depend on the openssl compatibility layer.  Note that you do not need to use --disable-opensslall; it is disabled by default.

Warm regards, Anthony

Hi Jakob,

My name is Anthony and I am a member of the wolfSSL team. As of yet we do not have support for assembly optimizations foir brainpool curves so yes, you are seeing expected behaviour.

That said, can you let us know a bit more about yourself and your project?  What are your goals?  Are you interested in seeing Brainpool assembly optimizations?

If you desire privacy, you can send this information to our confidential support address:  support@wolfssl.com.

Warm regards, Anthony

DJ3434,

May I ask if your interest in wolfSSL is professional, academic or person?  If you are concerned about confidentiality you can submit more information via support@wolfssl.com .

Warm regards, Anthony

Hi Hannson,

Thank you so much for all these details.  I see on the commandl-ine you display you have -DNO_DSA and -DNO_PSK.  So, that would be the cause of the redefinition.  Perhaps the solution would be to remove NO_DSA and NO_PSK from your user_setting.sh.h file.

Might I ask if this is a commercial use case?  If so, to preserve you privacy, I would suggest further interaction happen via our confidential technical support channel.  You can send messages to support@wolfssl.com and we will support you there.  Note that you can also send messages with attachments there.   

Warm regards, Anthony

Thank you so much for finding this!! I really appreciate it.  We'll look into fixing this.  Feels like it should be a simple fix.

Warm regards, Anthony

Hi Sheondael,

My name is Anthony and I am a member of the wolfSSL team.  The wolfssl library has never supported XMSS in certificates.  The reason is because the use case for certificates would be for network protocols and XMSS is a stateful hash-based signature scheme.  The state makes it inappropriate for usage in network protocols. 

Where it is appropriate is in code and firmware signing.  As such we use it in our wolfBoot product.  In that case, no certificate is required.

That said, can you let us know your use case for XMSS in certificates?  Here at wolfSSL, we are always interested in how people are using our code and I would love to understand your need for XMSS in certificates.  Also, can you let us know your geographical location and whether this is out of professional, personal or academic interest?

Warm  regards, Anthony