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'?
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'?
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):
01
, 0202
or 030303
in your case).80
8000
or 800000
in your case).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).
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.