 Okay, we're up. Thank you. Thanks everyone for hosting me here and thanks Men for setting everything up. And I'm sorry if you came in here expecting the original talk. I really wanted to talk about the actual state of crypto module in Node.js, but I figured that it'd be terrible to talk to three people and alienate the rest of the room. So let's instead do a quick crypto one-on-one session and I'm sorry if you already know all of that stuff. And thank you for attending my talk. So I'm Mujwa. You can find me on Twitter or get up on AtricerCookin. If you hate the talk, please mention me and in the rant you make on Twitter. And why are we doing this talk? So this is a quotation that I really like from David Kahn and he says, few false men have more firmly with the few false ideas, sorry, have more firmly with the minds of so many intelligent men than the one that if they just tried they could invent a cipher that no one could break. And that really captures the idea of the state of cryptography today because after all, nothing that we really use is secure. Nothing is 100% secure. Everything is completely valuable and it's really important that we follow the state of this ecosystem and really follow that we're using all the best practices, make sure that we're on the top of our game. A little bit about me. As mentioned, I work on Node.js. I'm one of the core collaborators. I also help maintain electron. So if you like that, then thank you. Also work on a couple of related projects like LibUV. As of recently, I've been contributing more and more to V8 and then by extension TC39 helping out the entire JavaScript ecosystem. I've also been associated with Google Summer of Code before. A quick disclaimer, I'm going to throw out through around the word crypto a lot. So what do I mean when I say crypto? This is really important when I say stuff like do we need crypto? Because we do need cryptography, right? But when I say crypto, I mean the crypto modules in Node.js and not TLS. It's something that's very closely related. It's maintained by the same team, but it's beyond the scope of this presentation. I also do not mean cryptocurrencies. And if you're confused between these, my reaction is pretty much like no. Please, please. But why do you need crypto? I assume a lot of people here work on Frontend.js and a lot of times, I come across 10 JavaScript developers saying, oh, we have TLS. Why do we need cryptography? Like that's pretty much all we need, right? But that's not exactly the case. You might need cryptography for a lot more things than just SSL. One of the things might be encryption. You might want to encrypt data on Frontend as well as the backend of the application. You might want to exchange keys between users for video games and stuff. You might want to hash stuff cryptographically. You want to do data signing. That's something that's catching wind right now. You might want to generate secure random numbers. More on these later, just don't worry about big names. And you might want to interoperate between different systems, maybe for running a huge application with a lot of services, something's written in Python, something's written in Ruby. You might want to interoperate with these. So talking about encryption, what do we mean when we say encryption? Encryption is basically encoding user data to prevent unauthorized access. It upholds confidentiality of your data. And the way we enable people to do this in Node.js is by using Cypher and DeCypher classes. Now, hold up, what is a Cypher? A Cypher is basically an algorithm that we use for performing encryption. You cannot use these classes directly, but you use something like CreateCypher or CreateDeCypher, which are methods that you use in Node.js for creating Cypher and DeCypher. Now, we do not recommend that you use these. These functions have been deprecated. Why build up on that? But if you want to do encryption stuff, we suggest that you use CreateCypher IV and CreateDeCypher IV. One of the reasons for that, I push this slide further, is that if you do not use an initialization vector, get something like that. So, actions speak louder than words, photos speak louder than actions. That's a picture of tux encrypted without an initialization vector. It's still pretty obvious what it is, right? So, initialization vectors add security and randomness to your encryption. If you use CreateCypher, it might be insecure. If you use CreateCypher with counter mode or GCM or CCM, it might be flat out insecure. We print out a warning if you do that, but please don't. Now, if you reuse your IV, it also might cause vulnerability. So, it's really important that you follow the best practices in this subject. And most importantly, you use these functions. So, we did a couple of stuff for that. But basically how encryption works is that you have a Cypher function which you feed your plain text and the initialization vector to with the key. And you put the Cypher text in IV on the receiver's end for the decipher. And as long as the same corresponding key has been entered, we get the correct main text. So, that's pretty cool, right? How we do this in Node.js is by using the CreateCypher IV function. You enter the encryption algorithm. Right now I'm using AES. And then you call CreateCypher.update with the plain text. That's the input encoding that you have your plain text in. It's usually UDF8 if you're writing in English. If you have multiple characters, you might use a different encoding or some sort of unicode. And the output has to be hexadecimal. And then we do the final encryption phase and then push that to encryption. The encrypted text could then be deciphered using the decipher, CreateCypher IV, and then updating the decipher object with the same Cypher text. So that works. About key exchange, where even is key exchange? So key exchange is securely exchanging keys over a public channel. You might want to exchange keys for a lot of reasons, maybe just like the last step we talked about. And it's very, it's usually often common for people to not find a way to exchange keys over a private network. It's really hard to find a private shared network. And if you have a private network, just share the data over that. So if you want to do stuff for an insecure channel over a public channel, you use a key exchange algorithm. Why even bother? Because it's one of the ways to agree upon a key for a conversation, before a conversation. If you didn't know, it's a very difficult problem to solve because there's two parties, communicating over a public channel. And it's really hard to have a shared secret without leaking any information in the middle. How it's solved in node is there's two ways of doing it. There's a prime number base method and there's an electric curve base method. That's a lot of weird math stuff, but for you to see that you can use the Diffie-Hellman class or ACDH classes. Basically how it works is there's two parties involved. Let's name them Alice and Bob. Alice computes a secret key that's secret to herself. She doesn't share it with anybody else. Bob computes his own secret key. They both have a shared public constant, let's call it P. They calculate P, K, A and P, K, B and then they transfer P, K, A and P, K, B over the network. Now the catch here is that it's impossible to get the original value of K, A by just looking at P, K, A. So anybody who's sitting in the middle does not know what K, A or K, B is. They now know what P, K, A and P, K, B are and they're unable to deduce the values of K, A and K, B. On the other hand, Alice and Bob can just find out this final value, P, K, A, B, but the attacker in the middle has no way to figure that out. So it's pretty nifty, huh? How you do it is somewhat convoluted. It might be a bit too much, but if you just bear with me, you just get the prime and the generator function of the key using the createDiffieHelman method and you take that secret of Alice to Bob who uses Alice's key to compute his secret and Alice uses Bob's key to compute her secret and then you can verify that they're the same thing. Same with ECDH. Hashing, hash is probably the most commonly used primitive that you must have heard about. I mean, pretty much everybody, I assume, would have heard about checksums and verifying data transferred on the internet. What is hashing? It's quite literally the use of hash functions that does not help a lot. Hash functions actually map arbitrarily long data to actually a fixed size bit strings so you might remember having huge files and then just calculating a checksum which is fixed size from that string. It's hard to invert, that's the whole point. It's collision-resistant so you cannot find out a different set of data that maps to the same checksum and because of that, it's very easy to calculate the checksum of any given data or a file but it's really hard to do the opposite. So that's why they're used for verification and authentication stuff. They uphold authentication and integrity of data. Integrity is really important here because when you're dealing with data on the public internet, you might want to know for sure that it's the exact same thing that reach you, right? They help with the tough stuff. One of the reasons they're so common is that they're probably the farthest from an actual crypto systems. They usually use these utilities inside other completely built crypto systems and you'll see that. For example, data signing uses hashing extensively HMAX which is hash-based message authentication systems. They used hashes also. The way you do it inside of Node.js is using the hash class and the HMAX class for specifically doing HMAX. So that's pretty much how it looks. You have an arbitrary length data or a message or file, whatever. You feed it to the hash function and produces a fixed hash value. It's pretty simple. How to calculate a hash. You just input the hash function. There's a couple of hash functions that you should and should not use. SHA-256 is what Bitcoin and all these cryptocurrencies use. Doesn't mean you should use them but it's pretty secure still. You just update what data you want to feed to the hash and then produce a digest. If you see HMAX, they're pretty much the same. They just require a secret to verify that the message is not only authentic but it's also sent by the same person that you think it was sent by. So it's like a sort of password if you may. For data-signing, that's just one extra layer over encryption as well as hashing if you may. Data-signing involves presenting the authenticity of digital documents and messages. It involves authentication of data and also non-repudiation. So non-repudiation is important. When I say non-repudiation, that's actually a very important thing about signing. One of the thing that signatures are used in the physical world is that you sign a document and then you can't go back on that. If you sign something, then you say, okay, I've put my signature on this document and for time memorial, anybody could verify that, okay, it is in fact your signature that you put on the document. You can't take it back. So when I say non-repudiation, I mean that once signed, a document for all posterity, it could be verified that a certain person signed that document. It also ensures integrity of the document. You do them with the signed and verified classes. Sorry, I'm rushing through this. It's just, it's an hour-long presentation that I basically have to do in 20 minutes. But yeah, how you do these is that you have your data that you put through a hash function. The hash function is encrypted using the signers' private key, the certificate and the signature attached together to produce digitally signed data. This digitally signed data can then be broken down at the receiver's end into the data and the signature. And then the signature could be verified to be the encrypted version of the hash of your data. So that's pretty nifty. How you do that is quite close to how you do hashing in Node. You just create a sign using the hash method. So that's pretty much the only moving part in the signing protocol, just which hash method to use. You update the data. You get your private key somehow. And then you put in your signature, your computer signature. And you verify them using pretty much the same way. So random numbers generation. So random numbers are really important, right? They're really important for cryptography. They're really important for a lot of reasons. In most cases, they're sprinkled on top of existing crypto systems to make things secure. Cryptographic applications require a lot of random numbers. Key generation initialization vectors and salts and all these weird math things. Do not use math.random. So I cannot stress on this more. I've seen a lot of people use math.random for a lot of really important and secure stuff. It's not secure. It can be completely broken down. It has literally no entropy at all. And the people who build the spec for math.random do not suggest that you use math.random. Use math.random pretty much never. Random bytes and random fill are the two functions that we provide. They're very secure if you compare them with math.random. And I cannot agree more with Robert Archibald who says the generation of random numbers is too important to be left to chance. You can do that synchronously using just random bytes or again, asynchronously using random bytes. It's just standard Node.js. If you feed in a callback, it does stuff asynchronously. Same with random fill. Just a buffer needs to be created. Interoperability. So that's important. There's a lot of great crypto libraries that we absolutely do not use. We use OpenSSL because we only have the time and energy to work on one crypto library at a time. One of them is Bonsy Castle. If you use Java or C-Shop, Bonsy Castle. Or Salt for C, Libsodium for C, and PyCryptorome for Python. And there's a lot more. And people love to use these libraries in different applications and in different services that they built in these languages. Node.js on the other hand use OpenSSL. You might not agree with me on these, but we do not have any regrets. VepCrypto is really important. So if you're a friend in JavaScript developer, you probably know about VepCrypto by now. VepCrypto is a really high level API that allows you to securely do crypto stuff on the browser. It's really cool. And you don't need to import megabytes worth of libraries for you to do that. It's still being secure. It's built into the browser. It's now a spec that's maintained, co-maintained by W3C and TC39. It's really cool. We're building that in V8. And what are the pain points in Node.js? Because Node.js is used for server side applications alongside the web so much. People expect the Node.js crypto library to just blankly work with VepCrypto. And unfortunately, that's not the case yet. It's not perfectly interoperable. We're trying to make it more and more interoperable. Sadly, the requirements and the use cases for cryptography are very different on the server side than they are on the front end. And for example, VepCrypto deals with a lot of 2FA stuff that's really important on front end, but why would you do 2FA on the server? But yeah, we're working on that. It's a really high value target for introp, and your opinions are being heard. If you want to talk about VepCrypto, you can find me later. But yes, boring SSL is an important case. Boring SSL is the fork of open SSL that's used in Electron and Chromium. It's sort of like Google's take on open SSL. Google just forked open SSL and made sure that nobody else can use it. Sadly, Electron, because it embeds Chromium, it needs to find a way to make boring SSL and open SSL works because it has node in Chromium, like both. And it needs to juggle these somehow. We try to work as much as we can to make these work together. Sometimes there's breaking chains between these, but it's also one of the bigger targets that we focus on. And actually, we cannot talk about this. So that's pretty much it for no, no, no, no, no, no, no. Thank you very much. And we thought that you'd love to talk about some of the TC39 stuff that I've been working on. Despite not being one of the actual representatives representing an organization like Google or Mozilla, I still work on some of these things. So if you want to contribute or get started with how things work when you specify JavaScript, you could definitely ask a question. There's not enough time to ask questions right now, but you could find me later. And I'd love to help you out. So how it's going to happen is we're going to give five minutes for any questions about open source, about TC39. Because it's very rare that we get someone who's also involved in that space to be here. So raise your hands, and we will give you a microphone. There's one. So just one question about the crypto talk. I really appreciate it. So the scenario I'm thinking about is this. I'm a developer. My users' data and funds are important. And I need to encrypt things, but I'm stupid. And I don't want to think. I don't want to make choices. And I don't want to think about what our government is used, what I do. Thank you. That's an amazing question. That's actually one of the problems that has been haunting the whole crypto team in Node.js and me personally a lot. Every other 3AM or wake-ups like, oh shit. People can't use cryptography. There's a problem with the crypto model in Node.js, if you didn't notice, it's terrible. It's terribly designed. And actually, so there's this running joke in the team. When we added the functionality to use S-Crypt, which is a verification and password generation algorithm, one of my friends and colleagues, Joe Pie91, he actually created an NPM module and named it S-Crypt for humans. And the problem is that the crypto library doesn't work well for humans. And that's because it offers you a lot of choices. And that's because we don't want to restrict you, no matter how powerful of a user you are. We want to enable you to do pretty much everything. And one of the awesome things that could be done, and I am working on that, is that it's personally my personal repository right now, but easy crypto. Oh, no. Easy crypto. So safer, easier to use, and beginner friendly. So yay. If you're a beginner, you can just make crypto easy to use, make crypto safe to use, and require as little crypto-specific knowledge as possible. You don't need a mad degree to do crypto. You should not need a mad degree to do crypto. And that's pretty much what I'm working on. Hopefully, if I get more time to work on this in a couple of weeks, this could get fully fleshed out with a lot of features. And this could be merged into Node.js. So instead of some random guy slash easy crypto, you'd probably use Node.js slash easy crypto. And pretty much everybody who's involved in Node.js crypto is working on this right now, as we speak. And yeah, great question. Thanks. And this is definitely something that we care about. OK, we have one more question short. Hi. Thanks for your great talk. And I'm just a little bit interested in your personal story. Like, how did you get so, like, I think a lot of us are, like, amazed that you can get so deep? And obviously, it's an intense personal interest. But how do you, like, fall down? How do you even start, like, getting involved in this kind of problem? Thank you. Thank you very much for the question. I think, like, my personal story, I think the catch is that I'm usually too impatient to wait around for nice things to happen. And that's, for some reason, that has brought me, like, if you just look in this way, it has brought me a lot of success in the sense that I was writing Node.js modules. There's certain things that are not available in Node.js or, like, nobody's working on them. And one week later, I am contributing to Node.js. A month later, I'm one of the core contributors. Then there's weird shit in V8 that nobody is, like, looking into. And then, like, a few weeks later, I started working on V8. Just too impatient to, like, let people, let things take due course of time, because, like, in open source, things are really slow. And sometimes, the features that you want might take weeks, if not months to end. And sometimes, it's just faster to just go ahead. And I think that's the catch. Everybody here, I see great JavaScript developers, a lot of you, really awesome applications. It's just that, you know, sometimes you've got to go out there and say, you know what? I'll just do this for you, because you can. And that's one of the reasons why I've started going out and talking to all these awesome people at awesome conferences and meetups, is that everybody should, at some point, step up and say, you know what? I want to work on your project. I want to work on the JavaScript language. I want to work on this API. And it makes everybody's life easier. It would make my life easier if you come up to me and say, you know what, I just want to maintain it. And you'd be surprised at how welcoming and how amazing and helpful people are. I have had one-on-ones with V8 engineers at Google who I never thought would give me a minute of their time, because they're so helpful, they're so welcoming. They want people to help out. And the only reason, the only thing that is stopping you from working on those projects is yourself. If you just decided to one day go ahead and work on those, there's no way you could not get your name at chromium.org. If there are any other questions, feel free to. Oh, yeah. OK, one more? One more? OK. You have a lot of time inside. Oh, yeah, sorry. Actually, I'm very bad with time. First of all, thank you for contributing. No, no.