Franklin-reiter Related Message Attack

[Kenya Ahyet]

Coppersmiths attack describes a class of cryptographic attacks on the public-key cryptosystem RSA based on the Coppersmith method. Particular applications of the Coppersmith method for attacking RSA include cases when the public exponent e is small or when partial knowledge of a prime factor of the secret key is available.

If the public exponent is small and the plaintext m \displaystyle m is very short, then the RSA function may be easy to invert, which makes certain attacks possible.Padding schemes ensure that messages have full lengths, but additionally choosing the public exponent e = 2 16 + 1 \displaystyle e=2^16+1 is recommended. When this value is used, signature verification requires 17 multiplications, as opposed to about 25 when a random e \displaystyle e of similar size is used. Unlike low private exponent (see Wiener's attack), attacks that apply when a small e \displaystyle e is used are far from a total break, which would recover the secret key d. The most powerful attacks on low public exponent RSA are based on the following theorem, which is due to Don Coppersmith.

Franklin and Reiter identified an attack against RSA when multiple related messages are encrypted: If two messages differ only by a known fixed difference between the two messages and are RSA-encrypted under the same RSA modulus N \displaystyle N , then it is possible to recover both of them. The attack was originally described with public exponent e = 3 \displaystyle e=3 , but it works more generally (with increasing cost as e \displaystyle e grows).

Suppose Bob sends a message M \displaystyle M to Alice using a small random padding before encrypting it. An attacker, Eve, intercepts the ciphertext and prevents it from reaching its destination. Bob decides to resend M \displaystyle M to Alice because Alice did not respond to his message. He randomly pads M \displaystyle M again and transmits the resulting ciphertext. Eve now has two ciphertexts corresponding to two encryptions of the same message using two different random pads.

By definition, the Franklin Reiter related message attack works in a scenario where two messages differ only by a fixed known difference. Suppose I have two messages encrypted by RSA with the same public key (N, e), where:

RSA with public exponent e=3, allowing us to use Franklin-Reiter related message attack. The caveat is that the (related) messages are created by adding a random number, generated by a LCG, to the integer flag. By reconstructing the LCG we can apply our attack and recover the flag.

Because we have constructed the LCG we know what rand_num_1 and rand_num_2 are, so we know the numerical difference between the messages. Or in other words, these two ciphertexts are related by a known difference. If we rewrite the above to

Taking a look at the outer layer it consists of the used XOR blind concatenated with the outer layer ciphertext. This ciphertext is encrypted with a public exponent of 127, which is not very small but not really large either. Since the blind is smaller than the outer layer plaintext, it can be seen as some kind of random padding. However the Coppersmith short-pad attack is only feasible if the padding is about

Again, we have to deal with the XOR blinding. This time we cannot set up a linear relationship between two of the plaintexts as we have no clue about the underlying message. However, for the inner layer we only have a public exponent of $e=5$ and $n=1024$, such that we can recover random padding up to 40 bits, theoretically. Of course in practice (and within CTF time), this limit is a couple of bits lower. Luckily for us, this is enough for us to mount a simple Coppersmith short-pad attack on the inner layer.

Below you can find an example implementation of this attack on a local ltet = LTET() class. Note that the attack does not require any knowledge on the structure or contents of the encrypted message itself.

RSA is an intrinsically fragile cryptosystem containing countless foot-guns which the average software engineer cannot be expected to avoid. Weak parameters can be difficult, if not impossible, to check, and its poor performance compels developers to take risky shortcuts. Even worse, padding oracle attacks remain rampant 20 years after they were discovered. While it may be theoretically possible to implement RSA correctly, decades of devastating attacks have proven that such a feat may be unachievable in practice.

To set up RSA, Alice needs to choose two primes p and q that will generate the group of integers modulo N = pq. She then needs to choose a public exponent e and private exponent d such that ed = 1 mod (p-1)(q-1). Basically, e and d need to be inverses of each other.

Just as in the private exponent case, implementers want to use small public exponents to save on encryption and verification time. It is common to use Fermat primes in this context, in particular e = 3, 17, and 65537. Despite cryptographers recommending the use of 65537, developers often choose e = 3 which introduces many vulnerabilities into the RSA cryptosystem.

The fundamental issue here is that padding is necessary when using RSA, and this added complexity opens the cryptosystem up to a large attack surface. The fact that a single bit of information, whether the message was padded correctly, can have such a large impact on security makes developing secure libraries almost impossible. TLS 1.3 no longer supports RSA so we can expect to see fewer of these attacks going forward, but as long as developers continue to use RSA in their own applications there will be padding oracle attacks.

Second, any Diffie-Hellman based key agreement or signature scheme (including elliptic curve variants) does not require padding and therefore completely sidesteps padding oracle attacks. This is a major win considering RSA has had a very poor track record avoiding this class of vulnerabilities.

Trail of Bits recommends using Curve25519 for key exchange and digital signatures. Encryption needs to be done using a protocol called ECIES which combines an elliptic curve key exchange with a symmetric encryption algorithm. Curve25519 was designed to entirely prevent some of the things that can go wrong with other curves, and is very performant. Even better, it is implemented in libsodium, which has easy-to-read documentation and is available for most languages.

RSA was an important milestone in the development of secure communications, but the last two decades of cryptographic research have rendered it obsolete. Elliptic curve algorithms for both key exchange and digital signatures were standardized back in 2005 and have since been integrated into intuitive and misuse-resistant libraries like libsodium. The fact that RSA is still in widespread use today indicates both a failure on the part of cryptographers for not adequately articulating the risks inherent in RSA, and also on the part of developers for overestimating their ability to deploy it successfully.

Sorry, I cannot really agree. The biggest advantage of c25519 is its speed, shorter keys and resistance against timing attacks (so yes: I am all for c25519, but NOT because RSA has a general problem).

I implemented RSA key generation for a customer a few years ago. On the advice of our regulator, we tried to rigorously follow the method in Annex B.3 of FIP186-4, and we had a true hardware RNG at our disposal. Is the FIPS procedure considered OK or broken?

You should be okay using FIP186-4. Most of the attacks on prime generation occur when people cut corners and try to only generate primes of a specific form like in ROCA. As the post points out, though, a lot of other things can go wrong with RSA implementations so we still recommend not using it even if all components are based on a vetted standard.

This paper proposes a software architecture to enable the use of cloud computing in applications with strict security and privacy requirements. This architecture considers how the components of an application can be integrated so that the privacy and security of user data are guaranteed. The sensitive part of the processing is therefore isolated and the architecture considers different strategies for aggregating sensitive data in environments where there are no guarantees of full confidentiality.

In our work, we consider two implementations of the secure aggregation module, one based on homomorphic encryption, which is completely programmed in software, but imposes high additional processing costs, and another based on Intel SGX (Software Guard eXtensions) [5] technology, which does not impose high computational costs, but requires processors that support the software guard instruction setFootnote 1. The first enables computations to be performed on ciphertext without compromising encryption. For example, a homomorphic search system allows locating terms in encrypted databases without disclosing any information about the database or about the term being searched. The second allows processes to be run in a protected mode, where memory and execution are protected against access, even from users or processes with higher levels of privilege, avoiding the need to perform computations in ciphertext.

Finally, certain limitations were identified during the development of the work: (i) to be feasible, the set of computations for the fully homomorphic encryption is limited, which makes it much more difficult to develop arbitrary data processing modules; (ii) the use of Intel SGX prevents certain operations from being performed, such as system calls (syscalls), which has implications for the type of code that will run in a protected manner; and (iii) Intel SGX also has memory usage limitations, 128 MB per host in the current implementation, but with the ability to paginate memory.

The rest of the paper is organized as follows. The related work is discussed in Section 2. Section 3 depicts the software architecture designed to ensure secure data aggregation. The evaluation method is explained in Section 4, the results are presented in Section 5 and are discussed in Section 6. A threat analysis of this solution is discussed in Section 7. Finally, Section 8 highlights the main conclusions of the paper and its limitations.

3a8082e126