651

(3 replies, posted in wolfCrypt)

Hi jesussotofan,

I have taken your code, re-compiled and run the test on Linux, I'm giving you my source code, just update the print statements and you should observe intended test case.


#include <stdio.h>
#include <wolfssl/options.h>
#include <wolfssl/wolfcrypt/settings.h>
#include <wolfssl/wolfcrypt/aes.h>

int main(void) {
Aes enc;
Aes dec;
int ret;

int x;

byte key[] = {"234567890abcdef"};

byte iv[]  = {"1234567890abcdef"};

byte plain[32]  = {"Hola mundoHola mundoHola mundo"};   // an increment of 16, fill with data
byte plain2[32];
byte cipher[32];

printf("sizeof key = %d\n", (int) sizeof(key));
printf("sizeof cipher = %d\n", (int) sizeof(cipher));
printf("sizeof plain = %d\n", (int) sizeof(plain));

printf("plain value                      ");

for(x=0; x<16; x++){
  printf("%02x", plain[x]);
  printf(" ");
  }
printf(" \n");



printf("printing key value               ");

for(x=0; x<16; x++){
  printf("%02x", key[x]);
  printf(" ");
  }
printf(" \n");


printf("printing iv value                ");
for(x=0; x<16; x++){
  printf("%02x", iv[x]);
  printf(" ");
  }

printf(" \n");

//encrypt
ret = wc_AesSetKey(&enc, key, sizeof(key), iv, AES_ENCRYPTION);
if (ret != 0) {
    printf("Encrypt set key failed with error: %d\n", ret);
    return ret;
}
ret = wc_AesCbcEncrypt(&enc, cipher, plain, sizeof(plain));
if (ret != 0) {
    printf("AesCbcEncrypt failed with error: %d\n", ret);
    return ret;
}



printf("cipher value                     ");

for(x=0; x<16; x++){
  printf("%02x", cipher[x]);
  printf(" ");
  }
printf(" \n");



printf("printing key value before cipher ");

for(x=0; x<16; x++){
  printf("%02x", key[x]);
  printf(" ");
  }
printf(" \n");


printf("printing iv value before cipher  ");
for(x=0; x<16; x++){
  printf("%02x", iv[x]);
  printf(" ");
  }
printf(" \n");

//decrypt
ret = wc_AesSetKey(&dec, key, sizeof(key), iv, AES_DECRYPTION);
if (ret != 0) {
    printf("Decrypt set key failed with error: %d\n", ret);
    return ret;
}
ret = wc_AesCbcDecrypt(&dec, plain2, cipher, sizeof(cipher));
if (ret != 0) {
    printf("AesCbcDecrypt failed with error: %d\n", ret);
    return ret;
}


printf("plain2 value                     ");

for(x=0; x<16; x++){
  printf("%02x", plain2[x]);
  printf(" ");
  }

printf(" \n");
printf(" \n");
printf(" \n");

}

Regards,

Kaleb

652

(3 replies, posted in wolfCrypt)

Hi jesussotofan,

the key must be modulo AES_SIZE (16). A byte array containing 1234567890abcdef is size 17 (array indexing if it contains 16 elements it's one larger for the '\0' or NULL character on the end of the string in c. Change your key to "234567890abcdef" and you test should work.


One other note you are printing out HEX values and looping 32 times. Each hex byte is 8 bytes long. You're working with an array of 32 8-byte elements and the print in the for loop prints out 2 8-bytes elements each loop. You should only loop 16 times, not 32. You're printing memory off the end of your buffers.

for(x=0; x<16; x++){
  Serial.print(plain[x], HEX);
  Serial.print(" ");
  }
Serial.println(" ");

ALSO it is highly recommended you check your return codes and you would have seen the error happening IE:

wc_AesSetKey(&enc, key, sizeof(key), iv, AES_ENCRYPTION);

SHOULD BE:

/* make an integer "ret" */
ret = wc_AesSetKey(&enc, key, sizeof(key), iv, AES_ENCRYPTION);
if (ret != 0) {
    Serial.println(" Aes Set Key Failed with error code: ");
    Serial.print(ret, INTEGER); /* or however you output an int I'm not familiar with this print functionality */
}

And do the same for other wolfSSL API's.


Regards,

Kaleb

Hi will,


To get the IP of a server is quite simple and there are many online "checkers" if you just need to get the number once for example:
http://ipinfo.info/html/ip_checker.php

Or from a command line you can use the "dig" utility, just execute this command:

dig +short www.google.com

If your program needs to re-determine the IP at run time then please try the following:

#define BAD_HOST -1

/* in your function ... */

  struct hostent     *hostInfo;
  struct sockaddr_in  serveraddr;
  int                 socket;
  int ret;

  const char hostname[] = "www.google.com";

  /* convert to IP */
  if ( (hostInfo = gethostbyname(hostname) ) == NULL ) {
      return BAD_HOST;
  }

  memcpy(&server.sin_addr, hostInfo->h_addr_list[0], hostInfo->h_length);
  server.sin_family = AF_INET;
  server.sin_port = htons(443);

  /* Now do the call to "connect" */

Lastly you stated you are getting a return of negative 1. Is there a server running on your computer that is listening at 127.0.0.1 that you are trying to connect to? If there is no server listening then yes I would expect the client to get a failed connection every time.


Regards,

Kaleb

654

(4 replies, posted in wolfSSL)

Hi Stana,


1.

Warnings of this nature:

src\internal.c(13894): warning:  #1293-D: assignment in condition
              &&  !(ret = wc_Sha256Update(sha256, messageVerify, verifySz))) {

are thown by SOME but not all C compilers. Depending on the compiler this warning basically saying:

"Hey you have an if condition like this:

 if (x = 1) { do something; } 

"Did you really mean to do this?:

if (x == 1) { do something; }

It's a friendly reminder that you may have made a mistake but it does not mean it is incorrect. This is something we have evaluated internally in the past and we decided at that time it is not something we feel is necessary to change since all compilers (that we know of) that do throw this warning also provide an option to disable the warning.

That being said we have not discussed it in some time so I will voice your concern in our next meeting and see if the team still feels the same.



2. Could you send me the full list of enumerated type mixed with another type that you are seeing (kaleb@wolfssl.com) or is what you included the full list? We will evaluate these and see if there is any potential for undefined or dangerous behavior. Once evaluated I will post an update on this thread.


Thanks,

Kaleb

655

(4 replies, posted in wolfSSL)

Hi sp,

I have opened a pull request to address this build time warning:

https://github.com/wolfSSL/wolfssl/pull … 55c9d378f4


Kind Regards,

656

(4 replies, posted in wolfSSL)

Hi sp,

This is indeed a strange warning. The reason we cast to void is there exists paths such that ticketLen may not be used. In that event we do not wish a compiler to throw a build time error/warning for "unused variable". By casting to void after declaration most C compilers see that it gets used at least once and will not complain. We have never seen a compiler throw a "used before set" on the void cast, that is new. Thank you for sharing.

You can resolve by setting it equal to 0, same as for "doDynamicCopy" variable.


Regards,

Kaleb

Hi jesussotofan,

I have asked our python expert to look into this for you. Moises should be in touch soon with a resolution.


Kind Regards,

Kaleb

658

(5 replies, posted in wolfCrypt)

Hi jesussotofan,

Not a problem. Happy we could assist you with this project!


Regards,

Kaleb and the wolfSSL Team

659

(5 replies, posted in wolfSSL)

Hi ravi.kumar,

One of my colleagues also wanted to ensure the mp_int is being correctly populated:


mp_int a;

mp_init(&a);

mp_read_unsigned_bin(&a, p256_modulus, sizeof(p256_modulus));



This will populate the mp_int correctly from his byte array.

- David Garske


Kind Regards,

- Kaleb

660

(6 replies, posted in wolfSSL)

Hi will,

Yes I believe you are correct here. The close notify signifies nothing particularly went wrong with the connection other than the server decided it was going to shut down and knew in advance so it sent out a notification to the client that it was shutting down the session. This could be for a few reasons:

1. The server expected a specific bit of information that it never got, eventually timed out and terminated the session.
2. The server expected a specific bit of information and incorrect information was sent. Not a true error, but not a successful exchange either.
3. The server was being shutdown for an update and termination procedures ensued (not as likely).
4. May be others but the above three are the most common reasons to send a "close notify".

If something went wrong during the handshake or the server just died you would likely see an "Alert Fatal Error" or a -308 "Error state on Socket"

If you have access to wireshark you might start it up, connect to the server again and capture the exchange, filter the report on your ip address

ip.addr==<your client ip>

and send us the trace. We could look at it more closely to determine if this is what happened or not.


Kind Regards,

Kaleb

661

(5 replies, posted in wolfCrypt)

Hi jesussotofan,


I checked with our python expert and he said this is a very common issue.


if you run python inside wolfssl/wrapper/python
it will try to use the local code instead of the installed one.
the local code doesn’t have the _ffi module, it is built during the building process.

    - Moisés Guimarães

His suggestion is to run python from a different location and if you have similar issue then take a screenshot or echo the error output to a file and send to us for review.


- Kaleb

662

(5 replies, posted in wolfSSL)

Hi ravi.kumar,

Is there a reason you are working with such an outdated version of our library? v3.3.0 is very old at this point (Dec 5, 2014 nearly two years old). We have had two major and several minor updates to the ECC math libraries since then, one major update was to fix an issue when ECC_SHAMIR was not defined (got unexpected results as you describe) and another to defeat a side-channel cache attack (see more on this in our blog https://wolfssl.com/wolfSSL/Blog/Blog.html or in README.md). I can not guarantee but suspect you have encountered one of the issues that has since been fixed.

Please run your test against v3.9.10 and let us know if you observe the same behavior: https://wolfssl.com/wolfSSL/download/downloadForm.php

OR development branch here:
https://github.com/wolfSSL/wolfssl


Kind Regards,

Kaleb

Hi tmarschen,

So we have a "struct tm" in asn.c that is implemented if defined USE_WOLF_TM.

You've added this check:

#ifndef USE_WOLF_TM
#include <time.h>
#endif

which accomplishes this: "If wolfssl is not going to implement a tm structure then we're going to include the posix time.h header which DOES implement the tm structure" Then we will define wolfssl_tm to be that tm instead of the one in wolfssl/wolfcrypt/src/asn.c (since it wasn't implemented in this case)"

There is nothing wrong with doing that as long as the tm struct in <time.h> has all the same elements and will not result in our library accessing some element of that structure that doesn't exist.

We try to remain as portable as we can across all platforms. I believe you have identified a case where we were not 100% portable. We would not consider this a bug because there is no "undefined" or "unexpected" behavior taking place during the execution of the program. This is a compile time issue that resulted from building on a non-standard environment. Porting and building on different environments often requires minor additions/modifications to get everything working smoothly. When we identify these portability issues we try to account for them for all future users so thank you for pointing it out to us.

Could you tell us the operating system and version you are working on, which compiler you're building with and how your include directories are setup (IE why the ../include_posix/time.h). If we can replicate the issue we can look into getting a fix for portability sake.

Thank you again for your question and we look forward to hearing back from you.


Kind Regards,

Kaleb and the wolfSSL Team

Hi datorgalva,

Your initial issue was with MinGW(gcc). This looks like a screen shot from MicroSoft Visual Studio. Have you built our example projects (solution file located in <wolfssl-root>/wolfssl64.sln)?

If not please take a look at those projects and the pre-processor macros used. You will need to build with the same macros.

I see you've included <wolfssl/options.h> is this because you built with MinGw(gcc), were able to generate options.h with configure script and now are trying to build in VisualStudio using the MinGW(gcc) compiled library?

wolfssl/options.h is usually not available in windows environment unless you write it by hand. Instead we use the file <wolfssl-root>/IDE/WIN/user_settings.h to control our windows projects and we define "WOLFSSL_USER_SETTINGS" so that file gets pulled in.

I'll wait for your answers on my above questions.


Regards,

Kaleb

665

(3 replies, posted in wolfSSL)

Hi jesussotofan,

I checked with our python expert and he said this is a very common issue.

if you run python inside wolfssl/wrapper/python
it will try to use the local code instead of the installed one.
the local code doesn’t have the _ffi module, it is built during the building process.

- Moisés Guimarães

His suggestion is to run python from a different location and if you have similar issue then take a screenshot or echo the error output to a file and send to us for review.

- Kaleb

Hi stamp_age,

No problem, glad we could help!


- Kaleb

667

(6 replies, posted in wolfSSL)

Hi Will,

Thank you so much for sending that, I believe I know what was happening.

Once I received the cert with the private key stripped out there was nothing wrong with it whatsoever. Upon further exploration I wondered if having the private key in the file is what made the difference so I put one of my private keys after the cert and sure enough I was able to reproduce your error. I tried parsing the cert with the key in the bottom using another TLS solution and even though that solution was able to parse it, it simply ignored the key at the bottom of the file and never even acknowledged it's presence.

As such I believe we may be able to modify our error message to be more informative if this occurs, but I believe to error out is a better solution so you don't accidentally send out a private key in a cert unintentionally.

We typically expect keys to be in key files and certs to be in cert files. I see you were already loading a key in (devkeyslockhome.pem) what is the difference between that key and the RSA private key contained in the cert before you removed it to send to me?

Is there a purpose for having that in the same file as the certificate?

I believe you will find that having removed the key from the cert everything should work as expected.


Kind Regards,

Kaleb

Hi stamp_age,

Yes I can. I believe you need to define "HAVE_ECC" in the pre-processor macros for VS2010 project to get same ciphers as supported in the TIRTOS project. Try that first and if it does not work we'll go from there.

Edit the file <wolfssl-root>\IDE\WIN\user_settings.h and add the following line at the top of the file just above the line with "/* Configurations */" comment (So both the library and the client/server build with this define):

#define HAVE_ECC

Now rebuild and try the connection again and let me know if that works.


Kind Regards,

Kaleb

669

(6 replies, posted in wolfSSL)

Hi will,

Could you send me a copy of the slockhomecerts.pem NOTICE: DO NOT SEND ME YOUR PRIVATE KEY PLEASE

So I can verify it is properly formatted.

What exactly is the PEM header and where should it be located?

This is the PEM header: "-----BEGIN CERTIFICATE-----"

This should be located immediately prior to the hex representation of the certificate.


Kind Regards,

Kaleb

670

(1 replies, posted in wolfSSL)

Hi jesussotofan,

Could you tell me which board you are working with and what your available RAM and FLASH is?

For the AES algorithm to work unfortunately requires very large static tables (10280 bytes of RO or 10k). These can be viewed in <wolfssl-root>/wolfcrypt/src/aes.c under the define NEED_AES_TABLES. The only to get around using the tables in software is to have an AES hardware module on the board you're working with. It is very likely your board does not have that feature but it would not hurt to check.

If you do not have a hardware AES module and the tables will not fit into the available memory space... since this is a research project and you're probably not extremely concerned with bit-strength of the algorithm chosen... might I suggest instead using one of the following ciphers as alternates to AES:

wc_AesSetKey             [4338 bytes code size | 10280 bytes RO data] Very Big footprint

Non-Stream cipher:
wc_Des3_SetKey           [1560 bytes code size | 2200 bytes RO data]  Medium footprint

Stream ciphers:

wc_Chacha_SetKey         [1160 bytes code size | 32 bytes RO data  ] smaller footprint
wc_Arc4SetKey            [184  bytes code size | 0 bytes RO data   ] tiny footprint

All of these work fine on the Intel Gallileo, however if you platform is truely limited to 2k RAM as your error would indicate you will have to go with a much smaller algorithm.


Kind Regards,

Kaleb (AKA kalsheraut on pi forums)

671

(3 replies, posted in wolfSSL)

Hi jesussotofan,

Please see my reply to your inquiry on the pi forums: https://www.raspberrypi.org/forums/view … 4#p1054274

Regards,

kaleb

672

(8 replies, posted in wolfCrypt)

Hi jesussotofan,

You're correct, wc_aes.c was a typo, should have been just aes.c.

Now that you have <path-to-arduino>/libraries/wolfssl/(bunch of stuff + aes.c, wc_port.c, coding.c, and error.c) you need to take the last step performed by the script which is to simply create a new file and call it "wolfssl.h" and put this line in it:

/* stub header file for Arduino compatibility */

arduino won't recognize it as a library without a header file with the same name as the directory (that's why I noted to rename wolfssl-x.x.x to simply wolfssl).


Regards,

Kaleb

Hi stamp_age,

The last time we updated the certificates was on Aug 11 20:07:37 2016 GMT

Since there is no

 gettimeofday();

on the TIVA-C the time has to be hard-coded.

In the TIVA-C example there should be a define at the top of the file

#define CURRENTTIME

with some time in epoch seconds.

In the example I have from TI that value is
1410303972 which converted is Tue, 09 Sep 2014 23:06:12 GMT

So basically whats happening is your board thinks it's last year, or sometime before Aug 11 when we updated the certificates in our library.

Please change that value to: 1471035600 which will tell your board it's Aug 12 21:00:00 2016 GMT
                                 or to: 1476377542 which is right now Oct 13 2016 16:52:22 GMT

For other Epoch dates there's a nice tool online here: http://www.epochconverter.com/


Kind Regards,

Kaleb

674

(8 replies, posted in wolfSSL)

Reviewing old blog posts and came across this. For completeness sake secure renegotiation was added for client side in release 3.3.0 (wolfSSL is now on stable release 3.9.10)

https://wolfssl.com/wolfSSL/Blog/Entrie … 3.3.0.html

NOTE: This is not secure despite the name "Secure Renegotiation" it is prone to MIM attacks.

See: CVE-2009-3555 ( https://cve.mitre.org/cgi-bin/cvename.c … -2009-3555 ) for further details. We provided this due to customer demand but we do not recommend it be used EVER!

Please keep in mind this feature will not be available in TLS1.3 which wolfSSL will implement as soon as the draft is finalized. (so plan accordingly)

Kind Regards,

Kaleb & the wolfSSL Team

675

(8 replies, posted in wolfCrypt)

Hi jesussotofan,

There are a couple of steps needed when building for Arduino. Most notably I will point out we have only ever tested the following on Intel Galileo board. We have not ported to any other platforms using Arduino.

You stated you only desire to use AES encrypt and decrypt, is this the only functionality you need? Are you not doing any TLS?
If this is the case you should be able to compile a select subset of our libraries which means you would only place the following four files in the <wolfssl-root> directory and then copy the root directory into the search path for Arduino.

wc_port.c                                                                
coding.c                                                                                                                                
aes.c                                                                 
error.c

If that is not the case and you intend to do a full build then the steps are just about as simple as the README implies. I will try to simplify more:

In arduino IDE hit File->open
By default you should be looking at a directory containing a folder named "libraries"
Note where that folder is located.
Now take wolfssl download.
If your download has "wolfssl-x.x.x" as the name, rename it to simply "wolfssl". I will refer to this directory as <wolfssl-root>, it just means the top-level wolfssl directory as we also have a directory inside the root directory named "wolfssl".
copy/paste the entire <wolfssl-root> directory into the "libraries" directory, not at the same level.
You should now have:

<path-to-arduino>/libraries/wolfssl
now follow the steps in the README for moving all the .c source files to the root directory of wolfssl and building the libraries.


Make sure you have the correct settings
In the Arduino IDE check Tools -> Board
by default this is set to something like "Arduino/Genuino Uno" if that is not the board you're building for then select the correct board. If you do not see the board you are looking for then select the "Board Manager" option and find the correct board support and install it. Then restart the IDE and again go Tools -> Board and find your board.

If you have any further trouble let us know.


Kind Regards,

Kaleb