 Okay, let's talk real quick about Cripp now First of all, I'm a member of Ruby core and what I do there mainly is maintaining the open SSL extension so in Matt's keynote we all heard about how Diversity is the basis for innovation and I also think that diversity is also what gives us The ability to choose to choose the right tool for the job and That's what I think that Ruby cryptography should also not be just about using open SSL as it is right now and That's where Cripped enters the picture because Cripped is also about diversity So in one sentence you can describe Cripped as being a platform and library independent cryptography framework for Ruby and It's ultimate goal is to replace open SSL So that's a bird's-eye view of Cripped in general as you can see there are different layers and we're going to look into each layer now in detail first of all each of those layers is a separate gem and Depending on the Platform or library or operating system that you're on you can combine those as you need it So let's have a look at the provider layer. Well provider is a native implementation of Depending if you're on a C-based Ruby, then it's written in C. Otherwise for J Ruby would be written in Java and what it mainly does is it Will implement all those low-level primitives that you need in crypto such as digests Cyphers or signatures and so on What happens is that provider defines an interface and see this would be a header file and Java We have an interface that needs to be implemented By each implementation of such a provider. I Want to try to keep those? Minimal so that people would be encouraged to provide their own Providers So it's also possible to do just a partial implementation. For example, if you have one very specific feature that's just available in one Particular library and you want to use this then you could write a partial implementation of a provider and Still be able to use this with the default providers. So anything else would be Given to you by the default provider and you can use your special feature in parallel What I hope to achieve in the future is that to not only support OpenSSL, but to Support a lot of different crypto libraries that are specifically Well suited for different operating systems, so we should support Windows we should support OSX and so on So in general you can think of provider as writing an adapter for your favorite library and In a hopefully not too distant future My plan is to also write something that implements crypto entirely in Ruby in Between all this is the core layer and you can think of it as The link between the native world and the Ruby world what it does is it offers a Provider API in Ruby so you can access the provider features in Ruby using such a provider and There's also some performance critical things that have to be implemented in Crip core for example stuff. That's very intensive on IO and That's why we currently have three different implementations One for C-based rubies one for Java and Also one that's written entirely in Ruby and whenever I have to reach out to native code This would be done by using FFI Which is pretty interesting because this allows you to use OpenSSL in J Ruby Even if OpenSSL is written in C and on top of all of this is crypt itself You can think of crypt as the high level. Yeah, high level cryptography in general it's written entirely in Ruby nominative code and Implements a lot of those fancy acronyms higher level protocols that Yeah, well use the lower level primitives to achieve some form of protocol So let's talk about the design principles of crypt as you might have noticed my goal is to use Ruby as much as possible and Also, I want to have it run on each Ruby equally Well, which is not the case right now with OpenSSL And by being able to choose we will also be more independent So we're not as tightly bound to OpenSSL anymore And what I also hope to achieve by this is more stability because right now We're often surprised by what happens upstream with OpenSSL without really knowing what's going on So this is always Yeah, kind of sucks because we have to react very fast to some security Fixes or anything like that and if we are in control This would help us to achieve more stability And it would also probably Be a bad thing if the design is nice and everything but the performance is magnitudes Slower than OpenSSL. So I think if we want to replace it. We should be comparable to its performance This is something that's really important for me personally Because I think that many of you if you use crypto then You're probably not really interested if you're using SHA-256 or SHA-3 or Whatever petting scheme you're using I think the only thing that you're probably interested in is that the whole thing is secure and it should be easy to use Right now with OpenSSL. You have so many options and it's easy to screw things up and Yeah, it should be easy to integrate a new provider So whenever you have a new favorite crypto library and it should be easy to support this Yeah, I also want to fix some of the problems that currently exist with OpenSSL It's not like there are none our VM users probably notice if you're on Windows you probably noticed and The biggest problem that I currently see is the way how OpenSSL handles certificate validation There's just recently been this paper where somebody analyzed how popular applications Deal with certificate validation and it's most of the time it's wrong because just the API is way too complicated and OpenSSL also They don't want to implement a proper HTTP Implementation so it's really hard to use your else or OCSP And yeah, my goal is once this is finally done that we hopefully can kiss very fine on goodbye So I think 10 years of trolling is enough So you might ask why would you want to break with integrating battle-tested C libraries when basically everybody else who's C-based does this and So the argument is often that for crypto you need to be in control you need to be able to wipe memory you need to Be able to squeeze every bit of performance out of it. So you need see But that's I don't think that's really the way to go I rather believe that crypto in and by itself is hard enough as it is So if you add pointers and memory management to the mix This is just asking for trouble because it's just way too complicated. And if you don't believe me, you should look at recent Vulnerabilities because I would bet that probably half of them are related to implementation issues and not crypto issues So I think that we would rather need something that's high level that takes care of all of this for us and Gives us just enough control to do the things that we want and Of course, this would be Ruby So I've discussed this with other people on the core team specifically with Hiroshi and We both agreed that Ruby is probably currently not the best language to Implement crypto because there are some things that are hard to do But I think we can fix all those problems while we're on the way and Bineal which I want to talk about later would be one of those things that fixes the problems So now I want to show you some of the things that I implemented in crypt, which I think are worth Investigating some interesting things happened there and the first I want to talk about is the ace in one parser that I implemented from scratch So ace in one for those of you who don't know it you can think of it as XML for crypto it's defines data structures in binary format and It's probably used. Yeah, almost everywhere in crypto and because of that. It's also important that this better be fast One of the problems that we currently have an open SSL is that we can't process ace in one data streaming in a streaming manner and This is usually fine because the data is Coming in little chunks, but as soon as you start for example Signing a database lock or a web server lock Then you're running into trouble because you can't parse the whole thing into memory anymore So I looked into other parsers other parser technologies and because ace in one and XML are so similar I Yeah, I ended up looking into XML parses and if you think about which language has probably done everything with XML in the past So Java they have their their XML parses better be fast and yeah Once I looked into their positive technologies I noticed that many of them were event-based, but I Don't really like event-based parses because all those callbacks They rip you out of the context and you can't You don't know what's going on after a time So I found pull parses pull parses up mainly Yeah, they look like they're non-streaming parses, but the API is probably very similar and so The principle is that you decide when you want to pull the next token from the stream instead of that your Token is being pushed to a callback and so you're in control when you want to do things when you want to process your Tokens, so the API is pretty simple You have this next token method that you call in your parser you get a token on that and If you want to process this token you can call IO on it and you would get a stream and can Could process the stream so that's actually pretty easy to achieve The next thing that I implemented for as in one which I found important is I wanted to have an easy way to create as in one data structures because They're used in a lot of places. So it should be easy to create them and If you look at this it looks very familiar if you're familiar with active record and similar things you would define your fields and and Yeah, you can declare data Data classes there and as long as you're in ruby you can deal with normal ruby classes strings integers and so on and only when you serialize this stuff It will be transferred into the format that is being expected by as in one and Currently if you want to do something that is similar to this you would have to do this manually and So you end up writing a lot of boilerplate code Which is probably really error-prone because you end up copy pasting so much and With template you get all of this for free because this DSL already provides the parsing and serialization methods for you and All you have to do is declare your classes and you can start parsing and encoding right away another Specific feature of this parses that it does lazy parsing and what I mean by this is that I cache the original encoding once I start parsing data and There's a good reason for this because bouncy castle not too long ago They adopted what's called indefinite length and coatings for signatures and that a good reason to do this because This is what eventually enables you to process signatures in a streaming fashion But there's a problem with this because indefinite length encodings. They're no longer unique they're what's called be our encodings and As opposed to the our encodings which are unique They are not and the problem is that if you have such an encoding you parsed it and you want to re-encode it Using OpenSSL or any other library. What happens is they get re-encoded to DER because that's the only thing the parsing knows what to do in that situation and This is really bad because what happened to me in the past is that this potentially breaks signatures And that's something you don't want to have to happen So the only way we can deal with this is actually to cache the original encoding and Now let's see how this works in practice. Let's consider. We have a very simple data structure a That consists of two elements B and C So if you just parse the data and re-encoded right away again, what happens is it will just cache the entire encoding And just dump it out again. That's all that happens Only if you start accessing the fields we will Start to interpret the inner encodings and once we for example imagine we access CRB here Then we will interpret B and C's encodings and now that we got their encodings We can actually discard the outer encoding because the outer encoding is just just consists of the encodings of B and C so once we done that we discarded the outer encoding and If we start writing it out again, we can simply now write out the cached encodings of B and C and Things get really interesting once we start modifying those data structures Let's imagine we have an a and now we want to assign a new value to one of the fields in order to do this we will first need to interpret the encodings of B and C then we can discard the encoding of C because we now assign a new value and We haven't got an encoding yet and only if you start Encoding this again, then we can compute the new encoding of C on the fly and in Subsequent attempts to encode this we can just write out the new cached encoding That's yeah, pretty much how this works and once you start caching stuff you always are afraid of how Will this work with memory consumption because it can Grow quite high, but the cool fact about this here is that we since we are able to discard outer encodings when we go further inside the data structure It's a fact that at all times we just stay Below two times the memory that we would need if we didn't cache anything at all And so I think this is pretty nice because we know for guaranteed that our memory consumption is bounded It's also nice that this approach is really lenient. So whenever you write a parser everybody recommends you to do this lenient as possible and I've had it happen in the past that I wanted to validate a signature of a certificate But my parser rejected this because there was some date field wrong and I wasn't really interested in the date field So I just wanted to validate the signature and you can do this with this parser Only the stuff that you're interested in will be validated And of course all this caching has a huge impact on performance. I Did some benchmarks there that I want to present to you. So The red stuff is the Crip parser and the black stuff is the existing open SSL implementation So yeah, I like this one and If you look at j ruby similar picture and since this was so fast I was getting curious and I wanted to know how it would stand up to native code and This is what happened the only library that was able to keep up with this was Jabba's built-in Security library, but all the other libraries that I tested were actually magnitude slower and So that's what I felt like So, but I think what's even more important than that is this stuff is so fast is the fact that We have no outliers anymore like we had for rabbinus in this one slide. So we have similar numbers Although everything is written in a different language, but because it follows the same design principles we get Comparable numbers there and that's pretty amazing Okay, so the second thing I want to present to you is fuzz bird The background there is that I wanted script to be Really really well tested. So I think testing should be priority anyways, but especially for a security Project and that's something that I don't see with other crypto libraries. They have some tests, but it's not really really well tested So what I do is I have the usual suspects there I try to include official test vectors in the test. I do code coverage not only for Ruby, but also for C in Java code It's on Travis, of course and for C. I have to find memory leaks and all those stuff also included valgurant But the problem is with testing. We cannot test exhaustively It's an exponential exponentially hard problem and to see why even with the most simple Methods for example, if you imagine that this method here that arc could only be take on integer values We still couldn't test it exhaustively because there are infinitely many integers So what we need is a heuristic something that covers a lot of ground while not taking up too much time and One of those heuristics is random testing or fuzzing as it's also called so random testing means you generate random data shoot it at your app and see what happens and Unfortunately, although it's been around for quite a while now People don't really seem to like it. So the arguments often. Yeah It crashes, but come on. Nobody would ever send such data and There's this general feeling of it's not fair because a machine generated it But I actually think that's the real strength of random testing because it has no bias So as a developer you always biased when writing tests because you think you know where to look for trouble But you probably omit places that would be interesting too and that's also what random testing Tends to find it tends to find those weird cases and That's a good thing because hackers do exactly the same thing They will use fuzzing to find vulnerabilities in your application. So it's good if you can find them Before they do and yeah Also, your users might find errors that you never thought of so just ask my mom she's found a lot of box and windows that I never thought possible and Because a lot of the stuff happens in an automated way We can also cover a lot more ground that we could usually in less time So in its most simple form we would just shoot completely random data at the app and This is probably not what we Want because it means we're scratching a lot on the surface. So we're wasting a lot of time with data that's That we already know will be rejected. So we probably don't get the edge cases that are further within the application So there's a trade-off between completely random data and test cases that apply more structure to the data and I believe that in order to have a good random testing suite. We need both and Fuzzbird is something that aims to help you with this So what it is. It's something that looks probably familiar to our spec You have this fuss directive to declare your tests You have one of those deploy blocks that tells fuss bird how to Send the data to your application. So you're Really flexible there you it's not just for example targeted at Web applications, then you have several of those data Blocks that generate the data and there you have you're free to choose how much structure you want to apply for example this first line the first data block that's Producing completely random data and the other supply more structure So that's fine as long as you're working with binary protocols But as soon as you want to fuss let's say a web app or anything. That's string-based data What you actually want is to have some form of template support because you're dealing with strings That's also possible with fuss birds. I included this very simplistic Templating language you can see it there in the middle in red That's a template for producing JSON data and you can assign variables using dollar and Curly paracys and after that you can assign generators that generate random data to those variables So what's nice about the testing procedure in general is that it runs in a separate process? Because you want to be able to deal with cases when your VM would crash entirely and So threats were out of the picture. We need to do this in separate processes Everything happens in memory So there's no marshaling or un-marshalling and this of course beats up things a lot And it's only when something fails that those particular cases will be persisted Now that we've talked about all of this the question is does it actually work and oh, yes, it does I can only recommend this course at Udacity They cover a lot of random testing more than I can do here and it's pretty interesting. You should check that out So some of the arguments against random testing are that it's not scientific There's no scientific foundation to it but those people tend to forget that there's no scientific foundation for traditional testing either and Another argument is that you need to still need to know what you're doing But I think you always should know what you're doing. Otherwise, you're screwed anyway And if you really want science then I can give you some ideas you could start modeling failure arrival using for example an exponential distribution there and Then you start measuring the expected time until one of the test fails and you can do Dynamically update your tests by doing some hypothesis testing So if one test takes too much time Compared to the average time you could kick it out and take in a new one and so you could start off with a basis of Just a few tests and mutate them on the way and keep updating them and Yeah, this is the dream of having completely automated tests with just a small basis of Tests so if there are some are people amongst you, please do this I want to encourage you to play with this start fuzzing whatever you like You can you could for example start fuzzing the ruby parser You could start fuzzing rails. You can even use this fast bird to fuss Command line tools, so it's not just ruby Only and I really believe that fuzzing is really the next step of testing and we should all be doing this so my next showcase would have been binyo, but I've been working on something lately that I thought would probably be even more interesting since binyo is just a vaporware right now so What I want to talk about is hashing not this hashing but Hashes in ruby, so let's just think about where our hashes used in your everyday programming and The question is rather where aren't they used? I think every real-world application uses hashes somewhere There's been this blog post by Charlie About how we should avoid hashes because they're only trouble But I think we all started to Love them and would like to use them in our application, so I don't think we can really get rid of them Now what I want to talk about is Maybe some of you know about this last year. There was this hash-dos thing presented at KS computer club where people were able to Mount the Nile of service attack on the hash implementations of programming languages So the problem was it was quite easy to produce collisions for general purpose hash functions and What was surprising is that this hasn't been a new thing. It's been around for quite some while Back in 2003. Mr. Crosby Found this but at the time he only targeted Pearl so that's why Basically, everybody else seemed to ignore this and it was only fixed for Pearl at the time So but last year we decided to fix this for good in every other language, too And the fix that was proposed was to randomize the hash function so why because this is something that was already outlined in the book Introduction to Algorithms, they call it universal hashing and Universal hashing means you would just pick a random hash function from a random family of hash functions And this will give you an upper bound to the collision probability now that's all well, but there's a problem with this thinking because Universal hashing explicitly assumes the hash function to act like a pseudo random function Pseudo random function means that the output is not distinguishable from a real random function so if there's somebody rolling a die and Your pseudo random function you shouldn't notice a difference The problem is that basically every general purpose hash function is not pseudo random and Just randomizing the seed as we did last year is not good enough and to see why Imagine this very stupid hash function that takes in a random seed, but always outputs 42 So this will never be random regardless. How good your seed is So it turns out that Jean-Philippe or my son who's of a Sha three fame He invented Blake and Daniel J. Bernstein. You probably know him, too They were working on a hash function and by the way, you should follow these guys are really good and While they were working on this hash function, they found out how to produce multi collisions for murmur hash In its versions two and three and they were even able to produce this with the fix applied last year of randomizing the seeds and the problem is Those hash functions are used in C Ruby J Ruby and Rubinius in some form and it doesn't Simply doesn't matter whatever the random seed is and how good it is. You can still produce collisions at will and Yeah, I would have loved to show you this but You all know how it went, but I will probably yeah, I have some announcement later on about this So when I heard of this and talk to Jean-Philippe I was afraid that this would be turning out as the Ruby thing and that people would start claiming Yeah, it's a Ruby problem so I Was looking into who else could be probably target Maybe some language that always claimed to be also secure and that's used in a lot of enterprise Applications and you guessed right so good news. They're affected, too so Okay, we can produce collisions now, but what good is that well the problem is that if you think about web servers What they do is they create hashes from user input So if you send form encoded data if you send json, whatever it Causes a hash to be filled with this data and the problem is that the worst-case behavior of the hash function for an insertion is Linear as opposed to its average time, which is constant So this means that if you insert n values you will end up having a quadratic time instead of a linear time and This is bad because with very little effort you can actually take down a web server Now what can we do about this? There have been some attempts and that's also I think the philosophy that some of the Programming languages last year took we could start restricting parameters We could start looking into libraries each and everywhere, but I think the chance that one of those libraries will be Yeah, that somebody will fix this wrong is just too high So I think we should fix it where it happens, which is in the ruby function ruby hash function So one way out would be to use a cryptographic hash function as we all know MD5 or sha one or whatever. They're just too slow So what we actually want is to have a really fast cryptographic hash function that renders this attack infeasible And if you want to know more about how this works and if you actually want to see the demo Jean-Philippe is going to give a presentation next week in Switzerland And I'm going to be there and I will demonstrate those I will demonstrate how to use this attack on a real-world rails application and Afterwards, we are also going to publish this code. So shot code is if you apply a shot and Freud it to hash functions And yeah, my final words. Let's make an effort to replace open SSL Thanks for having me here. Sorry for the problems. I want to thank you all Please visit my code. Please have a look at crypt if you can bear it you can read my blog and Follow me on Twitter right mean email. Thanks