Diversity and Transparency for ECC

Generating and standardizing elliptic curves to use them in a cryptographic context is a hard task. In this note, we don’t make an explicit proposal for an elliptic curve, but we deal with the following issues. Security: We give a list of criteria that should be satisfied by a secure elliptic curve. Although a few of these criteria are incompatible, we detail what we think are the best choices for optimal security. Transparency: We sketch a way to generate a curve in a fully transparent way so that it can be trusted and not suspected to belong to a (not publicly known to be) vulnerable class. In particular, since the computational cost of verifying the output of such a process may be quite high, we sketch out the format of a certificate that eases the computations. We think that this format might deserve being standardized

Twist Insecurity

Several authors suggest that the use of twist secure Elliptic Curves automatically leads to secure implementations. We argue that even for twist secure curves a point validation has to be performed. We illustrate this with examples where the security of EC-algorithms is strongly degraded, even for twist secure curves. We show that the usual blindig countermeasures against SCA are insufficient (actually they introduce weaknesses) if no point validation is performed, or if an attacker has access to certain intermediate points. In this case the overall security of the system is reduced to the length of the blinding parameter. We emphazise that our methods work even in the case of a very high identification error rate during the SCA-phase

Generation, Verification, and Attacks on Elliptic Curves and their Applications in Signal Protocol

Elliptic curves (EC) are widely studied due to their mathematical and cryptographic properties. Cryptographers have used the properties of EC to construct elliptic curve cryptosystems (ECC). ECC are based on the assumption of hardness of special instances of the discrete logarithm problem in EC. One of the strong merits of ECC is providing the same cryptographic strength with smaller key size compared to other public key cryptosystems. A 256 bit ECC can provide similar cryptographic strength as a 3072 bit RSA cryptosystem. Due to smaller key sizes, elliptic curves are an attractive option in devices with limited storage capacity. It is therefore essential to understand how to generate these curves, verify their correctness and assure that they are resistant against attacks. The security of an EC cryptosystem is determined by the choice of the curve that is used in that cryptosystem. Over the years, a number of elliptic curves were introduced for cryptographic use. Elliptic curves such as FRP256V1, NIST P-256, Secp256k1 or SM2 curve are widely used in many applications like cryptocurrencies, transport layer protocol and Internet messaging applications. Another type of popular curves are Curve25519 introduced by Dan Bernstein and Curve448 introduced by Mike Hamburg, which are used in an end to end encryption protocol called Signal. This protocol is used in popular messaging applications like WhatsApp, Signal Messenger and Facebook Messenger. Recently, there has been a growing distrust among security researchers against the previously standardized curves. We have seen backdoors in the elliptic curve cryptosystems like the DUAL_EC_DRBG function that was standardized by NIST, and suspicious random seeds that were used in NIST P-curves. We can say that many of the previously standardized curves lack transparency in their generation and verification. We focus on transparent generation and verification of elliptic curves. We generate curves based on NIST standards and propose new standards to generate special types of elliptic curves. We test their resistance against the known attacks that target the ECC. Finally, we demonstrate ECDLP attacks on small curves with weak structure