0

I have some public/private encryption code written. It works fine when the data to be encrypted is short, example: "this is plain text".

private static final String ALGORITHM = "RSA";

public static byte[] encryptWithPrivateKey(byte[] privateKey, byte[] inputData) throws Exception {

    PrivateKey key = KeyFactory.getInstance(ALGORITHM).generatePrivate(new PKCS8EncodedKeySpec(privateKey));

    Cipher cipher = Cipher.getInstance(ALGORITHM);
    cipher.init(Cipher.ENCRYPT_MODE, key);

    byte[] encryptedBytes = cipher.doFinal(inputData);

    return encryptedBytes;
}

But when I try to encrypt a much longer string, I get an error ...

javax.crypto.IllegalBlockSizeException: Data must not be longer than 245 bytes

... according to this StackOverflow answer here ... the solution is to use algorithm "RSA/ECB/PKCS1Padding" instead of "RSA". [UPDATE: This conclusion was incorrect.]

When I changed ALGORITHM = "RSA"; to ALGORITHM = "RSA/ECB/PKCS1Padding";, I get this error ...

"java.security.NoSuchAlgorithmException: RSA/ECB/PKCS1Padding"

How do I fix this "NoSuchAlgorithm" error?

Just FYI, I'm using Spring Tool Suite 4 (4.6.0) and Java 1.8.0_241 that either came with it or was installed by Mac software updates.

AndySummers2020
  • 411
  • 1
  • 6
  • 14
  • 1
    I don't know how you can read that answer as saying to use "RSA/ECB/PKCS1Padding" instead of "RSA". It doesn't say that at all, but it does tell you what the problem is. Also, the algorithm name for the KeyFactory and Cipher getInstance methods are related but not identical. `Cipher.getInstance()` requires a *transformation* string containing 3 parts in order: the algorithm name, the mode, and the padding scheme. `KeyFactory.getInstance()` requires just a string specifying the key, so in this case just `KeyFactory.getInstance("RSA")` – President James K. Polk Jun 29 '20 at 02:00
  • 1
    I can see there is support for RSA/ECB/PKCS1Padding in Cipher – Sabareesh Muralidharan Jun 29 '20 at 02:04
  • @PresidentJamesK.Polk Yes, re-reading it I was clearly confused. Had about 3 hours sleep in the past 24 hours so I think it's time to hit the hay and start fresh again tomorrow. In the meantime, is there another approach I should consider to public/private key encryption other than using this RSA algorithm that won't cause me to suffer from this data-length/key-length/padding issue? I will try those code examples in that another question tomorrow but it seems like a lot of extra steps to go through to make it work. Let me know if you have any other ideas! – AndySummers2020 Jun 29 '20 at 02:44
  • @PresidentJamesK.Polk Morning, fresh brain I think I understand now ... the RSA pub/pvt key is only for encrypting small data (like keys). It is not intended to encrypt large data files. So the solution (from the other question) is to use AES symmetric encryption to encrypt the big file. And use RSA private key to encrypt the AES key. The holder of the RSA private key delivers the encrypted file and the encrypted key. The holder of the public key can decrypt the AES encryption key (using the RSA public key), and can decrypt the big file using AES symmetric key. Is all of that correct? – AndySummers2020 Jun 29 '20 at 15:44
  • No, but it's close. The **recipient** of the encrypted file holds her private key, and you must obtain her public key through a trusted process and use that public key to encrypt a randomly generated AES key. Use that AES key to encrypt your data and send both the AES-encrypted data and the RSA-encrypted AES key to the recipient. – President James K. Polk Jun 29 '20 at 15:53
  • @PresidentJamesK.Polk Ok ... got it. That's safe delivery of a file to an individual with their own private key. My situation, I'm giving a software app to a customer. I have pvt key, the app has pub key. My plan was to encrypt a license file with the pvt key, deliver the encrypted lic file to the customer. The software decrypts lic file with pub key and runs. This does (A) the software knows the lic file actually came from me; (B) adds an admittedly weak layer of obscurity to prevent honest corporations from easily hacking the license file. [... cont ...] – AndySummers2020 Jun 29 '20 at 16:42
  • @PresidentJamesK.Polk [... cont ...] I believe you said I can accomplish the same thing by digitally signing the lic file instead of encrypting it. Perhaps that is better (but for education purposes, I'd still like to get the encryption part working before moving to digital signing). – AndySummers2020 Jun 29 '20 at 16:43

0 Answers0