The short answer is NO. Generally, it is not true that for RSA with no padding, the length of data must be equal to the key length. When and if that applies, that's a restriction of a particular cryptographic library, and either that's not the only restriction about the data, or the library does not allow reliable decryption of what's encrypted.
RSA (encryption) with no padding is a well defined algorithm when enciphering integers. It uses a public key $(N,e)$. The key length is given as the bit size $n$ of $N$; that is $n$ is the integer such that $2^{n-1}\le N<2^n$. This form of RSA encryption with no padding takes as input some integer $m$ with $0\le m<N$ called the plaintext (or message), and outputs the integer $c$ with $0\le c<N$ called the ciphertext, such that $c\equiv m^e\pmod N$ (or in other words such that $m^e-c$ is a multiple of $N$). That transformation is reversible for decryption. Notice that if we remove the restriction that $m$ is less than $N$, we create the problem that $m$ and $m+N$ yield the same $c$, therefore decryption of the ciphertext can not reliably recover the plaintext; for example, $m=2^n-N-1$ and $m=2^n-1$ both encipher to the same $c$.
RSA with no padding is not universally defined when we move to data rather than integers, for many reasons including:
- There's no agreement on the stuff data is made of. Is that bits? Octets of 8 bits? Characters for various definitions of that?
- Endianness in the conversion to integer and back.
- Dealing with the aforementioned $m<N$ requirement; a fine option would be defining a fixed data size insuring that. For example, message data of exactly $\lfloor (n-1)/8\rfloor$ octets (and some usual conversion to integer) would insure $0\le m<2^{n-1}\le N$; but then that fixed data size is less than the key length (in octets).
The library in the question does not do the later. Its requirement seems to be that the input data length in bytes (octets) must be a multiple of $n/8$, where $n$ is the key size in bits (an a multiple of 8 in all the examples). We can guess that the input is split into data blocks of exactly $n/8$ octets, each individually converted to a number $m$ (probably using straight big-endian convention, which is the most common), then RSA-enciphered as above, with each result converted back to exactly to $n/8$ bytes using the same convention, and the results concatenated in the same order as the original to form the ciphertext. We have no way to guess what happens when one of the $m$ does not meet the $m<N$ requirement.
It seems the library in the question unify symmetric and asymmetric cryptography into a one-size-fits-all API, even if that's at the price of drawbacks:
- Making it easy to unwillingly implement an unsafe cryptosystem; in particular, if some data belonging to a small set (like a dice throw, or candidates to an election) is enciphered in this way, it is trivial to break the encryption (just encipher each possible plaintext and see which match the ciphertext).
- Allowing large data and subdividing that into blocks before enciphering each with RSA, which makes decryption grossly inefficient; and is insecure when used with no padding: in particular repeated plaintext blocks are visible in the ciphertext.
- Either ignoring the $m<N$ requirement (with the consequence that for some data, encryption followed by decryption does not give back the original data); or rejecting some data at encryption time (which might escape testing). Most likely, one of this occurs when enciphering a block of data consisting of $n/8$ octets all
0xFF.
Except in very specific cases (such as enciphering a random bit string of $n-1$ bits):
- Do not use RSA with no padding (also called textbook RSA or naked RSA), but rather use some secure RSA scheme built on top of that; see e.g. RSAES-OAEP of PKCS#1. Among the reasons not to use RSA encryption with no padding
- Like any deterministic public encryption, it is unsafe when the plaintext has low entropy.
- Short plaintext is vulnerable. In particular, even uniformly random plaintext of $\lfloor n/e\rfloor$ bits can be found by $e^{\text{th}}$ root extraction, and there are extensions to that.
- Dan Boneh's Twenty Years of Attacks on the RSA Cryptosystem has more excellent reasons; and there are even more.
- Do not use RSA to directly encipher application data that could be larger than what makes the RSA scheme used safe (for example, RSAES-OAEP with 2048-bit key and SHA-256 hash allows to safely encipher data of 0 to 190 octets and still have enough randomness added by the scheme); rather, use hybrid encryption.
