The way the article uses RSA is no better than a simple substitution cipher. Both the "l"s in "hello" are enciphered to 2575. It's a newspaper cryptogram.
You're supposed to concatenate all the input numbers, to create a message that has hundreds or thousands of digits; then RSA-encrypt that number.
I thought it was a padding scheme, where you use a moving mask to obscure the plaintext, then encrypt that. Since it's being XOR'ed, adjacent characters will not have the same encryption values anymore. Sort of like using CBC instead of ECB for block ciphers. However, because this article is about the maths with RSA itself, he probably correctly thought it was not relevant to what he was writing about and would just unnecessarily complicate things.
My article isn't written as a step-by-step tutorial and doesn't come with example numbers. But mine fills in certain things that xnacly doesn't cover: random prime generation, efficiently calculating the decryption exponent d from (n, e) by using a modular inverse, using modular exponentiation instead of power-then-modulo.
One of the bigger hurdles in implementing RSA is having an algorithm which can multiply the large numbers in real time. If you try a niave multiplication algorithm, you might find you'll never get an answer. A lot of hardware now comes with special instructions which implement efficient algorithms for doing this.
Sure, you can't use built in multiplication, but it isn't a very big hurdle. Just use repeated squares, it's fairly trivial to implement. I've worked on software that did this on very low power mobile payment devices.
The way the article uses RSA is no better than a simple substitution cipher. Both the "l"s in "hello" are enciphered to 2575. It's a newspaper cryptogram.
You're supposed to concatenate all the input numbers, to create a message that has hundreds or thousands of digits; then RSA-encrypt that number.
I thought it was a padding scheme, where you use a moving mask to obscure the plaintext, then encrypt that. Since it's being XOR'ed, adjacent characters will not have the same encryption values anymore. Sort of like using CBC instead of ECB for block ciphers. However, because this article is about the maths with RSA itself, he probably correctly thought it was not relevant to what he was writing about and would just unnecessarily complicate things.
And pad! Padding for RSA is like CDM (?) for AES.
I have a different take on the same topic: https://www.nayuki.io/page/java-biginteger-was-made-for-rsa-...
My article isn't written as a step-by-step tutorial and doesn't come with example numbers. But mine fills in certain things that xnacly doesn't cover: random prime generation, efficiently calculating the decryption exponent d from (n, e) by using a modular inverse, using modular exponentiation instead of power-then-modulo.
By the way for Python, modular exponentiation is pow(x, y, m) (since 3.0), and modular inverse is pow(x, -1, m) (since 3.8, Oct 2019). https://docs.python.org/3/library/functions.html#pow
One of the bigger hurdles in implementing RSA is having an algorithm which can multiply the large numbers in real time. If you try a niave multiplication algorithm, you might find you'll never get an answer. A lot of hardware now comes with special instructions which implement efficient algorithms for doing this.
Sure, you can't use built in multiplication, but it isn't a very big hurdle. Just use repeated squares, it's fairly trivial to implement. I've worked on software that did this on very low power mobile payment devices.
Repeated squares is a way to implement exponentiation, not multiplication.
RSA is one of those algorithms where understanding it once actually sticks.