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
wolfBoot v2.0.0
Designed by @Noxifer81
The long awaited version 2.0.0 of our bootloader is finally out!
Here is a summary of some of the new key features, selected from the full changelog, available at github.
Post-Quantum secure boot
As previously announced in a recent blog post, wolfBoot 2.0.0 supports post-quantum secure boot.
wolfBoot 2.0.0 is, to our knowledge, the first secure bootloader supporting post-quantum stateful hash-based signature (HBS) schemes for firmware verification.Thanks to the support for LMS/HSS and XMSS/XMSS^MT recently added in wolfCrypt and the integration with third-party signing entities, such as HSM providers, we successfully added HBS schemes to the list of supported algorithms.
wolfBoot as TrustZone-M secure supervisor
The latest generation of ARM Cortex-M microcontroller has introduced a hardware-assisted Trusted Execution Environment (TEE), called TrustZone-M. By installing wolfBoot to secure the boot process on those devices, it is now possible to extend the cryptography library linked with the bootloader to cover multiple algorithms and key lengths beyond those required to implement the secure boot mechanism. An application or operating system running in non-secure mode has access to all those cryptographic operations provided by wolfBoot, through a non-secure-callable API, that is accessible through standard PKCS#11 function calls.
An extended description of this feature has been previewed in a blog post we have recently published.
Advanced TPM features
Since the early days of wolfBoot development, we have been researching the integration with wolfTPM and the unique opportunities it offers to communicate with TPM devices in the very early stages of the target’s boot up process. With wolfBoot 2.0, we expanded this integration to include some new powerful features. Among other things, TPM 2.0 devices can now be used as Root of Trust for the boot process. The extension of the PCRs can be customized according to the specific characteristic of the boot mechanism, to easily implement measured boot at different stages. Moreover, wolfBoot can now seal and unseal non-volatile memory slots in the TPM based both on the verification of externally signed PCR policy and/or password based sealing.
Full support for secure boot on Intel x86-64 bit targets
Adding support for x86-64 targets using Intel’s Firmware Support Packages (FSP) in wolfBoot 2.0.0 has paved the way to controlling the entire secure boot mechanism from the machine power-on. This gives a key advantage in keeping the entire boot process secure on x86-based Single-board Computer systems (SBC). wolfBoot 2.0 boot flow is divided into two stages. The first stage includes basic memory, silicon initialization, PCI enumeration and the interaction with hardware-assisted security mechanisms. The first stage will then verify the second stage and pass control to it. The second stage is responsible for AHCI initialization, SATA disk locking/unlocking, TPM interaction to unseal secrets, verification of entire disk partitions or images and finally staging the image. It supports different payloads: raw images, Linux kernel, or Multiboot2/ELF images.
Find out more about wolfBoot! Download the source code and documentation from download page, or clone the repository from github. If you have any questions about any of the above, comments or suggestions, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.
Download wolfSSL Now
wolfMQTT Releases v1.17.0
The latest release of wolfMQTT, v1.17.0, is now available! This release has several bug fixes and optimizations including:
- Fix for declaration after executable block by @lealem47 in #341
- Add QNX IDE, Makefile, and remove source code exec bit by @JacobBarthelmeh in #317
- update for cmake after wolfssl added NAMESPACE by @JacobBarthelmeh in #343
- Add mutex protection to MqttClient_NetDisconnect by @embhorn in #342
- Add DTLS support to MQTT-SN client by @embhorn in #348
- Tie zephyr tests to a release by @julek-wolfssl in #350
- add documentation link to README by @gojimmypi in #355
- Possible patch for POSIX conditional wait issue by @dgarske in #356
- Fix publish with topic ID >=127 by @embhorn in #351
- Adding publish and subscribe atomic client examples by @embhorn in #347
- Allow disabling the posix conditional signal by @dgarske in #360
- Exclude CI tests with external brokers by @embhorn in #362
- Improvements for client property stack by @dgarske in #361
- Add mosquitto to CI tests by @embhorn in #365
- Fixes for non-blocking edge cases by @dgarske in #363
- Refactor MQTT-SN code by @embhorn in #366
Release 1.17.0 has been developed according to wolfSSL’s development and QA process and successfully passed the quality criteria.
Check out the changelog from the download for a full list of features and fixes, or contact us at facts@wolfSSL.com with any questions.
While you’re there, show us some love and give the wolfMQTT project a Star!
You can download the latest release of wolfMQTT today Or clone directly from our GitHub repository.
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: Everything you need to know about DTLS 1.3
Announcing the Highly-Anticipated Return of the DTLS 1.3 Webinar!
We’re thrilled to invite you to the upcoming webinar, Everything you need to know about DTLS 1.3, on November 9th presented by wolfSSL Senior Software Engineer, Juliusz. If you’re eager to delve deep into the world of DTLS 1.3 and expand your knowledge, this is an unmissable opportunity.
Watch the webinar here: DTLS 1.3 Webinar
As a pioneer in DTLS 1.3 implementation, wolfSSL has brought numerous enhancements and innovations to bolster the security and efficiency of the DTLS protocol. Notably, ExpressVPN recently integrated DTLS 1.3 support into their lightweight core library via wolfSSL. Juliusz will be providing invaluable insights into the DTLS 1.3 protocol improvements and sharing the latest updates on security.
Sneak peek of the webinar:
- Introduction to basic DTLS
- DTLS v1.3 vs v1.2 comparison
- wolfSSL DTLS 1.3 examples and experiments
- Hands-On: utilizing DTLS in UDP applications
- Unveiling new features and updates
This is your perfect opportunity to gain in-depth understanding and enhance your DTLS 1.3 technical skills. Don’t miss out on the chance to learn and have your DTLS 1.3 related questions answered live. Watch it 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
Enhanced PKCS7 support in wolfSSL
Previously with calls to wolfSSL_SMIME_read_PKCS7 in wolfSSL we were automatically performing a verification of the bundle’s signature after parsing it. To support more use cases the behavior was updated to allow for only parsing the ASN.1 syntax when calling wolfSSL_SMIME_read_PKCS7. Now more complex bundle setup’s are supported and more flexible means of verifying the bundle after it has been parsed. One of the more straightforward ways that still exist to verify the bundle is by using wolfSSL_PKCS7_verify.
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
wolfTPM v3.0 Released
This is a major version for wolfTPM. We are excited for this release because it includes some really excellent new features and fixes!
Secure Boot Examples:
This release adds new examples for secure boot. See examples/boot/README.md for details.
We added a new secret sealing/unsealing example based on an externally signed policy. This is a complex use-case showing how to seal a secret based on a policy that is externally signed. The seal operation uses a public key. The private key associated with it is used to sign a policy to allow unsealing that secret. These examples use PCR registers, however there are other policy methods supported by the TPM. See secret_seal and secret_unseal.
We also added an example for anchoring a root of trust in the TPM using an NV in the platform hierarchy and optional NV lock feature. See secure_rot.
Support for ECC Parameter Encryption / Secrets:
We added support for encrypting secrets using ECC key. Allows using ECC for parameter encryption and importing ECC keys with custom seed. (See PR 276)
Authentication Refactor:
This release adds command information including the specific authentication requirements. If a command expects authentication and it is not provided the wolfTPM library will warn (if using –enable-debug). Likewise if a command does not use authentication it will automatically exclude it. If additional authenticated session(s) are available like HMAC or policy it will be included. The user is still required to set the correct session index.
HAL Improvements:
We have refactored the HAL to make it available with the library, not just in the examples. HAL support for Microchip Harmony SPI has been added. The STM32 I2C support has been fixed and performance improved. We added support for memory mapped (MMIO) found on Intel hardware.
PEM support:
We have added new API’s for making it easy to import and load PEM or DER/ASN.1 encoded ECC or RSA keys (private or public).
See “wolfTPM2_ImportPrivateKeyBuffer” and “wolfTPM2_ImportPublicKeyBuffer”
Security Best Practices:
We have added a new API “wolfTPM2_ChangePlatformAuth” to help set the platform authentication. This is useful during the boot phase to prevent access to the platform. Typically a random value is used, since this auth is cleared on reset or power cycle.
Testing has been greatly expanded in this release for our examples including greater use/support of -aes/-xor options for parameter encryption. See examples/run_examples.sh.
Full wolfTPM v3.0.0 Change Log:
Summary
Refactor of command authentication. Support for ECC sessions and secrets. Support for policy sealing/unsealing. Examples for secure boot.
Detail
- Refactor of the command authentication. If command does not require auth do not supply it (PR #305)
- Refactor HAL and added Microchip Harmony SPI HAL support (PR #251)
- Relocate crypto callback code to its own code file (PR #304)
- Fixed using a custom wolfTPM CSR sigType (PR #307)
- Fixed support for ECC 384-bit only support (PR #307)
- Fixed issue with using struct assignment (switched to memcpy) (PR #303)
- Fixed various issues building with C++ compiler (PR #303)
- Fixed issues with STM32 I2C build and improved performance (PR #302)
- Fixed seal with RSA and PCR extend auth. (PR #296)
- Fixed issue including user_settings.h when –disable-wolfcrypt set (PR #285)
- Fixed TPM private key import with custom seed (PR #281)
- Fixed autogen.sh (autoconf) to generate without warnings (PR #279)
- Fixed TPM2 create with decrypt or restricted flag set (PR #275)
- Fixed and improved low resource build options (PR #269)
- Fixed the TPM_E_COMMAND_BLOCKED macro to have the correct value (PR #257)
- Fixed casting and unused variable problems on windows (PR #255)
- Fixed Linux usage of cs_change and added config overrides (PR #268)
- Fixed and improved the NV auth and session auth set/unset (PR #299)
- Fixed capability to handle unknown TPM2_GetCapability type and fix bad printf (PR #293)
- Fixed macros for file IO XFEOF and XREWIND to make sure they are available (PR #277)
- Fixed seal/unseal example (PR #306)
- Fixed TLS examples with param enc enabled (PR #306)
- Fixed signed_timestamp with ECC (PR #306)
- Added CI tests for CSharp wrappers (PR #307)
- Added support for sealing/unsealing based on a PCR that is signed externally (PR #294)
- Added examples for Secure Boot solution to store root of trust in NV (PR’s #276, #289, #291 and #292)
- Added support for importing and loading public ECC/RSA keys formatted as PEM or DER (PR #290)
- Added new policy_nv example (PR #298)
- Added -nvhandle argument to nvram examples (PR #296)
- Added code to test external import between two TPM’s (PR #288)
- Added support for STM32 Cube Expansion Pack (PR #287)
- Added support memory mapped (MMIO) TPM’s (PR #271)
- Added wc_SetSeed_Cb call for FIPS ecc (PR #270)
- Added wrapper support for setting key usage (not just extended key usage) (PR #307)
- Added RSA key import methods to handle PEM and DER encoding directly (PR #252)
- Added thread local storage macro and make gActiveTPM local to the thread (PR #253)
- Added Microchip macro names and Support for bench with MPLABX Harmony (PR #256)
- Added support for encrypting secret using ECC key (PR #276)
- Added wolfTPM2_ChangePlatformAuth wrapper to help set the platform auth (PR #276)
- Improvements to CMake build (PR’s #280, #283 and #284)
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 Extends Support for System CA Certificates to Apple Devices
We are excited to announce an important update for our Apple device users: wolfSSL’s support for installed system CA certificates now extends to Apple devices! This means that applications can now use the convenient wolfSSL_CTX_load_system_CA_certs() API to authenticate TLS connections against certificates installed to the system trust store.
Due to recently introduced OS changes around application sandboxing, applications running on non-macOS Apple platforms can no longer directly access trusted certificates installed on the system. This prevents these certificates from being enumerated and loaded into wolfSSL to use for authentication.
To accommodate this API restriction, we have introduced a new certificate verification routine that relies on Apple’s Security framework APIs to authenticate peer certificates. TLS peer certificates are first checked against the trusted CAs loaded into wolfSSL’s certificate manager, as they always have been. However, if this check is unsuccessful, wolfSSL will now attempt to validate the peer certificate chain using the system trust APIs. This new routine is only used when support for system CA certificates is enabled and when compiling for an Apple target.
If you are building wolfSSL for iOS using configure, this new feature will be on by default and no additional configuration is required by the user. If you are building with a user_settings.h file, you must define the WOLFSSL_SYS_CA_CERTS and WOLFSSL_APPLE_NATIVE_CERT_VALIDATION preprocessor macros, as well as ensure you are linking wolfSSL against the Apple CoreFoundation and Security frameworks. Calling wolfSSL_CTX_load_system_CA_certs() before creating a new TLS connection will now enable system CA certificates to be used for authenticating a peer connection.
To use this feature on MacOS, the steps are the same except that you must define the WOLFSSL_APPLE_NATIVE_CERT_VALIDATION preprocessor macro even when building with configure, as the feature is not on by default.
If you are using cURL + wolfSSL, ensure that the feature is enabled in your wolfSSL build as described above, then set the CURLSSLOPT_NATIVE_CA curlopt in your curl application to indicate the native certificate verification routines should be used.
if you have questions, comments or suggestions about any of the above, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.
Download wolfSSL Now
Repost: wolfBoot support for the STM32C0
Designed by Freepik: www.freepik.com
We are adding wolfBoot support for the new STM32C0. This is a low cost MCU similar to the STM32G0 based on a Cortex-M0 (48MHz). It is a very low cost general purpose 32-bit MCU with up to 32KB flash and 12KB RAM.
Our wolfBoot secure bootloader is the only solution available for this platform thanks to our small code size. Most STM32 parts are supported with wolfBoot out of the box. See our video series with ST for a tutorial on using wolfBoot.
See the STM32C0 announcement from ST.
Features:
- Written in C for bare-metal use
- Small footprint to run on small embedded devices
- Memory safety (no malloc/free)
- Support for on-board or external SPI flash
- Simple partitioning and header scheme
- Abstracted HAL design for CPU speed and flash
- Bootloader handles swapping and loading of partitions
- Key tools for key generation/import and signing
- Encrypted updates
- Delta updates (only differences)
Signature algorithms supported:
- ECC (SECP256R1,SECP384R1)
- RSA (2048/3072/4096)
- ED25519
- ED448
Firmware image integrity using hash digest:
- SHA2-256
- SHA2-384
- SHA3-384
Flexible partition scheme determined at build-time:
- Bootloader (10-30KB)
- Application
- Update
- Swap (1 sector)
- And custom partition ID’s
Reliable Firmware update mechanism:
- Independent from the update transport mechanism
- Fallback to a previous version when the update fails
- Resume interrupted swap operations during update, in case of power failure
Support for STM hardware crypto acceleration:
- STM32 HASH/AES/PKA
- ST33TP* TPM 2.0 using wolfTPM
If you are interested in trying our wolfBoot on the STM32C0, curious about post-quantum signature support in wolfBoot or 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 hosted on Australian time for our Asia Pacific audience: SM Ciphers are now implemented in wolfSSL
How to access them, use them, and what sets them apart.
Join us for an informative webinar on the release of wolfSSL’s SM cipher implementations, presented by wolfSSL Senior Software Engineer Sean on November 3rd at 12pm AEST. This webinar is scheduled for Australian time to cater to our audience in the Asia Pacific region.
Watch the webinar here: wolfSSL’s SM cipher implementations
As many are aware, 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 multinationals that conduct business in China, they have expressed the need for the inclusion of these algorithms in wolfSSL products.
We recently released 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 truly exciting news for our customers in the Chinese markets!
For those considering using wolfSSL products, here are 6 key benefits you will gain:
- The SM Ciphers are fully supported in wolfSSL’s TLS 1.3 and DTLS 1.3 implementations.
- 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 support bare metal for SM2, SM3, and SM4.
- 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 versions of the SM ciphers are available for download on GitHub
Commercially licensed versions are available.
Sean will delve into the insights of SM Ciphers and explain how you can effectively employ SM Ciphers with wolfSSL. Bring all your questions related to ShangMi Ciphers and algorithms; Sean is ready to answer them all.
Sneak peek of the SM Ciphers webinar:
- Background of the ShangMi Ciphers: SM2, SM3, SM4
- TLS and SM Ciphers
- When to Utilize SM Ciphers
- wolfSSL and SM Ciphers
- Building wolfSSL with SM Ciphers
- Using SM Ciphers in wolfSSL
- Future Developments
If you have questions about the ShangMi ciphers and algorithms, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.
Download wolfSSL Now
Native CAN bus and A Full API Manual for the wolfSentry Embedded Firewall/IDPS
With our recent release of version 1.6, wolfSentry now natively supports CAN bus, with idiomatic bitmask-based address matching. Addresses and bitmasks can be supplied as hexadecimal, octal, or decimal numbers, supporting both 11 bit part A and 29 bit part B addresses.
Indeed, all address families now support bitmask matching, including user-defined address families, with computational overhead confined to bitmask-matched families. When using JSON configuration, bitmask matching is a simple matter of supplying a “bitmask” rather than a “prefix-bits” value for an endpoint. Bitmask-matched addresses can also be supplied directly through the API, using WOLFSENTRY_ROUTE_FLAG_REMOTE_ADDR_BITMASK and WOLFSENTRY_ROUTE_FLAG_LOCAL_ADDR_BITMASK. Consult the documentation for details.
Speaking of documentation, wolfSentry now includes a comprehensive developer’s manual, fully detailing the API, JSON configuration, build flags, and basic application integration in FreeRTOS-lwIP. The new API manual is available both as a bundled pregenerated PDF file at doc/wolfSentry_refman.pdf, and as Doxygen-generated HTML by running “make doc-html”.
Release 1.6 also includes additional portability improvements, allowing for full functionality in a newlib-nano runtime with a C89 toolchain. Callbacks are provided for all system facilities, assuring easy porting.
The latest wolfSentry release is available on GitHub, with native in-tree support for 32 and 64 bit targets and POSIX, DeOS, FreeRTOS, and MacOS X runtimes. Let us know if you would like it on another platform. Our current porting plans include Green Hills IntegrityOS, VxWorks, LynxOS, PetaLinux,TRON/ITRON/µITRON, QNX, PikeOS and NuttX. Clone it now, and make test!
Please contact us at facts@wolfSSL.com or call us at +1 425 245 8247 with any questions or for help getting started with wolfSentry in your project!
Download wolfSSL Now
Weekly updates
Archives
- November 2024 (26)
- October 2024 (18)
- September 2024 (21)
- 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)