0

I have a question about an RSA academic example. If we are using block-RSA with a block-size of 3 and we have this message: "android". It is broken into 'and', 'roi', 'd'.

How to encrypt the last character 'd'?

otus
  • 32,132
  • 5
  • 70
  • 165
Med Choaib Assoualma
  • 21
  • 4

2 Answers2

2

With such a small block size there is no way to employ RSA padding modes such as PKCS#1 v1.5 padding or OAEP. You could however see the encryption as ECB mode encryption. In that case you could apply padding mechanisms that have been constructed for symmetric block ciphers.

Those padding modes however have been defined for bytes rather than characters. That's no problem - let's just assume ASCII text so we can convert the text to bytes without issue. Within many programming environments you may not even have to perform the conversion explicitly (e.g. C has char*).

OK, so after the conversion you have multiple options (values are in hexadecimals):

  • PKCS#5 padding: a padding where each added byte has the value of the size of the padding in bytes (i.e. 01, 0202 or 030303 in your case).
  • Bit-padding: just add a single 1 bit and then zero's up to the end (i.e. 80 8000 or 800000 in your case).
  • Zero-padding: just add zero bytes until the next boundary, i.e. $\varnothing$ (nothing), 00 or 0000. This one is probably used most for textbook RSA.

Zero padding is non-deterministic as it may strip off 00 valued bytes at the end of the plaintext after decryption. It has however the advantage that you don't have to pad when the plaintext is already correctly sized.

Furthermore, at least for ASCII (and UTF-8) you won't find any zero bytes in printable text. Zero byte value is often seen as end-of-string marker - especially in the C language. Don't forget that your string may need to end with a 00 in those kind of environments (so make your buffer one byte larger and set the rightmost byte to 00 before or after decryption).

If the zero's are not stripped off automatically by the runtime then you usually have right-trim function such as rtrim(plaintext, '\0') available to you.

After conversion you need to convert the 3 byte sequences into unsigned integer before you can feed them into your function that performs modular exponentiation with the public key. PKCS#1 defines a method on how to do that called OS2IP (and I2OSP to convert back).

Make sure that the resulting integer is always smaller than the modulus (ASCII is 7 bit, so a 24 bit modulus should be sufficient).

Maarten Bodewes
  • 92,551
  • 13
  • 161
  • 313
0

This is an issue with any block cipher. One solution is to pad the message. This means that, first you split it into blocks and then you will have some remaining characters at the end that are not one whole block.

So lets say that the block length is L and you have n characters. You can add at the end of your message L-n extra characters so that with those, your message will end up to be a multiple of the block length.

The extra characters can be what ever you want but generally you need a way to find out what the padding is after you decrypt. There are various techniques to do that. The best as far as i know is OAEP.

mandragore
  • 357
  • 1
  • 8
  • In the case of RSA the extra characters cannot be whatever you want. Unlike with (real) block ciphers, the padding has important security reasons for being used (e.g. making encryption non-deterministic). – otus Feb 07 '16 at 08:34
  • 2
    The random padding needs to be applied every time you perform the RSA algorithm. This is regardless of whether the message length is a multiple of the blocksize. If the RSA algorithm that is used is deterministic to begin with then all but the last blocks will be deterministic which is very bad. Adding randomness just in the last block will not help. – mandragore Feb 07 '16 at 13:34