Backdoor in a Public RSA Key

When I saw how it works, say that I was shocked is to say nothing. It’s a pretty simple trick, but after reading this article, you will never look at the RSA as before. This is not a way to hijack RSA, but something that will make your paranoia greatly swell.

So, imagine that you have access to the generator of an RSA key and you want to give someone the opportunity to get the private key without any factorization and other quantum computers. What we need to do?

2). Let us recall about great Curve25519, namely the fact that any 32-byte sequence is valid for its private key. At the same time, the public key is always 32 bytes also. Let’s pre-generate the master key and assign it to a constant variable:

For each generated RSA key pair we will also generate a random key pair of Curve25519 and then calculate the shared secret from the public key of the pair, and our private key. This secret is the key to PRNG from step 1.

It’s worth saying that key-based RSA is always two prime numbers p and q. Their product is called «modulus» and is part of the public key. In this case, two 2048 bits numbers are searched with the help of our PRNG and then a single key pair is built from them.

4). Now, replace some bytes from p*q modulus with our payload. It makes sense to replace more significant bytes, so that they are not deleted later. 80 bytes-shifting should be enough.

Thus, by owning a Curve25519 private key, only we can obtain a private key of any backdoored RSA.

Where it can be applied? Anywhere! You’ll never prove that the key pairs issued to you by banks do not have these type of markings. It’s impossible to prove! So try to generate keys by yourself. Well, and stop using RSA, if possible.

I wrote the Python implementation that this article is based on. I was too lazy to do a proper write-up, and I think this one is pretty good.

This port does have some subtle implementation errors, though.

The embedded key is the master *private* key, so anyone with this code can recover any RSA keys generated with it. I submitted a pull request on github that fixes it.

For those asking «who uses private keys generated by untrusted sources» — this could be implemented in hardware, for example a smart card. Binaries you don’t have the source for or didn’t compile yourself could also be affected.

«For those asking «who uses private keys generated by untrusted sources» — this could be implemented in hardware, for example a smart card. Binaries you don’t have the source for or didn’t compile yourself could also be affected.»

That would apply then to any algorithm, operating system, random number generator, or anything you use in life, not just RSA. Pretty weak argument against RSA

Joozek got the point. When you activate even the cheapest https server/domain you generate the private key locally with your openssl apache tool, then register the only public key to the Certification Authority.

I think the idea is this one: What if your closed source Super Encryption Enterprise Edition generates keys on your own desktop, with this backdoor built in?
People had always known that sort of thing could be abused, but this is a method of doing so which isn’t overly obvious.

Most of us work with strings one way or another. There’s no way to avoid them — when writing code, you’re doomed to concatinate strings every day, split them into parts and access certain characters by index. We are used to the fact that strings are fixed-length arrays of characters, which leads to certain limitations when working with them. For instance, we cannot quickly concatenate two strings. To do this, we will at first need to allocate the required amount of memory, and then copy there the data from the concatenated strings.