WEBVTT 00:03.700 --> 00:11.500 Very good afternoon, good evening, or even good morning, depending on which time zone you are listening to this talk from. 00:11.960 --> 00:17.020 Isn't it interesting how we all are so very well virtually connected through this platform? 00:17.020 --> 00:24.840 And for this to happen, I'd like to give a huge shout-out to the Crypto Village organizing community for making this happen. 00:24.920 --> 00:30.400 I know it has been hard in the middle of this global pandemic, but we are still connected. 00:30.400 --> 00:31.460 That's great. 00:32.840 --> 00:35.620 It's always a good idea to introduce yourself. 00:35.620 --> 00:37.220 I'm Manasi Sheth. 00:37.220 --> 00:43.860 I work as a principal security researcher for a leading static analysis company called Veracode. 00:43.860 --> 00:46.820 We are located just outside Boston. 00:47.420 --> 00:54.660 We have over 2,000 unique customers across different verticals using all kinds of programming languages. 00:54.660 --> 01:18.480 What my job is there is to be on top of all the latest and greatest happenings in the security domain, more specifically in the application security domain, see how those things are implemented by different languages and frameworks, and then translate all that knowledge into finding anti-patterns in our customers' code bases. 01:18.840 --> 01:23.540 I'm not a cryptologist or a crypto analyst or even a mathematician. 01:23.540 --> 01:29.020 I'm just a huge crypto enthusiast like a lot of people here. 01:29.020 --> 01:33.180 I like to be on top of all the practical aspects of cryptography. 01:33.180 --> 01:43.340 I've spent a lot of time understanding details of different crypto primitives and crypto mini systems. 01:43.680 --> 01:48.960 I've seen a lot of crypto implementations across languages. 01:48.960 --> 01:55.240 And I try to use all this information to make sure our customers' code bases are secure. 01:58.040 --> 02:00.120 So why cryptography? 02:00.660 --> 02:03.480 Well, I think cryptography is everywhere. 02:04.600 --> 02:09.220 It's the basis of a lot of things you are currently seeing around you. 02:09.220 --> 02:11.480 You would be connected through Wi-Fi. 02:11.480 --> 02:13.980 You would be having some Bluetooth devices. 02:13.980 --> 02:17.780 You might be using e-wallets to buy coffee or something. 02:17.780 --> 02:19.600 You might be looking at emails. 02:19.600 --> 02:25.320 You are listening to this through a video conferencing software which is supposed to be secure. 02:25.780 --> 02:28.740 You might be doing some Bitcoin mining. 02:28.740 --> 02:30.420 What I'm trying to say is it's everywhere. 02:30.420 --> 02:34.000 It's used right now by you, your family, your friends. 02:34.560 --> 02:40.900 Everyone you know and care about and hope are secure enough from any kind of online threats. 02:42.260 --> 02:48.240 In this hyper-connected world, we rely a lot on crypto to keep us secure. 02:48.240 --> 02:59.100 We rely on a lot of crypto services like confidentiality of our digital assets or authenticity and integrity of our digital transactions. 02:59.100 --> 03:03.060 Like maybe e-banking or e-wallets or whatever. 03:03.640 --> 03:09.180 Or maybe code signing of a software we are trying to buy. 03:09.180 --> 03:17.020 We need cryptography to help us be secure for all these things and much, much more than that. 03:17.740 --> 03:20.600 Then why are we seeing so many crypto failures? 03:21.460 --> 03:26.260 Well, I'm sure a lot of people would be having this reaction like, oh no, not again. 03:26.260 --> 03:27.980 Why are things failing now? 03:27.980 --> 03:36.880 This is going to break so many new protocols and so many different protocols across different systems and how to mitigate it. 03:37.640 --> 03:39.060 It's like this. 03:39.880 --> 03:45.880 Thinking a little deeper while looking at different use cases of crypto failures. 03:45.900 --> 03:50.160 What I feel is cryptography is hard. 03:50.460 --> 03:58.120 Only more than a couple of dozens of people across decades completely understand all aspects of cryptography. 03:58.120 --> 04:13.140 And then how it is being interpreted by people who actually implement the APIs or libraries for further usage in larger systems. 04:13.140 --> 04:15.580 Well, I have all respect for these implementers. 04:15.580 --> 04:19.060 They have to understand the hardest parts of cryptography. 04:19.060 --> 04:23.760 They have to use their domain development experience to write these libraries. 04:23.760 --> 04:32.120 And then even worry about, and then we expect them to even put some more weightage into how these APIs are designed. 04:32.120 --> 04:38.300 How it will be well understood by the most well-meaning security conscious developers. 04:38.300 --> 04:45.740 So that they don't make any mishaps of using these implementations. 04:47.340 --> 04:53.060 I wish the implementers took it a little bit ahead than that. 04:53.060 --> 05:00.480 And took some responsibility of writing much cleaner documentation, much cleaner APIs. 05:00.480 --> 05:08.380 Secure defaults, deprecating legacy or insecure algorithms right out of the sight of developers. 05:08.960 --> 05:13.780 Maybe we might be seeing a few lesser crypto failures at that point. 05:13.780 --> 05:16.260 In my opinion, it's almost undebatable. 05:16.260 --> 05:21.800 85% of crypto failures we see are coming from not bad implementations. 05:21.800 --> 05:25.080 But bad usages of those implementations. 05:25.240 --> 05:34.140 So hopefully we all share some responsibility in educating users of these crypto APIs. 05:36.200 --> 05:41.940 Before going any further, I would like to make some cryptographic disclaimers. 05:41.980 --> 05:47.240 No matter how tempting it is, please don't roll your own crypto. 05:47.240 --> 05:55.360 All these great implementers have spent way too much time understanding all different aspects of a crypto algorithm. 05:55.360 --> 06:01.740 And provided us with the implementation which a lot of times is time-tested, crypto-analyzed. 06:01.740 --> 06:03.000 Please use that. 06:03.000 --> 06:06.040 It's for us to use it and be safe. 06:06.940 --> 06:12.000 I understand not always we have an option to choose an implementation. 06:12.000 --> 06:17.200 But if you do, I would highly suggest you use this implementation called NSEL. 06:17.200 --> 06:19.320 It's written by cryptographers. 06:19.540 --> 06:21.180 Documentation is very clean. 06:21.180 --> 06:25.760 They have all kinds of secure defaults just out of the box. 06:25.760 --> 06:28.840 Everything else is not even visible to us. 06:29.180 --> 06:39.700 And most importantly, a lot of modern programming languages, I'm sure Python, PHP, they have some kind of a wrapper implementation of this library. 06:39.700 --> 06:44.480 Even Lipsodium, another favorite, is a fork of NSEL. 06:44.480 --> 06:48.460 So use one of that and you will go a long way. 06:49.520 --> 06:55.480 Crypto is crucial to be secured, but that does not mean we ignore everything else in the system. 06:55.480 --> 07:01.100 We still have to worry about all kinds of application security attacks, all kinds of networking. 07:01.100 --> 07:03.280 We have to make sure our endpoints are secure. 07:03.280 --> 07:05.340 We have to take care of all those things. 07:05.340 --> 07:10.100 We should not be relaxing the moment we got our crypto right. 07:11.140 --> 07:14.000 Let's see what we are going to talk about today. 07:14.080 --> 07:26.280 Any crypto system you come across will usually have some kind of basic crypto primitives, which is a cryptographically secured random number generator. 07:26.280 --> 07:27.440 It's quite a mouthful. 07:27.440 --> 07:30.620 I'm just going to call as CSPRNG going ahead. 07:30.620 --> 07:35.920 There will be some kind of an encryption scheme going, usually symmetric encryptions. 07:36.640 --> 07:40.020 Maybe some kind of one-way hash functions. 07:40.600 --> 07:45.780 And no crypto system works, none of these crypto primitives work in isolation. 07:45.780 --> 07:57.320 So most of the crypto applications are a mix or match of these basics crypto primitives and those ultimately become building blocks to have a complete crypto system. 07:58.120 --> 08:13.520 So we will be spending some time into looking into some of the most common crypto applications, namely message authentication codes, how to actually store any kind of secure information and digital signatures. 08:14.240 --> 08:19.620 OK, let's start by first looking at CSPRNG, which is used almost everywhere. 08:19.620 --> 08:21.660 So what is CSPRNG? 08:21.660 --> 08:31.200 It's like this huge set of digits or zeros and ones, which needs to execute few, which needs to exhibit few properties. 08:31.240 --> 08:34.900 Namely, it should appear completely random. 08:35.060 --> 08:41.900 We should not be able to locate any kind of pattern in the way those digits are. 08:41.980 --> 08:47.220 Secondly, it should be completely, it should be unpredictable. 08:47.220 --> 08:54.780 So knowing or looking at the current digit, we should not be able to predict which is the next digit, which is going to come out of this generator. 08:55.300 --> 08:59.960 And lastly, we should never be able to reproduce the same set of digits again. 09:00.620 --> 09:03.860 Now, where is this used or where is it required? 09:03.860 --> 09:04.940 Well, it's everywhere. 09:04.940 --> 09:10.540 It's like any kind of keying material you would be generating for any kind of cryptographic algorithm. 09:10.540 --> 09:16.660 Namely, you would need keys to be generated for your encryption, for your message authentication codes. 09:17.220 --> 09:28.600 Depending on the mode and the algorithms being used for your initialization vectors or nonces or like for storing secrets, you would need it for soil generation. 09:28.600 --> 09:31.940 Basically, it's going to be used every single place. 09:31.940 --> 09:35.900 Now, how to actually generate this? 09:36.940 --> 09:42.340 There are three main blocks or three main areas. 09:43.720 --> 09:48.480 There are three main parts of any CSPRNG algorithm. 09:48.480 --> 09:52.070 Obviously, the output which you most care about. 09:52.900 --> 09:57.800 And the algorithm which basically churns and gives you this output. 09:57.800 --> 10:03.940 But knowing the algorithm, it's extremely trivial to get the output. 10:03.940 --> 10:16.980 What makes the output actually CSPRNG or cryptographically secure random is the way this algorithm is actually initialized or seeded, the way it is called. 10:17.480 --> 10:26.940 For the seeding to happen, the input to the seeding part of the algorithm should be of the highest entropy possible. 10:26.940 --> 10:36.760 Basically, the output is depending on how high the entropy or the source of randomness of this seeding sources. 10:37.500 --> 10:44.820 Well, it would have been ideal if we could get the randomness from external thermal elements and stuff, but that's not practical. 10:44.820 --> 10:48.940 So we had to rely on what the computer is going to offer us. 10:49.220 --> 10:54.220 So right now, the highest source of entropy is what the operating system is going to provide us. 10:54.220 --> 11:02.220 And what it does is it picks up all kinds of different entropy elements going on in your system at a particular time. 11:02.220 --> 11:13.720 Like there could be interrupts in your programs or disk IO or the way your mouse and keyboards are moving or even your kernel or user level entropy in their programming land. 11:13.720 --> 11:18.520 All these things are collected and then fed into the algorithm. 11:18.520 --> 11:26.360 And that's what makes your CSPRNG output extremely secure or extremely random. 11:26.360 --> 11:37.020 It's almost safe to say that the entropy provided to this seeding algorithm is what makes your entire crypto system secure. 11:37.020 --> 11:39.820 Or it's directly proportional, at least that way. 11:41.420 --> 11:44.420 So what are some of the do's and don'ts around it? 11:44.420 --> 11:50.120 Well, since the source of entropy is most important, let's start talking about that first. 11:50.420 --> 11:54.320 Always go with what your operating system provides us. 11:55.300 --> 12:03.240 There are different mechanisms which the operating system provides. 12:03.240 --> 12:08.940 Most importantly, either you go with a blocking source of entropy or a non-blocking. 12:08.940 --> 12:19.860 What does that mean is non-blocking is till a sufficient quantity of entropy is reached, the algorithm is not seeded. 12:19.860 --> 12:25.280 So basically, our algorithm is blocked till the entropy is filled out. 12:25.280 --> 12:29.000 And non-blocking is whatever entropy is available, just feed the algorithm. 12:30.400 --> 12:33.120 That's what operating system gives us. 12:33.120 --> 12:36.940 Well, most of the cryptographers are pessimistic people. 12:36.940 --> 12:42.260 They'll say, oh my god, you have to use blocking source, you have to have some level of entropy. 12:42.780 --> 12:45.020 Well, I beg to differ. 12:45.080 --> 12:50.420 80% of the applications don't really need that high level of entropy. 12:50.420 --> 12:56.340 You would be fine with using a non-blocking source for most part. 12:57.780 --> 13:17.040 Second thing is, you should just be aware of, in this virtual machine era, where all the applications are deployed on virtual machines, even the source of entropy is coming from the guest operating system and not the actual host, which has a far longer list of entropy sources, 13:17.040 --> 13:19.100 which even the operating system provides. 13:19.100 --> 13:29.780 What I'm trying to say is, the entropy provided in an application deployed in a guest operating system might not be at par with what a host can provide. 13:30.720 --> 13:39.860 It's better to go for non-blocking, otherwise the applications might never really start, because they are just sitting and waiting for a desired set of entropy. 13:41.100 --> 13:48.120 It's an active area of research, there are mechanisms to avoid it, but the most important step is first to be aware of that situation. 13:48.120 --> 13:57.780 And lastly, I've seen countless examples, even some implementations, which rely on the milliseconds and microseconds as a source of entropy. 13:58.260 --> 14:01.040 Just don't do that, please. 14:01.920 --> 14:06.040 There are obviously some attacks because of a lower source of entropy. 14:06.040 --> 14:11.620 One which comes to my mind is the Sony PlayStation attack. 14:11.620 --> 14:27.900 The digital signature used for signing that particular piece of game was used, the entropy used to generate the digital signature was of very low randomness. 14:27.900 --> 14:31.660 So this is out there, it happens all the time. 14:31.980 --> 14:35.060 The next is, what algorithm to use? 14:35.060 --> 14:46.720 Well, it's always better to rely on algorithms which are based on hashing or hash-based MACs, or even good symmetric ciphers. 14:46.980 --> 14:51.600 Government standards approved only these ones, it's better to use that. 14:51.860 --> 14:59.680 Unfortunately, not a lot of implementations provide this out of the box, but please use that if they are actually being provided. 14:59.680 --> 15:06.760 If not these, then usually there are some good library-specific algorithms. 15:06.760 --> 15:16.040 But make sure those library-specific mechanisms are using operating system source of entropy, and not anything other than that. 15:16.240 --> 15:24.780 If you are using that, be a little more conscious and Google around if there is anything wrong with the library implementation. 15:24.780 --> 15:35.800 For example, SHA-1 PRNG, a few versions of Java ago, it was okay as long as it was not seeded initially before use. 15:35.800 --> 15:41.980 But if it was seeded initially, it used to just go in some initial state and always give that output. 15:41.980 --> 15:46.660 It's fixed now, but there could be such idiosyncrasies lying somewhere. 15:46.660 --> 15:55.840 And there are different algorithms based on mercery twisters, like the older dual EC1s, again the classic Sony hack. 15:56.600 --> 16:03.620 Even some insecure symmetric cipher based, just don't use any of that anymore. 16:03.760 --> 16:16.060 And finally, I just had to put it on the website, on this slide, please don't use random math, there is nothing cryptographically secure about that, it does not exhibit all the properties we require for CSPRNG. 16:17.060 --> 16:25.700 Next, let's talk about one of the most famous crypto primitive called encryption, almost synonymous to cryptography. 16:25.820 --> 16:32.100 Well, we obviously need our data which is stored at rest or in transit to be confidential. 16:32.200 --> 16:34.800 So that is one of the biggest property we expect. 16:35.260 --> 16:49.380 But over time, we realized that our data, whenever it is online, which is as we saw 95% of the times, we needed some kind of authenticity as well as integrity out of that data in transit. 16:49.480 --> 16:50.880 And why so? 16:50.940 --> 17:11.100 To avoid or to safeguard or to mitigate against all kinds of padding oracle attacks where an adversary can just sit in between the sender and receiver and start tampering with the data being sent to the receiver and get all kinds of information back from the receiver. 17:11.800 --> 17:21.580 We all are aware of all kinds of issues with TLS protocols, most notably Beast and Poodle, which had all these issues. 17:22.080 --> 17:31.660 Well, historically, what used to happen is for authenticity and integrity, they will use another primitive called MAC in conjunction with encrypting the data. 17:31.940 --> 17:35.220 It used to work, but there are a lot of issues with that. 17:35.220 --> 17:39.480 It was slow, it had a lot more crypto systems going on. 17:39.480 --> 17:41.380 So the crypto analysis became difficult. 17:41.380 --> 17:43.380 It was much more fragile. 17:43.600 --> 17:52.920 So what the greater crypto community came up with was providing an authenticated encryption right out of the box. 17:52.960 --> 18:02.060 And this is another property we expect out of AE, which is authenticated encryption. 18:02.380 --> 18:04.720 We need authenticity as well as integrity. 18:04.720 --> 18:11.160 So these are the three properties we expect out of any modern symmetric encryption scheme. 18:11.400 --> 18:13.200 And how is this achieved? 18:13.360 --> 18:17.940 Well, at the core of it, we still have a symmetric block cipher running. 18:17.940 --> 18:23.000 It takes a symmetric key, it takes plain text, it throws away ciphertext. 18:23.000 --> 18:31.440 But there was yet another detail, yet another information, which was like a nice to have feature called associated data. 18:32.120 --> 18:40.260 What that is, it would be nice to have some plain text being transferred as plain text on the receiver side. 18:40.260 --> 18:43.640 But it still takes part in the authenticity of it. 18:43.640 --> 18:48.840 So for example, imagine a sender is sending a packet to a receiver. 18:48.840 --> 18:54.940 So the IP address of the receiver needs to be in plain text, but the payload needs to be encrypted. 18:54.940 --> 19:02.960 So that kind of a scheme is what is the most common thing or you should, that's what you should be using going ahead. 19:03.660 --> 19:07.840 It is called as authenticated encryption with associated data. 19:08.120 --> 19:11.080 So just coming back to this block diagram. 19:12.540 --> 19:23.300 Authenticity and integrity is provided by this authentication tag, which is computed based on associated data, which is plain text as well as plain text data. 19:23.300 --> 19:25.520 And obviously the symmetric key. 19:25.580 --> 19:28.900 Authenticated data comes out as plain text. 19:28.900 --> 19:32.160 And we obviously get the ciphertext. 19:32.160 --> 19:45.740 And similarly, on the opposite side, we have decryption, which takes care, which takes the same symmetric key, the ciphertext, the authentication tag, and the plain text of associated data. 19:45.740 --> 19:58.740 If nothing of the keys or the ciphers or the AAD is tampered, then the output of this decryption is going to be plain text. 19:58.820 --> 20:01.700 That's how simply it all works. 20:03.880 --> 20:05.480 Do's and don'ts. 20:05.480 --> 20:08.480 Well, you can use any good block cipher. 20:08.760 --> 20:14.800 AES is one of the most commonly used safe block cipher here in the United States. 20:14.800 --> 20:18.980 If we talk more globally, we have ARIA, Camellia, and CAST6 too. 20:19.700 --> 20:26.260 There are only few block cipher modes which provide authenticity and integrity services. 20:26.260 --> 20:28.380 GCM being the most famous. 20:28.380 --> 20:32.960 The rest of the modes are either expensive or patented. 20:33.160 --> 20:36.720 Patents expire at different times in different countries. 20:36.780 --> 20:40.180 So AES-GCM is the most famous scheme. 20:41.100 --> 20:43.480 And hopefully you would be using GCM. 20:43.480 --> 20:55.180 Just be very careful you are not using the same key and initialization vector for GCM modes more than twice to encrypt different sets of data. 20:56.460 --> 21:04.600 I'd like to introduce you to a new kid on the block, which is based on a stream cipher called Chacha. 21:04.660 --> 21:11.720 And it comes with its own authenticity scheme called Poly1305. 21:11.720 --> 21:19.220 It's a promising alternative or a backup plan if AES-GCM fails. 21:19.320 --> 21:23.860 If it fails, the world cannot all of a sudden be insecure. 21:23.860 --> 21:33.540 So our great cryptographers have already come up and it has already been implemented in a lot of modern programming languages. 21:33.600 --> 21:41.180 And to go a little further, I think Google and Cloudflare are already using this in their TLS implementation. 21:41.180 --> 21:48.140 So knowingly or unknowingly, right now even 30% of our websites use this anyways. 21:48.800 --> 21:51.820 It's three times faster than AES-GCM scheme. 21:51.820 --> 22:00.300 So a lot of slower hardware, even your Android phones or IoT devices needed an authentication scheme. 22:00.300 --> 22:03.300 And this is a promising alternative for that. 22:03.920 --> 22:05.700 So embrace that. 22:05.720 --> 22:08.600 There is no harm in using that already. 22:10.560 --> 22:16.480 And lastly, stay away from all other block ciphers, all other stream ciphers and all other modes. 22:16.480 --> 22:19.560 There are just way too many to list on the slide. 22:19.680 --> 22:23.560 I've just listed the most common ones out there. 22:25.480 --> 22:29.760 Okay, let's see how both these primitives work in action. 22:29.760 --> 22:33.860 And for that, let's go into our development environment. 22:33.860 --> 22:39.780 I'm choosing to show these API usages in Java for two main reasons. 22:39.780 --> 22:44.740 One, Java is one of the most chaotic crypto implementation I have seen. 22:44.740 --> 22:49.740 And second thing is, it's one of the most commonly used enterprise programming language. 22:49.740 --> 22:55.160 So it's extremely important that we pass the message on how to use it securely. 22:56.380 --> 23:03.840 Okay, I have done nothing more than setting up a simple Java Griddle project with some of the dependencies we might be using. 23:05.260 --> 23:17.820 Let's just start with first creating a mandatory crypto driver class where we will be using all 23:21.300 --> 23:24.060 different APIs through. 23:26.520 --> 23:31.580 Simple HelloWorld, where we are going to say hello to CryptoVillage. 23:34.350 --> 23:36.610 And let's see if this works. 23:37.270 --> 23:38.550 Super! 23:38.750 --> 23:45.170 Okay, let's start building an authenticated encryption scheme. 23:45.170 --> 23:47.010 And for that, what all do we need? 23:47.010 --> 23:51.570 We need a SIM key used in encryption as well as decryption. 23:51.570 --> 23:56.450 Use a CSPRNG ID for the GCM mode. 23:56.870 --> 24:00.390 We need the plain text to be encrypted. 24:00.410 --> 24:04.410 We need a plain text A associated data. 24:04.410 --> 24:09.470 And finally, the actual encryption and decryption APIs. 24:10.190 --> 24:17.350 For that, let's do a little bit of designing before we go into the coding session. 24:17.510 --> 24:29.830 And for that, I have opened this particular link which gives us all details about all algorithms coming out of the box of JDK in the latest Java version. 24:30.530 --> 24:35.110 What all do we need here is, let's start with symmetric keys. 24:35.110 --> 24:36.550 How to generate a symmetric key. 24:36.550 --> 24:41.670 And for that, we need to rely on this algorithm class called KeyGenerator. 24:41.770 --> 24:44.210 And look at the options it provides us. 24:44.210 --> 24:51.210 We just have to be safe and secure and use the AES algorithm because we are going to use AES GCM scheme here. 24:51.490 --> 24:54.470 Next, we need to generate a CSPRNG. 24:54.470 --> 25:05.490 And for that, we need to go into the secure random class, pick up the right algorithm and go by the default OS entropy for the seeding of that algorithm. 25:05.810 --> 25:18.690 And the actual encryption and decryption scheme is defined by the Cypher class where we have to configure it with the scheme we plan to use in terms of transformation. 25:18.690 --> 25:20.450 What does that scheme mean? 25:20.450 --> 25:24.590 To use the right block Cypher out of all these options. 25:24.590 --> 25:27.490 Use the right authentication mode. 25:27.490 --> 25:29.490 All these are unauthenticated mode. 25:29.490 --> 25:33.490 Use just the GCM and the required padding. 25:33.510 --> 25:42.490 GCM underneath is mainly just a counter mode, which is a stream Cypher, which does not need any padding. 25:42.590 --> 25:46.470 So that's how we will be defining our Cypher scheme. 25:46.470 --> 25:49.470 See the amount of moving blocks here. 25:49.470 --> 25:52.450 So let's get into coding. 25:52.930 --> 25:54.270 Symmetric keys. 25:54.270 --> 26:02.330 For that, let's go and create a symmetric class we are going to use for other primitives as well. 26:03.330 --> 26:07.530 A dedicated package for it. 26:10.010 --> 26:18.170 We'll return a secret key, which is nothing but a holder class to hold your symmetric keys to be transported around. 26:22.810 --> 26:25.490 Which takes the algorithm. 26:31.540 --> 26:37.180 And we can decide the size of the key we plan to generate. 26:38.380 --> 26:40.460 I choose 256. 26:40.460 --> 26:43.420 Even for whatever reason, you need to choose 128. 26:43.420 --> 26:44.580 Don't lose sleep over it. 26:44.580 --> 26:45.580 It's fine. 26:45.580 --> 26:50.540 This just puts us all the more ahead to be future compliant. 26:50.540 --> 26:52.340 Or future safe. 26:52.460 --> 26:53.880 Or future proof us. 26:56.540 --> 26:59.840 Key generator algorithm as we saw. 26:59.840 --> 27:04.020 Let's create an instance of it based on the algorithm. 27:05.020 --> 27:07.860 Initialize it with the right key size. 27:09.460 --> 27:11.920 And just generate it actually. 27:15.890 --> 27:16.990 Okay. 27:17.590 --> 27:21.210 Nothing in Java works without some kind of exceptional handling. 27:21.210 --> 27:22.290 Please don't do this. 27:22.290 --> 27:24.950 This is just to keep the demo shorter. 27:25.710 --> 27:29.170 So this is how a symmetric key would be generated. 27:29.170 --> 27:30.890 Let's use it here. 27:40.980 --> 27:45.480 And let's define the algorithm we plan to use this with. 27:46.340 --> 27:50.860 String a-algo is going to be a-es. 27:54.240 --> 27:55.100 Okay. 27:55.100 --> 27:57.120 Let's use this. 28:01.270 --> 28:04.050 With a-algo. 28:04.050 --> 28:04.730 Perfect. 28:04.730 --> 28:08.450 This should give us a nice looking safe, secure key. 28:08.730 --> 28:11.350 Next is generating IV. 28:11.350 --> 28:16.410 For that, let's first decide the size of the IV we plan to generate. 28:19.910 --> 28:23.410 Well, a good IV is anything above 128. 28:23.410 --> 28:26.890 I'll go for 256 because, hey, why not? 28:26.890 --> 28:29.630 It's defined in bytes, so 32. 28:30.550 --> 28:37.490 First, I'll initialize an array which will hold this IV for me. 28:38.710 --> 28:41.430 Of the IV size. 28:42.070 --> 28:47.390 Secondly, the more important one is actually generating it correctly. 28:48.450 --> 28:56.390 We decided to use drbg which provides us with 128 bits of security strength. 28:58.350 --> 29:01.110 Default is based out of hash. 29:02.050 --> 29:04.730 And just populate this guy. 29:05.010 --> 29:06.590 I want a secret key. 29:08.570 --> 29:09.850 SecureRandom. 29:11.370 --> 29:14.570 This should give us a good CSPR engine. 29:14.570 --> 29:17.010 And let's do some exceptional handling here. 29:20.960 --> 29:22.140 Perfect. 29:22.200 --> 29:25.300 The message we want to encrypt. 29:32.500 --> 29:34.600 Associated data. 29:36.560 --> 29:40.500 We can specify the IP address. 29:43.880 --> 29:45.760 And pass that around. 29:45.760 --> 29:50.110 A more common thing to do is actually do something like this. 29:50.740 --> 29:53.940 But in the interest of time. 29:55.540 --> 30:00.100 Finally, let's get to the most interesting part, which is how to write an encryption scheme. 30:10.240 --> 30:17.100 We'll return a ciphertext from the encryption function. 30:17.180 --> 30:20.940 Think about the block diagram. 30:20.940 --> 30:24.600 We'll take the plain text message. 30:24.600 --> 30:27.520 The associated data. 30:27.520 --> 30:29.800 The secret key. 30:30.800 --> 30:33.900 And the IV. 30:34.660 --> 30:40.300 Similarly, decryption will return a plain text byte array. 30:41.440 --> 30:48.180 It will take the ciphertext in byte array. 30:49.720 --> 30:57.100 If you again need the associated data, the secret key and the IV. 31:01.770 --> 31:08.370 The first steps for doing any encryption or decryption is initializing the cipher object as we saw. 31:08.510 --> 31:12.310 And which is common for both encryption as well as decryption. 31:12.310 --> 31:15.070 Let's do some code reuse here. 31:15.070 --> 31:22.650 And create a private method which will return an initialized cipher object. 31:24.770 --> 31:28.190 For both our encryption as well as decryption. 31:28.190 --> 31:32.910 For that, we'll first need the mode which is either encryption or decryption. 31:32.910 --> 31:41.990 It will take the associated data, the secret key as well as the byte array for your GCM. 31:42.490 --> 31:47.510 First, we will define the transformation which we saw. 31:50.420 --> 31:57.140 AES with GCM and no padding. 31:57.140 --> 31:57.900 Perfect. 31:59.020 --> 32:04.600 Next, we need to further define how the GCM mode is going to work. 32:04.600 --> 32:10.880 And for that, we need to go into the details of configuring the algorithm. 32:11.540 --> 32:14.020 And you have to trust me here. 32:15.400 --> 32:22.620 I am defining the output size of the authentication bit we expect and the IV it needs. 32:23.980 --> 32:31.360 Finally, we are just going to initialize the cipher algorithm with the mode. 32:32.520 --> 32:36.400 Sorry, this is the mode which is going to be passed here. 32:37.340 --> 32:40.640 Then, the next is the secret key. 32:41.040 --> 32:43.980 The algorithm spec we defined. 32:44.140 --> 32:50.020 And finally, some amount of randomness for the underneath algorithm to work. 32:50.020 --> 33:10.440 And this uses the default secure random algorithm which is native PRNG in non-blocking mode which is fine for most of the applications we are going to write encryption schemes for. 33:10.780 --> 33:15.560 Finally, just adding the associated data to it. 33:15.560 --> 33:25.920 And this should give us a nice configured cipher algorithm for use in both encryption as well as decryption. 33:26.580 --> 33:29.940 After some exceptional handling, obviously. 33:36.380 --> 33:37.280 Super. 33:37.280 --> 33:40.000 Let's go back to our encryption scheme. 33:41.000 --> 33:47.240 This passing on the mode which is the encryption mode here. 33:47.800 --> 33:53.040 The associated data, secret key and IV. 33:54.340 --> 33:56.420 Sorry, this is in caps. 33:57.900 --> 34:00.220 Next is we are going to... 34:02.760 --> 34:08.540 We are going to make the cipher object ready to start encrypting our message. 34:08.540 --> 34:14.800 For that, we are just going to take the message and convert it into bytes. 34:15.740 --> 34:23.540 But we are going to store this in a byte array to be returned properly to the driver class. 34:23.540 --> 34:24.540 And for that... 34:30.440 --> 34:32.760 And return this. 34:38.380 --> 34:41.260 This should do the encryption for us. 34:41.260 --> 34:48.460 And similarly, in the decryption side, we are going to set it in the decrypt mode. 34:48.460 --> 34:54.420 Pass on the associated data, the secret key and the initialization vector. 34:54.420 --> 35:02.460 Get back a nicely initialized ciphertext just which is used in... exactly as it would be used in the encryption mode. 35:02.460 --> 35:12.260 And prepare yourself for getting the plain text in a byte array to be returned back to the driver program. 35:16.670 --> 35:19.070 Ciphertext array to be... 35:19.610 --> 35:25.270 Let's store it in the plain text because there would be some exception handling. 35:28.610 --> 35:33.330 Okay, this should do the decryption for us. 35:33.330 --> 35:37.110 Let's put all these things together in the driver class. 35:37.350 --> 35:43.710 Let's prepare it to hold the ciphertext array from the authentication code. 35:43.710 --> 35:46.690 Before that, we have to use this class. 36:03.120 --> 36:06.220 First, let's encrypt the message. 36:06.240 --> 36:12.660 Pass on the associated data, the secret key and the IV. 36:13.640 --> 36:16.280 And get back plain. 36:18.920 --> 36:20.320 Plain text 36:23.420 --> 36:30.980 array, passing the ciphertext, associated data, secret key and the IV. 36:31.680 --> 36:34.920 And let's hope everything works. 36:35.260 --> 36:39.060 To preprint the byte array of plain text. 36:43.120 --> 36:48.100 And we got back the decrypted version of the message we encrypted. 36:48.100 --> 36:49.520 Super! 36:50.260 --> 36:59.280 Okay, after going through this frantic coding session, let's take a look at a little more simpler crypto primitive. 36:59.500 --> 37:02.720 It does not involve any keys, which is great news. 37:02.720 --> 37:08.460 This is called as hash functions or message digests or even checksums. 37:08.460 --> 37:20.320 And how it works is it takes a message, goes through this hash function and depending on the hash function is used, it will generate an output of fixed size. 37:20.760 --> 37:22.100 Where is it used? 37:22.100 --> 37:33.520 It's used in a lot of different crypto applications, most famously in generating machine authentication code for providing us with the authenticity and the integrity services. 37:33.520 --> 37:37.460 It's also used in digital signatures for similar services. 37:37.460 --> 37:49.220 It's used for any kinds of integrity checks or checksums, file integrity checks or even hard disk integrity checks and those kind of stuff. 37:49.880 --> 37:53.720 What kind of properties do we expect out of it? 37:53.920 --> 37:55.780 Well, it should be collision resistant. 37:55.780 --> 38:01.240 We should never be able to get hold of two different messages, which results in the same hash. 38:01.240 --> 38:14.280 It should be one-way, also called as a first-permise, which means that knowing the hash output, we should never be able to go back to the original message which generated that hash. 38:14.460 --> 38:24.420 And finally, it should be unpredictable, meaning we should never be coming up with two... knowing one message, we should not be able to generate second message to generate the same output. 38:25.100 --> 38:28.580 And what kind of a security strength do we expect? 38:28.580 --> 38:35.340 Well, security strength of 112 is going to be soon considered unsafe. 38:35.340 --> 38:38.020 Soon meaning after a decade though. 38:38.100 --> 38:44.020 So, which is not a lot of time in a cryptographic perspective. 38:44.540 --> 38:53.340 So, if we are using it, might as well let's use a hash function which at least exhibits 128 bits of security or even more. 38:54.060 --> 39:04.680 And the security strength of a hash depends on actually where it is used and which of these properties is the most important in that application. 39:04.680 --> 39:09.180 So , yeah, you have to be a little careful in which thing to use. 39:09.180 --> 39:11.940 But I have a simple pseudocode for that. 39:11.940 --> 39:22.880 What to do is just worry, just use the safest one which is SHA-3 or one of these three algorithms which has been recently made into the safe hashing list. 39:23.440 --> 39:29.160 SHA-224 is okay for MAC as well as digital signatures right now. 39:29.520 --> 39:36.720 But for digital signatures, it just provides 112 bits of security which is soon to be deprecated so why not just avoid it. 39:36.720 --> 39:42.860 And please don't use message digest anymore, MD family of algorithms for any of the applications. 39:42.860 --> 39:48.000 SHA-1 is still okay for HMAC but why bother. 39:48.180 --> 39:56.420 So, what I would do is I would just blindly use any SHA-256 or 384 kind of algorithms. 39:56.420 --> 40:08.800 Okay, next let's see the first symmetric key-based application called message authentication code. 40:08.840 --> 40:17.530 For any crypto systems which needs integrity or authenticity, this is one of the most famously used scheme. 40:17.530 --> 40:30.390 Most famously, you might be seeing it used in API authentication in most of the web applications right now providing APIs for usage. 40:30.390 --> 40:31.950 How it works? 40:31.950 --> 40:33.770 There is a sender and a receiver. 40:33.770 --> 40:34.830 There is a message. 40:34.830 --> 40:40.790 There is a symmetric key involved which your sender and receiver both has a copy of. 40:40.790 --> 40:52.290 The message and the key makes it into a MAC algorithm, generates a MAC and this MAC along with the plaintext is passed on to the receiver where this process is repeated. 40:52.290 --> 41:01.530 And if the incoming MAC is same as the MAC computed at the receiver side, well, the message received has authenticity as well as integrity checks in it. 41:01.590 --> 41:03.850 Pretty simple, straightforward. 41:04.210 --> 41:07.250 Let's see what to do and what not to do. 41:08.550 --> 41:13.090 There are a few different kinds of MAC algorithms. 41:13.090 --> 41:16.830 Some are based on hash, some are based on block ciphers. 41:17.650 --> 41:20.430 Avoid all the block cipher ones. 41:20.530 --> 41:29.150 They are a little bit more complicated involving two different keys, one for the actual MAC, one for the actual block cipher underneath. 41:29.230 --> 41:30.350 It's just complicated. 41:30.350 --> 41:31.250 Avoid using that. 41:31.250 --> 41:34.650 Use a hash-based MAC called HMAX. 41:34.650 --> 41:45.410 The key used for symmetric key use at least of size over 128 even if you have options to use 96 or 112 bit keys. 41:45.510 --> 41:52.850 And the reason being, based on this and the underlying hash, the security strength of your MAC is decided. 41:52.850 --> 41:58.050 So, there is a little bit of math here which I don't want to go into detail but just use this. 41:58.050 --> 42:01.010 And finally, protect your symmetric key on both the sides. 42:01.010 --> 42:05.430 This goes without saying but I still have seen a lot of things failing because of that. 42:07.010 --> 42:10.770 Let's see how both of this actually works in action. 42:12.950 --> 42:19.230 For that, let's go back in the development environment to see how to use this. 42:19.230 --> 42:20.930 Well, guess what? 42:20.930 --> 42:21.510 Surprise! 42:21.510 --> 42:29.730 I'm not going to do the entire coding here because it's fairly straightforward using the right APIs and making the right algorithmic choices. 42:29.730 --> 42:34.930 I'll just point you to the options available and which ones to pick. 42:35.010 --> 42:42.030 Let's first look at the way of generating message digest which is happening through this particular class. 42:42.030 --> 42:44.310 Look at the amount of options they provide. 42:44.310 --> 42:47.530 They provide still the MD family of algorithms. 42:47.530 --> 42:50.830 They also obviously provide SHA-1 and SHA-254. 42:50.830 --> 42:54.550 It's not out of scope or out of use yet. 42:55.170 --> 42:58.890 And it has the good ones, the SHA-2 and the SHA-3 family. 42:58.890 --> 43:03.410 Choosing one of these should keep you in safe areas. 43:04.430 --> 43:11.170 Similarly, for generating message authentication code, luckily we don't have to write the whole scheme from scratch. 43:11.170 --> 43:13.790 We have a corresponding API provided. 43:15.850 --> 43:19.770 Java does not at least provide block ciphers which is a good news. 43:19.770 --> 43:25.610 It provides a lot of algorithms based for HMAC. 43:26.230 --> 43:38.450 You have HMAC schemes using underlying MD5 family of algorithms, SHA-1, SHA-2, SHA-24, all the SHA-2 and SHA-3 family of algorithms. 43:38.450 --> 43:50.430 For safely storing your secrets or mainly generating keying material based on low entropy inputs, there are options also provided by the map class. 43:50.750 --> 43:53.570 It's good to know if you need to use that. 43:54.150 --> 44:02.810 The coding is as straightforward as the cipher object where you just initialize it with the right algorithm. 44:02.810 --> 44:13.050 Prepare the initialized object with the data you need to map or find a digest for and just do that with the doFinal method. 44:13.110 --> 44:14.870 That's pretty standard. 44:15.410 --> 44:19.070 In the interest of time, I'm not going to code that up for you. 44:21.150 --> 44:39.370 Going ahead with the applications, let's next look at how to actually store your secrets or the information you want to safeguard, be it your personal identifiable information or some GDPR compliance information, and most importantly, password. 44:39.370 --> 44:49.470 This application is very famously called as password hashing or password storage, but in my opinion, it can be extended to safeguard any kinds of secrets. 44:50.270 --> 44:55.030 Well, it's a well-known fact, don't ever store your data in plain text. 44:55.030 --> 45:00.590 It's also a big no-no to store it in a hash or just a simple salted hash. 45:00.710 --> 45:12.090 Modern GPUs and A6 hardware are very good at just parallelizing it and just cracking all this information. 45:12.090 --> 45:15.430 So, terrible idea in this day and time. 45:15.430 --> 45:26.050 What you should be doing is using something called as key derivation functions, which is inbuilt to be more expensive to be computed. 45:26.410 --> 45:31.530 There are a few different kinds of key derivation functions. 45:31.990 --> 45:36.250 Again, at the core of it, it will take a password, a salt, and then a hash. 45:37.080 --> 45:48.550 But there is something called as a work factor, which can be configured to add a way to artificially increase the computation time needed to generate this hash. 45:49.210 --> 45:55.350 What kind of work factors are available depends heavily on the algorithm used. 45:55.350 --> 46:12.850 There are a few algorithms called as adaptive functions, where we can just configure a repetition of a number of times the core primitive would be computed for thousands, even sometimes a couple of millions of times. 46:12.890 --> 46:22.190 And another category of functions are called as memory hard functions, where there is some amount of memory involved in doing this computation. 46:22.190 --> 46:31.330 I have another talk later in the day today, which talks extensively about all these kinds of functions. 46:31.330 --> 46:36.050 I'll highly encourage if you are interested in this to log in to watch that. 46:37.770 --> 46:44.370 Let's move on to talking about public key cryptography or asymmetric encryption. 46:45.230 --> 46:56.010 Well, it is still very similar to asymmetric keys, except for there is a private key involved to encrypt your message and a public key involved to actually decrypt back that message. 46:56.370 --> 47:06.930 And the core principle or the core property is having the public key, which is a public information, we should never be able to go back and get hold of the private key. 47:06.930 --> 47:18.650 Traditionally, these keys were computed based on prime numbers, which over time has proven not to be the best option. 47:18.650 --> 47:27.610 The algebra involved or the exponents needed to choose this prime number was getting increasingly fragile. 47:27.610 --> 47:33.950 These schemes are constant reasons of padding oracle attacks. 47:33.950 --> 47:40.610 And most importantly, we have a more promising option available in terms of elliptic curves. 47:40.610 --> 47:45.410 So I would highly encourage us to embrace this. 47:45.410 --> 47:47.570 They are much more compact. 47:47.570 --> 48:00.170 And most importantly, most of the public key cryptography based applications have a good amount of schemes out of the box available for this usage. 48:00.330 --> 48:04.830 So briefly, let's talk about how this elliptic curves work. 48:04.830 --> 48:11.290 There is this algebraic equation defined, which basically defines a particular curve. 48:11.290 --> 48:22.170 And the public key and the private key is based on the number of points on this curves and actual x and y coefficients of those points. 48:22.710 --> 48:34.810 And this expression contains, this algebraic expression contains all these kinds of coefficients, which is important in defining the curve. 48:35.550 --> 48:42.290 Everything except the private key, which is the number of points chosen on the curve is a public information. 48:42.890 --> 48:52.010 And again, given the public key, we cannot get hold of the private key. 48:54.250 --> 48:58.250 Elliptic curves is not such a modern or a newer thing. 48:58.250 --> 49:01.630 It is in existence since 1985. 49:01.630 --> 49:07.810 And over time, there have been lots of curves which have came into picture or being proposed. 49:07.810 --> 49:09.930 Not all of them are secure. 49:10.750 --> 49:13.510 I won't get distracted with any of those. 49:13.510 --> 49:23.790 What I use is Edward curves with specifically these two ones are specified on the slide 255.19 and 448. 49:24.430 --> 49:27.330 NIST has also approved a lot of curves. 49:27.330 --> 49:36.090 Not all of them provide security, which is 112 bits. 49:36.090 --> 49:42.170 So while picking NIST curves, be careful about the security provided out of the box. 49:42.310 --> 49:47.610 And it's NIST, there is always this conspiracy theory going on that there are backdoors. 49:47.610 --> 49:50.630 So my preference, stay away from it. 49:50.630 --> 49:54.610 But if you have to use it, there is nothing yet wrong about it. 49:55.090 --> 49:57.730 And as I said, stay away from everything else. 49:58.270 --> 50:06.570 The good thing is most of the public key applications comes with a bundled scheme to use these curves right out of the box. 50:06.570 --> 50:11.010 You don't have to deal with choosing key sizes or any of that. 50:12.630 --> 50:20.250 For digital signatures, you have an Edward curve based scheme similarly for key exchange. 50:20.250 --> 50:25.070 And a symmetric encryption scheme is also available called ECIS. 50:25.070 --> 50:31.730 With its own drawback, it can't encrypt more than 256 GB of data. 50:31.730 --> 50:37.310 This scheme is not yet very famously used or commonly used, but it's there. 50:39.770 --> 50:48.270 Next, let's look at one of the most common public key based application called digital signatures. 50:48.410 --> 51:05.430 So just like in a physical world, when we sign a document, you are saying that you are providing authenticity, integrity and a way of not walking away from the document, which is the non-reputation service while putting that simple signature on a piece of document. 51:05.430 --> 51:11.870 Similarly, we have a construct in digital world called digital signatures. 51:12.050 --> 51:14.110 How does that work? 51:14.110 --> 51:22.530 Again, there is a plain text message whose hash is computed, passed through a signature algorithm and the signature is computed. 51:22.530 --> 51:30.350 This signature along with the plain text message is passed to the receiving side where the same operation is performed again. 51:30.350 --> 51:32.230 The output hashes are compared. 51:32.230 --> 51:36.750 If they are same, then the services are achieved out of the box. 51:36.770 --> 51:43.450 Something very similar to Mac, except for there is a private key involved on the sender side or for signing. 51:43.510 --> 51:47.350 And for verification, there is a public key of the signer involved. 51:47.350 --> 51:51.590 So that's how simply the digital signatures work. 51:52.510 --> 51:56.050 Let's look at some of the do's and things to avoid. 51:56.050 --> 52:05.970 Digital signatures over time have been very famously used by RSA algorithms or the Al-Gamal key-based DSA algorithms. 52:06.290 --> 52:08.410 If you have a choice, just avoid that. 52:08.410 --> 52:14.830 In fact, DSA is already going to be deprecated in the next DSS standard coming out of the government body. 52:14.830 --> 52:17.910 RSA is fragile as we spoke earlier. 52:18.710 --> 52:21.630 ECDSA is another common thing used. 52:21.670 --> 52:25.810 It has its own issues of how well the nonces are generated. 52:25.910 --> 52:29.210 There was a talk talking in detail about this earlier today. 52:29.210 --> 52:33.370 Hopefully, you got a chance to look at that. 52:34.070 --> 52:37.010 As we spoke earlier, use Edward curves. 52:37.010 --> 52:43.670 Underlying hashes use SHA-2 or SHA-3 family providing at least 112 bits of security. 52:43.670 --> 52:49.810 Avoid MD families and SHA-2 and even SHA-24 algorithms. 52:51.290 --> 52:53.730 Let's see how this actually works. 52:53.730 --> 52:58.710 For that, let's go to the development environment again. 53:00.430 --> 53:02.910 Back to our CryptoDriver class. 53:02.910 --> 53:07.510 Let's see how we can implement digital signatures using Java. 53:07.510 --> 53:12.470 What all do we need from planning and designing? 53:12.470 --> 53:16.090 We need ECC based key pairs. 53:16.830 --> 53:22.250 We need signer side of the code and the verifier side of the code. 53:22.270 --> 53:26.530 Now, I have a little bit of a bad news for you. 53:26.530 --> 53:35.990 The signature classes and the public key algorithms coming out of the box from Java does not provide us with Edward keys. 53:35.990 --> 53:40.710 Edward key based key exchange algorithms are available but not for signatures. 53:41.170 --> 53:45.710 But worry not, we have a pretty good shortcut for this. 53:45.710 --> 53:57.130 There is a third party provider for Java called Bouncy Castle which provides us with this and it seamlessly works with all the JDK APIs we have been looking at so far. 53:57.130 --> 53:59.850 So, let's go ahead and use that. 53:59.850 --> 54:05.910 And for that, let's first go ahead and create an ECC keys generator class. 54:07.010 --> 54:12.890 Again, just like secret keys, this class is a holder for the public and the private keys. 54:16.070 --> 54:26.950 And for us to use this third party provider, the only thing extra we need to do is add it on our class part to be picked up by the algorithms. 54:27.130 --> 54:31.370 And after that, it's pretty much business as usual actually. 54:31.670 --> 54:36.250 Let's make sure we use the required algorithm. 54:37.210 --> 54:41.190 And this is going to be provided by this Bouncy Castle provider. 54:41.470 --> 54:50.410 And we just have to generate key pairs at this point after obviously adding the much needed exception handling here. 54:50.810 --> 54:54.130 Let's go back to our driver class and start using this. 55:12.030 --> 55:13.830 Key pairs... 55:16.820 --> 55:24.050 And let's see the signer and the verifier side of the code. 55:24.880 --> 55:28.880 It's just creating a simple message for us to sign. 55:35.080 --> 55:44.880 Let's go ahead and create a different package to help us with this signer and verifier APIs for digital signatures. 55:44.980 --> 55:50.660 We are going to return the actual sign for the message. 55:50.660 --> 55:55.520 We need private key and that's it actually. 55:55.520 --> 56:09.380 And similarly on the verifier side, we are going to return a boolean saying all the services we expect the scheme to provide are actually met or not. 56:12.040 --> 56:14.810 And actually pass the signature. 56:20.820 --> 56:23.520 Okay, let's go ahead and coding up. 56:23.520 --> 56:27.000 Again we are going to use the signature API class. 56:30.980 --> 56:35.860 Making sure we are using the right algorithm we plan to use. 56:36.120 --> 56:43.280 Next going ahead and preparing this class for actually signing messages with the private key. 56:44.200 --> 56:55.560 And then adding the message we wish to do just like we did it in Cypher as well as looked at doing it in Mac or Message Digest. 56:55.560 --> 57:02.020 And this is just going to hold a final signature for us. 57:03.180 --> 57:05.460 Actually sign it. 57:05.460 --> 57:07.720 This is what we are going to return. 57:08.880 --> 57:12.520 Let's add some exception handling here. 57:18.580 --> 57:22.740 Similarly on the verifier side. 57:25.300 --> 57:30.860 We are again going to use the same AdWords course. 57:31.120 --> 57:37.860 This time we are going to prepare it for verifying with the public key. 57:38.640 --> 57:43.520 Preparing it with the message to be verified. 57:45.000 --> 57:48.920 And finally actually verifying the message. 58:00.710 --> 58:06.730 Signature.VerifyWithSignProvided And let's return this guy. 58:16.750 --> 58:19.750 Cool, this is the signer and the verifier side. 58:19.750 --> 58:23.690 So let's go back to the driver class and actually use this. 58:37.290 --> 58:42.540 Let's collect the signature in this particular array. 58:43.650 --> 58:48.690 The message and the private key. 58:48.950 --> 58:51.750 And let's see if we could verify this. 59:03.180 --> 59:06.980 This time we are going to give it a public key. 59:07.040 --> 59:09.600 And the actual signature. 59:10.180 --> 59:12.600 And let's see if all this works. 59:18.810 --> 59:19.980 Cool. 59:20.590 --> 59:26.230 So just to show how easy it is to use elliptic curves. 59:26.230 --> 59:27.670 Don't be discouraged. 59:27.670 --> 59:28.710 Embrace that. 59:28.710 --> 59:29.980 It's really simple. 59:30.490 --> 59:32.930 And let's go back to our slides. 59:32.930 --> 59:43.150 This is what I wanted to talk about in all different crypto primitives and its building blocks and some most commonly used applications. 59:43.970 --> 59:51.150 Before I conclude, I want to point out that key management is a huge issue. 59:51.550 --> 59:59.370 If you would have noticed across all the things we spoke about, we always needed some kind of a key material. 01:00:00.030 --> 01:00:11.770 We have to be conscious about how we are generating it, how we are reusing it, how we are distributing it, how well we are storing it, how well we are refreshing it on a timely basis. 01:00:11.770 --> 01:00:20.210 And unfortunately, all these aspects of actually managing your key material is usually homegrown. 01:00:20.570 --> 01:00:27.090 Which is one of the biggest reasons why any crypto systems fail. 01:00:27.850 --> 01:00:34.910 And something which is not very widely talked about or honestly not even paid a lot of attention to. 01:00:34.910 --> 01:00:47.070 The worst things I have seen is hard-coded keys and even worse is actually those keys getting checked in into open GitHub repositories. 01:00:47.070 --> 01:00:56.150 There are many attacks around that recently which comes to mind as PrimeFace's WebLogic-based key attack. 01:00:57.310 --> 01:00:59.090 Just be conscious about that. 01:00:59.090 --> 01:01:00.030 Don't ignore this. 01:01:00.030 --> 01:01:01.190 It's huge. 01:01:02.770 --> 01:01:22.450 Finally, I hope next whenever you look at any new crypto failure, hopefully it does not happen often, or you are looking at understanding previous use cases, you might find something which was on the don'ts list or something on the cautious list in today's talk. 01:01:23.230 --> 01:01:31.670 This small community of ours shares the biggest responsibility of making the internet a safer place and keeping it secure. 01:01:32.650 --> 01:01:38.730 And that was what I hope you have shared enough in this one hour. 01:01:39.810 --> 01:01:43.810 Finally, I would like to conclude by giving my contact information. 01:01:43.810 --> 01:01:46.330 My DMs are always open. 01:01:46.330 --> 01:01:58.310 I talk a lot about all these things and a few other topics on my employer's blog post in much more detail than what I could ever cover in just 60 minutes. 01:01:58.390 --> 01:02:07.590 And all the codes we worked up today is more polished and in a real world API-based usage dockerized on the GitLab repo here. 01:02:07.590 --> 01:02:10.630 So feel free to poke around. 01:02:11.010 --> 01:02:11.970 Thank you.