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.
> 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.
That's not how it works...
In modern protocols, you don't encrypt at all with RSA. You use a key exchange, and if you use RSA, you only use it as a signature algorithm to initiate the key exchange.
If you happen to want to encrypt with RSA, which you usually shouldn't, you first use a padding algorithm (the modern variant of that is called RSA-OAEP) with which you prepare and then encrypt a random key. That key you then use for symmetric encryption.
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.
I made a similar tutorial for RSA and DH in Easylang—a learning and teaching programming language I developed myself. What makes things a bit difficult is that Easylang doesn't support big numbers.
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.
> 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.
That's not how it works...
In modern protocols, you don't encrypt at all with RSA. You use a key exchange, and if you use RSA, you only use it as a signature algorithm to initiate the key exchange.
If you happen to want to encrypt with RSA, which you usually shouldn't, you first use a padding algorithm (the modern variant of that is called RSA-OAEP) with which you prepare and then encrypt a random key. That key you then use for symmetric encryption.
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
I made a similar tutorial for RSA and DH in Easylang—a learning and teaching programming language I developed myself. What makes things a bit difficult is that Easylang doesn't support big numbers.
https://easylang.online/apps/tut_publk.html
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.
Oops, yes, I meant exponentiation. Which you need (mod n) in RSA.
RSA is one of those algorithms where understanding it once actually sticks.