Why aren't large RSA keys encrypting to a unique value?

Question

I'm calculating two 2048-bit prime numbers using BigInteger's probablePrime method, as follows: BigInteger.probablePrime(2048, new Random());. Respectively, let's call those primes p and q. I'm calculating the private exponent, using the following code: BigInteger.TWO.multiply(r).add(BigInteger.ONE).divide(e); where e is equivalent to BigInteger.valueOf(3) and r is equivalent to a BigInteger whose value is: (p - 1)(q - 1).

Creating the encrypted BigInteger goes as follows: message.modPow(e, r), where message is a BigInteger.

Let's say that I wish to encrypt 774356626352684872522728355634287624183747537718011900969524254770659766752605764866132228010801740792162094. This large integer is "The quick brown fox jumped over the lazy dog." converted to binary, then converted to decimal. My result is 464326058229369014486528960945777245568243099145851675968955902027904135435059026247893552949145149936678174588724345105141605583511438062567406913039976998983678282605288609470234530610515268764924240227134432014767865301287496131771559993377618477929696113174968779730288058725125905006272019930686696412137679303439126584.

No matter how many times I run the above code, it always encrypts to the same exact value. It does not seem to matter which primes it generates- the encrypted value is always the above for that particular message value.

Now here's where it becomes particularly peculiar, if I generate 512-bit primes, the result is unique. Each time I run the above code, generating 512-bit primes instead of 2048 or even 1024-bit primes, it generates a unique result every time it's run. However, if I wish to generate 1024 or 2048-bit primes, the result is always the same, regardless of the primes that are generated.

Can anyone explain why this occurs, or what changes would need to be made for the code to generate unique encrypted integers using 2048-bit primes? Specifically, why does it work for 512 or lower-bit primes, but not 1024 or larger-bit primes? I apologize if this wasn't the most well constructed question, so please do not hesitate to ask for clarification if something is confusing.

Thanks.

EDIT: Here is code to produce the problem:

import java.io.IOException;
import java.math.BigInteger;
import java.security.SecureRandom;

public class Yeet {
    public static void main(String[] args) throws IOException {
        int t = (int) (System.currentTimeMillis() / 1000);

        byte[] date = new byte[]{
          (byte) (t >> 24),
          (byte) (t >> 16),
          (byte) (t >> 8),
          (byte) t,
        };  

        BigInteger p = BigInteger.probablePrime(2048, new SecureRandom(date));
        BigInteger q = BigInteger.probablePrime(2048, new SecureRandom(date));
        BigInteger e = BigInteger.valueOf(3);
        BigInteger r = p.subtract(BigInteger.ONE).multiply(q.subtract(BigInteger.ONE));

        BigInteger message = new BigInteger("774356626352684872522728355634287624183747537718011900969524254770659766752605764866132228010801740792162094");

        System.out.println(message.modPow(e, r));
    }
}

Run it as many times as you'd like. It always produces 464326058229369014486528960945777245568243099145851675968955902027904135435059026247893552949145149936678174588724345105141605583511438062567406913039976998983678282605288609470234530610515268764924240227134432014767865301287496131771559993377618477929696113174968779730288058725125905006272019930686696412137679303439126584. Now, if we swap 2048 for 512 on lines 16 & 17, each run produces a unique value...

Answer 1

You are performing raw / textbook RSA, where the encryption is just modular exponentiation with the public exponent. Well, that and some conversion or change or interpretation to / from integers, of course.

Now the public exponent in your case is very small: 3. So it is likely that a small input plaintext is smaller after exponentiation than the modulus. The quick brown fox jumped over the lazy dog. is 45 characters / bytes, or 360 bits. If you have a 360 bit number and you perform exponentiation with 3 then you get a value of 360 x 3 = 1080 bits, far below the 2 x 2048 = 4096 bit modulus, so no modular reduction will be performed. 2 x 512 = 1024, so with those size of primes your value is just "a few bits" larger than the modulus, so the modulus value matters.

Of course you could use the fifth prime of Fermat (F4) with value 65537 instead. That will result in modular reduction as 360 x 65537 > 4096. However, to be secure, you should use a padding method such as the ones specified in PKCS#1 v2.2. These will expand the plaintext value so the number representation that depends on the plaintext will be much closer to the modulus, in bits. The result of modular exponentiation will then actually perform at least a few modulus reductions, and is therefore dependent on the different modulus values.

Even more importantly, the PKCS#1 v1.5 or OAEP padding specified in PKCS#1 v2.2 is random itself, so encrypting the same plaintext will result in a different ciphertext even if the same key pair / modulus is used. For larger key sizes even exponent 3 is considered secure although F4 is still preferred by the majority of RSA implementations (OpenSSL, Java, C#/.NET etc. etc.).