The yaSSL Embedded Web Server for AVR has some optimizations our users might want to hear about: Assembly code for the AVR and AVR 32 instruction sets in the SSL cryptography. Assembly code for the AVR 32 instruction set speeds up public key operation during the SSL handshake. Need to use it? Already using it? Let us know if you need any help with further optimizations or find any bugs!
Hi! If you came to our site because you are considering wolfSSL as an alternative to OpenSSL, this blog post is your cheat sheet that details the differences between the two products:
1. Size: With a 30-40k build size, wolfSSL is 20 times smaller than OpenSSL. wolfSSL is a better choice for resource constrained environments.
2. Standards Support: wolfSSL is up to date with the most current standards of TLS 1.2 with DTLS, which OpenSSL has yet to address.
3. Support for streaming media: wolfSSL is up to date with the best current ciphers and standards for streaming media support.
4. Embedded systems support: wolfSSL is the leading SSL library for real time, mobile and embedded systems, by virtue of its breadth of platform support and successful implementations on embedded environments.
5. Commercial licensing available from the source of the code: wolfSSL is available under proper commercial licenses direct from Montana, or under the GPL, whereas OpenSSL is available only under their unique license from multiple sources.
If you have further questions on how we compare ourselves to OpenSSL, please contact us at email@example.com.
Machine-to-machine communication takes place between both wired and wireless systems all around the world every day. As stated here, “M2M uses a device (sensor, meter, etc.) to capture an ‘event` (temperature, inventory level, etc.), which is relayed through a network (wireless, wired or hybrid) to an application (software program), that translates the captured event into meaningful information (e.g., items need to be restocked).”
M2M communication holds a very important part in many business actions and decisions an as such needs to be secured. If your device has a TCP/IP stack in place, SSL, specifically wolfSSL, is an optimal solution for this problem.
wolfSSL is a small and lightweight embedded SSL library, offering your M2M devices a security solution which fits inside your resource constraints. If you have questions or would like more information on how you can use yaSSL products to enhance your M2M communication, please contact firstname.lastname@example.org
Earlier this week we stated our commitment to ARM by explaining our assembly code optimizations on a number of our math intensive cryptography operations. To give you more information, these optimizations are for Public Key operations with the CTaoCrypt fastmath option. This translates to a speed increase when using RSA, Diffie-Hellman, or DSA.
If you dive into our code, these optimizations can be found in the asm.c source file.
Today, Team yaSSL continues to exhibit at the ARM Technology Conference in Santa Clara, CA. If you are in the area, feel free to stop by our booth to visit or contact us at email@example.com with any questions.
The yaSSL booth at ARM TechCon is perfectly situated to check out the QNX based/ARM based Corvette on the show floor. It’s a silver beauty! See the pictures below.
Reminder: if you’re building a QNX based car computer and need to secure it with small embedded SSL solution, then contact us. One of the earliest wolfSSL users did just that, so we have some experience in the domain.
Hi! As you may know from reading our posts here, Team yaSSL is exhibiting at ARM TechCon this week. What you may not know is that we’ve been working with ARM’s mbed.org team to facilitate a port of wolfSSL to mbed. Why? Because hobbyists need security too! And it is fun.
Here at ARM TechCon, mbed has paired with Pololu to create an mbed-based robot. Additionally, these two companies have created a contest for developers to race the robots based on the program they write. We’re going to help ensure a robot does not lose because its communication is subject to an MITM attack!
Hi! About 20% of our users are using CTaoCrypt to provide standalone cryptographic functionality, and about 80% of our users have not thought about using it that way. The purpose of this blog post is to inform users on how to use CTaoCrypt as a standalone library:
1. CTaoCrypt is available as a function set within wolfSSL, licensed under GPL or commercially. If you are interested in using it outside of wolfSSL, then let us know. Basically this means that 100% of the CTaoCrypt functions are available through the wolfSSL API set.
2. Support for various development environments is included in the download, including GCC, Visual Studio, and Xcode.
3. The build process is described in the README. A program to test your build is included.
4. If you are a benchmark junkie, and since we know you probably are, we include a simple benchmark application to get you started.
5. CTaoCrypt has a lot of useful features, including:
– AES-NI support for super fast AES on the newer intel chips.
– One way hash functions: SHA-1, MD2, MD4, MD5, RIPEMD-160
– Message authentication codes: HMAC
– Block Ciphers: DES, Triple-DES, AES
– Stream Ciphers: ARC4, Rabbit and HC-128
– Public Key Crypto: RSA, DSA, Diffie-Hellman
– Password based key derivation: PBKDF2 from PKCS #5
– Pseudo Random Number Generators
– Large Integer Support
– Base 16/64 encoding/decoding
– DER encoding/decoding
– X.509 processing
– x86, x86_64, SSE2, ARM, PPC32, and PPC64 and AVR32
– Support for FastMath
6. If you need porting, support, or just regular help with CTaoCrypt, then get in contact with us at firstname.lastname@example.org.
“The Register” reported on using SHODAN to pinpoint embedded devices that are not properly secured yesterday. See http://www.theregister.co.uk/2010/11/02/scada_search_engine_warning/ for details. In summary, SHODAN can be used to quickly identify internet connected devices with known exploits. For us, it points to yet another reason why mobile and embedded systems developers should harden their devices with the wolfSSL embedded SSL library and the yaSSL Embedded Web Server.
A review of the event from CNET is available here: https://www.cnet.com/news/researchers-hack-toys-attack-iphones-at-toorcon/.
Of particular interest is Firesheep: http://codebutler.com/firesheep, a firefox browser extension for simplifying SideJacking of open wireless networks. It is open source, courtesy of Eric Butler and Ian Gallagher. Their stated goal for developing the tool is creating more awareness of the problem. We think they’ll achieve their goal!
As a vendor of embedded SSL, you can probably imagine what we think about this, but repetition is the mother of learning, so we’ll repeat: If you’re building software for embedded devices, you need to enable SSL/TLS. The most efficient tool for doing that on an embedded environment is wolfSSL.
Need help enabling ssl your device? Contact us at email@example.com
Hi! Do you need OCSP (Online Certificate Status Protocol) in wolfSSL? Let us know. We’re currently considering it for a feature addition to our next release. Sometimes OCSP may be necessary to obtain timely information about the revocation status of a certificate. OCSP solves that problem. Additional status information is also available under the protocol. More information on the protocol is available here: http://www.ietf.org/rfc/rfc2560.txt. This is not a big feature for us to add, but we’re weighing it against other development priorities. So let us know what you think! Send in your vote for or against OCSP being a high priority for wolfSSL to firstname.lastname@example.org.