Why do you need a lot of randomness for effective encryption?

Question

I saw that in many places he mentioned that randomness is important for generating keys for symmetric and asymmetric cryptography and when using keys to encrypt messages.

Can someone explain how security can be compromised if there is not enough chance?

Answer 1

Accident means unidentified input. If the input is valid, then the output can be easily calculated. This is bad.

For example, Debian had a long-standing error in the implementation of SSL, which could not collect enough randomness when creating the key. This led to the software creating one of the 32k possible keys. Thus, it is easy to decrypt everything that is encrypted with such a key, having tried all the 32k features, having tried them, which is very quickly given to the processor speed.

Answer 2

An important feature of most cryptographic operations is that they are easy to perform if you have the correct information (for example, a key) and cannot be completed if you do not have this information.

For example, symmetric cryptography: if you have a key, encryption and decryption is easy. If you don’t have a key (and don’t know anything about its design), you should proceed with something expensive, for example, an exhaustive search for a key space or a more efficient cryptanalysis of encryption, which, however, will require a large number of samples.

On the other hand, if you have any information about the probable key values, your exhaustive search in the key space is much simpler (or the number of samples required for cryptanalysis is much lower). For example, it is currently not possible to perform test decryption of 2 ^ 128 to find out what a 128-bit key is. If you know that the key material has come out of the value of the time that you know for a billion ticks, then your search just became 340282366920938463463374607431 times easier.

Answer 3

To decrypt a message, you need to know the correct key.

The more keys you have to try, the more difficult it is to decrypt the message.

Taking an extreme example, we say that there is no chance at all. When I create a key to encrypt my messages, I always get the same key. No matter where and when I run the program for working with keys, it always gives me the same key.

This means that anyone who has access to the program that I used to generate the key can trivially decrypt my messages. In the end, they just have to ask him to generate the key, and they will get one identical to the one I used.

So, we need some randomness to make it unpredictable which key you use. As David Schmitt mentions, Debian had a bug due to which it generated only a small number of unique keys, which means that to decrypt a message encrypted with the default OpenSSL implementation on Debian, I just need to try this fewer possible keys. I can ignore a huge number of other valid keys, because the Debian SSL implementation will never generate them.

On the other hand, if there was enough randomness in key generation, it was impossible to guess anything about the key. You should try all possible bit patterns. (and for a 128-bit key, which is a lot of combinations.)

Answer 4

This is due to some of the main reasons for cryptography:

• Make sure the message is not changed in the path (Continuous)
• Make sure the message is not read in the path (Secure)
• Make sure the message is written from the user (Authentic)
• Make sure the message does not match the message previously reported (No Replay)
• etc.

Here you need to add a few things to make sure this is true. One important thing is random value.

For example, if I encrypt “Too many secrets” with a key, it may exit with “dWua3hTOeVzO2d9w”

There are two problems: an attacker can easily break encryption, since I use a very limited set of characters. Also, if I send the same message again, it will look exactly the same. Finally, the attacker can record it and send the message again, and the recipient will not know that I did not send it, even if the attacker did not violate it.

If I add some kind of random garbage to the string every time I encrypt it, this not only complicates the hacking process, but the encrypted message is different every time.

Other features of cryptography in the above brands are fixed using other means than randomness (initial values, two-way authentication, etc.), but randomness takes care of several problems and helps in solving other problems.

A bad source of randomness again limits the character set, so it is easier to break, and if it is easy to guess or otherwise limit it, then the attacker has fewer ways to try and make a brute force attack.

-Adam

Answer 5

A common pattern in cryptography is the following (sending text from alice to bob):

Take plaintext p Generate random k Encrypt p with k using symmetric encryption, producing crypttext c Encrypt k with bob private key, using asymmetric encryption, producing x Send c+x to bob Bob reverses the processes, decrypting x using his private key to obtain k 

The reason for this pattern is that symmetric encryption is much faster than asymmetric encryption. Of course, it depends on a good random number generator to create k, otherwise the bad guys might just guess about it.

Answer 6

Here is an analogue of the "card game": suppose we play several rounds of the game with the same deck of cards. Shuffling a deck between rounds is a major source of randomness. If we hadn't shuffled correctly, you could have won the game by predicting cards.

When you use a bad source of randomness to generate an encryption key, you significantly reduce the entropy (or uncertainty) of the key value. This can compromise encryption, as it greatly facilitates brute force searches in key space.

Answer 7

Develop this problem from Project Euler, and it will truly bring home what “a lot of chance” does for you. When I saw this question, it was the first thing that appeared in my head.

Using the method he talks about it, you can easily see that “more chance” will pick you up.

Answer 8

A good article that says why not being careful with randomness can lead to uncertainty:

• http://www.cs.berkeley.edu/~daw/papers/ddj-netscape.html

This describes how, in 1995, the Netscape browser SSL protocol implementation was vulnerable to guessing SSL keys due to a problem consuming PRNG.