TKTK
TKTK
Diffie-Hellman is the first ever public-key crypto algorithm. It acts on finite fields (FFDH) but has also been augmented to work in elliptic curves (ECDH). While the two algorithms are very similar, they are also subject to different types of attacks. In this page, we refer to FFDH only. See the ECDH page for the elliptic curve variant.
Many implementations of Diffie-Hellman will often come with pre-generated parameters. For example TLS 1.3 specifies exactly what DH groups can be negotiated. While these groups taken directly from RFC 7919 are secure, this is not always the case and the slightest change can introduce issues. For example:
For these reasons, it is important to test the validity of the public parameters used. Tools exist for this.
First, when we talk about keysize what we're talking about is the bit-size of the public modulus.
As with every keysize concerns, www.keylength.com is often the answer (spoiler alert: 2048-bit).
In addition, the cryptography by the numbers page gives some idea of what academic attacks have been able to do (spoiler alert: a 768-bit modulus has been broken). Although academic estimates that state adversary should be able to break 1024-bit modulus.
RSA is both a signature and an asymmetric encryption scheme. It is important to know which algorithm and which version of it you are using (as not all of them are secure); they are mostly defined in PKCS#1 documents (v1.5, v2.0, v2.1, v2.2).
There are many encryption schemes that have been standardized, unfortunately not all of them are that great and the great ones are often not implemented by libraries.
No. Bleichenbacher found an attack on PKCS#1 v1.5 in 1998 which allows to decrypt the content of any encrypted payload, as long as the server advertises (or leaks) the validity of a ciphertext's PKCS#1 v1.5 padding. In spite of this, most certificates on the internet (and thus most internet protocols) are stil using this old and broken primitive. This has led to difficult to implement workarounds and mitigations, that have consequently been found not to work over and over:
RSA OAEP standardized in PKCS#1 v2.x is deemed "good enough" if you do not have access to better standards like RSA-KEM. Nonetheless, implementations of OAEP must mitigate against Manger's attack meaning that they must check in constant time the full padding of the ciphertext, even if the first null byte is incorrect. For example an error returning too early could give indication on the value of the first padding byte.
First, when we talk about keysize what we're talking about is the bit-size of the RSA public modulus.
As with every keysize concerns, www.keylength.com is often the answer (spoiler alert: 2048-bit).
In addition, the cryptography by the numbers page gives some idea of what academic attacks have been able to do (spoiler alert: a 768-bit modulus has been broken). Although academic estimates that state adversary should be able to break 1024-bit modulus.
Probably not, depending on how you use RSA there might exist more attacks. See Twenty Years of Attacks on the RSA Cryptosystem.
RSA's key generation requires good randomness and good algorithms to generate prime numbers. Both these requirements have been butchered in the past:
To ensure that a key generation algorithm is safe, it needs to be audited.
not really, unless your threat model involve attackers being able to physically observe or tamper with your device OR you are running adversarial code on the same computer. TKTK (fault attacks (rowhammer), timing attacks, etc.)