 Okay, good afternoon. My name is Larry Stefanik. I'm with yet another SSL. Some people call it Yazzle, I've heard Yaw, SSL, and we have a company policy, project policy, and answering to whatever you happen to call us. So the quick outline of the talk is pretty basic. We're going to talk about our SSL implementation. Probably the most important thing to this group is what's the difference about Yazzle versus some of the other ones out there. I think Daniel gave a nice talk about explaining some of the differences. I'll take this talk as my opportunity as a rebuttal to some of the things he listed as cons on yet another SSL. Talk about some of the cypher suites, some of the stuff we've done with cypher suites. Oh, I need to move here. And then some of the projects that we're interested in and we're looking for collaborators on. Talk a little bit about what we've done with embedded web servers, particularly secure embedded web servers. And then some of the fun stuff that we're doing with Yazzle that we think may be interesting. And again, we're looking for collaborators. So the basic information on Yazzle is, maybe I should start with what the genesis of Yazzle was. It was built at a time when MySQL in 2004 was concerned about the OpenSSL license and using OpenSSL to secure MySQL clients and MySQL servers. And the OpenSSL license leaves a lot of questions open. So I worked there at the time and we wanted a clean room developed SSL library to use for that purpose as a replacement to OpenSSL for the MySQL project. At the time we thought we'd be real clever and be the first guys to develop an SSL library in C++. And that was, it was clever at the time, maybe a little too clever for the user base and the market space for this type of software. So we still haven't maintained the project called Yazzle, which is the C++ implementation of SSL. It's primarily for the SSL user who happens, SSL developer who also happens to be a C++ efficient auto. As previously mentioned by Daniel, we're targeting C Yazzle, which is the C-based version of the project to embedded and real-time operating system environments and embedded down to bare metal, no operating system type environments. Our mantra, our focus on developing the project is to keep it small and keep it fast. And those goals sometimes come in conflict with adding features. So when we have a choice to make, we choose smallness and speediness over features, which is kind of what that comes down to in terms of, say, project philosophy. In terms of industry standards, we love them. We support them all. We're one of the few SSL libraries to support all of the standards up to TLS 1.2. I'll talk about that in a second. Also talk about portability. I think we, and I have a list of the environments that we run on, but we again have focused on portability because that's critical for the real-time and embedded computing environments and also, of course, mobile environments. One of the things that distinguishes our project from some of the others is that we are dual licensed of our company that is in open source. Dual licensing means that we license under the GPL with a floss exception, which means that you can plug it into a BSD or MIT-based project and the GPL will not rule the day. It won't be the one license to rule them all in those cases through a free software foundation approved exception to the GPL license. But we also offer commercial licenses to the people that need them that can't use GPL or tolerate the GPL in their code base. And that's how we fund our development staff is through licensing and the support. It was pointed out just to me that by someone who viewed the presentation last night that for this audience I should point out that it's not a new project, it's not a young project. It's the same development team that started it on behalf of my SQL in 2004. So that should talk about where we fit in the ecosystem. I think the one thing that really distinguishes us from what we would look and say is the kind of the griller the most widely used SSL library out there is this bottom point. They were up to 20 times smaller than open SSL. And that's not so meaningful when you're talking about an enterprise system or a desktop system. But if you're running on, say, a sensor that's trying to keep track of the amount of wire, the amount of electricity coming into your home, then it becomes meaningful and it becomes important because you have widely distributed embedded devices that you want to conserve memory on. And that's kind of where we fit is the environments where the size does matter and small is important. In terms of standards, we were the first SSL library to embrace TLS 1.2. We coded it up pretty much after the spec went final. The other people that support TLS 1.2 that were early on the bandwagon were Opera, the Opera browser, and GNU TLS project. So we don't have a lot of people to test against. Open SSL supports at the 1.0 or 1.0 and a half level. So we do all of our testing against Opera and GNU TLS. Now the surprising thing is we coded this up about a year and a half ago when we added TLS 1.2 support. But for whatever reason it's actually becoming important in the market today. And we've found and discovered that our customers in user base are actually pretty interested in this stuff right now. And I think the reason for that is that there's a lot more people thinking about securing streaming media with TLS. We also supported added support for DTLS. Again, we're one of the few projects to support that. I'm not sure about GNU TLS but I certainly know Open SSL sort of kind of doesn't support it. There is some branches of the project that do. But we've been supporting it again for about 18 months. Primarily because of the users that are interested in streaming media. I should say that's one of the things that differentiates CSL from some of the other SSL solutions is we have specifically targeted a fair bit of our feature development energy towards being good at supporting streaming media. And I'll comment a little bit on that further on in the presentation. You can see the size numbers. They're small. I think it says 300k here. We haven't had people strip it down even further. Guys in like the Open WRT project have gotten it down to like 15k. So in terms of absolute minimum, we can get you there. We think we have the simplest API for coding SSL. We took a liberal application of Open's Razor to the project and said, here's what you need to do SSL. And all this other stuff is just extra stuff. If you need to code in your application. We tried to make it as simple and easy to use and develop with as possible from the get go. And that sort of goes along with our general development philosophy of applying Occam's Razor to everything that we can. But despite that philosophy, we did put together an Open SSL compatibility layer from the get go. We thought if our project was ever going to get any popularity we would have to have some compatibility with, again, the Gorilla in SSLs and the one that's been out there the longest, which is Open SSL. Now it turns out being compatible with Open SSL and their 4,000 functions is a real challenge. In fact, the first thing we did to test our compatibility layer was do a port to libcurl to see if we could do it with the Open SSL compatibility layer we had at the time. It turns out we had to add 10 more functions. In every other project we had to get integrated but it seems like we had to add 10 more functions. So the state of play, the current state of that API, our Open SSL compatibility API is about 400 out of 4,000 functions. So we think we have the most used Open SSL functionality in our compatibility layer. The caveat here is that we don't have it all and I don't think we'll ever have it all because it also grows and kind of changes over time. One of the things we're really interested in because we run close to the metal and our users are interested in it is because it's adding hardware optimization support. Most recently that means AES-NI, which is the new Intel server-based chips that AES built in. We know how to call that. We know how to use it. We know how to leverage and optimize it. Optimize against it. It's fast. That's what's exciting about it. The benchmarks prove that you can look on our website to see what the Delta really looks like if you're running AES-NI versus standard in-software AES encryption. And we also, over time, we've done a lot of assembly that is for different chips. Is that a three-minute slot? Three-minute slot. Oh, okay. I'm going to go faster. Time is up already, but you started three minutes late. Okay. So I just want to point out we had a couple of cool server suites that are super fast. Rabbit, HC-128. These are thanks to the EU largest. They funded those. They're awesome. I'll show you a benchmark here real quick that kind of tells you what that is and does. I guess I already talked about TLS 1.2 support, so I'll skip to this slide. There's a project called Memcache, which is very popular for caching and distributed memory manager that's really popular a lot of the high traffic websites like Facebook and Google and those guys. We decided to secure it and then see what the cost of securing Memcache would be. And the thing that's interesting to us, this is running Memcache against a regular Memcache. It's unsecured. This is running with AES shock. What we thought was interesting is this HC-128 streaming cipher, which is something you can find in a lot of SSL implementations. We think it's exciting and interesting because it shows how a streaming cipher can be so much faster than some of the other ciphers that are out there and available. I want to mention this in my 10 seconds left. We have had a lot of users that are interested in doing and rolling their own secure firmware update systems with C-AZL, getting fresh firmware down to your device. We're looking for collaborators on that. We're going to code a framework for secure firmware updates. It'll be based on C-AZL. We've seen enough of the domain and enough people using our stuff to build their own, to realize, A, that the open-source community and the industry in general needs a way to do this effectively and efficiently. We know enough about it to think we have some ideas on how it can be done best and want to be involved. If that's something you're interested in, I'll be back here late in the day and available to talk about that kind of stuff. We're talking about building what you need on the agent side once you get the firmware down there and what you need at the server side for a secure firmware update system. Quick note, we added a certificate generation to the last release and it appears my time is nearly up and I want to mention one more thing that I think is cool. C-AZL on a GPU, harness the power of the GPU on a desktop system, on your server-based system to run your crypto. We've been working on this for a while. The standards for doing it have been kind of young and developing, but it's all possible and I'd say we're one-third of the way there. If anybody wants to get this running on a GPU, we want to support you in doing it if you want to collaborate with us. Generally we think it's a super cool project and I'm done. That was a fast 15 minutes. That was 15 minutes. You can tell it's much faster if you want to. It's the reason you didn't want to. We spent a few years in Japan and we learned to smoke smoke. There are many, many more cool SSL things to talk about. Come see me if you want to talk SSL. You have the time at the end of the day and we'll see you soon.