The windows equivalent is the Cryptography API: Next Generation (CNG) library.
I would like to second using the native encryption supported by the OS. It's still good to have encryption support for when moving to a system that does not have native encryption support. This could be the case for things like Arduino. It's more common to lack the native encryption support when working on embedded devices and I think that is more likely to be limited to iotivity-constrained than iotivity. -----Original Message----- From: Macieira, Thiago Sent: Wednesday, September 21, 2016 6:49 PM To: Nash, George <george.nash at intel.com> Cc: Dave Thaler <dthaler at microsoft.com>; Gregg Reynolds <dev at mobileink.com>; iotivity-dev at lists.iotivity.org Subject: Re: [dev] SECURE build flag setting as default configuration On quarta-feira, 21 de setembro de 2016 15:02:15 PDT Nash, George wrote: > 20:02:51 *********************************** Error: > **************************************** 20:02:51 * Please download mbedtls > using the following command: * 20:02:51 * $ > git clone https://github.com/ARMmbed/mbedtls.git > extlibs/mbedtls/mbedtls * > 20:02:51 > ********************************************************************** > ***** > ******** As we're moving to TCP/TLS support, we should also investigate using native encryption libraries instead of shipping our own. That's OpenSSL for Linux, SecureTransport for Apple OSes, and Microsoft may have something for Windows (I'm not familiar, Qt ships OpenSSL on Windows). This would allow us to offload responsibility for keeping the encryption software to the OS vendor. It also has benefits because encryption routines may be subject to export regulations in some countries. The feature that required mBed TLS should be reverted and rewritten using the native SSL/TLS routines, per OS. The architecture for that change was not reviewed in the mailing list. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center
