© Copyright 2000-2003 Entrust. All rights reserved.

Elliptic Curve CryptographySupport in Entrust

Author: Robert ZuccheratoDate: May 9, 2000Version: 1.0

Entrust is a registered trademark of Entrust, Inc. in the United States and certain other countries. Entrust is a registered trademark of Entrust Limited in Canada. All other Entrust product names and service names are trademarks or registered trademarks of Entrust, Inc or Entrust Limited. All other company and product names are trademarks or registered trademarks of their respective owners. © Copyright 2000-2003 Entrust. All rights reserved.

1 IntroductionThere are three families of public-key cryptography in common use today. The most widely used systemsare those based on integer factorization. In particular, the RSA cryptographic system is perhaps the mostpopular public-key algorithm. It is used in most web browsers (for SSL), email packages (for S/MIME) aswell as within the Entrust family of products. Systems based on the discrete logarithm problem are alsovery popular as they can provide support for both digital signatures (with DSA) and key agreement (withthe Diffie-Hellman algorithm). Traditionally Entrust has supported both of these families of cryptographicalgorithms.

With the release of Version 5.0 of the Entrust product line, Entrust now also supports a third family ofcryptographic algorithms. This family is based on arithmetic using elliptic curves. Elliptic curvecryptography (ECC) is a relatively new family of public-key algorithms that can provide shorter keylengths and, depending upon the environment and application in which it is used, improved performanceover systems based on integer factorization and discrete logarithms.

This paper will give a brief introduction to elliptic curve cryptography, discuss its security and performanceadvantages and describe Entrust’s support of this important type of cryptography.

1.1 ECC BackgroundThe purpose of this section is to provide sufficient background material in ECC to understand theremainder of this document. For a more complete description of ECC the reader is referred to [P1363] and[X962].

All public-key cryptographic systems have their security based on certain mathematical problems that aredifficult to solve. For example, RSA, since it is from the integer factorization family, has its security basedon the difficulty of factoring integers. Given two large integers p and q, it is easy to compute their product

qpn ×= .However, given a large integer n (where n has over 300 digits) it is extremely difficult, given today’sresources, to factor n into two non-trivial factors p and q. For this reason, integer factorization is called aone-way function: it is easy to multiply integers, but hard to invert the operation (i.e. factor integers).

Similarly, ECC has its security based on a difficult mathematical problem. An elliptic curve can be thoughtof as a mathematical structure in which certain operations can be defined. These operations provide a one-way function that can be used to produce efficient cryptographic systems. The one-way function used inECC is called the elliptic curve discrete logarithm problem (ECDLP). The ECDLP is similar to the one-way function on which DSA and Diffie-Hellman are based, and hence, elliptic curve analogs of each ofthese algorithms have been defined. The most popular signature scheme which uses elliptic curves is calledthe Elliptic Curve Digital Signature Algorithm (ECDSA), the most popular encryption scheme is calledthe Elliptic Curve Integrated Encryption Scheme (ECIES) and the most popular key agreement methodis called Elliptic Curve Diffie-Hellman (ECDH).

There are also two distinct, non-interoperable types of elliptic curve cryptography. The elliptic curve canbe either odd characteristic (also called modulo p or prime characteristic) or even characteristic (alsocalled over a finite field with 2m elements). Odd characteristic elliptic curves are more suited to softwareimplementations on a PC whereas even characteristic elliptic curves are more suited to hardwareimplementations.

Among even characteristic curves, there are a number of non-interoperable, different methods forrepresenting public keys and performing arithmetic. The two most common methods are using apolynomial basis and using a normal basis.

2 Security of ECCOne of the advantages of using elliptic curve based cryptographic systems instead of integer factorizationor discrete logarithm based methods is that they provide similar security levels using smaller key lengths.

Why is this? As mentioned in the previous section, the security of any public-key based cryptography isbased upon the difficulty of solving certain mathematical problems. Thus, we can determine the amount ofeffort that would be required to break one of these public-key systems by looking at the effort required tosolve these hard problems, using the best algorithms, software and hardware which are known. It should benoted that in the future new solutions to any of these problems might be discovered that drastically changethe amount of effort required to solve them. The analysis below is based on the best methods known today.

Most people consider the integer factorization and discrete logarithm problems to have approximatelyequivalent security. Both of these problems have undergone intensive review and study by many of theworld’s top mathematicians and cryptographers. This can give us a sense of comfort that these problemsare, in fact, difficult to solve. Actually, the best method known to solve each of these problems is theNumber Field Sieve (NFS). The NFS is what is known as a sub-exponential time method. This meansthat the problem can be considered hard to solve, but not as hard as problems that only allow fullyexponential solutions.

It is generally accepted that, based on the difficulty of solving the integer factorization problem and discretelogarithm problem, RSA, DSA and Diffie-Hellman keys should be at least 1024 bits long and that for verylong-term security (20 years or more) 2048 bit keys should be used. Recently a large-scale effort was ableto factor a 512-bit integer, thus showing that keys of this size are vulnerable to attack by large,sophisticated adversaries [RSA512].

On the other hand, solving the ECDLP is generally considered to be a much more difficult problem thanfactoring integers or solving the discrete logarithm problem. Because of the structure that is inherentwithin an elliptic curve, the types of solutions to these problems do not seem to apply to the ECDLP. Thebest method known to solve the ECDLP is an elliptic curve version of an attack developed by Entrustresearchers for the discrete logarithm problem, known as the parallel collision search method [VOW]. Thismethod is fully exponential, which means that that the ECDLP can be considered among the hardest typesof problems to solve, using the best methods known today. One of the consequences of the ECDLP onlyhaving a fully exponential solution is that for every two additional bits of key used, attacking that keyrequires twice as much effort. Thus, attacking a 193-bit elliptic curve public key requires twice as mucheffort as attacking a 191-bit key.

Because it is relatively new, the ECDLP has not received as much attention from mathematicians andcryptographers as the integer factorization and discrete logarithm problem. Although, within the past fewyears, that has begun to change and a great deal of effort has been made at attempting to solve this problem.Since a great deal of research is still ongoing, it is difficult to directly compare the security levels providedby ECC with those provided by RSA, DSA and Diffie-Hellman, for example. However, it seemsreasonable that for security equivalent to an RSA key with 1024 bits, one should use an elliptic curve withabout 170 bits and that for security equivalent to an RSA key with 2048 bits, one should use an ellipticcurve with about 230 bits.

The above discussion on the difficulty of attacking an ECC public key assumes that certain weak caseshave been avoided when constructing the elliptic curve parameters. There are certain elliptic curves thatare known to produce cryptographic systems with a substantially lower security level than the general casedescribed above. These weak cases include:• a class of curves known as supersingular elliptic curves;• elliptic curves modulo p which contain exactly p points; and• elliptic curves defined over a finite field with 2m elements where m is not a prime.

Fortunately, each of these classes of weak curves is easy to identity and most standards bodies forbid theiruse. In order to guarantee that a given curve has not been intentionally constructed to somehow be weakerthan expected and also to guard against possible future attacks against additional classes of weak curves, itis generally recommended to use elliptic curves which have been verifiably generated at random. This isthe most conservative, or safest, option when choosing elliptic curves on which to base a system.

There exists another class of special elliptic curves which requires attention. This class of evencharacteristic curves, called Koblitz curves, allows more efficient implementations. For very resource

constrained environments these curves are an attractive option. However, some cryptographers areconcerned that the additional structure exploited in these curves to obtain the efficient implementationsmay also be used to efficiently attack them. In fact, Entrust researchers were one of two independentgroups which were able to show that these curves provide a few bits less security than randomly generatedcurves [WZ]. While the slight weakness demonstrated should not, in itself, stop people from using thesecurves, it does raise the question of how secure these curves really are. Entrust recommends that thesecurves be used with caution.

3 Comparison with RSAThis section compares ECC public key sizes, signature and encryption lengths, and speed with those ofRSA. Typical usage scenarios will be used to describe the effect these have on various implementations.The ECC system under consideration will use an odd characteristic 192-bit elliptic curve, which is thedefault used by the Entrust product line. The RSA system will use 1024-bit keys, which is also the defaultin the Entrust product line.

3.1 SizeThe size of an ECC public key, ECDSA signature and an ECIES encryption will be compared with thoseproduced by an RSA system.

3.1.1 Public Key SizeAn RSA public key consists of an ordered pair (n,e) where n is a composite number, called the modulus,and e is the public exponent. In a 1024-bit RSA system, n will have 1024 bits. A common value for thepublic exponent is e=216+1. This is the value that Entrust uses. Thus, an Entrust RSA public key wouldrequire 128 bytes for the modulus and 3 bytes for the public exponent. The total size is then 131 bytes.

An ECC public key consists of a point on the elliptic curve. Each point is represented by an ordered pair ofelements (x,y) each with 192 bits. For a 192-bit elliptic curve, the public key would then be represented bytwo 24-byte values, giving a total key size of 48 bytes.1

As can be seen from the numbers above, ECC does provide a significant reduction in public key size. Thisreduction can be crucial in many severely constrained environments where large public keys are notpossible. However, in a PKI using X.509 certificates, the effect of using the smaller public keys isminimal. A typical size for an X.509 certificate would be about 1K (~1000 bytes). Thus, changing a user’spublic key from RSA or DSA to ECC would reduce his/her certificate size by less than 10%.

Another important point to keep in mind is that each ECC public key is only valid in the context of certainparameters. These parameters must also be specified and transferred with integrity to the public keyrecipient (e.g. within an X.509 certificate). While there do exist certain curves which can be representedusing short identifiers, in the general case, it will require an additional five 192-bit (24-byte) quantities tospecify these parameters. Thus, it could take up to 110 additional bytes. RSA does not require anyparameters be transferred with the public key.

3.1.2 Signature SizeAn RSA signature consists of a single 1024 bit value. Thus, it can be represented in 128 bytes.

An ECDSA signature consists of two 192-bit values. Thus, it can be represented using two 24-byte values,for a total signature size of 48 bytes.2

1 A method does exist to reduce the size of ECC public keys by almost a factor of 2. This method, calledpoint compression, is a proprietary technique that is not available to all implementers of ECC, thus toensure interoperability it is not recommended. For this reason, the size estimates given assume no pointcompression has been performed. If point compression was used, a public key could be represented usingone 192-bit value and one additional bit. This would then require (24+1=) 25 bytes.

Again, the reduction in signature size is substantial and may be important for many constrainedenvironments. However, as with public key size, the difference represents less than 10% of the size of apublic key certificate. For larger signed messages, the difference would represent an even smallerpercentage of the overall message.

3.1.3 Encryption SizeThis section will compare the difference in size in transporting a 128 bit symmetric key using RSA andECIES. This is the typical scenario when files are encrypted, for example. The encryption algorithmECIES is specified in the ANSI X9.63 draft [X963].

A 128 bit symmetric key encrypted using RSA will consist of one 1024 bit value. Thus, it can berepresented using 128 bytes.

A 128 bit symmetric key encrypted using ECIES will consist of an elliptic curve point, a 128-bit value anda 160-bit value. The elliptic curve point consists of two 192-bit values, so it can be represented using two24-byte values, or 48 bytes.3 The 128-bit value can be represented using 16 bytes and the 160-bit value canbe represented using 20 bytes. Thus the encrypted symmetric key requires 84 bytes.

While ECIES does indeed produce smaller encrypted values than RSA, the difference is not as dramatic asfor public keys and signature values. When considering that the symmetric key will then usually be used toencrypt much larger files, the advantage may become inconsequential.

3.2 SpeedThis section will compare the time required to perform ECC signature and encryption operations with thetime required for RSA signatures and encryption. Absolute timings for different cryptographicimplementations can vary widely. These variations can be caused by a number of factors, including thequality of the implementation, the platform used, optimizations made which exploit certain special cases, orthe use of proprietary or patented techniques not available to other implementers. For this reason it canoften be misleading to directly compare any individual timings. It is better to consider general trends intimings for types of cryptographic systems. That is what we do here.

The first issue to consider is whether the implementation is in software or hardware. For a hardwareimplementation in custom silicon, even characteristic elliptic curves clearly allow the fastestimplementations. This is due to the fact that the underlying arithmetic for even characteristic curves can beimplemented using fewer gates, and thus in a smaller area, than the arithmetic for odd characteristic curvesor for RSA. Thus, the advantage these curves have is lost if the implementation is in software or firmwareon an embedded processor. Odd characteristic elliptic curves and RSA however can take advantage of theinteger mathematics routines that inherently exist on most computers and therefore they should be used forsoftware implementations. The decision as to which of these two to use in a software implementation willdepend on the particular environment in which the cryptography will be used. The remainder of thissection will examine some common, general software environments in which this choice must be made.

Using a small public exponent value (e.g. e=216+1), the RSA public key operations can be made very fast.This means that RSA signature verification and RSA encryption can be performed up to 40 times fasterthan an ECDSA verify or ECIES encryption operation. The RSA private key operations (i.e. signaturegeneration and decryption) are generally slower than the public key operations. The ECC private key

2 Signature sizes cannot be reduced using point compression. Thus, 48 bytes is the smallest signature sizeavailable for a 192-bit elliptic curve system.3 As with ECC public keys, the 48 bytes required to represent the elliptic curve point in an ECC encryptioncan be reduced to 25 bytes using point compression. Since this is a proprietary technique not available toall implementers of ECC, in order to ensure interoperability it is not recommended that point compressionbe used. For this reason, the size estimates given assume no point compression has been performed.

operations are generally faster than the public key operations. The situation can be summarized in thefollowing table.

RSA ECCPrivate Key Operations(Signature Generation and Decryption)

LESS FAST FAST

Public Key Operations(Signature Verification and Encryption)

VERY FAST LESS FAST

Let’s now consider four common situations. First, let’s consider the question of which algorithm would bebest for CA signing keys. CA signing keys are used to sign certificates and CRLs. Each certificate andCRL only gets signed once, but is verified many times. In particular, every time that an end user’ssignature is verified or something is encrypted at least one certificate and CRL must be verified. Thus, itmakes sense for CAs to try and minimize the amount of time end users spend on signature verification. Inthis situation, RSA appears to be a better choice for CA public keys.

Now let’s consider end user signing keys. Each signature, regardless of the number of people to whom itwill be sent or the number of times that it will be verified, will only be created once. In the general casehowever, it may potentially be verified many times, by many different people. Thus, it makes sense in thissituation, again, to try and minimize the time that signature verification takes. Since signature generationwill only be performed once, we are not as concerned about the amount of time that operation takes. Thus,again, RSA appears to be a more optimal choice for end user signature keys.

Let’s now look at what happens with end user encryption keys. When encrypting a document, the actualdocument will get encrypted with a symmetric algorithm (e.g. DES, CAST, IDEA) and then the symmetrickey will be individually encrypted using the public-key algorithm for each recipient. Thus, the personencrypting the document must perform a separate public-key encryption for each recipient and thereforemay need to perform many public-key encrytions each time a document is encrypted. Each recipient,however, will only need to perform one decryption operation each time access to the document is required.Thus, in this situation it makes sense to try and minimize the amount of time the person encrypting thedocument must spend and, therefore, minimize the amount of time spent on encryption. Again, using RSAseems to make the most sense in this situation.

Finally, let’s consider a general email application where a user wishes to digitally sign and encrypt an emailfor one recipient. Digitally signing the email requires one private key operation. Encrypting the emailrequires one public key operation to encrypt the symmetric key which will be used to encrypt the contentsof the email. However, before using the recipient’s encryption public key, the sender must first validate therecipient’s public key certificate. Validating the certificate will involve verifying the signature on at leastone certificate and also verifying the signature on at least one CRL. Thus, at least three public keyoperations must be performed before the email can get sent. In this situation, the difference between thetime required for an RSA-based system and an ECC-based system is very small. Either choice will resultin a very fast implementation.

4 Entrust Support for ECCThis section will describe Entrust’s present and future support for ECC. In the 5.0 release of the Entrustproduct line, support for ECDSA was introduced. Initially only end user ECDSA keys are supported, butsupport for CA ECDSA keys is expected in a future release. Thus, Entrust now supports all three majordigital signature algorithms, RSA, DSA and ECDSA. At the present time Entrust does not support eitherECIES encryption or ECDH. These algorithms will be supported when market demand warrants.

Entrust’s elliptic curve implementation is completely general. Any odd or even characteristic elliptic curve(that is not a member of one of the weak classes described in Section 2) is supported. However, in order tomake things easier for the user and to promote interoperability, Entrust has chosen certain default curvesthat will be used if no other curve is specified. Since the environment is software based, Entrust has chosenodd characteristic elliptic curves to be the default type of curve.

As was mentioned in Section 2, a 170-bit elliptic curve system seems to provide approximately equivalentsecurity to a 1024-bit RSA system. Since elliptic curves are relatively less studied than integerfactorization or discrete logarithms, Entrust felt it was prudent to choose default curves which provideslightly more security than required, to allow for future advances in cryptanalytic attacks. The default oddcharacteristic curve has 192 bits and the default even characteristic curve is 191 bits. Both of these defaultcurves are specified in ANSI X9.62 [X962] and can be represented by standardized short identifiers. Infact, Entrust recognizes all of the identifiers specified in the ANSI X9.62 standard and is X9.62 compliant.For even characteristic curves, however, Entrust only supports curves represented with respect to apolynomial basis. Normal bases are not supported.

5 References[P1363] IEEE Std 1363-2000: Standard Specifications for Public-Key Cryptography.

[RSA512] “Factorization of RSA-155”, available athttp://www.rsasecurity.com/rsalabs/challenges/factoring/rsa155.html

[VOW] P.C. van Oorschot and M.J. Wiener, Parallel collision search with cryptanalytic applications,Journal of Cryptology, 12 (1999), pp. 1-28.

[WZ] M.J. Wiener and R.J. Zuccherato, Faster attacks on elliptic curve cryptosystems, Selected Areas inCryptography- 5th Annual International Workshop, SAC ’98, Lecture Notes in Computer Science 1556(1999), Springer-Verlag, pp. 190-200.

[X962] ANSI X9.62-1998, Public Key Cryptography for the Financial Services Industry: The EllipticCurve Digital Signature Algorithm (ECDSA).

[X963] ANSI X9.63, Public Key Cryptography for the Financial Services Industry: Elliptic Curve KeyAgreement and Transport Protocols, draft, 1999.