Cryptography isn’t very useful without randomization. In this video, you’ll learn about cryptographic nonces, initialization vectors, and salting.
One of the core elements of cryptography is that there is a sufficient amount of randomization that the resulting encrypted data looks nothing like the original plain text. If there was encrypted data that looked similar to the original plain text, then there may be a way for an attacker to reverse engineer and determine what the original text may have been. An example of cryptography without any type of randomization can be seen here. I have a picture of this little puppy. And I performed an encryption of this puppy.
And as you can see, the encrypted form of this looks almost exactly the same as the puppy I had originally, except in a reverse form. You can easily see the image that I started with because this type of cryptography did not add any type of randomization. This was an encryption done with 128-bit ECB, which is Electronic Code Book, which is a way to take blocks of data and encrypt it.
So I took a block of data, encrypted it with a password, and wrote that encrypted data into this image. The problem is that there’s no randomization to the key that I use. So each block of data looks very similar to the block of data that was there previously, because most of this is either a color white or a color black. And then we’re left with this very non-random result when we see the final encrypted form of this image.
To be able to add randomization to this cryptographic process, we need to add a nonce. A nonce is an arbitrary number that you would use one time. It comes from the term “for the nonce,” which means for the time being. This nonce would be a random value or something that would be randomized enough so that an attacker would not be able to guess it or easily replicate it. This could even be a counter, as long as both sides are able to keep track on what the counter’s values might be.
We often use a cryptographic nonce during a login process. This might start with a server that would send us this random nonce. And we would then use our password hash and combine it with this nonce and send all of that information back to the server. The server would then evaluate the password hash and nonce with what it thought the password hash and nonce should be to be able to authenticate you to that system.
The benefit of this is that the server is going to send you a different nonce each time you log in. So every time you send that hash back to the server, it will be different every time. This means that if someone was to capture that password hash being sent from the client to the server, they would not be able to use this in a replay attack because that password hash will be different every single time you log in.
A type of nonce we commonly use in encryption is an Initialization Vector, or an IV. This is a way to add randomization to the encryption scheme that’s being used. If we’re able to add this initialization vector to an encryption key that we’re using, especially a key that we’re using over and over again, it will make the overall encryption method that much stronger. You may see an IV used in encryption methods such as the WEP encryption that we see here in this block diagram and in some implementations of SSL.
Not only would we use a nonce during the interactive login process, but we might also include a nonce for the password hashes that we’re storing permanently in our database. This type of password randomization is called a “salt.” And it’s a way to make sure that the passwords that we’re storing are randomized across all users on the system.
If we use a different salt for every user that has a password stored on our system, every user could be using exactly the same password. But the stored hash value would be very different between all of them. This means if somebody was to gain access to our password store, they would not be able to see that all of the users had similar passwords. They would see a random value for every single user account.