1
00:00:03,700 --> 00:00:11,500
Very good afternoon, good evening, or even good morning, depending on which time zone you are listening to this talk from.

2
00:00:11,960 --> 00:00:17,020
Isn't it interesting how we all are so very well virtually connected through this platform?

3
00:00:17,020 --> 00: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.

4
00:00:24,920 --> 00:00:30,400
I know it has been hard in the middle of this global pandemic, but we are still connected.

5
00:00:30,400 --> 00:00:31,460
That's great.

6
00:00:32,840 --> 00:00:35,620
It's always a good idea to introduce yourself.

7
00:00:35,620 --> 00:00:37,220
I'm Manasi Sheth.

8
00:00:37,220 --> 00:00:43,860
I work as a principal security researcher for a leading static analysis company called Veracode.

9
00:00:43,860 --> 00:00:46,820
We are located just outside Boston.

10
00:00:47,420 --> 00:00:54,660
We have over 2,000 unique customers across different verticals using all kinds of programming languages.

11
00:00:54,660 --> 00: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.

12
00:01:18,840 --> 00:01:23,540
I'm not a cryptologist or a crypto analyst or even a mathematician.

13
00:01:23,540 --> 00:01:29,020
I'm just a huge crypto enthusiast like a lot of people here.

14
00:01:29,020 --> 00:01:33,180
I like to be on top of all the practical aspects of cryptography.

15
00:01:33,180 --> 00:01:43,340
I've spent a lot of time understanding details of different crypto primitives and crypto mini systems.

16
00:01:43,680 --> 00:01:48,960
I've seen a lot of crypto implementations across languages.

17
00:01:48,960 --> 00:01:55,240
And I try to use all this information to make sure our customers' code bases are secure.

18
00:01:58,040 --> 00:02:00,120
So why cryptography?

19
00:02:00,660 --> 00:02:03,480
Well, I think cryptography is everywhere.

20
00:02:04,600 --> 00:02:09,220
It's the basis of a lot of things you are currently seeing around you.

21
00:02:09,220 --> 00:02:11,480
You would be connected through Wi-Fi.

22
00:02:11,480 --> 00:02:13,980
You would be having some Bluetooth devices.

23
00:02:13,980 --> 00:02:17,780
You might be using e-wallets to buy coffee or something.

24
00:02:17,780 --> 00:02:19,600
You might be looking at emails.

25
00:02:19,600 --> 00:02:25,320
You are listening to this through a video conferencing software which is supposed to be secure.

26
00:02:25,780 --> 00:02:28,740
You might be doing some Bitcoin mining.

27
00:02:28,740 --> 00:02:30,420
What I'm trying to say is it's everywhere.

28
00:02:30,420 --> 00:02:34,000
It's used right now by you, your family, your friends.

29
00:02:34,560 --> 00:02:40,900
Everyone you know and care about and hope are secure enough from any kind of online threats.

30
00:02:42,260 --> 00:02:48,240
In this hyper-connected world, we rely a lot on crypto to keep us secure.

31
00:02:48,240 --> 00: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.

32
00:02:59,100 --> 00:03:03,060
Like maybe e-banking or e-wallets or whatever.

33
00:03:03,640 --> 00:03:09,180
Or maybe code signing of a software we are trying to buy.

34
00:03:09,180 --> 00:03:17,020
We need cryptography to help us be secure for all these things and much, much more than that.

35
00:03:17,740 --> 00:03:20,600
Then why are we seeing so many crypto failures?

36
00:03:21,460 --> 00:03:26,260
Well, I'm sure a lot of people would be having this reaction like, oh no, not again.

37
00:03:26,260 --> 00:03:27,980
Why are things failing now?

38
00:03:27,980 --> 00: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.

39
00:03:37,640 --> 00:03:39,060
It's like this.

40
00:03:39,880 --> 00:03:45,880
Thinking a little deeper while looking at different use cases of crypto failures.

41
00:03:45,900 --> 00:03:50,160
What I feel is cryptography is hard.

42
00:03:50,460 --> 00:03:58,120
Only more than a couple of dozens of people across decades completely understand all aspects of cryptography.

43
00:03:58,120 --> 00: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.

44
00:04:13,140 --> 00:04:15,580
Well, I have all respect for these implementers.

45
00:04:15,580 --> 00:04:19,060
They have to understand the hardest parts of cryptography.

46
00:04:19,060 --> 00:04:23,760
They have to use their domain development experience to write these libraries.

47
00:04:23,760 --> 00: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.

48
00:04:32,120 --> 00:04:38,300
How it will be well understood by the most well-meaning security conscious developers.

49
00:04:38,300 --> 00:04:45,740
So that they don't make any mishaps of using these implementations.

50
00:04:47,340 --> 00:04:53,060
I wish the implementers took it a little bit ahead than that.

51
00:04:53,060 --> 00:05:00,480
And took some responsibility of writing much cleaner documentation, much cleaner APIs.

52
00:05:00,480 --> 00:05:08,380
Secure defaults, deprecating legacy or insecure algorithms right out of the sight of developers.

53
00:05:08,960 --> 00:05:13,780
Maybe we might be seeing a few lesser crypto failures at that point.

54
00:05:13,780 --> 00:05:16,260
In my opinion, it's almost undebatable.

55
00:05:16,260 --> 00:05:21,800
85% of crypto failures we see are coming from not bad implementations.

56
00:05:21,800 --> 00:05:25,080
But bad usages of those implementations.

57
00:05:25,240 --> 00:05:34,140
So hopefully we all share some responsibility in educating users of these crypto APIs.

58
00:05:36,200 --> 00:05:41,940
Before going any further, I would like to make some cryptographic disclaimers.

59
00:05:41,980 --> 00:05:47,240
No matter how tempting it is, please don't roll your own crypto.

60
00:05:47,240 --> 00:05:55,360
All these great implementers have spent way too much time understanding all different aspects of a crypto algorithm.

61
00:05:55,360 --> 00:06:01,740
And provided us with the implementation which a lot of times is time-tested, crypto-analyzed.

62
00:06:01,740 --> 00:06:03,000
Please use that.

63
00:06:03,000 --> 00:06:06,040
It's for us to use it and be safe.

64
00:06:06,940 --> 00:06:12,000
I understand not always we have an option to choose an implementation.

65
00:06:12,000 --> 00:06:17,200
But if you do, I would highly suggest you use this implementation called NSEL.

66
00:06:17,200 --> 00:06:19,320
It's written by cryptographers.

67
00:06:19,540 --> 00:06:21,180
Documentation is very clean.

68
00:06:21,180 --> 00:06:25,760
They have all kinds of secure defaults just out of the box.

69
00:06:25,760 --> 00:06:28,840
Everything else is not even visible to us.

70
00:06:29,180 --> 00: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.

71
00:06:39,700 --> 00:06:44,480
Even Lipsodium, another favorite, is a fork of NSEL.

72
00:06:44,480 --> 00:06:48,460
So use one of that and you will go a long way.

73
00:06:49,520 --> 00:06:55,480
Crypto is crucial to be secured, but that does not mean we ignore everything else in the system.

74
00:06:55,480 --> 00:07:01,100
We still have to worry about all kinds of application security attacks, all kinds of networking.

75
00:07:01,100 --> 00:07:03,280
We have to make sure our endpoints are secure.

76
00:07:03,280 --> 00:07:05,340
We have to take care of all those things.

77
00:07:05,340 --> 00:07:10,100
We should not be relaxing the moment we got our crypto right.

78
00:07:11,140 --> 00:07:14,000
Let's see what we are going to talk about today.

79
00:07:14,080 --> 00: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.

80
00:07:26,280 --> 00:07:27,440
It's quite a mouthful.

81
00:07:27,440 --> 00:07:30,620
I'm just going to call as CSPRNG going ahead.

82
00:07:30,620 --> 00:07:35,920
There will be some kind of an encryption scheme going, usually symmetric encryptions.

83
00:07:36,640 --> 00:07:40,020
Maybe some kind of one-way hash functions.

84
00:07:40,600 --> 00:07:45,780
And no crypto system works, none of these crypto primitives work in isolation.

85
00:07:45,780 --> 00: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.

86
00:07:58,120 --> 00: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.

87
00:08:14,240 --> 00:08:19,620
OK, let's start by first looking at CSPRNG, which is used almost everywhere.

88
00:08:19,620 --> 00:08:21,660
So what is CSPRNG?

89
00:08:21,660 --> 00: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.

90
00:08:31,240 --> 00:08:34,900
Namely, it should appear completely random.

91
00:08:35,060 --> 00:08:41,900
We should not be able to locate any kind of pattern in the way those digits are.

92
00:08:41,980 --> 00:08:47,220
Secondly, it should be completely, it should be unpredictable.

93
00:08:47,220 --> 00: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.

94
00:08:55,300 --> 00:08:59,960
And lastly, we should never be able to reproduce the same set of digits again.

95
00:09:00,620 --> 00:09:03,860
Now, where is this used or where is it required?

96
00:09:03,860 --> 00:09:04,940
Well, it's everywhere.

97
00:09:04,940 --> 00:09:10,540
It's like any kind of keying material you would be generating for any kind of cryptographic algorithm.

98
00:09:10,540 --> 00:09:16,660
Namely, you would need keys to be generated for your encryption, for your message authentication codes.

99
00:09:17,220 --> 00: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.

100
00:09:28,600 --> 00:09:31,940
Basically, it's going to be used every single place.

101
00:09:31,940 --> 00:09:35,900
Now, how to actually generate this?

102
00:09:36,940 --> 00:09:42,340
There are three main blocks or three main areas.

103
00:09:43,720 --> 00:09:48,480
There are three main parts of any CSPRNG algorithm.

104
00:09:48,480 --> 00:09:52,070
Obviously, the output which you most care about.

105
00:09:52,900 --> 00:09:57,800
And the algorithm which basically churns and gives you this output.

106
00:09:57,800 --> 00:10:03,940
But knowing the algorithm, it's extremely trivial to get the output.

107
00:10:03,940 --> 00: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.

108
00:10:17,480 --> 00:10:26,940
For the seeding to happen, the input to the seeding part of the algorithm should be of the highest entropy possible.

109
00:10:26,940 --> 00:10:36,760
Basically, the output is depending on how high the entropy or the source of randomness of this seeding sources.

110
00:10:37,500 --> 00: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.

111
00:10:44,820 --> 00:10:48,940
So we had to rely on what the computer is going to offer us.

112
00:10:49,220 --> 00:10:54,220
So right now, the highest source of entropy is what the operating system is going to provide us.

113
00:10:54,220 --> 00: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.

114
00:11:02,220 --> 00: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.

115
00:11:13,720 --> 00:11:18,520
All these things are collected and then fed into the algorithm.

116
00:11:18,520 --> 00:11:26,360
And that's what makes your CSPRNG output extremely secure or extremely random.

117
00:11:26,360 --> 00: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.

118
00:11:37,020 --> 00:11:39,820
Or it's directly proportional, at least that way.

119
00:11:41,420 --> 00:11:44,420
So what are some of the do's and don'ts around it?

120
00:11:44,420 --> 00:11:50,120
Well, since the source of entropy is most important, let's start talking about that first.

121
00:11:50,420 --> 00:11:54,320
Always go with what your operating system provides us.

122
00:11:55,300 --> 00:12:03,240
There are different mechanisms which the operating system provides.

123
00:12:03,240 --> 00:12:08,940
Most importantly, either you go with a blocking source of entropy or a non-blocking.

124
00:12:08,940 --> 00:12:19,860
What does that mean is non-blocking is till a sufficient quantity of entropy is reached, the algorithm is not seeded.

125
00:12:19,860 --> 00:12:25,280
So basically, our algorithm is blocked till the entropy is filled out.

126
00:12:25,280 --> 00:12:29,000
And non-blocking is whatever entropy is available, just feed the algorithm.

127
00:12:30,400 --> 00:12:33,120
That's what operating system gives us.

128
00:12:33,120 --> 00:12:36,940
Well, most of the cryptographers are pessimistic people.

129
00:12:36,940 --> 00:12:42,260
They'll say, oh my god, you have to use blocking source, you have to have some level of entropy.

130
00:12:42,780 --> 00:12:45,020
Well, I beg to differ.

131
00:12:45,080 --> 00:12:50,420
80% of the applications don't really need that high level of entropy.

132
00:12:50,420 --> 00:12:56,340
You would be fine with using a non-blocking source for most part.

133
00:12:57,780 --> 00: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,

134
00:13:17,040 --> 00:13:19,100
which even the operating system provides.

135
00:13:19,100 --> 00: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.

136
00:13:30,720 --> 00: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.

137
00:13:41,100 --> 00: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.

138
00:13:48,120 --> 00: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.

139
00:13:58,260 --> 00:14:01,040
Just don't do that, please.

140
00:14:01,920 --> 00:14:06,040
There are obviously some attacks because of a lower source of entropy.

141
00:14:06,040 --> 00:14:11,620
One which comes to my mind is the Sony PlayStation attack.

142
00:14:11,620 --> 00: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.

143
00:14:27,900 --> 00:14:31,660
So this is out there, it happens all the time.

144
00:14:31,980 --> 00:14:35,060
The next is, what algorithm to use?

145
00:14:35,060 --> 00: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.

146
00:14:46,980 --> 00:14:51,600
Government standards approved only these ones, it's better to use that.

147
00:14:51,860 --> 00: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.

148
00:14:59,680 --> 00:15:06,760
If not these, then usually there are some good library-specific algorithms.

149
00:15:06,760 --> 00:15:16,040
But make sure those library-specific mechanisms are using operating system source of entropy, and not anything other than that.

150
00:15:16,240 --> 00: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.

151
00:15:24,780 --> 00: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.

152
00:15:35,800 --> 00:15:41,980
But if it was seeded initially, it used to just go in some initial state and always give that output.

153
00:15:41,980 --> 00:15:46,660
It's fixed now, but there could be such idiosyncrasies lying somewhere.

154
00:15:46,660 --> 00:15:55,840
And there are different algorithms based on mercery twisters, like the older dual EC1s, again the classic Sony hack.

155
00:15:56,600 --> 00:16:03,620
Even some insecure symmetric cipher based, just don't use any of that anymore.

156
00:16:03,760 --> 00: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.

157
00:16:17,060 --> 00:16:25,700
Next, let's talk about one of the most famous crypto primitive called encryption, almost synonymous to cryptography.

158
00:16:25,820 --> 00:16:32,100
Well, we obviously need our data which is stored at rest or in transit to be confidential.

159
00:16:32,200 --> 00:16:34,800
So that is one of the biggest property we expect.

160
00:16:35,260 --> 00: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.

161
00:16:49,480 --> 00:16:50,880
And why so?

162
00:16:50,940 --> 00: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.

163
00:17:11,800 --> 00: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.

164
00:17:22,080 --> 00: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.

165
00:17:31,940 --> 00:17:35,220
It used to work, but there are a lot of issues with that.

166
00:17:35,220 --> 00:17:39,480
It was slow, it had a lot more crypto systems going on.

167
00:17:39,480 --> 00:17:41,380
So the crypto analysis became difficult.

168
00:17:41,380 --> 00:17:43,380
It was much more fragile.

169
00:17:43,600 --> 00:17:52,920
So what the greater crypto community came up with was providing an authenticated encryption right out of the box.

170
00:17:52,960 --> 00:18:02,060
And this is another property we expect out of AE, which is authenticated encryption.

171
00:18:02,380 --> 00:18:04,720
We need authenticity as well as integrity.

172
00:18:04,720 --> 00:18:11,160
So these are the three properties we expect out of any modern symmetric encryption scheme.

173
00:18:11,400 --> 00:18:13,200
And how is this achieved?

174
00:18:13,360 --> 00:18:17,940
Well, at the core of it, we still have a symmetric block cipher running.

175
00:18:17,940 --> 00:18:23,000
It takes a symmetric key, it takes plain text, it throws away ciphertext.

176
00:18:23,000 --> 00:18:31,440
But there was yet another detail, yet another information, which was like a nice to have feature called associated data.

177
00:18:32,120 --> 00:18:40,260
What that is, it would be nice to have some plain text being transferred as plain text on the receiver side.

178
00:18:40,260 --> 00:18:43,640
But it still takes part in the authenticity of it.

179
00:18:43,640 --> 00:18:48,840
So for example, imagine a sender is sending a packet to a receiver.

180
00:18:48,840 --> 00:18:54,940
So the IP address of the receiver needs to be in plain text, but the payload needs to be encrypted.

181
00:18:54,940 --> 00: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.

182
00:19:03,660 --> 00:19:07,840
It is called as authenticated encryption with associated data.

183
00:19:08,120 --> 00:19:11,080
So just coming back to this block diagram.

184
00:19:12,540 --> 00: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.

185
00:19:23,300 --> 00:19:25,520
And obviously the symmetric key.

186
00:19:25,580 --> 00:19:28,900
Authenticated data comes out as plain text.

187
00:19:28,900 --> 00:19:32,160
And we obviously get the ciphertext.

188
00:19:32,160 --> 00: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.

189
00:19:45,740 --> 00: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.

190
00:19:58,820 --> 00:20:01,700
That's how simply it all works.

191
00:20:03,880 --> 00:20:05,480
Do's and don'ts.

192
00:20:05,480 --> 00:20:08,480
Well, you can use any good block cipher.

193
00:20:08,760 --> 00:20:14,800
AES is one of the most commonly used safe block cipher here in the United States.

194
00:20:14,800 --> 00:20:18,980
If we talk more globally, we have ARIA, Camellia, and CAST6 too.

195
00:20:19,700 --> 00:20:26,260
There are only few block cipher modes which provide authenticity and integrity services.

196
00:20:26,260 --> 00:20:28,380
GCM being the most famous.

197
00:20:28,380 --> 00:20:32,960
The rest of the modes are either expensive or patented.

198
00:20:33,160 --> 00:20:36,720
Patents expire at different times in different countries.

199
00:20:36,780 --> 00:20:40,180
So AES-GCM is the most famous scheme.

200
00:20:41,100 --> 00:20:43,480
And hopefully you would be using GCM.

201
00:20:43,480 --> 00: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.

202
00:20:56,460 --> 00: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.

203
00:21:04,660 --> 00:21:11,720
And it comes with its own authenticity scheme called Poly1305.

204
00:21:11,720 --> 00:21:19,220
It's a promising alternative or a backup plan if AES-GCM fails.

205
00:21:19,320 --> 00:21:23,860
If it fails, the world cannot all of a sudden be insecure.

206
00:21:23,860 --> 00:21:33,540
So our great cryptographers have already come up and it has already been implemented in a lot of modern programming languages.

207
00:21:33,600 --> 00:21:41,180
And to go a little further, I think Google and Cloudflare are already using this in their TLS implementation.

208
00:21:41,180 --> 00:21:48,140
So knowingly or unknowingly, right now even 30% of our websites use this anyways.

209
00:21:48,800 --> 00:21:51,820
It's three times faster than AES-GCM scheme.

210
00:21:51,820 --> 00:22:00,300
So a lot of slower hardware, even your Android phones or IoT devices needed an authentication scheme.

211
00:22:00,300 --> 00:22:03,300
And this is a promising alternative for that.

212
00:22:03,920 --> 00:22:05,700
So embrace that.

213
00:22:05,720 --> 00:22:08,600
There is no harm in using that already.

214
00:22:10,560 --> 00:22:16,480
And lastly, stay away from all other block ciphers, all other stream ciphers and all other modes.

215
00:22:16,480 --> 00:22:19,560
There are just way too many to list on the slide.

216
00:22:19,680 --> 00:22:23,560
I've just listed the most common ones out there.

217
00:22:25,480 --> 00:22:29,760
Okay, let's see how both these primitives work in action.

218
00:22:29,760 --> 00:22:33,860
And for that, let's go into our development environment.

219
00:22:33,860 --> 00:22:39,780
I'm choosing to show these API usages in Java for two main reasons.

220
00:22:39,780 --> 00:22:44,740
One, Java is one of the most chaotic crypto implementation I have seen.

221
00:22:44,740 --> 00:22:49,740
And second thing is, it's one of the most commonly used enterprise programming language.

222
00:22:49,740 --> 00:22:55,160
So it's extremely important that we pass the message on how to use it securely.

223
00:22:56,380 --> 00: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.

224
00:23:05,260 --> 00:23:17,820
Let's just start with first creating a mandatory crypto driver class where we will be using all

225
00:23:21,300 --> 00:23:24,060
different APIs through.

226
00:23:26,520 --> 00:23:31,580
Simple HelloWorld, where we are going to say hello to CryptoVillage.

227
00:23:34,350 --> 00:23:36,610
And let's see if this works.

228
00:23:37,270 --> 00:23:38,550
Super!

229
00:23:38,750 --> 00:23:45,170
Okay, let's start building an authenticated encryption scheme.

230
00:23:45,170 --> 00:23:47,010
And for that, what all do we need?

231
00:23:47,010 --> 00:23:51,570
We need a SIM key used in encryption as well as decryption.

232
00:23:51,570 --> 00:23:56,450
Use a CSPRNG ID for the GCM mode.

233
00:23:56,870 --> 00:24:00,390
We need the plain text to be encrypted.

234
00:24:00,410 --> 00:24:04,410
We need a plain text A associated data.

235
00:24:04,410 --> 00:24:09,470
And finally, the actual encryption and decryption APIs.

236
00:24:10,190 --> 00:24:17,350
For that, let's do a little bit of designing before we go into the coding session.

237
00:24:17,510 --> 00: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.

238
00:24:30,530 --> 00:24:35,110
What all do we need here is, let's start with symmetric keys.

239
00:24:35,110 --> 00:24:36,550
How to generate a symmetric key.

240
00:24:36,550 --> 00:24:41,670
And for that, we need to rely on this algorithm class called KeyGenerator.

241
00:24:41,770 --> 00:24:44,210
And look at the options it provides us.

242
00:24:44,210 --> 00: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.

243
00:24:51,490 --> 00:24:54,470
Next, we need to generate a CSPRNG.

244
00:24:54,470 --> 00: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.

245
00:25:05,810 --> 00: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.

246
00:25:18,690 --> 00:25:20,450
What does that scheme mean?

247
00:25:20,450 --> 00:25:24,590
To use the right block Cypher out of all these options.

248
00:25:24,590 --> 00:25:27,490
Use the right authentication mode.

249
00:25:27,490 --> 00:25:29,490
All these are unauthenticated mode.

250
00:25:29,490 --> 00:25:33,490
Use just the GCM and the required padding.

251
00:25:33,510 --> 00:25:42,490
GCM underneath is mainly just a counter mode, which is a stream Cypher, which does not need any padding.

252
00:25:42,590 --> 00:25:46,470
So that's how we will be defining our Cypher scheme.

253
00:25:46,470 --> 00:25:49,470
See the amount of moving blocks here.

254
00:25:49,470 --> 00:25:52,450
So let's get into coding.

255
00:25:52,930 --> 00:25:54,270
Symmetric keys.

256
00:25:54,270 --> 00:26:02,330
For that, let's go and create a symmetric class we are going to use for other primitives as well.

257
00:26:03,330 --> 00:26:07,530
A dedicated package for it.

258
00:26:10,010 --> 00: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.

259
00:26:22,810 --> 00:26:25,490
Which takes the algorithm.

260
00:26:31,540 --> 00:26:37,180
And we can decide the size of the key we plan to generate.

261
00:26:38,380 --> 00:26:40,460
I choose 256.

262
00:26:40,460 --> 00:26:43,420
Even for whatever reason, you need to choose 128.

263
00:26:43,420 --> 00:26:44,580
Don't lose sleep over it.

264
00:26:44,580 --> 00:26:45,580
It's fine.

265
00:26:45,580 --> 00:26:50,540
This just puts us all the more ahead to be future compliant.

266
00:26:50,540 --> 00:26:52,340
Or future safe.

267
00:26:52,460 --> 00:26:53,880
Or future proof us.

268
00:26:56,540 --> 00:26:59,840
Key generator algorithm as we saw.

269
00:26:59,840 --> 00:27:04,020
Let's create an instance of it based on the algorithm.

270
00:27:05,020 --> 00:27:07,860
Initialize it with the right key size.

271
00:27:09,460 --> 00:27:11,920
And just generate it actually.

272
00:27:15,890 --> 00:27:16,990
Okay.

273
00:27:17,590 --> 00:27:21,210
Nothing in Java works without some kind of exceptional handling.

274
00:27:21,210 --> 00:27:22,290
Please don't do this.

275
00:27:22,290 --> 00:27:24,950
This is just to keep the demo shorter.

276
00:27:25,710 --> 00:27:29,170
So this is how a symmetric key would be generated.

277
00:27:29,170 --> 00:27:30,890
Let's use it here.

278
00:27:40,980 --> 00:27:45,480
And let's define the algorithm we plan to use this with.

279
00:27:46,340 --> 00:27:50,860
String a-algo is going to be a-es.

280
00:27:54,240 --> 00:27:55,100
Okay.

281
00:27:55,100 --> 00:27:57,120
Let's use this.

282
00:28:01,270 --> 00:28:04,050
With a-algo.

283
00:28:04,050 --> 00:28:04,730
Perfect.

284
00:28:04,730 --> 00:28:08,450
This should give us a nice looking safe, secure key.

285
00:28:08,730 --> 00:28:11,350
Next is generating IV.

286
00:28:11,350 --> 00:28:16,410
For that, let's first decide the size of the IV we plan to generate.

287
00:28:19,910 --> 00:28:23,410
Well, a good IV is anything above 128.

288
00:28:23,410 --> 00:28:26,890
I'll go for 256 because, hey, why not?

289
00:28:26,890 --> 00:28:29,630
It's defined in bytes, so 32.

290
00:28:30,550 --> 00:28:37,490
First, I'll initialize an array which will hold this IV for me.

291
00:28:38,710 --> 00:28:41,430
Of the IV size.

292
00:28:42,070 --> 00:28:47,390
Secondly, the more important one is actually generating it correctly.

293
00:28:48,450 --> 00:28:56,390
We decided to use drbg which provides us with 128 bits of security strength.

294
00:28:58,350 --> 00:29:01,110
Default is based out of hash.

295
00:29:02,050 --> 00:29:04,730
And just populate this guy.

296
00:29:05,010 --> 00:29:06,590
I want a secret key.

297
00:29:08,570 --> 00:29:09,850
SecureRandom.

298
00:29:11,370 --> 00:29:14,570
This should give us a good CSPR engine.

299
00:29:14,570 --> 00:29:17,010
And let's do some exceptional handling here.

300
00:29:20,960 --> 00:29:22,140
Perfect.

301
00:29:22,200 --> 00:29:25,300
The message we want to encrypt.

302
00:29:32,500 --> 00:29:34,600
Associated data.

303
00:29:36,560 --> 00:29:40,500
We can specify the IP address.

304
00:29:43,880 --> 00:29:45,760
And pass that around.

305
00:29:45,760 --> 00:29:50,110
A more common thing to do is actually do something like this.

306
00:29:50,740 --> 00:29:53,940
But in the interest of time.

307
00:29:55,540 --> 00:30:00,100
Finally, let's get to the most interesting part, which is how to write an encryption scheme.

308
00:30:10,240 --> 00:30:17,100
We'll return a ciphertext from the encryption function.

309
00:30:17,180 --> 00:30:20,940
Think about the block diagram.

310
00:30:20,940 --> 00:30:24,600
We'll take the plain text message.

311
00:30:24,600 --> 00:30:27,520
The associated data.

312
00:30:27,520 --> 00:30:29,800
The secret key.

313
00:30:30,800 --> 00:30:33,900
And the IV.

314
00:30:34,660 --> 00:30:40,300
Similarly, decryption will return a plain text byte array.

315
00:30:41,440 --> 00:30:48,180
It will take the ciphertext in byte array.

316
00:30:49,720 --> 00:30:57,100
If you again need the associated data, the secret key and the IV.

317
00:31:01,770 --> 00:31:08,370
The first steps for doing any encryption or decryption is initializing the cipher object as we saw.

318
00:31:08,510 --> 00:31:12,310
And which is common for both encryption as well as decryption.

319
00:31:12,310 --> 00:31:15,070
Let's do some code reuse here.

320
00:31:15,070 --> 00:31:22,650
And create a private method which will return an initialized cipher object.

321
00:31:24,770 --> 00:31:28,190
For both our encryption as well as decryption.

322
00:31:28,190 --> 00:31:32,910
For that, we'll first need the mode which is either encryption or decryption.

323
00:31:32,910 --> 00:31:41,990
It will take the associated data, the secret key as well as the byte array for your GCM.

324
00:31:42,490 --> 00:31:47,510
First, we will define the transformation which we saw.

325
00:31:50,420 --> 00:31:57,140
AES with GCM and no padding.

326
00:31:57,140 --> 00:31:57,900
Perfect.

327
00:31:59,020 --> 00:32:04,600
Next, we need to further define how the GCM mode is going to work.

328
00:32:04,600 --> 00:32:10,880
And for that, we need to go into the details of configuring the algorithm.

329
00:32:11,540 --> 00:32:14,020
And you have to trust me here.

330
00:32:15,400 --> 00:32:22,620
I am defining the output size of the authentication bit we expect and the IV it needs.

331
00:32:23,980 --> 00:32:31,360
Finally, we are just going to initialize the cipher algorithm with the mode.

332
00:32:32,520 --> 00:32:36,400
Sorry, this is the mode which is going to be passed here.

333
00:32:37,340 --> 00:32:40,640
Then, the next is the secret key.

334
00:32:41,040 --> 00:32:43,980
The algorithm spec we defined.

335
00:32:44,140 --> 00:32:50,020
And finally, some amount of randomness for the underneath algorithm to work.

336
00:32:50,020 --> 00: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.

337
00:33:10,780 --> 00:33:15,560
Finally, just adding the associated data to it.

338
00:33:15,560 --> 00:33:25,920
And this should give us a nice configured cipher algorithm for use in both encryption as well as decryption.

339
00:33:26,580 --> 00:33:29,940
After some exceptional handling, obviously.

340
00:33:36,380 --> 00:33:37,280
Super.

341
00:33:37,280 --> 00:33:40,000
Let's go back to our encryption scheme.

342
00:33:41,000 --> 00:33:47,240
This passing on the mode which is the encryption mode here.

343
00:33:47,800 --> 00:33:53,040
The associated data, secret key and IV.

344
00:33:54,340 --> 00:33:56,420
Sorry, this is in caps.

345
00:33:57,900 --> 00:34:00,220
Next is we are going to...

346
00:34:02,760 --> 00:34:08,540
We are going to make the cipher object ready to start encrypting our message.

347
00:34:08,540 --> 00:34:14,800
For that, we are just going to take the message and convert it into bytes.

348
00:34:15,740 --> 00:34:23,540
But we are going to store this in a byte array to be returned properly to the driver class.

349
00:34:23,540 --> 00:34:24,540
And for that...

350
00:34:30,440 --> 00:34:32,760
And return this.

351
00:34:38,380 --> 00:34:41,260
This should do the encryption for us.

352
00:34:41,260 --> 00:34:48,460
And similarly, in the decryption side, we are going to set it in the decrypt mode.

353
00:34:48,460 --> 00:34:54,420
Pass on the associated data, the secret key and the initialization vector.

354
00:34:54,420 --> 00:35:02,460
Get back a nicely initialized ciphertext just which is used in... exactly as it would be used in the encryption mode.

355
00:35:02,460 --> 00:35:12,260
And prepare yourself for getting the plain text in a byte array to be returned back to the driver program.

356
00:35:16,670 --> 00:35:19,070
Ciphertext array to be...

357
00:35:19,610 --> 00:35:25,270
Let's store it in the plain text because there would be some exception handling.

358
00:35:28,610 --> 00:35:33,330
Okay, this should do the decryption for us.

359
00:35:33,330 --> 00:35:37,110
Let's put all these things together in the driver class.

360
00:35:37,350 --> 00:35:43,710
Let's prepare it to hold the ciphertext array from the authentication code.

361
00:35:43,710 --> 00:35:46,690
Before that, we have to use this class.

362
00:36:03,120 --> 00:36:06,220
First, let's encrypt the message.

363
00:36:06,240 --> 00:36:12,660
Pass on the associated data, the secret key and the IV.

364
00:36:13,640 --> 00:36:16,280
And get back plain.

365
00:36:18,920 --> 00:36:20,320
Plain text

366
00:36:23,420 --> 00:36:30,980
array, passing the ciphertext, associated data, secret key and the IV.

367
00:36:31,680 --> 00:36:34,920
And let's hope everything works.

368
00:36:35,260 --> 00:36:39,060
To preprint the byte array of plain text.

369
00:36:43,120 --> 00:36:48,100
And we got back the decrypted version of the message we encrypted.

370
00:36:48,100 --> 00:36:49,520
Super!

371
00:36:50,260 --> 00:36:59,280
Okay, after going through this frantic coding session, let's take a look at a little more simpler crypto primitive.

372
00:36:59,500 --> 00:37:02,720
It does not involve any keys, which is great news.

373
00:37:02,720 --> 00:37:08,460
This is called as hash functions or message digests or even checksums.

374
00:37:08,460 --> 00: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.

375
00:37:20,760 --> 00:37:22,100
Where is it used?

376
00:37:22,100 --> 00: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.

377
00:37:33,520 --> 00:37:37,460
It's also used in digital signatures for similar services.

378
00:37:37,460 --> 00: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.

379
00:37:49,880 --> 00:37:53,720
What kind of properties do we expect out of it?

380
00:37:53,920 --> 00:37:55,780
Well, it should be collision resistant.

381
00:37:55,780 --> 00:38:01,240
We should never be able to get hold of two different messages, which results in the same hash.

382
00:38:01,240 --> 00: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.

383
00:38:14,460 --> 00: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.

384
00:38:25,100 --> 00:38:28,580
And what kind of a security strength do we expect?

385
00:38:28,580 --> 00:38:35,340
Well, security strength of 112 is going to be soon considered unsafe.

386
00:38:35,340 --> 00:38:38,020
Soon meaning after a decade though.

387
00:38:38,100 --> 00:38:44,020
So, which is not a lot of time in a cryptographic perspective.

388
00:38:44,540 --> 00: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.

389
00:38:54,060 --> 00: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.

390
00:39:04,680 --> 00:39:09,180
So , yeah, you have to be a little careful in which thing to use.

391
00:39:09,180 --> 00:39:11,940
But I have a simple pseudocode for that.

392
00:39:11,940 --> 00: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.

393
00:39:23,440 --> 00:39:29,160
SHA-224 is okay for MAC as well as digital signatures right now.

394
00:39:29,520 --> 00: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.

395
00:39:36,720 --> 00:39:42,860
And please don't use message digest anymore, MD family of algorithms for any of the applications.

396
00:39:42,860 --> 00:39:48,000
SHA-1 is still okay for HMAC but why bother.

397
00:39:48,180 --> 00:39:56,420
So, what I would do is I would just blindly use any SHA-256 or 384 kind of algorithms.

398
00:39:56,420 --> 00:40:08,800
Okay, next let's see the first symmetric key-based application called message authentication code.

399
00:40:08,840 --> 00:40:17,530
For any crypto systems which needs integrity or authenticity, this is one of the most famously used scheme.

400
00:40:17,530 --> 00: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.

401
00:40:30,390 --> 00:40:31,950
How it works?

402
00:40:31,950 --> 00:40:33,770
There is a sender and a receiver.

403
00:40:33,770 --> 00:40:34,830
There is a message.

404
00:40:34,830 --> 00:40:40,790
There is a symmetric key involved which your sender and receiver both has a copy of.

405
00:40:40,790 --> 00: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.

406
00:40:52,290 --> 00: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.

407
00:41:01,590 --> 00:41:03,850
Pretty simple, straightforward.

408
00:41:04,210 --> 00:41:07,250
Let's see what to do and what not to do.

409
00:41:08,550 --> 00:41:13,090
There are a few different kinds of MAC algorithms.

410
00:41:13,090 --> 00:41:16,830
Some are based on hash, some are based on block ciphers.

411
00:41:17,650 --> 00:41:20,430
Avoid all the block cipher ones.

412
00:41:20,530 --> 00: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.

413
00:41:29,230 --> 00:41:30,350
It's just complicated.

414
00:41:30,350 --> 00:41:31,250
Avoid using that.

415
00:41:31,250 --> 00:41:34,650
Use a hash-based MAC called HMAX.

416
00:41:34,650 --> 00: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.

417
00:41:45,510 --> 00:41:52,850
And the reason being, based on this and the underlying hash, the security strength of your MAC is decided.

418
00:41:52,850 --> 00: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.

419
00:41:58,050 --> 00:42:01,010
And finally, protect your symmetric key on both the sides.

420
00:42:01,010 --> 00:42:05,430
This goes without saying but I still have seen a lot of things failing because of that.

421
00:42:07,010 --> 00:42:10,770
Let's see how both of this actually works in action.

422
00:42:12,950 --> 00:42:19,230
For that, let's go back in the development environment to see how to use this.

423
00:42:19,230 --> 00:42:20,930
Well, guess what?

424
00:42:20,930 --> 00:42:21,510
Surprise!

425
00:42:21,510 --> 00: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.

426
00:42:29,730 --> 00:42:34,930
I'll just point you to the options available and which ones to pick.

427
00:42:35,010 --> 00:42:42,030
Let's first look at the way of generating message digest which is happening through this particular class.

428
00:42:42,030 --> 00:42:44,310
Look at the amount of options they provide.

429
00:42:44,310 --> 00:42:47,530
They provide still the MD family of algorithms.

430
00:42:47,530 --> 00:42:50,830
They also obviously provide SHA-1 and SHA-254.

431
00:42:50,830 --> 00:42:54,550
It's not out of scope or out of use yet.

432
00:42:55,170 --> 00:42:58,890
And it has the good ones, the SHA-2 and the SHA-3 family.

433
00:42:58,890 --> 00:43:03,410
Choosing one of these should keep you in safe areas.

434
00:43:04,430 --> 00:43:11,170
Similarly, for generating message authentication code, luckily we don't have to write the whole scheme from scratch.

435
00:43:11,170 --> 00:43:13,790
We have a corresponding API provided.

436
00:43:15,850 --> 00:43:19,770
Java does not at least provide block ciphers which is a good news.

437
00:43:19,770 --> 00:43:25,610
It provides a lot of algorithms based for HMAC.

438
00:43:26,230 --> 00: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.

439
00:43:38,450 --> 00: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.

440
00:43:50,750 --> 00:43:53,570
It's good to know if you need to use that.

441
00:43:54,150 --> 00:44:02,810
The coding is as straightforward as the cipher object where you just initialize it with the right algorithm.

442
00:44:02,810 --> 00: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.

443
00:44:13,110 --> 00:44:14,870
That's pretty standard.

444
00:44:15,410 --> 00:44:19,070
In the interest of time, I'm not going to code that up for you.

445
00:44:21,150 --> 00: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.

446
00:44:39,370 --> 00: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.

447
00:44:50,270 --> 00:44:55,030
Well, it's a well-known fact, don't ever store your data in plain text.

448
00:44:55,030 --> 00:45:00,590
It's also a big no-no to store it in a hash or just a simple salted hash.

449
00:45:00,710 --> 00:45:12,090
Modern GPUs and A6 hardware are very good at just parallelizing it and just cracking all this information.

450
00:45:12,090 --> 00:45:15,430
So, terrible idea in this day and time.

451
00:45:15,430 --> 00: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.

452
00:45:26,410 --> 00:45:31,530
There are a few different kinds of key derivation functions.

453
00:45:31,990 --> 00:45:36,250
Again, at the core of it, it will take a password, a salt, and then a hash.

454
00:45:37,080 --> 00: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.

455
00:45:49,210 --> 00:45:55,350
What kind of work factors are available depends heavily on the algorithm used.

456
00:45:55,350 --> 00: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.

457
00:46:12,890 --> 00: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.

458
00:46:22,190 --> 00:46:31,330
I have another talk later in the day today, which talks extensively about all these kinds of functions.

459
00:46:31,330 --> 00:46:36,050
I'll highly encourage if you are interested in this to log in to watch that.

460
00:46:37,770 --> 00:46:44,370
Let's move on to talking about public key cryptography or asymmetric encryption.

461
00:46:45,230 --> 00: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.

462
00:46:56,370 --> 00: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.

463
00:47:06,930 --> 00:47:18,650
Traditionally, these keys were computed based on prime numbers, which over time has proven not to be the best option.

464
00:47:18,650 --> 00:47:27,610
The algebra involved or the exponents needed to choose this prime number was getting increasingly fragile.

465
00:47:27,610 --> 00:47:33,950
These schemes are constant reasons of padding oracle attacks.

466
00:47:33,950 --> 00:47:40,610
And most importantly, we have a more promising option available in terms of elliptic curves.

467
00:47:40,610 --> 00:47:45,410
So I would highly encourage us to embrace this.

468
00:47:45,410 --> 00:47:47,570
They are much more compact.

469
00:47:47,570 --> 00: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.

470
00:48:00,330 --> 00:48:04,830
So briefly, let's talk about how this elliptic curves work.

471
00:48:04,830 --> 00:48:11,290
There is this algebraic equation defined, which basically defines a particular curve.

472
00:48:11,290 --> 00: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.

473
00:48:22,710 --> 00:48:34,810
And this expression contains, this algebraic expression contains all these kinds of coefficients, which is important in defining the curve.

474
00:48:35,550 --> 00:48:42,290
Everything except the private key, which is the number of points chosen on the curve is a public information.

475
00:48:42,890 --> 00:48:52,010
And again, given the public key, we cannot get hold of the private key.

476
00:48:54,250 --> 00:48:58,250
Elliptic curves is not such a modern or a newer thing.

477
00:48:58,250 --> 00:49:01,630
It is in existence since 1985.

478
00:49:01,630 --> 00:49:07,810
And over time, there have been lots of curves which have came into picture or being proposed.

479
00:49:07,810 --> 00:49:09,930
Not all of them are secure.

480
00:49:10,750 --> 00:49:13,510
I won't get distracted with any of those.

481
00:49:13,510 --> 00:49:23,790
What I use is Edward curves with specifically these two ones are specified on the slide 255.19 and 448.

482
00:49:24,430 --> 00:49:27,330
NIST has also approved a lot of curves.

483
00:49:27,330 --> 00:49:36,090
Not all of them provide security, which is 112 bits.

484
00:49:36,090 --> 00:49:42,170
So while picking NIST curves, be careful about the security provided out of the box.

485
00:49:42,310 --> 00:49:47,610
And it's NIST, there is always this conspiracy theory going on that there are backdoors.

486
00:49:47,610 --> 00:49:50,630
So my preference, stay away from it.

487
00:49:50,630 --> 00:49:54,610
But if you have to use it, there is nothing yet wrong about it.

488
00:49:55,090 --> 00:49:57,730
And as I said, stay away from everything else.

489
00:49:58,270 --> 00: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.

490
00:50:06,570 --> 00:50:11,010
You don't have to deal with choosing key sizes or any of that.

491
00:50:12,630 --> 00:50:20,250
For digital signatures, you have an Edward curve based scheme similarly for key exchange.

492
00:50:20,250 --> 00:50:25,070
And a symmetric encryption scheme is also available called ECIS.

493
00:50:25,070 --> 00:50:31,730
With its own drawback, it can't encrypt more than 256 GB of data.

494
00:50:31,730 --> 00:50:37,310
This scheme is not yet very famously used or commonly used, but it's there.

495
00:50:39,770 --> 00:50:48,270
Next, let's look at one of the most common public key based application called digital signatures.

496
00:50:48,410 --> 00: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.

497
00:51:05,430 --> 00:51:11,870
Similarly, we have a construct in digital world called digital signatures.

498
00:51:12,050 --> 00:51:14,110
How does that work?

499
00:51:14,110 --> 00:51:22,530
Again, there is a plain text message whose hash is computed, passed through a signature algorithm and the signature is computed.

500
00:51:22,530 --> 00:51:30,350
This signature along with the plain text message is passed to the receiving side where the same operation is performed again.

501
00:51:30,350 --> 00:51:32,230
The output hashes are compared.

502
00:51:32,230 --> 00:51:36,750
If they are same, then the services are achieved out of the box.

503
00:51:36,770 --> 00:51:43,450
Something very similar to Mac, except for there is a private key involved on the sender side or for signing.

504
00:51:43,510 --> 00:51:47,350
And for verification, there is a public key of the signer involved.

505
00:51:47,350 --> 00:51:51,590
So that's how simply the digital signatures work.

506
00:51:52,510 --> 00:51:56,050
Let's look at some of the do's and things to avoid.

507
00:51:56,050 --> 00:52:05,970
Digital signatures over time have been very famously used by RSA algorithms or the Al-Gamal key-based DSA algorithms.

508
00:52:06,290 --> 00:52:08,410
If you have a choice, just avoid that.

509
00:52:08,410 --> 00:52:14,830
In fact, DSA is already going to be deprecated in the next DSS standard coming out of the government body.

510
00:52:14,830 --> 00:52:17,910
RSA is fragile as we spoke earlier.

511
00:52:18,710 --> 00:52:21,630
ECDSA is another common thing used.

512
00:52:21,670 --> 00:52:25,810
It has its own issues of how well the nonces are generated.

513
00:52:25,910 --> 00:52:29,210
There was a talk talking in detail about this earlier today.

514
00:52:29,210 --> 00:52:33,370
Hopefully, you got a chance to look at that.

515
00:52:34,070 --> 00:52:37,010
As we spoke earlier, use Edward curves.

516
00:52:37,010 --> 00:52:43,670
Underlying hashes use SHA-2 or SHA-3 family providing at least 112 bits of security.

517
00:52:43,670 --> 00:52:49,810
Avoid MD families and SHA-2 and even SHA-24 algorithms.

518
00:52:51,290 --> 00:52:53,730
Let's see how this actually works.

519
00:52:53,730 --> 00:52:58,710
For that, let's go to the development environment again.

520
00:53:00,430 --> 00:53:02,910
Back to our CryptoDriver class.

521
00:53:02,910 --> 00:53:07,510
Let's see how we can implement digital signatures using Java.

522
00:53:07,510 --> 00:53:12,470
What all do we need from planning and designing?

523
00:53:12,470 --> 00:53:16,090
We need ECC based key pairs.

524
00:53:16,830 --> 00:53:22,250
We need signer side of the code and the verifier side of the code.

525
00:53:22,270 --> 00:53:26,530
Now, I have a little bit of a bad news for you.

526
00:53:26,530 --> 00: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.

527
00:53:35,990 --> 00:53:40,710
Edward key based key exchange algorithms are available but not for signatures.

528
00:53:41,170 --> 00:53:45,710
But worry not, we have a pretty good shortcut for this.

529
00:53:45,710 --> 00: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.

530
00:53:57,130 --> 00:53:59,850
So, let's go ahead and use that.

531
00:53:59,850 --> 00:54:05,910
And for that, let's first go ahead and create an ECC keys generator class.

532
00:54:07,010 --> 00:54:12,890
Again, just like secret keys, this class is a holder for the public and the private keys.

533
00:54:16,070 --> 00: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.

534
00:54:27,130 --> 00:54:31,370
And after that, it's pretty much business as usual actually.

535
00:54:31,670 --> 00:54:36,250
Let's make sure we use the required algorithm.

536
00:54:37,210 --> 00:54:41,190
And this is going to be provided by this Bouncy Castle provider.

537
00:54:41,470 --> 00:54:50,410
And we just have to generate key pairs at this point after obviously adding the much needed exception handling here.

538
00:54:50,810 --> 00:54:54,130
Let's go back to our driver class and start using this.

539
00:55:12,030 --> 00:55:13,830
Key pairs...

540
00:55:16,820 --> 00:55:24,050
And let's see the signer and the verifier side of the code.

541
00:55:24,880 --> 00:55:28,880
It's just creating a simple message for us to sign.

542
00:55:35,080 --> 00:55:44,880
Let's go ahead and create a different package to help us with this signer and verifier APIs for digital signatures.

543
00:55:44,980 --> 00:55:50,660
We are going to return the actual sign for the message.

544
00:55:50,660 --> 00:55:55,520
We need private key and that's it actually.

545
00:55:55,520 --> 00: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.

546
00:56:12,040 --> 00:56:14,810
And actually pass the signature.

547
00:56:20,820 --> 00:56:23,520
Okay, let's go ahead and coding up.

548
00:56:23,520 --> 00:56:27,000
Again we are going to use the signature API class.

549
00:56:30,980 --> 00:56:35,860
Making sure we are using the right algorithm we plan to use.

550
00:56:36,120 --> 00:56:43,280
Next going ahead and preparing this class for actually signing messages with the private key.

551
00:56:44,200 --> 00: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.

552
00:56:55,560 --> 00:57:02,020
And this is just going to hold a final signature for us.

553
00:57:03,180 --> 00:57:05,460
Actually sign it.

554
00:57:05,460 --> 00:57:07,720
This is what we are going to return.

555
00:57:08,880 --> 00:57:12,520
Let's add some exception handling here.

556
00:57:18,580 --> 00:57:22,740
Similarly on the verifier side.

557
00:57:25,300 --> 00:57:30,860
We are again going to use the same AdWords course.

558
00:57:31,120 --> 00:57:37,860
This time we are going to prepare it for verifying with the public key.

559
00:57:38,640 --> 00:57:43,520
Preparing it with the message to be verified.

560
00:57:45,000 --> 00:57:48,920
And finally actually verifying the message.

561
00:58:00,710 --> 00:58:06,730
Signature.VerifyWithSignProvided And let's return this guy.

562
00:58:16,750 --> 00:58:19,750
Cool, this is the signer and the verifier side.

563
00:58:19,750 --> 00:58:23,690
So let's go back to the driver class and actually use this.

564
00:58:37,290 --> 00:58:42,540
Let's collect the signature in this particular array.

565
00:58:43,650 --> 00:58:48,690
The message and the private key.

566
00:58:48,950 --> 00:58:51,750
And let's see if we could verify this.

567
00:59:03,180 --> 00:59:06,980
This time we are going to give it a public key.

568
00:59:07,040 --> 00:59:09,600
And the actual signature.

569
00:59:10,180 --> 00:59:12,600
And let's see if all this works.

570
00:59:18,810 --> 00:59:19,980
Cool.

571
00:59:20,590 --> 00:59:26,230
So just to show how easy it is to use elliptic curves.

572
00:59:26,230 --> 00:59:27,670
Don't be discouraged.

573
00:59:27,670 --> 00:59:28,710
Embrace that.

574
00:59:28,710 --> 00:59:29,980
It's really simple.

575
00:59:30,490 --> 00:59:32,930
And let's go back to our slides.

576
00:59:32,930 --> 00: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.

577
00:59:43,970 --> 00:59:51,150
Before I conclude, I want to point out that key management is a huge issue.

578
00:59:51,550 --> 00:59:59,370
If you would have noticed across all the things we spoke about, we always needed some kind of a key material.

579
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.

580
01:00:11,770 --> 01:00:20,210
And unfortunately, all these aspects of actually managing your key material is usually homegrown.

581
01:00:20,570 --> 01:00:27,090
Which is one of the biggest reasons why any crypto systems fail.

582
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.

583
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.

584
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.

585
01:00:57,310 --> 01:00:59,090
Just be conscious about that.

586
01:00:59,090 --> 01:01:00,030
Don't ignore this.

587
01:01:00,030 --> 01:01:01,190
It's huge.

588
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.

589
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.

590
01:01:32,650 --> 01:01:38,730
And that was what I hope you have shared enough in this one hour.

591
01:01:39,810 --> 01:01:43,810
Finally, I would like to conclude by giving my contact information.

592
01:01:43,810 --> 01:01:46,330
My DMs are always open.

593
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.

594
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.

595
01:02:07,590 --> 01:02:10,630
So feel free to poke around.

596
01:02:11,010 --> 01:02:11,970
Thank you.