4

I'm implementing RSA public-private key encryption and decryption and the input of these functions is encoded as hexadecimal. The library I use (react-native-rsa) however only accepts plain strings for encryption so I cannot convert the hexadecimal to a byte array first.

Encrypting the hexadecimal string works fine, but I'm wondering if it's somehow less secure than encrypting the source byte array? In other words, is it more secure to encrypt directly [10, 8] than encrypting its hexa representation which would be ['0', 'A', '0', '8']?

Or in general, does the encoding of the input string can have any impact on how secure the ciphertext is?

Improve this question
1
  • Right, I've fixed that now.
    – laurent
    Oct 10, 2021 at 9:44

2 Answers 2

Reset to default
17

It makes absolutely no difference to the cryptographic strength. If the contents of the plaintext affected the security of the cipher, then the cipher would be broken.

That said, it looks like the library you're using has functions that accept base64 string inputs along with the UTF-8 ones you've already seen. You should use these instead of hexadecimal. This is particularly important with RSA encryption operations because your message length is limited to the size of the RSA key, and if you encrypt a hex-string representation of your message then you're unnecessarily doubling the size of the plaintext.

Improve this answer
2
  • 5
    Using RSA directly to encrypt a message is highly error-prone, and will leak the key if you do it wrong (see: padding). I would advise OP not to do this, but instead use KEM and encrypt with a symmetric cipher using the key produced.
    – R.. GitHub STOP HELPING ICE
    Oct 3, 2021 at 13:42
  • 2
    @R..GitHubSTOPHELPINGICE I considered including a paragraph on why direct RSA encryption is problematic, but quickly realised that there were too many issues to cover and decided it was out of scope for the specific question. Needless to say, you're correct - direct RSA encryption of plaintext is incredibly fragile and fraught, and should only be considered for key encipherment in situations where key exchange/agreement cannot be delegated to a better algorithm (e.g. ECDH), for example where the involved parties are unable to communicate in realtime and an extra round trip is prohibitive.
    – Polynomial
    Oct 3, 2021 at 14:28
4

Against a symmetric cipher, it would help a brute-force attack distinguish a valid key from invalid, if the attacker knew that the plaintext was restricted to 16 of the possible 256 characters. (It's computationally cheap to check a block of output for being composed only of ASCII '0'..'9' and 'A'..'F', although even being valid Base64 or valid UTF-8 would rule out most wrong keys)

But we normally already assume that a brute-force attack can instantly recognize the correct plaintext if they stumble upon the right key, so if this was a problem you've probably already lost. (That's why we use ciphers with keys longer than 64-bit.) It doesn't help the attack in any other way; if it did that would be a serious flaw in the cryptosystem.

Against RSA and other public-key systems like you're asking about in this specific question, the attack mechanism doesn't involve trial decryption anyway. So in that case it doesn't help the attacker at all; they can tell from math on the key if they've found the private key.

Using an actual message directly instead of RSA encrypting a random AES key is unusual, BTW, and apparently easy to get wrong; see comments on Polynomial's answer.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.