Injecting Entropy in Your Code — Make sure that you understand it

Entropy is the measure of uncertainty associated with a random variable. In terms of Cryptography, entropy must be supplied by the cipher for injection into the plain text of a message so as to neutralize the amount of structure that is present in the unsecured plain text message. Entropy is at the heart of the security of a modern operating system: cryptographic keys, TLS nonces, ASLR offsets, password salts, TCP sequence numbers, and DNS source port numbers all rely on a source of hard-to-predict random bits.

We, as programmers, mostly introduce randomness or entropy in our code using the native functions provided by different programming languages. But do we know if the implementations of those functions are secure or not? Are we even aware that some of the native functions which provide randomness should not be used in first place.

Moreover, once you use insecure random number generators in your code, you are actually making applications vulnerable to trivial attacks.

Understanding Insecure Randomness

Let’s try to understand insecure randomness introduced by different programming languages.

According to OWASP, Insecure Randomness occurs when a function that can produce predictable values is used as a source of randomness in security-sensitive context. Let’s try to peep inside using some programming language context like Java.

Java programmers use java.util.Random class a lot to introduce randomness in their code. Using java.util.Random class makes your code more vulnerable because the underlying algorithm uses a less secure 48 bit seed ( a seed can be considered as a starting point or the initial value).

A typical example of using this random function is something like this:

import java.util.Random; 
  
public class generateRandom 
{ 
    public static void main(String args[]) 
    { 
        // create instance of Random class 
        Random rand = new Random(); 
  
        // Generate random integers in range 0 to 9999 
        int rand_int1 = rand.nextInt(10000); 
        int rand_int2 = rand.nextInt(10000); 
  
        // Print random integers 
        System.out.println("Random Integers: " + rand_int1); 
        System.out.println("Random Integers: " + rand_int2); 
    } 
}

If you check the underlying implementation of nextint() function of java.util.Random class, you will see something like this:

Image Source

In above case, hacker would require only 2⁴⁸ attempts to break it and know the randomness formula. With today’s advanced in CPUs and GPUs, it is possible to break it in predictable time.

It would be better to use java.security.SecureRandom class which provides a cryptographic based strong random number generator. SecureRandom class have up to 128 bits as compared to 48 bits of java.util.Random class. Therefore, it would require 2¹²⁸ attempts which will take years and years to break even with today’s advanced machines..

Moreover, Random class uses the system clock to generate the seed. This can be reproduced easily if the attacker knows the time at which the seed was generated. But SecureRandom takes Random Data from your OS (they can be interval between keystrokes etc — most OS collect these data and store them in files — /dev/random and /dev/urandom in case of linux) and use that as the seed.

Hence it’s always better to check if the code used for introducing randomness provide good enough security for your code and make it difficult to crack or not. It’s always worthwhile to spend time in knowing the secure functions/APIs in your language.

Following is a suggestive comparison of which function or modules should or shouldn’t be used for generating randomness in different programming languages:

Table: Do and Don’t for generating randomness

Effect of Hash Function on Entropy

Secure randomness is very important, but to really secure the underlying implementation, you need a lot of it. It is more important to know the correlation between underlying data and hash function used and its impact on entropy.

Suppose you have 32 bytes and you encode them either with hex or Base32 or Base64 into a 56-byte string. The result still contains 32 bytes of entropy, not 56.

Figure: Effect of Hash Function on Entropy

This means that regardless of how you encode the initial entropy, the result will never contain more of it. Therefore, you can’t get 256 bits of entropy from 128 bits, even if you hash them with SHA-512. The output will be 512 bits, but it will still contain 128 bits of entropy.

Conclusion

If you are a programmer and going to introduce randomness in your code, please be serious about it. Always remember to check the underlying implementations regardless of what the programming language claims. You cannot just sprinkle some crypto code to make it more secure and look cool in front of your boss. This can backfire in future if some hacker got it right with your weak crypto implementation.

My Bio

I am a hands on technical programmer and architect working on different consultancy assignment from Mobile Apps to AI applications. If you like this article and want to know more about me, please connect with me on LinkedIn.