Transcript from the "Approaches to Cryptography" Lesson
>> Another important idea when we're talking cryptography is, we might wanna do things like have a secret message that no adversaries can read. So there are a couple of ways to get this kind of outcome, we can have something like a symmetric cipher, where we have a shared secret.
[00:00:17] So this is like a password that you can use to unlock a piece of data that's been encrypted. So I'll have some examples later that we can play with to do that in Node, another example is asymmetric cryptography. This is when you have public private key pairs and if you have someone's public key, you can craft a message that only they will be able to unlock with their private key and no one else will.
[00:00:48] Of course, implementing this stuff in practice, there's so many caveats that you have to be very careful about. So, it's good to use existing solutions that have been audited and proven where you can. One of the basic ideas in a lot of these systems that you need to build them securely is a random number generator.
[00:01:14] So if you've ever done math dot random, this is a very lousy random number generator. And if you do things like if you graph out like in a P in, like a raster imaging canvas, you'll start to see patterns and things when the random number generators have bugs and they often do.
[00:01:33] I think, until quite recently, Chrome had a very bad implementation of its math.random generator and the problem is that if an adversely can predict the values that you get from your random number generator, then they can do things. Like they can guess for example what your private key is based on some other observed inputs.
[00:02:02] So it's important to use a secure random number generator if you have one. So in Node you can require('crypto').randomBytes, and this is gonna use the open SSL RNG to generate some number of bytes of output in the browser oops. So you can use window.crypto.getRandomValues, And this is also gonna use secure RNG, so you can actually do real crypto.
[00:02:35] Of course, doing real crypto in the browser is also a very complex thing and you have to worry about all kinds of adversarial models like mostly the server can decide to send you whatever data it wants whenever it wants. So to kind of always be thinking about how to do this kind of stuff, but for other use cases where you might have a browser like experience with an electron app, or with a web app running on local host, or maybe some sort of like browser extension.
[00:03:05] Maybe you don't have those problems, but you have other problems instead. So anyways, if we wanna use the browser's secure RNG you can pass it like a new Uint8Array with eight bytes and we get back some secure entropy based on the size that we requested, so sort of how you can do stuff in the browser.
[00:03:39] That terminal is locked up, Chrome stole my focus sorry about that. Okay, so it's really easy to screw up when it comes to crypto systems. So you have to really do a lot of research and really be very careful because there's a lot of pretty counterintuitive ways in which a crypto system can be insecure.
[00:04:11] Like a, one great way is a timing attack so, unless you're very careful how you construct your program, an adversary can measure things like the amount of time that it takes for you to craft a response. And then maybe if you have like branch in your program, that checks every character, of a password for example, then the adversary might be able to notice that when I provide a password that begins with the letter Q, it takes a little bit longer to send the response than when I send any other letter.
[00:04:46] So I bet that the letter Q is the first letter in the password, cuz you have to loop over each character, so this is an example of a kind of timing attack. I think even things like AES 192 have issues now and then, I think Bernstein found one of those a while ago, these timing attacks in these crypto libraries.
[00:05:10] So even people who are domain experts who put together these things can have bugs with their implementations. There's also replay attacks, this is when, maybe if you don't include something like a sequence number on your packets, or maybe if you reset the sequence number every time you have a session.
[00:05:35] So for example, if an eavesdropper is listening in while I go login to my bank website and send someone $5, then maybe they can just record all of the packets that were sent during that transaction, and they know that I was sending someone some money then. So they can just take all of those packets, record them and then send them to the bank, and now if the bank website wasn't implemented very correctly, it would be vulnerable to one of these replay attacks.
[00:06:08] And the attacker could cause my bank to send that same $5 over and over and over again, until there's millions of dollars that have been sent not just $5. All kinds of other issues in crypto, there's a really long list of them that's not even exclusive on Wikipedia here that you can read all about.
[00:06:32] Anyways, the important point is that, this stuff is very hard. So all of these examples that we're gonna see are like you shouldn't build a bank [LAUGH] unless you really know what you're doing unless you've really got like a proper audit, like by professionals, but even then, people mess that up.