 I'm with yet another SSL. We often times hear things like YAH SSL or YASL. We answer to any of the above. And that's not working. Other one. Oh, you have to point it at the black thing. Okay. I will now point it at the black thing. So the quick story of the talk is that I'll talk a little bit about basic information for SSL with some assumption that you've heard about SSL before. And then go into specifics on what's different about our implementation. You may know the most widely used implementation of SSL is open SSL. And we'll talk mainly about what's different between that one and ours, primarily because that's the one people understand. If there is time, we'll talk about the YASL embedded web server, which we've implemented primarily because our embedded users needed. It's basically the HTTP protocol implemented for embedded systems. And then we'll talk about some of the funner projects that we're doing with the YASL. The basics about our project, I'll tell you the project Genesis was originally to go into MySQL. That was the first and the biggest user of the YASL technology to secure between clients and servers for MySQL. But we also targeted the technology at the embedded in real-time operating systems environments or operating system lists environments. In the case you need to run SSL and secure your data coming from a very low-powered sensor type device up to the cloud, for example. Our focus is on size and speed. We try and be minimalist. We support the minimal of the spec that is widely used, which means we apply Occam's razor liberally to the implementation of SSL to keep it small and keep it also very portable. But we are very good at supporting the industry standards and I'll talk, I think I have a slide later on about that. Licensing-wise, we're GPL as well as commercially licensed. We are what we call dual-licensed, which means we as a company and a project own the copyright. And for those users that can't tolerate the terms of the GPL, we sell commercial licenses and that's how we fund the project development. We also support or include floss exceptions, which is free software foundation approved for implementing GPL-based libraries inside of, say, MIT or Berkeley-based, Berkeley-licensed projects without having the GPL kind of takeover. We've been around since 2004 when we did the original implementation, single source base since then, same development team working on it since that time. And probably the big point on this slide that we like to point out is that we're just a whole lot smaller, where's my pointer, than open SSL. So about 20 times smaller and the sizes are on the next slide. Starting with the standards we're supporting up to TLS 1.2. There's only a couple other projects that are supporting that level of the TLS standard. We also support DTLS, Datagram TLS. Both of those standards are useful in some of the newer uses of the internet, which specifically means streaming media. A lot of the old SSL implementations were really good at dealing with static web pages, going across the internet, encrypting those and securing those. We like to think our implementation of SSL is really good, if not the best, implementation for dealing with streaming media. So that means video or voice. And a lot of our users think so too. So we're ending up in things like voice over IP phones, IP telephony, that sort of thing. And sometimes gaming as well. You can see the sizes there. We're pretty small. We're about as small as it can get. Some guys on the OpenWRT project got it smaller. I think they got it down for their purposes to about 15k in size. We do keep our API simple, again, applying Occam's razor. And we think that's a strength of the product. We make this form of security easy to use, at least from the programmatic level, by making it as simple as possible. We also support the OpenSSL API in a limited subset. I think there's 4,000 or so functions available in OpenSSL. So it's fairly complex. We support 400 of those for projects, essentially for projects that need to port over from OpenSSL to Yazzle. We're very big on hardware optimization. So we've done a lot of optimization down to the assembly level for PIC32 chips, for example. A lot of the ARM chipsets. More recently we did AES-NI, which is for the new Intel server chipsets. We're pretty excited about some of the new cipher suites that we're supporting. All the ones in gray are kind of the standard stuff. But the new interesting ones to us are Rabbit and HTC 128. I talked about streaming media a minute ago. These are some of the new ciphers for streaming media. And they're super fast when you're dealing with streaming media. To date, I believe we're the only SSL implementation that has implemented these types of streaming ciphers. And the results are pretty dramatic, depending on the system course. As much as 50, 70% improvement, sometimes even a multiple, if you're on an underpowered CPU. So they can be pretty meaningful if you're trying to stream video in a secure way. We also have the ability, and of course anybody with some code has the ability to add their own ciphers. But we've modularized to the point where adding your own cipher to Yazzle can be fairly easy. And we've tried to make it as pluggable as possible. So there are some proprietary cipher suites available as well in C-Yazzle. And if you follow our project, you'll see announcements about that sort of thing in the coming months. Another thing that we talk about is the ability to work without an operating system. We do have a lot of people using us in sensor-based type environments, which means you're deploying X millions of chips to sense the amount of electricity going out of or into X million households. So you really want to minimize the cost of that device that you put into a household. Hence the follow-on requirement of not having the overhead of an operating system and not having the overhead of an expensive SSL. And cryptography can get pretty expensive. But we've made our product and project easy to run without an operating system to the point of actually not even needing the standard C library to build it. So I already mentioned TLS 1.2 support. Some of the other projects that are doing that, one of the limitations of supporting the newest and greatest in the TLS standard is the ability to test against others. Right now I think the only ones we can test against are the GNU TLS guys, which also have an excellent project and then the Opera browser. But that's it right now in terms of TLS 1.2 support. For whatever reason I can report to you that the industry is starting to pick up this level of the protocol and there seems to be a lot of demand in the last couple of quarters, the last six months or so. There's been a lot more demand for TLS 1.2 support, especially in telephony type environments, high-end telephony environments. So one of the funnest projects we did last summer was with Memcache. If you're in the web space you probably know what Memcache is. It's a distributed memory manager. We were wondering what about securing this distributed memory manager and what kind of performance would we get, specifically when you go secure something like this that's sort of driven to be a performance beast. So if you look on the far left, yes it's your left, this is Memcache running without any encryption. This is the benchmark running directly against a MySQL database. The interesting thing to note here is that roughly, and this is run on like maybe a three-year-old Mac, this particular benchmark. So it's kind of relative. If you're running on a brand new high-performance server, then these kind of get squished together relatively, especially if you're running our AESNI hardware encryption. But what we thought was interesting is how well the stream ciphers performed relative to some of the older and more standard ciphers. So you can see they work pretty good. Another project that we're really interested in because we've had a lot of users doing it for themselves and rolling their own with CIASL as the key component is building out systems for secure firmware updates. And to do that, you're going to need something, well, you're going to need an SSL essentially on the device to be able to roll out your firmware updates to the device. And we've also seen a certain number of attacks based on people taking over the device or getting their own firmware on the device or getting the malicious firmware built or set up on the device. So secure firmware updates is becoming a bigger and bigger issue. Part of the reason we're here at Fozdom is we want to talk up this issue. We're actually seeking collaborators, people who are interested in this problem. Essentially what we'd like to build out as a project and we have kind of the base formed for it is an open source secure firmware update system. And that means something on the server side that keeps track of who's updated and who's not. And it also means using something like CIASL on the device side but building kind of an agent around it for doing the updating. And like I said, we've had plenty of our users doing this but we have yet to roll it out as an actual project. But it is forthcoming from us and we are seeking collaborators on this. More recently just talking about new features. We've added a certificate generation to CIASL so you can make your own keys, you can be your own certificate authority if you want to start your own certificate business and go compete with Verisign and use CIASL to do what you can. But more likely you're not requiring an external authority and are in a position to generate your own certificates and keys and use them. But that's probably the newest kind of biggest thing we've done to the technology. One thing we found out in the course of managing our project is every month or so somebody else wants us to integrate CIASL into an embedded web server. We decided to sort of centralize those efforts. We've ported into, say, Lighty, we've ported into Nginx and a couple others and some proprietary ones. But we really like the Mongoose embedded web server so we centralized our efforts around that and that's what we recommend. And we've actually built out additional features and contribute to that project as well. If you're in the market for an embedded web server and you want it to be open source we can't think of a better one to work with. These guys are doing a really good job and it's one of our key collaborators for the CIASL project. So you can see basically what I'm running out of time but here's the standard features you get with the CIASL embedded web server which is, again, derived from the Mongoose project but it's all the basic stuff, again, applying Occam's razor for when you need an embedded web server on a device. A list of the environments that we support. By a show of hands are there any Tron users out there? Okay, I thought so. It's fairly esoteric and used primarily in Japan for, there's probably Tron users out there but they're on some device that's sitting in their living room somewhere. Another project we're seeking collaborators on is CIASL running on a GPU. We think cryptography is an interesting way to leverage and harness the power of GPUs. We've done some initial porting. OpenCL is also kind of young so we've run into a fair number of bugs porting our cryptography over to OpenCL on the GPU but that's in progress and we do expect that we'll release something and we're seeking people that want to join us in that effort. And the black thing. How's the embedded SSL used? Here's some examples. We've ported this thing into printers. I talked about sensors earlier, telepharmacy more recently so the doctor walking around and giving you a prescription and that going somewhere. That sort of thing needs to be secured with SSL. IP telephony we've been out for a number of years. More recently people, both commercial, primarily commercial video game manufacturers are starting to integrate this stuff and with that I'm finished. Thank you for your attention.