(1 replies, posted in wolfCrypt)

The documentation shows that I should call wc_AesSetKey, then wc_AesSetIV, then w_AesCbcEncrypt.

Is it really necessary to call SetIV being as the call to SetKey also takes the IV as input?  It seems to work OK without calling it, but I just want to confirm that there's not some side effect that I'm missing.



(2 replies, posted in wolfCrypt)

Thanks Chris.  That helps...

Thanks Kaleb - I had assumed it was probably a false warning because management of mp_int is handled by the application.  I definitely appreciate your research and work on this!



(2 replies, posted in wolfCrypt)

I'm assuming that I should use XMALLOC instead of malloc when allocating space on the heap.  But what should I use for type?  The enum value DYNAMIC_TYPE_TMP_BUFFER is mentioned, is this suitable for allocating a byte array of a certain length that I will later free using XFREE?

What are the risks of using malloc and free instead?

What I'm thinking is that I'll hash the pass phrase and manipulate the resulting string to make the keys...

BTW, I'm working with Rod Weaver from Wolf and will probably initiate a support thread with him later today.

Yes, the use case is that a user will activate the app by providing a pass phrase (in addition to getting a user name and password).  The pass phrase is a longer string comprised of at least 4 words and 30 characters: "My mother used to make me eat grits".  This serves two purposes:  1) it's used to authenticate the user when the password needs to be changed and 2) it is used to generate the public/private key pair for the RSA encryption.  Without having the pass phrase a user would not be able to regenerate their keys.

The pass phrase itself is not saved on the client or the server.

Hi Chris -
We're developing a secure messenger called Sesame.  All messages and attachments are encrypted from client to client and pass through the server ephemerally.  http://sesame.chat

I'm using this function when creating a sha256 hash.  my questions is, who frees the memory for hash, which is a byte*?

The examples in the doc don't show how this is allocated.  Would I be OK assuming that if I do the following, it will be allocated on the stack and deleted when it goes out of scope?

Sha256 sha256[1];
// call init and update here
char hash[32];
int ret = wc_Sha256Final(sha256, hash);

I get the following warning in Visual Studio when compiling WolfSSL to a .dll AND I have WOLFSSL_KEY_GEN set in my preprocessor directives.

c:\security\wolfssl-3.7.0\wolfcrypt\src\integer.c(4115): warning C4701: potentially uninitialized local variable 'q' used

I'm just guessing that this is because of the way that the mp_digit struct behaves - sort of taking things like validity of a number into its own hands.  But yet I have that nagging feeling that I don't like to have warnings in my build.

Any thoughts on this?

I want to generate a public/private key pair from a string.  For example "My secret pass phrase goes here" would be entered by a user and I would somehow generate the public and private RSA keys from that.

In looking at the documentation it appears that the only way to do that would be indirectly:  by somehow hashing the pass phrase down to a long integer that could then be used as "e" in "int MakeRsaKey(RsaKey* key, int size, long e, RNG* rng);".

Does that make sense?  Is there some other technique that I could use?

And given that my resulting hash will probably not be a prime number, does that make any difference?