RECENT BLOG NEWS
STM32 and wolfSSL – Hardware Crypto and RNG Support
We would like to announce that the wolfSSL embedded SSL library now has support for hardware-based cryptography and random number generation offered by the STM32F2. Supported cryptographic algorithms include AES (CBC, CTR), DES (ECB, CBC), 3DES, MD5, and SHA1. For details regarding the STM32F2 crypto and hash processors, please see the STM32F2xx Standard Peripheral Library document (linked below).
If you are using the STM32F2 with wolfSSL, you can see substantial speed improvements when using the hardware crypto versus using wolfSSL’s software crypto implementation. The following benchmarks were gathered from the CTaoCrypt benchmark application (ctaocrypt/benchmark/benchmark.c) running on the STM3221G-EVAL board (STM32F2) using the STM32F2 Standard Peripheral Library and FreeRTOS.
wolfSSL Software Crypto, Normal Big Integer Math Library
AES 1024 kB took 0.822 seconds, 1.22 MB/s
ARC4 1024 KB took 0.219 seconds, 4.57 MB/s
DES 1024 KB took 1.513 seconds, 0.66 MB/s
3DES 1024 KB took 3.986 seconds, 0.25 MB/s
MD5 1024 KB took 0.119 seconds, 8.40 MB/s
SHA 1024 KB took 0.279 seconds, 3.58 MB/s
SHA-256 1024 KB took 0.690 seconds, 1.45 MB/s
RSA 2048 encryption took 111.17 milliseconds, avg over 100 iterations
RSA 2048 decryption took 1204.77 milliseconds, avg over 100 iterations
DH 2048 key generation 467.90 milliseconds, avg over 100 iterations
DH 2048 key agreement 538.94 milliseconds, avg over 100 iterations
STM32F2 Hardware Crypto, Normal Big Integer Math Library
AES 1024 kB took 0.105 seconds, 9.52 MB/s
ARC4 1024 KB took 0.219 seconds, 4.57 MB/s
DES 1024 KB took 0.125 seconds, 8.00 MB/s
3DES 1024 KB took 0.141 seconds, 7.09 MB/s
MD5 1024 KB took 0.045 seconds, 22.22 MB/s
SHA 1024 KB took 0.047 seconds, 21.28 MB/s
SHA-256 1024 KB took 0.690 seconds, 1.45 MB/s
RSA 2048 encryption took 111.09 milliseconds, avg over 100 iterations
RSA 2048 decryption took 1204.88 milliseconds, avg over 100 iterations
DH 2048 key generation 467.56 milliseconds, avg over 100 iterations
DH 2048 key agreement 542.11 milliseconds, avg over 100 iterations
As the above benchmarks (and chart) show, the hardware-based algorithms on the STM32 demonstrate significantly faster speeds than that of their software counterparts.
To enable STM32 hardware crypto and RNG support, define STM32F2_CRYPTO and STM32F2_RNG when building wolfSSL. For a more complete list of defines which may be required, please see the WOLFSSL_STM32F2 define in
If you would like to use wolfSSL with STM32 hardware-based cryptography or RNG, or have any questions, please contact us at facts@wolfssl.com for more information.
wolfSSL embedded SSL library
STM32: http://www.st.com/internet/mcu/class/1734.jsp
STM32F2 Standard Peripheral Library documentation: http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/USER_MANUAL/DM00023896.pdf
wolfSSL 2.4.6 is Now Available
Version 2.4.6 of the wolfSSL embedded SSL/TLS library has been released and is now available for download. This release contains bug fixes and has a few new features including:
– ECC into main (GPLv2) version
– Lean PSK build (reduced code size, RAM usage, and stack usage)
– FreeBSD CRL monitor support
– wolfSSL_peek()
– wolfSSL_send() and wolfSSL_recv() for I/O flag setting
– CodeWarrior Support
– MQX / MFS / RTCS Support
– Freescale Kinetis support including Hardware RNG
– autoconf builds use jobserver
– cyassl-config
– Sniffer memory reductions
Thanks to Brian Aker for the improved autoconf system, make rpm, cyassl-config, warning system, and general good ideas for improving wolfSSL!
The Freescale Kinetis K70 RNGA documentation can be found in Chapter 37 of the K70 Sub-Family Reference Manual:
http://cache.freescale.com/files/microcontrollers/doc/ref_manual/K70P256M150SF3RM.pdf
To download the open source, GPLv2-licensed version of wolfSSL 2.4.6, please visit our Download Page. If you have any questions or comments or would like more information on commercial versions of wolfSSL, please contact us at info@yassl.com.
For build instructions, a full feature list, API reference, and more, please see the wolfSSL Manual.
Open Source for America
In case you didn`t notice, open source is growing rapidly in government usage. OpensourceforAmerica.org is keeping a helpful list of resources and examples of how open source is both helping government and expanding in usage. See: http://opensourceforamerica.org/projects/mentors/resources/. Our team is proud to participate in and support the growth of open source use in government and military projects! If you`re wondering how the wolfSSL lightweight SSL implementation is used in government and defense projects, just contact us at info@yassl.com.
wolfSSL Custom I/O: Handshaking
Last week we talked about wolfSSL’s custom I/O handling and how to set it up. The following discussion assumes the I/O callbacks are reading and writing into buffers rather calling send() or recv().
A tricky situation is during the handshake. When calling wolfSSL_connect(), the client will send cipher text first and try to receive a response from the server. The send callback will be called and then the receive callback, which will WANT_READ. Application code will have to actually send the first handshake message and wait for the response.
The server receives and sends in reaction. Its receive callback is called, then its send callback, then the receive which will WANT_READ. The application has to send the handshake message.
Both sides receive and send in reaction to each other. When the handshake hasn’t completed, calls to wolfSSL_read() and wolfSSL_send() call wolfSSL_negotiate() which will drive the handshaking. If things are set up right, a call to wolfSSL_read() may return WANT_READ and the cipher-send buffer will have data to be sent to the peer.
Don`t forget about Valgrind
One of our favorite tools at yaSSL is valgrind: http://valgrind.org . Originally a memory error detector, it`s now an instrumentation framework for dynamic analysis that also does thread error detection, cache and branch-prediction profiling, and heap profiling. If you`ve never used it, you should. If you are using it, you should probably be using it more.
We recently added an –enable-valgrind option to the wolfSSL lightweight SSL library to encourage us to use it more ourselves. If valgrind is installed on your system all of the wolfSSL tests will be run under it. This allows early detection of difficult to track down errors. The detailed output makes tracking down and fixing errors a relatively simple process.
CTaoCrypt on TinyOS with TinyPKC
One of our community members recently ported CTaoCrypt’s RSA and ECC code to the TinOS operating system in a project called TinyPKC (http://www-db.in.tum.de/~kothmayr/tinypkc/). TinyPKC was tested on 16-bit and 32-bit microcontroller platforms and should run on 8-bit platforms as well. It supports ECC key lengths from 112 bits to 521 bits and arbitrary RSA key lengths.
TinyPKC uses a subset of the CTaoCrypt functionality and provides support for the following operations:
– RSA public key encryption / private key decryption
– RSA private key signature generation / public key signature verification
– ECDSA signature generation and verification
– ECDH operations
For more information, please see the TinyPKC website and the included README in the download. Are you interested in running the wolfSSL embedded SSL library on TinyOS? If so, contact us at info@yassl.com.
yaSSL Partnership Program
yaSSL believes that business and technology partnerships are one of the keys to fostering success. Such partnerships can come in many forms – be that business, technical, or community based, and work for both open source or commercial solutions. To date, we have partnered with several companies, and are always looking for new partnerships. To see a list of our current partners, please visit our Partner Page (http://yassl.com/yaSSL/Partners.html).
Are you interested in becoming a partner with yaSSL? If so, contact us at info@yassl.com for more information.
Dark Reading describes the top ten mobile security issues of 2012
Hi! This top ten list crossed our desk today and we thought it was worthwhile to share with our users. Combating MITM attacks and properly implementing SSL/TLS are on the list again this year.
https://www.darkreading.com/top-mobile-vulnerabilities-and-exploits-of-2012/d/d-id/1138833
wolfSSL Custom I/O Setup
wolfSSL provides a mechanism to plug in your own application specific I/O routines. By default, the library uses functions that call the system’s recv() and send() functions with a file descriptor cached with the function wolfSSL_set_fd().
The prototypes for the I/O routines are:
int CBIORecv(CYASSL* ssl, char* buf, int sz, void* ctx);
int CBIOSend(CYASSL* ssl, char* buf, int sz, void* ctx);
In the default case, the network socket’s file descriptor is passed to the I/O routine in the ctx parameter. The ssl parameter is a pointer to the current session. In the receive case, buf points to the buffer where incoming cipher text should be copied for wolfSSL to decrypt and sz is the size of the buffer. In the send case, buf points to the buffer where wolfSSL has written cipher text to be sent and sz is the size of that buffer.
First you need to register your I/O callbacks with the CYASSL_CTX for your application using the functions wolfSSL_SetIORecv() and wolfSSL_SetIOSend().
wolfSSL_SetIORecv(ctx, myCBIORecv);
wolfSSL_SetIOSend(ctx, myCBIOSend);
As an example, for your application you want to control the socket for your own purposes. An example would be to have a server with a datagram socket which receives data from multiple clients or processes TLS through STDIN and STDOUT. In this case you would have four buffers:
cipher-receive encrypted data received from peer
cipher-send encrypted data to send to peer
clear-receive clear data received from wolfSSL
clear-send clear data passed to wolfSSL
Pointers to these buffers, values for their sizes, and read and write positions should be placed into a structure. This structure should be saved to the wolfSSL session with the functions wolfSSL_SetIOReadCtx() and wolfSSL_SetIOWriteCtx().
wolfSSL_SetIOReadCtx(ssl, buffer_data);
wolfSSL_SetIOWriteCtx(ssl, buffer_data);
The application receives a block of cipher text into the buffer cipher-receive. Next the application would call wolfSSL_read(ssl, buffer_data->clear_receive), causing wolfSSL to call myCBIORecv(). myCBIORecv() will be given a buffer, the size of the buffer, and the ctx, which has the cipher-receive buffer. The callback may be called many times for one call to wolfSSL_read(). If the cipher-receive buffer is empty, the callback should return -2, otherwise it should return the number of bytes copied into buf.
When the library wants to send data, like during handshaking or when wolfSSL_send() is called with some clear text, the library will call myCBIOSend(). The callback is given a buffer full of encrypted data, and the length of the encrypted data. In this example, the callback would copy this cipher text into cipher-send and return the number of bytes copied. If the cipher-send buffer isn’t big enough, the callback should return -2.
Using Cryptographic Hashes for Hash Tables
Choosing a good hash function for a hash table is difficult to say the least. Even if you can achieve good distribution and performance for a given hash function it`s still most likely dependent on table size and the type of input. Resizing the table or getting unexpected input can quickly turn an otherwise good choice into a bad one. Using a cryptographic hash function reduces nearly all of the problems. Any and all table sizes are now equally supported. Strings, numbers, and even binary data are all valid input. And since a change in a single bit of input has an avalanche effect on the output, uniform distribution is achieved. Really, the only possible negative is performance. But it`s not nearly as bad as you probably think.
We tested 100 bytes of random data and did the test 1,000,000 times using the hash functions MD5, SHA1, and a typical MULTIPLIER type hash function. Of course the basic hash function was the fastest at 0.66 microseconds per hash. MD5 used 0.78 microseconds per hash while SHA1 consumed 1.02 microseconds per hash. All in all, the small hit in performance seems well worth the gains in being able to use variable table sizes and any type of input without concern. Testing was done using wolfSSL`s cryptography functionality in the CTaoCrypt module.
Weekly updates
Archives
- September 2024 (5)
- August 2024 (24)
- July 2024 (27)
- June 2024 (22)
- May 2024 (28)
- April 2024 (29)
- March 2024 (21)
- February 2024 (18)
- January 2024 (21)
- December 2023 (20)
- November 2023 (20)
- October 2023 (23)
- September 2023 (17)
- August 2023 (25)
- July 2023 (39)
- June 2023 (13)
- May 2023 (11)
- April 2023 (6)
- March 2023 (23)
- February 2023 (7)
- January 2023 (7)
- December 2022 (15)
- November 2022 (11)
- October 2022 (8)
- September 2022 (7)
- August 2022 (12)
- July 2022 (7)
- June 2022 (14)
- May 2022 (10)
- April 2022 (11)
- March 2022 (12)
- February 2022 (22)
- January 2022 (12)
- December 2021 (13)
- November 2021 (27)
- October 2021 (11)
- September 2021 (14)
- August 2021 (10)
- July 2021 (16)
- June 2021 (13)
- May 2021 (9)
- April 2021 (13)
- March 2021 (24)
- February 2021 (22)
- January 2021 (18)
- December 2020 (19)
- November 2020 (11)
- October 2020 (3)
- September 2020 (20)
- August 2020 (11)
- July 2020 (7)
- June 2020 (14)
- May 2020 (13)
- April 2020 (14)
- March 2020 (4)
- February 2020 (21)
- January 2020 (18)
- December 2019 (7)
- November 2019 (16)
- October 2019 (14)
- September 2019 (18)
- August 2019 (16)
- July 2019 (8)
- June 2019 (9)
- May 2019 (28)
- April 2019 (27)
- March 2019 (15)
- February 2019 (10)
- January 2019 (16)
- December 2018 (24)
- November 2018 (9)
- October 2018 (15)
- September 2018 (15)
- August 2018 (5)
- July 2018 (15)
- June 2018 (29)
- May 2018 (12)
- April 2018 (6)
- March 2018 (18)
- February 2018 (6)
- January 2018 (11)
- December 2017 (5)
- November 2017 (12)
- October 2017 (5)
- September 2017 (7)
- August 2017 (6)
- July 2017 (11)
- June 2017 (7)
- May 2017 (9)
- April 2017 (5)
- March 2017 (6)
- January 2017 (8)
- December 2016 (2)
- November 2016 (1)
- October 2016 (15)
- September 2016 (6)
- August 2016 (5)
- July 2016 (4)
- June 2016 (9)
- May 2016 (4)
- April 2016 (4)
- March 2016 (4)
- February 2016 (9)
- January 2016 (6)
- December 2015 (4)
- November 2015 (6)
- October 2015 (5)
- September 2015 (5)
- August 2015 (8)
- July 2015 (7)
- June 2015 (9)
- May 2015 (1)
- April 2015 (4)
- March 2015 (12)
- January 2015 (4)
- December 2014 (6)
- November 2014 (3)
- October 2014 (1)
- September 2014 (11)
- August 2014 (5)
- July 2014 (9)
- June 2014 (10)
- May 2014 (5)
- April 2014 (9)
- February 2014 (3)
- January 2014 (5)
- December 2013 (7)
- November 2013 (4)
- October 2013 (7)
- September 2013 (3)
- August 2013 (9)
- July 2013 (7)
- June 2013 (4)
- May 2013 (7)
- April 2013 (4)
- March 2013 (2)
- February 2013 (3)
- January 2013 (8)
- December 2012 (12)
- November 2012 (5)
- October 2012 (7)
- September 2012 (3)
- August 2012 (6)
- July 2012 (4)
- June 2012 (3)
- May 2012 (4)
- April 2012 (6)
- March 2012 (2)
- February 2012 (5)
- January 2012 (7)
- December 2011 (5)
- November 2011 (7)
- October 2011 (5)
- September 2011 (6)
- August 2011 (5)
- July 2011 (2)
- June 2011 (7)
- May 2011 (11)
- April 2011 (4)
- March 2011 (12)
- February 2011 (7)
- January 2011 (11)
- December 2010 (17)
- November 2010 (12)
- October 2010 (11)
- September 2010 (9)
- August 2010 (20)
- July 2010 (12)
- June 2010 (7)
- May 2010 (1)
- January 2010 (2)
- November 2009 (2)
- October 2009 (1)
- September 2009 (1)
- May 2009 (1)
- February 2009 (1)
- January 2009 (1)
- December 2008 (1)