Hello,

I had an issue configuring my wolfssl/wolfcrypt sources after adding them to a git repository. The compilation failed, as the configure would set the "-Werror" flag. After a long search for the cause and many "WTFs" I figured out that the configure script checks for a .git folder to exist in the top directory (presumably for non-release builds), whereupon, apparently, the -Werror flag is set:

      
      if test -e ".git"; then :
  ac_cv_vcs_system="git"
fi

(configure, line 24359)

In hope that this helps anyone who encounters this issue.

Hello,

I was writing some tests for my project when I realized that the input size for AES-CBC is never checked to be a multiple of the AES_BLOCK_SIZE.
This has the consequence that if e.g. an byte array of the size 17 is used as the input plaintext, only the first 16 bytes are encrypted. If the input is empty, nothing is encrypted.
No error or warning is being returned so I felt like something has to be added there otherwise people might unintentionally leak unencrypted data.

I am using version 3.11. but I also tried it on the latest release (3.13) which seems to make no difference.

For AES-CTR this is the same case, though the "not fitting" Bytes are still encrypted and the message can also be decrypted.


Best Regards
telina

Hello,

I migrated my current project to the latest stable version 3.11.0 and now some of my AES_GCM tests are failing. I found that the cause for this are the new varaible checks in wc_AesGcmDecrypt

 if (aes == NULL || out == NULL || in == NULL || sz == 0 || iv == NULL ||
        authTag == NULL || authIn == NULL || authTagSz > AES_BLOCK_SIZE) {
        return BAD_FUNC_ARG;
    }

With these checks, additional data (authIn) is not permitted to be NULL anymore. I know that it can be avoided by passing an empty dummy instead, but shouldn't it be permitted to call the function without any additional data to authenticate?


Best Regards
telina

Hey Kaleb,

I am indeed only using 3.10.3. I'm going to update to the newest stable version, thank you! Still the --enable-ctr flag does not seem to be documented in the manual  (https://www.wolfssl.com/wolfSSL/Docs-wo … lfssl.html)


Best Regards
telina

Hey Kaleb,

don't worry about, it was really my fault. Such a stupid mistake, but I was too determined on the idea that the problem would be caused by something bigger.
Everything works now and makes sense big_smile. Thank you very much! I am trying to get the code to run on the board now.
I had some troubles configuring the library to cross-compile for sparc-rtems but I got something working now.

Out of interest:
I was using --enable-mcapi, but it requires me to define --with-libz and I cannot do that, because I can't cross compile libz for sparc-rtems. If I don't use --enable-mcapi, I get undefined references for both wc_AesCtrEncrypt and wc_AesSetKeyDirect. After searching through the configure file, I realised the necessary defines are set with --enable-fortress as well, so I am using that instead. Is there a reason theres nothing like --enable-ctr ? At least to me it was not obvious that I had to use --enable-fortress, maybe this could be made more obvious/added to the documentation ?


Best Regards
telina

Hi Kaleb,

I managed to fix it by changing the include order and putting the options.h first >.< Nevertheless, dh.h includes integer.h and not tmf.h


Thanks for your help,
telina

Hello,

I was indeed not including the options.h and just set the flags I need myself. I deleted all of them and included the wolfssl/options.h instead but it did not make a difference.
I am working on Debian Linux:

$ uname -a
Linux dev 3.16.0-4-amd64 #1 SMP Debian 3.16.39-1+deb8u2 (2017-03-07) x86_64 GNU/Linux

and I configured with the following flags:

./configure --enable-aesgcm --enable-aesccm --enable-mcapi --enable-fastmath --enable-sha512 --enable-ecc --with-libz

with generated the options.h attached to this post. It should be noted that I also wrote code for running AES with different modes of operation using fastmath without problems. In the future, this code is supposed to run on a board and I did cross compile the AES-tests with fastmath for it without problems, too.
After configuration I run make clean, make, sudo make install..

When I encountered this error in my code I tried to run a more simple example code taken but adjusted from the test.c.

#include <wolfssl/wolfcrypt/aes.h>
#include <wolfssl/wolfcrypt/dh.h>
#include <wolfssl/options.h>

void
simple_test()
{
    size_t testVal = 23;
    WC_RNG rng;
    int    ret;
    ret = wc_InitRng(&rng);
    DhKey  smallKey;

    byte   p[2] = { 0, 5 };
    byte   g[2] = { 0, 2 };
    byte   priv[2];
    word32 privSz = sizeof(priv);
    byte   pub[2];
    word32 pubSz = sizeof(pub);
    
    printf("testval is %zi\n", testVal);
    wc_InitDhKey(&smallKey);
    printf("testval is %zi\n", testVal);

    ret = wc_DhSetKey(&smallKey, p, sizeof(p), g, sizeof(g));
    if (ret != 0)
        printf("Error");

    ret = wc_DhGenerateKeyPair(&smallKey, &rng, priv, &privSz, pub, &pubSz);
    wc_FreeDhKey(&smallKey);
    if (ret != 0)
        printf("Error");
    
    wc_FreeRng(&rng);
    wc_FreeDhKey(&smallKey);
}

int main(int argc, char** argv) 
{
    simple_test();
   
    return 0;
}

I am using netbeans with its default generated Makefile. The compilation process looks like this

g++ -lwolfssl   -c -g -std=c++11 -MMD -MP -MF "build/Debug/GNU-Linux/main.o.d" -o build/Debug/GNU-Linux/main.o main.cpp
g++ -lwolfssl    -o dist/Debug/GNU-Linux/wolfssl_test build/Debug/GNU-Linux/main.o

And the output like this:

testval is 23
testval is 0

RUN FINISHED; Segmentation fault; real time: 10ms; user: 0ms; system: 0ms

I might have found something: Netbeans showed that there are 'unresolved includes' in wolfssl/wolfcrypt/dh.h leading to integer.h and to mpi_class.h, but I don't know what to do about it.

Hope that helps,
telina

Hello,

I am trying to use the DH key agreement but I keep running into a Segmentation Fault. After some debugging and analysing memory usage I came to the conclusion, that the bug must lie within the library. Even the code in your provided test wouldn't work.
I read through the code and figured that  wc_InitDhKey(DhKey* key) (dh.c) calls mp_init_multi(&key->p, &key->g, NULL, NULL, NULL, NULL) of the used integer library (in my case tfm.c). I previously configured wolfssl using fastmath and realised that this might be the issue.
Reconfiguring without using fastmath "solved" the issue for me.

Is this 'just' a bug, or did I misconfigure fast math?


Edit: Since the version I used was fetched from GitHub a while ago,  I tried both the latest version and the latest stable version without success.

Best Regards,
telina