RECENT BLOG NEWS
wolfSSL Release 5.6.4
wolfSSL version 5.6.4 is now available! This update introduces a number of exciting new features. We’ve added post-quantum support to DTLS 1.3, expanded sniffer support with keylog use, integrated post-quantum stateful hash-based signature schemes like LMS/HSS and XMSS/XMSS^MT, introduced Ada bindings, expanded our range with additional SM2 cipher suites, and incorporated AES EAX mode, and much more! Alongside these enhancements, the release brings quality improvements and addresses one identified vulnerability. You can review the full rundown of updates in the included ChangeLog.md. Here’s a breakdown of the latest features and enhancements:
New Feature Additions
- DTLS 1.3 PQC: support fragmenting the second ClientHello message. This allows arbitrarily long keys to be used, opening up support for all PQC ciphersuites in DTLS 1.3.
- SM2/SM3/SM4: Chinese cipher support including TLS 1.3 and 1.2 cipher suites. SM2 SP math implementation available for improved performance and minimum size. Bare metal support available.
- Ability to parse ASN1 only with SMIME_read_PKCS7
- Added support for MemUse Entropy on Windows
- Added Ada Bindings for wolfSSL, benefiting Ada language users who need to add security and FIPS to their designs.
- Added a PEM example that converts to and from DER/PEM.
- Added LMS/HSS and XMSS/XMSS^MT stateful hash-based signature scheme wolfcrypt hooks, both normal and verify-only options. wolfBoot, wolfSSH, and wolfSSL will inherit this functionality from wolfCrypt for users moving to CNSA 2.0
- Added support for the AES EAX mode of operation
- Port for use with Hitch (https://github.com/varnish/hitch) added
- Add XTS API’s to handle multiple sectors in the new port to VeraCrypt. VeraCrypt users now have access to FIPS based encryption of wolfCrypt.
- Sniffer tool now supports decrypting TLS sessions using secrets obtained from a SSLKEYLOGFILE
Enhancements and Optimizations
- Turned on SNI by default on hosts with resources
- Improved support for Silicon Labs Simplicity Studio and the ERF32 Gecko SDK
- Thumb-2 and ARM32 Curve25519 and Ed25519 assembly have significantly improved performance.
- Thumb-2 AES assembly code added.
- Thumb-2 and ARM32 SP implementations of RSA, DH and ECC have significantly improved performance.
- Minor performance improvements to SP ECC for Intel x64.
- AES-XTS assembly code added for Intel x64, Aarch64 and ARM32 to dramatically improve performance
- Added support for X963 KDFs to ECIES.
- Added 32-bit type only implementation of AES GMULT using tables.
- Add support for nginx version 1.25.0 for those using nginx with wolfSSL
- Add support for Kerberos version 5 1.21.1
- Check all CRL entries in case a single issuer has multiple CRL’s loaded
- CRL verify of the entire chain including loaded CA’s
- Added example for building wolfSSL as an Apple universal binary framework using configure
If you have questions about any of the above, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.
Download wolfSSL Now
Live Webinar: FIPS 140-3 OE additions and planning for 2024 and beyond
Join us for the highly anticipated FIPS 140-3 webinar! Save the date for our insightful session, ‘FIPS 140-3 OE Additions and Planning for 2024 and Beyond,’ led by wolfSSL’s Senior Software Engineer, Kaleb, scheduled for December 7th at 10 am PT. wolfSSL, a leader in embedded FIPS certificates, is on the verge of certifying wolfCrypt for FIPS 140-3.
Save the date: December 7th at 10am PT
Discover the latest updates and exciting news during this webinar, including:
- Progress updates and status of our FIPS 140-3 pursuit
- Notable differences between 140-2 and 140-3 standards
- Insights on Post-Quantum and NSA 2.0 Suite
- Engage with us during Q&A, offering input for our next submission
In this session, Kaleb will share exclusive insights into FIPS 140-3, providing valuable information to align your projects with FIPS requirements. Register now while seats last! Please note, webinar content may be subject to change.
As always, our webinars will include Q&A sessions throughout. If you have questions on any of the above, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.
Download wolfSSL Now
wolfSSL Support for Nginx 1.25.0 and 1.24.0
In wolfSSL release 5.6.4, we have updated support for Nginx versions 1.24.0 and 1.25.0. Nginx is a high-performance, high-concurrency web server which is compact, fast, and highly scalable. This makes wolfSSL a good choice for the TLS backend. wolfSSL is an embedded SSL/TLS library which supports a wide range of architectures and operating systems.
The instructions to build Nginx with wolfSSL can be found at https://github.com/wolfSSL/wolfssl-nginx
If you have any questions about using Nginx with wolfSSL, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.
Download wolfSSL Now
Support for DTLS 1.3 early data
The wolfSSL implementation of DTLS 1.3 supports Early Data or 0-RTT Data. Early Data is application data that can be sent by the client with the very first ClientHello message. It is also called 0-RTT Data because it requires 0 Round Trip Time before application data can be sent. To utilize Early Data in DTLS 1.3, the server needs to omit the cookie exchange when using a PSK connection. The handshake using Early Data is presented in the following figure.
Client Server ClientHello + early_data + key_share + psk_key_exchange_modes + pre_shared_key Early Data --------> ServerHello + pre_shared_key + key_share EncryptedExtensions + early_data Finished <-------- Application Data EndOfEarlyData Finished --------> Application Data <-------> Application Data
To use DTLS 1.3 Early Data in wolfSSL without the cookie exchange, the server needs to be modified:
- Compile wolfSSL with WOLFSSL_DTLS13_NO_HRR_ON_RESUME defined
- When compiling with configure add CPPFLAGS=-DWOLFSSL_DTLS13_NO_HRR_ON_RESUME
- When compiling with user settings add #define WOLFSSL_DTLS13_NO_HRR_ON_RESUME
- Call wolfSSL_dtls13_no_hrr_on_resume(ssl, 1) on the WOLFSSL object to disable the cookie exchange on resumption
- Continue like with a normal connection
Early Data is protected by using the cipher material associated with the PSK (pre-shared key). This can either be the cipher material of the previous connection when using a ticket or out-of-band cipher material when using a real PSK. As a result of using previous cipher material, Early Data can compromise PFS (Perfect Forward Secrecy).
For any questions about DTLS 1.3 and Early Data in wolfSSL, please contact us at facts@wolfssl.com or call us at +1 425 245 8247.
Download wolfSSL Now
Aarch64 Gets a Performance Boost in wolfCrypt
We at wolfSSL are continuously improving performance of the wolfCrypt code. Recently we took a look at our AES-GCM on Aarch64 and thought: we can do better.
By using the cryptographic instructions built into Aarch64 chips we had already gotten a significant boost over straight C but we saw that we could do more. By unrolling loops, interleaving the GCM calculation with AES encryption and using NEON as well as the base instructions at the same time, we were able to see a significant improvement!
How significant? Up to 9.5 times faster! The wolfSSL 5.6.4 numbers on an Apple M1 were:
------------------------------------------------------------------------------ wolfSSL version 5.6.4 ------------------------------------------------------------------------------ wolfCrypt Benchmark (block bytes 1048576, min 1.0 sec each) AES-128-GCM-enc 1845 MB took 1.000 seconds, 1845.382 MB/s AES-128-GCM-dec 907 MB took 1.005 seconds, 902.210 MB/s AES-192-GCM-enc 1845 MB took 1.002 seconds, 1842.527 MB/s AES-192-GCM-dec 902 MB took 1.002 seconds, 900.038 MB/s AES-256-GCM-enc 1845 MB took 1.000 seconds, 1844.793 MB/s AES-256-GCM-dec 897 MB took 1.001 seconds, 895.873 MB/s Benchmark complete
And now with the new assembly code:
------------------------------------------------------------------------------ wolfSSL version master ------------------------------------------------------------------------------ wolfCrypt Benchmark (block bytes 1048576, min 1.0 sec each) AES-128-GCM-enc 8583 MB took 1.000 seconds, 8580.862 MB/s AES-128-GCM-dec 8583 MB took 1.000 seconds, 8580.389 MB/s AES-192-GCM-enc 7875 MB took 1.001 seconds, 7870.179 MB/s AES-192-GCM-dec 7922 MB took 1.000 seconds, 7921.097 MB/s AES-256-GCM-enc 7067 MB took 1.000 seconds, 7064.394 MB/s AES-256-GCM-dec 7230 MB took 1.001 seconds, 7225.034 MB/s Benchmark complete
Try it out and you will see that the encryption and decryption of TLS packets will appear insignificant.
Are there other algorithms on Aarch64 whose performance you would like to see us improve? Let us know!
If you have questions about any of the above, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247
Download wolfSSL Now
Windows support added for our software-based source of entropy (wolfEntropy)
wolfEntropy, a software-based entropy source developed by the wolfSSL team, leverages timing jitter variations in memory accesses across various cache levels to generate entropy. It has been available since wolfSSL v5.5.4, and support for Windows has been introduced. This eliminates the need for hardware redesign to incorporate a hardware-based entropy source.
The first general purpose high performance software entropy source is available now!
It is designed to fully conform with SP800-90B. The SP800-90B is a publication by the National Institute of Standards and Technology (NIST) that specifies the requirements for entropy sources used in cryptographic applications.
The wolfEntropy library source is undergoing testing to meet the criteria of a certified entropy source as outlined in the publication. It will soon proceed through the FIPS Entropy Source Validation (ESV) process.
The design of wolfEntropy is depicted in this figure:
When dealing with Unix-style systems that employ autoconf/autotools for configuring the wolfCrypt cryptographic module and integrating wolfEntropy as a component, you need to adhere to these basic configuration prerequisites:
Using Auto-tools:
./configure –enable-entropy-memuse=nofallback
Enabling the nofallback feature is crucial in this context. It restricts the system from using any other entropy source apart from wolfEntropy, even if wolfEntropy experiences a failure in any of its health tests. This strict condition ensures SP800-90B compliance.
For Windows and systems using user_settings.h to fine-tune the wolfCrypt cryptographic module along with wolfEntropy as a component, you can configure your CFLAGS with the following options:
CFLAGS=”-DHAVE_ENTROPY_MEMUSE -DWOLFSSL_SHA3 -DENTROPY_MEMUSE_FORCE_FAILURE”
Much like the Unix-style systems, the ENTROPY_MEMUSE_FORCE_FAILURE option is pivotal. It disables the use of any other entropy source, allowing only wolfEntropy to be utilized. This adherence to ENTROPY_MEMUSE_FORCE_FAILURE ensures SP800-90B compliance.
If you have questions about any of the above, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.
Download wolfSSL Now
Live Webinar: wolfSSL and Automotive Hardware Security Modules (HSMs)
Join us on an informative webinar about wolfSSL and Automotive Hardware Security Modules (HSMs) presented by wolfSSL Software Engineer, Bill, on November 30th at 10 am PT. In today’s automotive landscape, vehicles have transformed into sophisticated digital systems, making automotive cybersecurity a paramount concern.
During this webinar, Bill will delve into the world of HSMs and explore how wolfSSL is dedicated to safeguarding data in connected vehicles.
Save the date: November 30th at 10 am PT
Sneak peek of the webinar
- Automotive HSM Features and benefits
- Exploring wolfHSM Functional Design
- wolfHSM Applicability to Standards
- wolfHSM Hardware Ports and Plans
- wolfHSM Demo on Infineon Aurix Tricore TC3xx
- Future Targets of wolfHSM technology
- And much more
Don’t miss this opportunity to expand your knowledge and technical skills in Automotive HSMs. Discover the full potential that wolfSSL products can offer and how wolfSSL products enhance automotive security. Bring all your questions related to Automotive HSMs and get ready to learn insights on automotive HSMS from Bill.
Seats are limited, so make sure to Register Now!
If you have questions about any of the above, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.
Download wolfSSL Now
wolfSSL adds ShangMi ciphers and algorithms SM2, SM3, and SM4 to wolfCrypt
As many people know, Chinese government regulators are now mandating use of SM2, SM3 and SM4 in critical systems, including automobiles, avionics, power systems, and communication systems. Since many of our customers are multi-nationals that do business in China, they have been requesting the addition of these algorithms in wolfSSL products.
Today we are about to release our supported versions of SM2, SM3, and SM4, with the intention to release the ZUC stream cipher at some point this year to completely satisfy SM9. We are also in contact with labs regarding support of OSCCA certification at some point in the future.
This is really great news for our customers selling into Chinese markets!
For those readers considering using wolfSSL products, here’s some additional notes:
- The SM Ciphers will be fully supported in wolfSSL’s TLS 1.3 implementation.
- wolfSSH, wolfBoot and our other products will support ShangMi ciphers.
- ARM, Intel, and RiscV assembly is in the works for our SM implementations for maximum performance.
- We will continue to support bare metal for ZUC, SM2, SM3, and SM4.
- True to form, we have maximized performance and minimized size, so the ShangMi algorithms will work well for embedded systems use cases on a wide variety of microcontrollers (MCU’s). They will be available for all of the MCU silicon that we currently support, including STM32, NXP i.MX, RISC-V, Renesas RA, RX, and Synergy, Nordic NRF32, Microchip PIC32, Infineon Aurix, TI MSP, and many others.
- Our GPLv2 licensed versions of the SM ciphers will be made available on GitHub and for download.
Commercially licensed versions are available.
If you have questions about our support for the ShangMi ciphers and algorithms, please contact us at facts@wolfSSL.com, or call us at +1 425 245 8247.
Download wolfSSL Now
Improved Silicon Labs Simplicity Studio support
In WolfSSL release v5.6.4 we have added support for Silicon Labs’ Simplicity Studio. In addition we have tested with the ERF32xG21 series of chips and have created an example setup. More information can be found in the WolfSSL repo.
Using our benchmarking tool, we have the following results from a Cortex M33 at 80MHz:
wolfCrypt Benchmark | (block bytes 1024, min 1.0 sec each) | ||
RNG | 200 KiB took 1.057 seconds | 189.215 KiB/s | |
AES-128-CBC-enc | 6 MiB took 1.000 seconds | 5.542 MiB/s | |
AES-128-CBC-dec | 6 MiB took 1.000 seconds | 5.518 MiB/s | |
AES-192-CBC-enc | 5 MiB took 1.001 seconds | 5.415 MiB/s | |
AES-192-CBC-dec | 5 MiB took 1.001 seconds | 5.390 MiB/s | |
AES-256-CBC-enc | 5 MiB took 1.004 seconds | 5.301 MiB/s | |
AES-256-CBC-dec | 5 MiB took 1.001 seconds | 5.268 MiB/s | |
AES-128-GCM-enc | 5 MiB took 1.003 seconds | 4.844 MiB/s | |
AES-128-GCM-dec | 5 MiB took 1.003 seconds | 4.625 MiB/s | |
AES-192-GCM-enc | 5 MiB took 1.002 seconds | 4.751 MiB/s | |
AES-192-GCM-dec | 5 MiB took 1.002 seconds | 4.532 MiB/s | |
AES-256-GCM-enc | 5 MiB took 1.002 seconds | 4.654 MiB/s | |
AES-256-GCM-dec | 4 MiB took 1.000 seconds | 4.443 MiB/s | |
AES-128-GCM-enc-no_AAD | 5 MiB took 1.004 seconds | 4.888 MiB/s | |
AES-128-GCM-dec-no_AAD | 5 MiB took 1.001 seconds | 4.658 MiB/s | |
AES-192-GCM-enc-no_AAD | 5 MiB took 1.000 seconds | 4.785 MiB/s | |
AES-192-GCM-dec-no_AAD | 5 MiB took 1.000 seconds | 4.565 MiB/s | |
AES-256-GCM-enc-no_AAD | 5 MiB took 1.004 seconds | 4.693 MiB/s | |
AES-256-GCM-dec-no_AAD | 4 MiB took 1.003 seconds | 4.479 MiB/s | |
GMAC Small | 5 MiB took 1.000 seconds | 4.653 MiB/s | |
CHACHA | 2 MiB took 1.012 seconds | 1.809 MiB/s | |
CHA-POLY | 1 MiB took 1.006 seconds | 1.189 MiB/s | |
POLY1305 | 5 MiB took 1.004 seconds | 5.082 MiB/s | |
SHA | 8 MiB took 1.000 seconds | 7.812 MiB/s | |
SHA-256 | 8 MiB took 1.000 seconds | 8.032 MiB/s | |
HMAC-SHA | 7 MiB took 1.000 seconds | 7.056 MiB/s | |
HMAC-SHA256 | 7 MiB took 1.002 seconds | 7.237 MiB/s | |
RSA 2048 public | 30 ops took 1.022 sec | avg 34.067 ms | 29.354 ops/sec |
RSA 2048 private | 2 ops took 2.398 sec | avg 1199.000 ms | 0.834 ops/sec |
ECC [SECP256R1] 256 key gen | 172 ops took 1.004 sec | avg 5.837 ms | 171.315 ops/sec |
ECDHE [SECP256R1] 256 agree | 186 ops took 1.005 sec | avg 5.403 ms | 185.075 ops/sec |
ECDSA [SECP256R1] 256 sign | 174 ops took 1.007 sec | avg 5.787 ms | 172.790 ops/sec |
ECDSA [SECP256R1] 256 verify | 160 ops took 1.003 sec | avg 6.269 ms | 159.521 ops/sec |
If you have questions about any of the above, please contact us at facts@wolfSSL.com, call us at +1 425 245 8247 or visit out FAQ page.
Download wolfSSL Now
Targets supported by wolfBoot
Designed by Freepik: www.freepik.com
Here at wolfSSL, we pride ourselves on the portability of our products. An essential part of the real-world applicability of our projects is that they can run in various environments in support of various use cases. We recently published an incomplete list of parts that our SSL/TLS library wolfSSL has been run on. Since our secure bootloader wolfBoot shares the same flexibility, we wanted to share a similar list of supported targets and architectures.
Here’s a list of supported CPU architectures:
CPU Architectures |
ARMv6-M Cortex-M0 |
ARMv7-A Cortex-A9 |
ARMv7-M Cortex-M3 |
ARMv7-M Cortex-M4 |
ARMv7-M Cortex-M7 |
ARMv7-R Cortex-R5 |
ARMv8-A Cortex-A53 |
ARMv8-A Cortex-A57 |
ARMv8-M Cortex-M33 |
PowerPC 32-Bit |
PowerPC 64-Bit |
RV32 32-Bit RISC-V |
Intel x86 32-Bit |
Intel x86 64-Bit |
RXv3 core |
Here’s a list of supported hardware parts and their manufacturers:
Part | Manufacturer |
Xilinx UltraScale+ ZCU102 | AMD |
PSoC 62S2 | Infineon/Cypress |
i.MX-RT1050 | NXP/Freescale |
i.MX-RT1060 | NXP/Freescale |
i.MX-RT1064 | NXP/Freescale |
Kinetis K64 | NXP/Freescale |
Kinetis K82 | NXP/Freescale |
QorIQ P1021 | NXP/Freescale |
QorIQ T1024 | NXP/Freescale |
QorIQ T2080 | NXP/Freescale |
QorIQ LS1028A | NXP/Freescale |
LPC54xxxx | NXP/Freescale |
nRF5280 | Nordic |
11th Gen Core i7 (Tiger Lake) | Intel |
PI3 | RaspberryPi |
RX72N | Renesas |
RA6M4 | Renesas |
STM32C0xx | ST Microelectronics |
STM32F4xx | ST Microelectronics |
STM32F7xx | ST Microelectronics |
STM32G0xx | ST Microelectronics |
STM32H7xx | ST Microelectronics |
STM32L0xx | ST Microelectronics |
STM32L4xx | ST Microelectronics |
STM32L5xx | ST Microelectronics |
STM32U5xx | ST Microelectronics |
STM32WBxx | ST Microelectronics |
HiFive1 | SiFive (RISC-V) |
ATSAMR21 | Microchip (Atmel) |
TM4C1294xx | Texas Instruments |
TMS570lc4xx | Texas Instruments |
CC26x2 | Texas Instruments |
For info on the wolfBoot configuration details of the targets listed above, visit https://github.com/wolfSSL/wolfBoot/blob/master/docs/Targets.md. For wolfBoot usage examples, visit https://github.com/wolfSSL/wolfBoot-examples.
Don’t see your part/architecture on this list? Not to worry! The minimalistic design and tiny HAL API of wolfBoot make it portable to the highest degree. Reach out to us letting us know the details of your system and we can get you in touch with our porting experts.
If you have questions, comments, and suggestions about any of the above, contact us at facts@wolfssl.com or call us at +1 425 245 8247.
Download wolfSSL Now
XMSS and LMS in wolfBoot and wolfCrypt for CNSA 2.0
Designed by Freepik: www.freepik.com
Have you seen the recently released wolfBoot v2.0.0? It is full of a lot of interesting new features and optimizations. You can see full detail in the changelog.
What about the CNSA 2.0 Guidance? We’ve mentioned it many times in our blog posts. You can find it here.
You might be wondering, what do these have to do with each other? The NSA’s CNSA 2.0 guidance specifically states that LMS/HSS and XMSS/XMSS^MT are appropriate for firmware signing. These algorithms are now supported in the 2.0.0 release of wolfBoot. They depend on our LMS and XMSS integrations in wolfCrypt which are part of the recently released 5.6.4 version of wolfSSL! So, you can start working with these algorithms and signing and verifying your firmware images TODAY.
Being able to do that today is really important because the CNSA 2.0 says that LMS/HSS and XMSS/XMSS^MT are to be added as an option and tested in your systems and products today. By 2025, only a year from now, these algorithms are to be the default and preferred algorithms. By 2030, all other algorithms are to be phased out.
Are you ready to meet these expectations? You are if you use wolfBoot!
If you have questions about any of the above, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.
Download wolfSSL Now
Weekly updates
Archives
- December 2023 (2)
- 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 (9)
- September 2022 (7)
- August 2022 (12)
- July 2022 (11)
- June 2022 (15)
- May 2022 (11)
- April 2022 (14)
- March 2022 (12)
- February 2022 (22)
- January 2022 (13)
- December 2021 (13)
- November 2021 (29)
- October 2021 (15)
- September 2021 (15)
- August 2021 (13)
- July 2021 (21)
- June 2021 (19)
- May 2021 (12)
- April 2021 (13)
- March 2021 (27)
- February 2021 (29)
- January 2021 (22)
- December 2020 (21)
- November 2020 (14)
- October 2020 (7)
- September 2020 (22)
- August 2020 (11)
- July 2020 (8)
- June 2020 (14)
- May 2020 (15)
- April 2020 (14)
- March 2020 (4)
- February 2020 (24)
- January 2020 (18)
- December 2019 (7)
- November 2019 (16)
- October 2019 (14)
- September 2019 (24)
- August 2019 (21)
- July 2019 (8)
- June 2019 (13)
- May 2019 (35)
- April 2019 (31)
- March 2019 (20)
- February 2019 (10)
- January 2019 (16)
- December 2018 (24)
- November 2018 (10)
- October 2018 (18)
- September 2018 (18)
- August 2018 (8)
- July 2018 (15)
- June 2018 (29)
- May 2018 (15)
- April 2018 (11)
- March 2018 (19)
- February 2018 (6)
- January 2018 (11)
- December 2017 (5)
- November 2017 (12)
- October 2017 (7)
- September 2017 (8)
- August 2017 (6)
- July 2017 (11)
- June 2017 (8)
- May 2017 (10)
- April 2017 (5)
- March 2017 (7)
- February 2017 (1)
- January 2017 (8)
- December 2016 (3)
- November 2016 (2)
- October 2016 (18)
- September 2016 (8)
- August 2016 (5)
- July 2016 (4)
- June 2016 (10)
- May 2016 (4)
- April 2016 (5)
- March 2016 (4)
- February 2016 (12)
- January 2016 (6)
- December 2015 (4)
- November 2015 (6)
- October 2015 (6)
- September 2015 (5)
- August 2015 (8)
- July 2015 (7)
- June 2015 (9)
- May 2015 (1)
- April 2015 (4)
- March 2015 (13)
- January 2015 (6)
- December 2014 (7)
- November 2014 (3)
- October 2014 (2)
- September 2014 (11)
- August 2014 (6)
- July 2014 (9)
- June 2014 (11)
- May 2014 (11)
- April 2014 (9)
- March 2014 (3)
- February 2014 (3)
- January 2014 (5)
- December 2013 (9)
- November 2013 (4)
- October 2013 (7)
- September 2013 (3)
- August 2013 (9)
- July 2013 (7)
- June 2013 (4)
- May 2013 (8)
- April 2013 (4)
- March 2013 (2)
- February 2013 (3)
- January 2013 (9)
- December 2012 (13)
- November 2012 (5)
- October 2012 (7)
- September 2012 (4)
- August 2012 (6)
- July 2012 (4)
- June 2012 (3)
- May 2012 (5)
- April 2012 (7)
- March 2012 (2)
- February 2012 (5)
- January 2012 (7)
- December 2011 (5)
- November 2011 (7)
- October 2011 (6)
- September 2011 (6)
- August 2011 (5)
- July 2011 (2)
- June 2011 (8)
- May 2011 (12)
- April 2011 (4)
- March 2011 (12)
- February 2011 (8)
- January 2011 (13)
- December 2010 (17)
- November 2010 (12)
- October 2010 (14)
- September 2010 (11)
- August 2010 (20)
- July 2010 (14)
- 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)