Okay, good afternoon, my name is Larry Stefanik, I'm with yet another SSL. Some people call it a Yazzle, I've heard Yaw, SSL. And we have a company policy, project policy of answering to whatever you happen to call us.

So the quick outline of the talk is pretty basic, 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 at this event. So the basic information on Yazzle is, maybe we 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 to 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 have and maintain the project called Yazzle, which is the C++ implementation of SSL.

And it's primarily for the SSL developer who also happens to be a C++ aficionado. 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. That's kind of what that comes down to in terms of 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 I have a list of the environments that we run on, but we again focus 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 for 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 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.

That's how we fund our development staff is through the licensing and the support. It was pointed out to me 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 MySQL 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 kind of the gorilla,

the most widely used SSL library out there is this bottom point that we're up to 20 times smaller than OpenSSL. 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 1 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. OpenSSL I think 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 I think a year and a half ago is when we added TLS 1.2 support, but for whatever reason it's actually becoming important in the market today.

And we found and discovered that our customers and user bases 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 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 OpenSSL sort 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 Seattle from some of the other SSL solutions. We have specifically targeted a fair bit of our future development energy towards being good at supporting streaming media.

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 30 to 100K here. We haven't had people strip it down even further. Guys in the OpenWrt 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 the liberal application of Occam's Ridge 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 it coded 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 OpenSSL compatibility layer from the get-go. We thought if our project was ever going to get any popularity, that we would have to have some compatibility with, again, the Gorilla in SSLs.

The one that's been out there the longest, which is OpenSSL. Now it turns out being compatible with OpenSSL and their 4000 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 OpenSSL compatibility layer we had at the time.

It turns out we had to add 10 more functions. And every other project we had to get integrated with, it seems like we had to add 10 more functions. So the state of play, the current state of that API, our OpenSSL compatibility API is about 400 out of 4000 functions.

So we think we have the most used OpenSSL functionality in our compatibility layer. But 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 is adding hardware optimization support. Most recently that means AES-NI, which is the new Intel server-based chips have AES built in.

We know how to call that, we know how to use it, we know how to leverage and 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.

Over time we've done a lot of assembly that is for different chips. I have three minutes left? Okay, I'm going to go faster. Your time is up already, but you started three minutes late.

So I just want to point out we have a couple of cool Cypher suites that are super fast. Rabbit, HC128, 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 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. The thing that's interesting to us, this is running Memcache against a regular Memcache, unsecured. This is running it with AES shock.

What we thought was interesting is this HC128 streaming Cypher which is something you can't find in a lot of SSL implementations. We think it's exciting and interesting because it shows how a streaming Cypher can be so much faster than some of the other Cyphers 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 rolling their own secure firmware update systems with Seattle, 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 that will be based on Seattle. We've seen enough of the domain and enough people using our stuff to build their own to realize 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 with the client 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 certificate generation to the last release and it appears my time is nearly up.

I want to mention one more thing that I think is cool. Seattle on a GPU. Harness the power of the GPU on your 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.

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 it must be done.

I'm done. That was a fast 15 minutes. Actually, you can talk much faster if you want to. We spent a few years in Japan, we learned to smoke smoke. We have many, many more cool SSL things to talk about. Come see me if you want to chat.

You have the time at the end of the day.