Security and Practical Considerations when
Implementing the Elliptic Curve Integrated
V. Gayoso Martínez, L. Hernández Encinas
Institute of Physical and Information Technologies (ITEFI)
Spanish National Research Council (CSIC), Spain
A. Queiruga Dios
University of Salamanca, Spain
The most popular encryption scheme based on elliptic curves is the El-
liptic Curve Integrated Encryption Scheme (ECIES), which is included in
ANSI X9.63, IEEE 1363a, ISO/IEC 18033-2, and SECG SEC1. These stan-
dards offer many ECIES options, not always compatible, making it difﬁcult
to decide what parameters and cryptographic elements to use in a speciﬁc
deployment scenario. In this work, we show that a secure and practical
implementation of ECIES can only be compatible with two of the four pre-
viously mentioned standards. In addition to that, we provide the list of func-
tions and options that must be used in such an implementation. Finally, we
present the results obtained when testing this ECIES version implemented as
a Java application, which allows us to produce some comments and remarks
about the performance and feasibility of our proposed solution.
Keywords data encryption, elliptic curves, Java, public key cryptography,
The aim of this contribution is to present ECIES and to identify the peculiarities
of the different versions of that encryption scheme that have been standardised in
ANSI X9.63 , IEEE 1363a , ISO/IEC 18033-2 , and SECG SEC1 .
Those versions offer a large number of implementation options, making it impos-
sible to deﬁne a secure version of ECIES fully compatible with all the standards.
In the present work, we have analysed the most relevant options of ECIES from a
security and performance point of view and, as a result of that research, we show
that a practical implementation of ECIES can only be compatible with two stan-
dards at the same time. Based on that knowledge, together with the information
provided by the most recent attacks against this cryptosystem, we propose a set of
functions and security recommendations that should be taken into account by any
developer who intends to implement ECIES in a secure and efﬁcient way. After
that, we offer some results of our Java implementation of ECIES and a compari-
son with a similar scheme based on RSA and AES, which allows us to share some
conclusions about the feasibility of the solution that we propose.
In  and , the authors provided a brief functional description of ECIES
and an analysis of the different versions of this encryption scheme included in
several standards, along with a list of the related functions used by ECIES (with
a special focus on the ECIES functions available in Java Card in ). In com-
parison, in this contribution we offer a much more detailed description of ECIES
(including a complete explanation of all the steps that must be performed in or-
der to carry out the encryption and decryption operations); a presentation of the
most important attacks against ECIES (which are necessary for understanding our
recommendations); a security analysis of the different functions and special op-
tions allowed in each standard; a recommended set of functions and parameters
based not only on their security, but also on their availability across the different
standards; the experimental results obtained with a Java implementation of the
version of ECIES which includes our proposed conﬁguration; and a comparison
with a similar scheme devised by us based on RSA and AES.
This paper is organized as follows: Section 2 presents a brief introduction to
Elliptic Curve Cryptography (ECC). Section 3 describes in detail ECIES and the
steps that must be performed during its encryption and decryption operation. Sec-
tion 4 enumerates the most important attacks on ECIES. In Section 5, we offer
a comparison of the ECIES allowed functions contained in the aforementioned
standards. Section 6 explains additional conﬁguration options for ECIES. Section
7 summarizes our proposed conﬁguration for the encryption scheme. Section 8
provides the results obtained with our Java implementation of ECIES and a com-
parison with a similar schemed based on RSA and AES designed by us. Finally,
Section 9 includes the conclusions about the feasibility of the ECIES version pro-
posed by us.
2 Elliptic Curve Cryptography
It is well known that Miller  and Koblitz  independently proposed a
cryptosystem based on elliptic curves, whose security relies on the Elliptic Curve
Discrete Logarithm Problem (ECDLP). This problem can be deﬁned as follows:
given an elliptic curve Edeﬁned over a ﬁnite ﬁeld Fqof qelements, a point G
on the curve E(Fq)of order n, and a point Pon the same curve, ﬁnd the integer
k∈[0, n −1] such that P=k·G.
So far, no algorithm is known that solves the ECDLP in an efﬁcient way, and
it is supposed that this problem is more difﬁcult to solve than other mathematical
problems used in Cryptography, such as the Integer Factorization Problem or the
Discrete Logarithm Problem . This characteristic makes ECC a particularly
well-suited option for devices with limited resources such as smart cards and some
mobile devices [18, 28, 53].
In order to clarify the notation, we will brieﬂy present some basic deﬁnitions
and properties of elliptic curves. An elliptic curve over a ﬁnite ﬁeld is deﬁned by
the following general Weierstrass equation :
E(Fq) : y2+a1x y +a3y=x3+a2x2+a4x+a6,(1)
where a1, a2, a3, a4, a6∈Fqand ∆6= 0,∆being the discriminant of the curve.
In practice, instead of the general Weierstrass equation, two short Weierstrass
forms that depend on the characteristic of the ﬁnite ﬁeld Fqare typically used:
If the ﬁnite ﬁeld has pelements, where p > 3is a prime number, then
Fq=Fp, and the equation (1) is reduced to
y2=x3+ax +b. (2)
If the ﬁnite ﬁeld has 2melements, then Fq=F2m, and the equation (1) can
be written as follows:
y2+xy =x3+ax2+b. (3)
The set of parameters to be used in any ECC implementation depends on the
underlying ﬁnite ﬁeld. When the ﬁeld is Fp, the set of parameters that deﬁne
the curve is P= (p, a, b, G, n, h), whereas if the ﬁnite ﬁeld is F2m, the set of
parameters is P= (m, f (x), a, b, G, n, h). The meaning of each element in both
sets is the following:
pis the prime number that characterizes the ﬁnite ﬁeld Fp.
mis the integer number specifying the ﬁnite ﬁeld F2m.
f(x)is the irreducible polynomial of degree mdeﬁning F2m.
aand bare the elements of the ﬁnite ﬁeld Fqtaking part in the equations (2)
Gis the point of the curve that will be used as a generator of the points that
belong to a cyclic subgroup of the curve.
nis the prime number whose value represents the order of the point G.
his the cofactor of the curve, computed as h= #E(Fq)/n, where #E(Fq)
is the number of points on the curve.
3 Elliptic Curve Integrated Encryption Scheme
3.1 The road to ECIES
The Discrete Logarithm Augmented Encryption Scheme (DLAES) was intro-
duced in , and it was later improved in  and , though by then it was
renamed as the Difﬁe-Hellman Integrated Encryption Scheme (DHIES) in order
to avoid misunderstandings with the Advanced Encryption Standard (AES) .
DHIES is an extended version of ElGamal encryption scheme, using elliptic
curves in an integrated scheme that includes public key operations, symmetric
encryption algorithms, Message Authentication Code (MAC) functions, and hash
computations. This integrated scheme is secure against chosen ciphertext attacks
without having to increase the number of elliptic curve operations (which are the
slowest operations involved) or the key length .
DHIES represents the kernel of ECIES, which is the generic term used to
deﬁne the best known encryption scheme using elliptic curves.
3.2 Functional components of ECIES
As its name properly indicates, ECIES is an integrated encryption scheme which
uses the following functions:
Key Agreement (KA): Function used by two parties for the creation of a
Key Derivation Function (KDF): Mechanism that produces a set of keys
from keying material and some optional parameters.
Hash: Digest function.
Encryption (ENC): Symmetric encryption algorithm.
Message Authentication Code (MAC): Information used to authenticate a
Figures 1 and 2 show graphic descriptions of the ECIES encryption and de-
cryption procedures, including the elements and functions involved in both pro-
Figure 1: ECIES encryption process.
In order to describe the steps that must be taken to encrypt a plaintext, we will
follow the tradition and will assume that Alice wants to send a message to Bob.
In that scenario, Alice’s ephemeral private and public keys will be represented as
Figure 2: ECIES decryption process.
uand U, respectively. Similarly, we will refer to Bob’s private and public keys as
vand V, respectively. The steps that Alice must complete in order to encrypt a
plaintext are the following:
1. Create a pair of ephemeral keys. The ephemeral private key is u, an integer
modulo nchosen at random, whilst the ephemeral public key is U=u·G.
2. Use the key agreement function, KA, in order to produce a shared secret
value. If the Difﬁe-Hellman (DH) primitive is used, the secret value is the
product of Alice’s ephemeral private key and Bob’s public key, u·V. Al-
ternatively, if the Difﬁe-Hellman with cofactor (DHC) is used , then
the secret value is computed as the product of the cofactor, the sender’s
ephemeral private key, and the receiver’s public key, h·u·V.
3. Take the shared secret value along with some optional parameters, identiﬁed
as Param #1, as input data for the key derivation function, denoted as KDF.
The output of this function is the concatenation of the MAC key, kM AC , and
the encryption key, kENC .
4. Encrypt the plaintext, m, using the ENC symmetric algorithm and the en-
cryption key, kENC . The ciphertext will be represented as c.
5. Use the selected MAC function, together with the encrypted message, the
MAC key, and some optional parameters, identiﬁed as Param #2, in order
to produce a tag.
6. Take the ephemeral public key, the encrypted message, and the tag, and send
the cryptogram consisting of those three elements to Bob. A simple method
for sending that information is concatenating the three elements, so in that
case the cryptogram would be represented as (U||tag||c), where || is the
concatenation operator. It is important to note that the cryptogram deﬁned
in this way is not the same as the ciphertext, as in addition to the encrypted
message, the cryptogram includes other two elements (the ephemeral public
key and the tag).
Regarding the decryption process, the steps that Bob must perform in order to
obtain the original message are the following:
1. Retrieve from the cryptogram the ephemeral public key U, the tag, and the
encrypted message c, so he can manage those elements separately.
2. Use the retrieved ephemeral public key, U, and his own private key, v, to
multiply both elements (optionally with the cofactor) in order to produce
the shared secret value, as u·V=u·v·G=v·u·G=v·U.
3. Produce the encryption and MAC keys by means of the KDF algorithm, the
shared secret value, and the same optional parameters that Alice used before
4. Compute the element tag* using the MAC key kM AC , the encrypted mes-
sage c, and the same optional parameters used by Alice (Param #2). After
that, Bob must compare the tag* value with the tag that he received as part
of the cryptogram. If the values are different, the receiver must reject the
cryptogram due to a failure in the MAC veriﬁcation procedure.
5. Decrypt the ciphertext cusing the symmetric ENC algorithm and kE N C . At
the end of the decryption process, Bob will be able to access the plaintext
that Alice intended to send him.
4 Known attacks against ECIES
Although ECIES is a relatively new encryption scheme, it has been reviewed ex-
tensively by the research community. This review process has exposed a number
of threats and attacks against ECIES, though fortunately those threats are either
not practical or can be disabled with a proper conﬁguration. The next subsections
describe the most important theoretical and practical attacks on ECIES.
4.1 Benign malleability
Shoup proved that, if the ephemeral public key Uis not included in the input
to the KDF function, and only the x-coordinate of the shared secret is used in
the KDF function, then ECIES is not secure against Adaptive Chosen Ciphertext
Attacks (CCA2), making the scheme malleable . More speciﬁcally, given
a cryptogram (U||c||tag), if the attacker replaces the elliptic curve point Uby
−U, then the KA function generates the shared secret −u·Vinstead of u·V.
But, taking into account that both points u·Vand −u·Vhave the same x-
coordinate, the input to the KDF function is the same in both cases, so from a valid
cryptogram (U||c||tag), the attacker is able to construct another valid cryptogram
In case of using the DHC primitive as the KA function, Shoup proved that it
is also possible to create an attack making the scheme malleable . To prevent
this attack, an element whose order divides the cofactor hcan be added to the
elliptic curve point U. Another option to avoid this problem consists in using the
DH primitive instead of the DHC version , as the DH primitive is allowed in
the four standards analysed (see §5.1) and the cofactor variant can lead to interop-
erability problems [10, 59].
Shoup deﬁned these type of problem as benign malleability, as so far no attack
has been able to obtain relevant information using this threat. However, from
a formal point of view, it is important to avoid these type of vulnerabilities (as
Shoup stated in , “for public-key encryption schemes, it is widely agreed that
the right notion of security for a scheme intended for general-purpose use is that
of security against adaptive chosen ciphertext attack. This notion was introduced
in , and implies other useful properties, like non-malleability”).
4.2 Malleability when using the XOR function
Shoup also proved in  that the ECIES scheme could be malleable, but now
in a malign way, when the XOR function is used in order to encrypt messages of
variable length, which could give way to attacks of type CCA2. Some solutions
to this problem are described below:
1. Establish a ﬁxed length for all the plaintexts .
2. Fix the interpretation of the MAC and ENC keys obtained from the keying
material which is the output of the KDF function, so those keys are always
interpreted as kM AC ||kEN C , as is suggested in , , and .
3. Forbid the usage of stream ciphers in ECIES, allowing only block ciphers,
as recommended in  and .
As the main use case for ECIES consists in the encryption of text messages or
binary ﬁles of arbitrary size, and in some cases the XOR key size could be really
big, from a practical point of view it is recommended to use block ciphers.
Regarding the second solution proposed, as it is mentioned in §6.3, the inter-
pretation kM AC ||kEN C is only allowed in IEEE 1363a, so we should discard this
option if the goal is to develop a version of ECIES compatible with more than one
Taking into account the previously stated considerations, we fully support the
recommendation of not using XOR as an encryption algorithm in this encryption
4.3 Small subgroup attacks
This type of attack is possible when an opponent deliberately provides an invalid
public key, where in this context a valid public key is an elliptic curve point which
belongs to the elliptic curve selected by the users and that presents the arithmetic
properties described in . If the sender does not check whether the other party’s
public key is valid, an opponent would be able to provide as the public key an
element of small order, with the goal to limit the range for the shared secret value
or to obtain information about the sender’s private key. The options available for
the deactivation of this kind of attack are:
1. Use the DH primitive and check carefully the validity of the parameters and
of the public key provided by the receiver (e.g., check that the order of the
public key Vis n) .
2. Use the DHC primitive. If the public key Vbelongs to a small subgroup,
then the element h·u·Vwill be equal to the point at inﬁnity O, a well
known point for any curve [57, 59].
3. Replace the shared secret by the hash code of the secret value as the input
to the KDF function .
In a typical scenario, the validity check on the public key Vwould be per-
formed by the trusted third party issuing certiﬁcates, so this validity checking
should not impact on the performance of ECIES.
Regarding the option of using the DHC primitive, as it was explained in §4.1,
it faces the theoretical threat of a malleability attack, that being one of the reasons
why most test vectors included in the standards do not use the DHC primitive
The usage of the hashed output is mentioned in IEEE 1363a, and thus it has
been implemented in Java Card since its version 2.2 . However, this feature is
used in the test vectors of neither ISO/IEC 18033-2  nor SECG GEC 2 ,
and Java Card 3.0 has added another operation mode in which the output of the
KA function is not hashed .
From the three possible solutions, we have selected the ﬁrst one for our pro-
posal, as the second option is regarded as not fully interoperable [10, 59], and the
third possibility is mentioned in only one standard. Besides, if the ephemeral key
pair is generated randomly and is used only once, then no practical information
that could be used in new encryption processes would be obtained by an attacker
using this method.
5 Allowed functions in standard ECIES
Given the number of functions and options involved, the major problem when
using ECIES is to determine the proper combination of functions and parameters
to use. In the following sections we will present the allowed functions included
in the different versions of ECIES, together with the recommendations that we
propose based on security and performance criteria.
5.1 Key Agreement function (KA)
The Key Agreement function produces a secret value that can only be obtained by
both sender and receiver. The two KA functions used in ECIES are DH and DHC,
which were described in §3.2.
Both DH and DHC are allowed in the four standards analysed. In devices with
limited resources, the DH primitive may be slightly faster as it implies only one
scalar multiplication. Besides, another reason for using DH instead of DHC is
mentioned in §4.1. Given both reasons, we propose using DH as the KA function.
5.2 Hash function (HASH)
Hash functions take as input a binary string of variable length and produce as a
result a binary string of ﬁxed length corresponding to the initial data. In the scope
of ECIES, hash functions are used by other primitives (e.g. KDF or MAC). The
hash functions mentioned in the standards where ECIES is included are SHA-
1, SHA-224, SHA-256, SHA-384, SHA-512 , RIPEMD-128, RIPEMD-160
, and WHIRLPOOL . Table 1 presents the hash functions used in each
ANSI X9.63 IEEE 1363a ISO/IEC 18033-2 SECG SEC 1
SHA-1 SHA-1 SHA-1 SHA-1
SHA-224 SHA-256 SHA-256 SHA-224
SHA-256 SHA-384 SHA-384 SHA-256
SHA-384 SHA-512 SHA-512 SHA-384
SHA-512 RIPEMD-160 RIPEMD-128 SHA-512
Table 1: Hash functions.
During the past years, several attacks on MD5, SHA-0, SHA-1, SHA-2 have
been published [5, 9, 15, 29, 54, 62–64]. Due to these attacks, NIST held a work-
shop to consider the status of hash functions at the end of 2005. The conclusions
of the workshop were ﬁrst to initiate a rapid transition to the SHA-2 family of
hash functions (NIST considers that the SHA-2 functions are much stronger than
SHA-1, and that practical attacks are unlikely to appear at least during the next
few years ), and second to set up a hash function competition, similar to the
AES development and selection process, in order to select the new SHA-3 algo-
rithm. On October 2012 NIST announced Keccak as the new SHA-3 hash algo-
rithm . As the decision on SHA-3 is very recent, so far none of the standards
where ECIES is described has updated their speciﬁcations in order to include the
Taking into account the level of scrutiny performed by the expert community,
from a security point of view we suggest to use one of the algorithms of the SHA-
2 family. If memory and bandwidth limitations are critical requirements in the
deployment scenario (e.g. smart cards), then we recommend using SHA-256.
In contrast, if memory and bandwidth are not critical elements, then we suggest
using SHA-512. Another argument in favour of selecting SHA-512 over SHA-
256 is its better performance on 64-bit architectures , which are the current
trend in laptop and desktop computers.
5.3 Key Derivation Function (KDF)
Key Derivation Functions (KDF) are used to generate keying material from a
shared secret and additionally from other optional elements. The key derivation
functions allowed by the different versions of ECIES are ANSI-X9.63-KDF ,
NIST-800-56-Concatenation-KDF , KDF1, and KDF2 . The KDF func-
tions considered in each standard version of ECIES are presented in Table 2.
ANSI X9.63 IEEE 1363a ISO/IEC 18033-2 SECG SEC 1
X9.63-KDF X9.63-KDF KDF1 X9.63-KDF
Table 2: KDF functions.
In order to perform the comparison, it must be taken into account that, if the
parameter SharedInfo is not used in X.63-KDF, then this function is equivalent to
So far, no speciﬁc threats have been discovered against the previously men-
tioned KDF functions, so theoretically any of them could be used in a secure
implementation of ECIES. Given that the KDF2 algorithm (or, equivalently, X.63-
KDF without SharedInfo) is allowed by all the standards, we recommend to use it
as the KDF algorithm.
5.4 MAC code generation function (MAC)
MAC functions take as input a binary string and produce as output another bi-
nary string (known as the tag) related to the input and to certain optional pa-
rameters. A speciﬁc type of MAC function is the HMAC group of functions
that use a hash primitive as part of the computations. The MAC functions al-
lowed in the standards where ECIES is included are HMAC-SHA-1, HMAC-
SHA-224, HMAC-SHA-256, HMAC-SHA-384, HMAC-SHA-512 , HMAC-
RIPEMD-128, HMAC-RIPEMD-160 , CMAC-AES-128, CMAC-AES-192,
and CMAC-AES-256 . Table 3 shows the allowed MAC functions in the four
standards, where for presentation reasons the word HMAC has been abbreviated
to simply H.
ANSI X9.63 IEEE 1363a ISO/IEC 18033-2 SECG SEC 1
H-SHA-1 H-SHA-1 H-SHA-1 H-SHA-1
H-SHA-224 H-SHA-256 H-SHA-256 H-SHA-224
H-SHA-256 H-SHA-384 H-SHA-384 H-SHA-256
H-SHA-384 H-SHA-512 H-SHA-512 H-SHA-384
H-SHA-512 H-RIPEMD-160 H-RIPEMD-128 H-SHA-512
Table 3: MAC functions.
In the case of using one of the SHA-2 functions as the hashing algorithm, we
recommend using one of MAC functions belonging to the HMAC-SHA-2 family.
If the deployment scenario has memory and bandwidth limitations, we propose
using HMAC-SHA-256, in line with what was stated in §5.2. Otherwise, our
suggestion would be to use HMAC-SHA-512.
5.5 Symmetric encryption function (ENC)
Symmetric encryption functions use a secret key in order to encrypt the input in-
formation. The symmetric algorithms included in the different versions of ECIES
are XOR, Triple DES , AES-128, AES-192, AES-256 , MISTY1 ,
CAST-128 , Camellia , and SEED . The symmetric ciphers considered
in the standards that include ECIES are shown in Table 4, where the related op-
eration modes are CBC (Chain Block Mode) and CTR (Counter), and the term
PKCS5 refers to the PKCS #5 padding mechanism.
As it is well known, the AES speciﬁcation comprises three block ciphers,
AES-128, AES-192, and AES-256, adopted from a larger collection originally
ANSI X9.63 IEEE 1363a ISO/IEC 18033-2 SECG SEC 1
XOR XOR XOR XOR
AES/CBC/PKCS5 TDES/CBC/PKCS5 AES/CBC
Table 4: Symmetric encryption functions.
published as Rijndael. Each of these ciphers has a 128-bit block size, with key
sizes of 128, 192, and 256 bits, respectively. Given the latest attacks on AES
[8, 11], it is commonly agreed that, until new attacks are published, AES-128 is
relatively more secure than AES-192 and AES-256 .
Regarding the mode of operation, even though CTR offers some advantages
(it does not require padding, its implementation is more efﬁcient, etc.) , as it
is only considered a valid operation mode in SECG SEC 1, in order to make the
ECIES implementation compatible with at least two standards, the AES operation
mode that should be implemented is CBC with PKCS #5 padding.
5.6 Summary of functions allowed in all the standards
As a summary of the information that has been previously presented, Table 5
includes all the cryptographic functions and algorithms allowed simultaneously
in the four standard versions of ECIES cited along this document.
KA HASH KDF ENC MAC
DH SHA-1 KDF2 XOR HMAC-SHA-1
DHC SHA-256 HMAC-SHA-256
Table 5: Common functions allowed in the standards.
Even though there are several combinations compatible with the four stan-
dards (e.g. DH, SHA-1, KDF2, XOR, and HMAC-SHA-1), all of them have in
common the same encryption algorithm, which is the XOR function. As it is
stated in §4.2, using the XOR function for encrypting messages of variable length
weakens the security of ECIES and makes the scheme less practical compared to
the case of using a block cipher with ﬁxed key lengths, so we consider that in this
particular case it is better to sacriﬁce full interoperability in favour of security and
For that reason, our recommendation is to use the following set of functions in
order to obtain a secure version of ECIES: DH, SHA-512, KDF2, HMAC-SHA-
512, and AES-128 in CBC mode with PKCS #5 padding.
6 Additional options
After reviewing the currently known attacks against ECIES and their countermea-
sures in §4, and addressing the topic of which are the most convenient functions
and algorithms in §5, this section focuses on the additional implementation deci-
sions that must be considered in order to develop a secure and efﬁcient implemen-
tation of ECIES.
6.1 Point compression usage
Point compression is a technique used when converting an elliptic curve point into
a byte string in which it is decided to include in the binary representation either
the ﬁrst coordinate of the point or both coordinates, in both cases together with
one byte that identiﬁes the format that has been selected. The point compression
formats that can be used by developers, and that are deﬁned in the four standards
analysed, are the following:
1. Uncompressed: Both coordinates are taken into account. A header byte
0x04 is used to indicate that this is the format in use, so the byte string cor-
responding to the elliptic curve point P= (xP, yP)would be 04||XP||YP,
where XPand YPare the binary representations as integers of the afﬁne
coordinates xPand yP.
2. Compressed: Only the ﬁrst coordinate is used, which is signalled by using
the header byte 0x02 or 0x03. The exact value of the header is decided based
on some computations performed involving both coordinates, which allows
the receiver to accurately generate the second coordinate, so for any elliptic
curve point only one compressed binary representation, either 02||XPor
03||XP, is valid.
From a security standpoint, there is no difference in transmitting to the other
party as part of the cryptogram the ephemeral public key Uin either compressed
or uncompressed form [51, 60]. However, even though Miller suggested com-
pressing a public key to simply its ﬁrst coordinate , there are several patents
over this topic [17, 56, 61], so in order not to infringe any of those patents we
recommend not to use point compression.
6.2 KDF input data
Independently of which of the KA functions is used (DH or DHC), developers
face a variety of options regarding the information that will be taken as input in
the KDF function. The elements that can be used to construct the input are the
1. The point obtained as the output of the KA function (i.e., P=u·Vor
P′=h·u·V), or just the ﬁrst coordinate of that point (i.e., xPor xP′).
2. The hash output of the elements previously mentioned (i.e., P,P′,xPor
3. The point that represents the ephemeral public key U, either compressed or
4. Additional parameters.
Table 6 shows the options allowed in each standard, where xPis the ﬁrst co-
ordinate of P=u·V,xUis the ﬁrst coordinate of U, and P#1 represents the
optional parameters identiﬁed as Param #1 in §3.2. The concatenation of binary
strings is represented with the usual symbol, ||, whilst the fact that two parameters
are used as input (but not in a concatenated form) is displayed using a comma.
For the sake of clarity we have presented only the options related to xP, though
all the options are also available when using xP′instead of xP.
With regards to the implications of using the whole point representing the
shared secret or only the ﬁrst coordinate as input to the KDF function (not to be
confused with the discussion in §6.1 about the format of the ephemeral public key
Uincluded in the cryptogram), some authors, such as Stern , state that from
ANSI X9.63 IEEE 1363a ISO/IEC 18033-2 SECG SEC 1
xP, P #1 xP, P #1 U||xPxP, P #1
U||xP, P #1
xU||xP, P #1
Table 6: KDF input data options.
a security point of view there is no difference in using any of the two options.
After reviewing the standards that include ECIES, most of them take only the ﬁrst
coordinate of the shared secret as input to the KDF function, so this seems to
be the commonly accepted solution in practice in order to produce more efﬁcient
Concerning the option of including the ephemeral public key of the sender as
an input to the KDF function, as it has been mentioned in §4.1, using the public
key Ucan help to prevent benign malleability, so we propose to use U||xPas
input to the KDF function in the ECIES implementation. We are aware that this
decision affects to the interoperability of ECIES, as it is only valid in IEEE 1363a
and ISO/IEC 18033-2, but we think that, in this particular case, security is more
important than interoperability.
Another alternative which preserves the security of ECIES is using xPas the
ﬁrst input parameter and Uas the second parameter, though not concatenated, so
in this case the implementation would be compatible with the format xP, P #1
allowed in IEEE 1363a and SECG SEC 1. The security level obtained with both
options is the same; the difference is the list of standards the ECIES implementa-
tion would be compatible with.
6.3 Keying material interpretation
Before obtaining the MAC and ENC keys from the output of the KDF function,
users must decide which is the interpretation order of that output. The two options
1. First, the MAC key; then, the ENC key (kMAC ||kE NC ).
2. First, the ENC key; then, the MAC key (kENC ||kM AC ).
All the analysed standards allow the kE N C ||kMAC interpretation when using
a block cipher as the symmetric encryption algorithm. Only IEEE 1363a permits
using the kM AC ||kENC interpretation, and strictly under speciﬁc circumstances
(stream cipher, etc.). Based on that, kEN C ||kM AC is the option that must be chosen
for any practical ECIES implementation.
6.4 MAC input data
The four standards allow using as input to the MAC function either the encrypted
message or the encrypted message concatenated with the optional parameters
identiﬁed as Param #2 in §3.2.
From a security standpoint, ECIES is slightly strengthened if sender and re-
ceiver share the content of this parameter, even if it is just a short passphrase not
strong enough to constitute a secure secret key (e.g. 1234). However, it must be
taken into account that this feature may not always be possible to use, for example
when sending a message to a user with whom no prior contact has been made, so
we think that using this option cannot be enforced as a general rule.
6.5 Dynamic selection of parameters and functions
Even though some authors consider it to be of the essence for the security of
ECIES to use the same set of parameters and the same KA, KDF, ENC, and MAC
functions during the whole life cycle of a speciﬁc key pair , and in IEEE
1363a this procedure is recommended, in practice there is no consensus among
the experts about the risk that a change of parameters and functions would imply
However, as the requirement made in  does not seem to have negative im-
plications, we adhere to the recommendation of changing neither the parameters
nor the functions during the life cycle of a given key pair.
6.6 Elliptic curve generation procedure
When working with elliptic curve protocols, an important topic is the selection
of the speciﬁc curve to use. Even though elliptic curve generation procedures
are deﬁned in standards from ANSI, IEEE, and ISO/IEC, it is usually the case
that the elliptic curve parameters are offered to the reader without a complete and
veriﬁable generation process. Some of the most important limitations detected
across the main cryptographic standards regarding this issue are the following
The seeds used to generate the curve parameters are typically chosen ad
The primes that deﬁne the underlying prime ﬁelds have a special form aimed
to facilitate efﬁcient implementations.
The parameters speciﬁed do not cover key lengths adapted to the security
levels required nowadays.
In this scenario, a European consortium of companies and government agen-
cies led by the Bundesamt für Sicherheit in der Informationstechnik (BSI) was
formed in order to study the aforementioned limitations and produce their recom-
mendations for a well deﬁned elliptic curve generation procedure. The group was
named ECC Brainpool (henceforth simply Brainpool), and in 2005 it delivered the
ﬁrst version of a document entitled “ECC Brainpool standard curves and curve
generation” , which was revised and published as a Request for Comments
(RFC) memorandum in 2010, the “Elliptic Curve Cryptography (ECC) Brainpool
standard curves and curve generation” .
The Brainpool speciﬁcation includes the steps that must be performed in order
to generate elliptic curves suitable for cryptographic purposes, and it also presents
the functional and security requirements that must be taken into account when
generating computationally efﬁcient and secure elliptic curves.
Given that the Brainpool procedure is the most complete and publicly available
procedure for generating elliptic curves, offering a range of key lengths for all
possible security needs (from 160 to 512 bits), we suggest using elliptic curves
generated by the Brainpool procedure.
Even though the Brainpool curves are different from the curves deﬁned in
other standards, selecting a working elliptic curve is independent of the encryp-
tion process itself, so it does not affect the interoperability of the ECIES imple-
mentation; it only affect its operation by the users.
7 ECIES conﬁguration
Based on the comments and recommendations included in the previous sections,
we summarize below the list of parameters, algorithms, and additional character-
istics that allow implementing an efﬁcient and secure version of ECIES, which is
compliant with the version described in the standards IEEE 1363a and ISO/IEC
KA: the DH function.
ENC: AES-128 in CBC mode with PKCS #5 padding.
Shared secret: use only the ﬁrst coordinate (without hash).
Input to the KDF function: ephemeral public key Uconcatenated to xP.
KDF output interpretation: kEN C ||kM AC .
Binary representation of Uas part of the cryptogram: uncompressed.
Selection of parameters and functions: static (for a given public key).
8 Experimental results
After proposing a conﬁguration for ECIES, the next step consisted in conducting
some tests in order to check the practicality and performance of the proposed so-
lution. The software that was employed in the tests was developed by the authors
as a Java application  that can be used to test different parameter combinations
for ECIES . Figure 3 displays part of its Conﬁguration panel, where all the
options can be selected.
The elliptic curves used in the tests belong to the group of curves published
by Brainpool [12, 13, 21]. As for the speciﬁc curves employed in the tests, a
representative of each available key length has been selected (160, 192, 224, 256,
320, 384, and 512 bits).
The tests whose results are presented in this section were completed using a
PC with Windows 7 Professional OS and an Intel Core i7 processor at 3.40 GHz.
The Java software used for compiling and executing the application is Java Devel-
opment Kit (JDK) 1.6 update 27 , with default parameters both for compiling
and running the application.
Figure 3: Java implementation of ECIES.
8.1 Message expansion factor
This section presents the message expansion factor (i.e., the ratio measured as
the quotient of the cryptogram length and the clear message length) when using
elliptic curves for the encryption of different messages.
Due to the nature of ECIES, the expansion in the cryptogram length (i.e., the
difference between the length of the cryptogram and the length of the original
message) depends on the following factors:
1. The ﬁnite ﬁeld and associated ﬁeld element representation.
2. The binary representation of the sender’s ephemeral public key (either com-
pressed or uncompressed).
3. The speciﬁc encryption function and the mode used.
4. The length of the MAC code.
Given that the message length in bytes used in the different tests of this section
is, in all the test cases, a multiple of 16 (which produces an additional block of
16 bytes when encrypting the original message with the AES algorithm in CBC
mode with PKCS #5 padding), the MAC code length is 64, and the elliptic curve
point representation is uncompressed, then the message expansion factor δis, for
any curve deﬁned over Fp, given by the expression
δ= 1 + 2 ·llog2p
8m+ 16 + 64 = 2 ·llog2p
where ⌈n⌉represents the ceiling function applied to the real number n. The deci-
sion of using messages whose length is a multiple of 16 has been taken in order
to present the worst-case scenario in terms of expansion (if the message length is
not a multiple of 16, then the amount of bytes that are needed for padding will be
less than 16, and the expansion will also be smaller).
Table 7 shows the cryptogram length for different plaintext sizes (16, 32, 64,
128, 256, 512, and 1024 bytes) when using the Brainpool curves of 160, 192, 224,
256, 320, 384, and 512 bits. Besides, Table 8 and presents the ratio computed
with those input values.
Key length (bytes)
160 192 224 256 320 384 512
16 137 145 153 161 177 193 225
32 153 161 169 177 193 209 241
64 185 193 201 209 225 241 273
128 249 257 265 273 289 305 337
256 377 385 393 401 417 433 465
512 633 641 649 657 673 689 721
1024 1145 1153 1161 1169 1185 1201 1233
Table 7: Cryptogram length in bytes.
As it can be observed in Figure 4, which displays the data offered in Table 8,
the overload added by the encryption process, compared to the size of the cipher-
text produced by a symmetric cipher such as AES, is irrelevant when encrypting
more than 1 KByte of information. However, when encrypting a short message
of less than 1 KByte, particularly when the data length is less than 64 bytes, the
ratio is very high. This implies that integrated encryption schemes as ECIES are
specially suited for the encryption of medium to large messages.
Key length (bytes)
160 192 224 256 320 384 512
16 8.56 9.06 9.56 10.06 11.06 12.06 14.06
32 4.78 5.03 5.28 5.53 6.03 6.53 7.53
64 2.89 3.02 3.14 3.27 3.52 3.77 4.27
128 1.95 2.01 2.07 2.13 2.26 2.38 2.63
256 1.47 1.5 1.54 1.57 1.63 1.69 1.82
512 1.24 1.25 1.27 1.28 1.31 1.35 1.41
1024 1.12 1.13 1.13 1.14 1.16 1.17 1.2
Table 8: Message expansion factor.
Figure 4: Message expansion factor for different elliptic curves and plaintexts.
8.2 Execution time
The details of the procedure used for obtaining the timing results of the encryption
process in our PC implementation are the following:
1. For each encryption process, the same original message consisting of 1024
bytes has been used. For each decryption process, the output of the encryp-
tion procedure with each curve has been used as input.
2. The time displayed for each curve represents the average time of 10 different
3. The Java function used for obtaining the timing is System.nanoTime()
4. In the encryption procedure, the start time has been taken exactly before
the random generation of the ephemeral key U, after all the parameters and
variables are loaded in memory. In comparison, the start time in the decryp-
tion procedure has been taken exactly before the v·Umultiplication, as in
that process there is no ephemeral key pair generation.
5. The ﬁnish time for each encryption procedure has been obtained just after
the cryptogram is stored in memory as a hexadecimal string, and before
any data is printed on screen (in order to avoid the delays produced when
presenting the results in the graphic interface). Similarly, the ﬁnish time for
each decryption procedure has been obtained after the recovered plaintext
is stored in memory as a hexadecimal string.
Table 9 shows the average execution time for the Brainpool curves when en-
crypting and decrypting the same plaintext of 1024 bytes. As expected, the ex-
ecution time is not linear, as ECC computations are more demanding as the key
length is increased. In order to illustrate this comment, Figure 5 depicts the aver-
age encryption time (we have not included the decryption time in the ﬁgure as it is
very similar to the encryption time and both charts would appear superimposed).
As observed in Table 9, the encryption and decryption time is practically the
same. The reason for this behaviour is that both processes perform the same
operations but for the ephemeral key generation, which is only performed in the
encryption phase. The running time of the ephemeral key generation is negligible
compared to the total execution time, so it is not a differentiation factor.
Key length (bytes)
160 192 224 256 320 384 512
Encryption (ms) 7.59 10.33 13.91 17.14 26.90 40.95 81.70
Decryption (ms) 7.36 10.47 13.31 17.27 28.21 39.75 82.84
Table 9: Encryption and decryption time in milliseconds with ECIES.
Figure 5: Encryption time for different elliptic curves.
8.3 Comparison with RSA
With the goal of completing a fair evaluation of the capabilities of ECIES, we have
implemented in Java a hybrid encryption scheme based on RSA and AES compa-
rable in its design to ECIES, so we could evaluate the cryptogram length and the
execution time in both cases. Our RSA-AES scheme performs the following steps
during the encryption phase:
1. It generates a random AES key of 16 bytes.
2. It encrypts a 1024-byte plaintext using AES-128 in CBC mode with PKCS
3. It encrypts the AES secret key using the receiver’s RSA public key.
4. It computes an RSA signature using the hash function SHA-512 and the
sender’s private key, taking as input both the plaintext and the encrypted
secret key. That signature acts as the MAC code employed in ECIES.
5. It outputs the cryptogram as the concatenation of the three previous ele-
ments: the data encrypted with the secret key, the encrypted secret key, and
In the decryption phase, our RSA-AES scheme completes the following steps:
1. It obtains the AES key using the receiver’s RSA private key.
2. It retrieves the 1024-byte plaintext using AES-128 in CBC mode with PKCS
3. It validates the digital signature using the sender’s RSA public key.
In all the RSA-AES tests we have encrypted the same plaintext of 1024 bytes
used in some of the ECIES tests. The RSA key lengths managed are associated
to ECC key lengths of similar cryptographic strength, where in this context the
cryptographic strength must be interpreted as the security offered by a symmetric
encryption algorithm with keys of nbits . Table 10 includes the ECIES and
RSA key lengths used in this comparison.
Table 11 shows the cryptogram length in bytes of ECIES and our RSA-AES
scheme. The cryptogram length in the RSA-AES implementation can be com-
puted as 1040 +2 ·klen, where klen represents the RSA key length. The symmetric
Security level ECIES key length RSA key length
80 160 1024
112 224 2048
128 256 3072
192 384 7680
256 512 15360
Table 10: ECIES and RSA comparable key lengths in bits (source: ).
encryption of 1024 bytes using AES in CBC mode with PKCS #5 padding pro-
duces an output of 1040 bytes, and the RSA encryption of the symmetric key and
the RSA signature generate two blocks of the same size as the RSA key length
used in each test. Given the data of Table 11, it can be observed that ECIES gen-
erates shorter cryptograms in all the instances, which is important when transmit-
ting data through networks with small bandwidth or when the device producing
the encrypted data has a limited communication channel (e.g. smart cards).
Security level ECIES RSA
80 1145 1296
112 1161 1552
128 1169 1808
192 1201 2960
256 1233 4880
Table 11: Cryptogram length in bytes with ECIES and RSA-AES.
Table 12 shows the encryption and decryption time in milliseconds of ECIES
and our RSA-AES version. Even though for smaller security levels the scheme
based on RSA and AES is faster than ECIES, for a security level of 128 bits the
execution time is similar, and for the highest security levels ECIES is clearly faster
than the RSA-AES scheme.
Figure 6 shows graphically the comparison between ECIES and RSA-AES re-
garding the encryption time (the decryption time is not included in the ﬁgure as
it is very similar to the encryption time, making both charts to appear superim-
Security level ECIES RSA-AES ECIES RSA-AES
80 7.41 1.81 7.36 1.81
112 13.73 6.42 13.31 6.53
128 16.96 18.88 17.27 19.01
192 40.77 240.55 39.75 239.76
256 81.52 1827.05 82.84 1834.13
Table 12: Execution time in milliseconds with ECIES and RSA-AES.
Figure 6: Encryption time comparison between ECIES and RSA-AES.
With all the previous data, it can be stated that ECIES is a valid alternative to
RSA-AES as a hybrid encryption scheme, which combines the ease of key distri-
bution associated to asymmetric cryptography and the good performance related
to symmetric cryptography.
ECIES is the best known encryption scheme using elliptic curves, and as such
it has been included in several standards. However, those standards offer a lot
of options, which vary in the available functions and the speciﬁc settings of the
scheme. This makes the selection of the proper conﬁguration for a speciﬁc de-
ployment scenario a difﬁcult task.
Moreover, the number of options and the existence of internal dependencies in
each standard provide as a consequence that, if the goal is to develop a practical
and secure implementation of ECIES, there is no common set of functions and
settings interoperable with the four standards analysed. We have shown with this
contribution that, if a developer tries to implement the countermeasures for all the
publicly known attacks on ECIES, the resulting version is interoperable only with
two standards, IEEE 1363a and ISO/IEC 18033-2 or, alternatively, IEEE 1363a
and SECG SEC 1, depending on one of the implementation decisions (see §6.2).
Taking into account all the security and efﬁciency considerations described
along this contribution, we have selected a combination of algorithms and func-
tionality options that create a secure implementation of ECIES. Then, we have
tested the version of ECIES thus designed using a Java application. This appli-
cation has allowed us to check the feasibility of our version of ECIES, as we
were able to develop it using a popular programming language such as Java. The
ECIES implementation has permitted us to compare the performance of the en-
cryption process using different key lengths, which can be used to determine if the
encryption scheme is adequate for key lengths related to high security levels. In
order to provide a complete evaluation of ECIES, we have also developed in Java
a comparable hybrid encryption scheme based on RSA and AES.
After conducting those tests it can be stated that, in absolute terms, the ex-
pansion added by the encryption process is not relevant when encrypting more
than 1 KByte of information, which implies that ECIES is optimized (regarding
bandwidth) for the encryption of medium to large messages. Encryption of small
messages is also possible, but in that case the expansion produced by ECIES re-
duces its usefulness. When comparing the expansion factor of ECIES to that of
our RSA-AES design, it is clear that ECIES generates smaller cryptograms.
With regards to the execution time of our Java implementation of ECIES, it
shows almost a linear behaviour for small key lengths. As it was expected, elliptic
curves with key lengths bigger than 256 bits present a slower performance, making
the computation with those curves less efﬁcient with today’s technology. If we
compare the results with the running time of our RSA-AES scheme, it can be
afﬁrmed that RSA-AES is faster for lower to medium security levels (i.e., smaller
key lengths), but slower than ECIES for medium to higher security levels, which
are the ones that will be used as time passes and new cryptographic attacks appear
for both ECIES and RSA.
With all the gathered information we are in a position to conclude that, in its
design as a hybrid encryption scheme, ECIES is a good alternative to RSA-AES
for encrypting data that must be send through insecure communication networks.
This work has been partially supported by Ministerio de Ciencia e Innovación
(Spain) under the grant TIN2011-22668, and by Comunidad de Madrid (Spain)
under the project S2013/ICE-3095-CIBERDINE-CM.
 Abdalla, M., M. Bellare, and P. Rogaway (1998). DHIES: An Encryption
Scheme Based on the Difﬁe-Hellman Problem. Contribution to IEEE P1363a.
 Abdalla, M., M. Bellare, and P. Rogaway (2001). The Oracle Difﬁe-Hellman
Assumptions and an Analysis of DHIES. Lecture Notes in Computer Sci-
ence 2020, 143–158.
 Adams, C. (1997). The CAST-128 Encryption Algorithm. Internet Engineer-
ing Task Force, RFC 2144. http://www.ietf.org/rfc/rfc2144.
 American National Standards Institute (2001). Public Key Cryptography for
the Financial Services Industry: Key Agreement and Key Transport Using El-
liptic Curve Cryptography. ANSI X9.63.
 Aoki, K., J. Guo, K. Matusiewicz, Y. Sasaki, and L. Wang (2009). Preimages
for step-reduced SHA-2. Lecture Notes in Computer Science 5912, 578–597.
 Aoki, K., T. Ichikawa, M. Kanda, M. Matsui, S. Moriai, J. Nakajima, and
T. Tokita (2001). Camellia: A 128-bit Block Cipher Suitable for Multiple
Platforms - Design and Analysis. Lecture Notes in Computer Science 2012,
 Bellare, M. and P. Rogaway (1997). Minimizing the Use of Random Ora-
cles in Authenticated Encryption Schemes. Lecture Notes in Computer Sci-
ence 1334, 1–16.
 Biryukov, A. and D. Khovratovich (2009). Related-key Cryptanalysis of the
Full AES-192 and AES-256. Cryptology ePrint Archive, Report 2009/317.
 Biryukov, A., M. Lamberger, F. Mendel, and I. Nikolic (2011). Second-order
differential collisions for reduced SHA-256. Lecture Notes in Computer Sci-
ence 7073, 270–287.
 Blake, I. F., G. Seroussi, and N. P. Smart (2004). Advances in Elliptic Curve
Cryptography. Cambridge, UK: Cambridge University Press.
 Bogdanov, A., D. Khovratovich, and C. Rechberger (2011). Biclique Cryp-
toanalysis of the Full AES. Cryptology ePrint Archive, Report 2011/449.
 Brainpool (2005). ECC Brainpool Standard Curves and Curve
 Brainpool (2010). Elliptic Curve Cryptography (ECC) Brainpool Standard
Curves and Curve Generation. IETF RFC 5639. http://tools.ietf.
 Bundesamt für Sicherheit in der Informationstechnik (2009). Elliptic Curve
Cryptography. BSI TR 03111. http://www.bsi.de/literat/tr/
 Cannière, C. D., F. Mendel, and C. Rechberger (2007). Collisions for 70-
step SHA-1: On the Full Cost of Collision Search. Lecture Notes in Computer
Science 4876, 56–73.
 Dobbertin, H., A. Bosselaers, and B. Preneel (1996). RIPEMD-160: A
Strengthened Version of RIPEMD. Lecture Notes in Computer Science 1039,
 Dworkin, J. D., M. J. Torla, P. M. Glaser, A. Vadekar, R. J. Lambert, and
S. A. Vanstone (2001). Circuit and Method for Decompressing Compressed
Elliptic Curve Points. US Patent 6,199,086.
 Elo, T. (2000). Lessons Learned on Implementing ECDSA on a Java Smart
Card. In Proceedings of NordSec2000. Reykjavik, Iceland.
 Gayoso Martínez, V., F. Hernández Álvarez, L. Hernández Encinas, and
C. Sánchez Ávila (2010). A comparison of the standardized versions of ECIES.
In Sixth International Conference on Information Assurance and Security (IAS
2010), pp. 1–4.
 Gayoso Martínez, V., F. Hernández Álvarez, L. Hernández Encinas, and
C. Sánchez Ávila (2011). Analysis of ECIES and other cryptosystems based
on elliptic curves. International Journal of Information Assurance and Secu-
rity 6(4), 285–293.
 Gayoso Martínez, V. and L. Hernández Encinas (2013). Implementing the
ECC Brainpool curve generation procedure using open source software. In
WorldComp 2013 - International Conference on Security & Management -
SAM’13, pp. 162–197. Las Vegas, USA.
 Gayoso Martínez, V., L. Hernández Encinas, and C. Sánchez Ávila (2010).
A Java Implementation of the Elliptic Curve Integrated Encryption Scheme.
In WorldComp 2010 - International Conference on Security & Management -
SAM’10, Volume II, pp. 495–501. Las Vegas, USA.
 Gueron, S., S. Johnson, and J. Walker (2010). SHA-512/256. Cryptology
ePrint Archive, report 2010/548. http://eprint.iacr.org/2010/
 Hankerson, D., A. J. Menezes, and S. Vanstone (2004). Guide to Elliptic
Curve Cryptography. New York, NY, USA: Springer-Verlag.
 Institute of Electrical and Electronics Engineers (2004). Standard Speciﬁ-
cations for Public Key Cryptography - Amendment 1: Additional Techniques.
 International Organization for Standardization / International Electrotech-
nical Commission (2004). Information Technology – Security Techniques –
Hash-functions – Part 3: Dedicated Hash-functions. ISO/IEC 10118-3.
 International Organization for Standardization / International Electrotech-
nical Commission (2006). Information Technology – Security Techniques –
Encryption Algorithms – Part 2: Asymmetric Ciphers. ISO/IEC 18033-2.
 Jia, Z. and Y. Zhang (2006). An Elliptic Curve Based User Authentication
Scheme with Smart Cards. Journal of Information Assurance and Security 1,
 Khovratovich, D., C. Rechberger, and A. Savelieva (2012). Bicliques for
preimages: Attacks on Skein-512 and the SHA-2 family. Lecture Notes in
Computer Science 7549, 244–263.
 Koblitz, N. (1987). Elliptic Curve Cryptosystems. Mathematics of Compu-
tation 48, 203–209.
 Krawczyk, H., M. Bellare, and R. Canetti (1997). HMAC: Keyed Hashing for
Message Authentication. Internet Engineering Task Force, RFC 2104. http:
 Lee, H. J., S. J. Lee, J. H. Yoon, D. H. Cheon, and J. I. Lee (2005). The
SEED Encryption Algorithm. Internet Engineering Task Force, RFC 4269.
 Lipmaa, H., P. Rogaway, and D. Wagner (2000). Comments to
NIST Concerning AES Modes of Operations: CTR-mode Encryp-
tion. National Institute of Standards and Technology. http:
 Menezes, A. J. (1993). Elliptic Curve Public Key Cryptosystems. Boston,
MA, USA: Kluwer Academic Publishers.
 Miller, V. S. (1986). Use of Elliptic Curves in Cryptography. Lecture Notes
in Computer Science 218, 417–426.
 National Institute of Standards and Technology (2001). Advanced Encryp-
tion Standard. NIST FIPS 197.
 National Institute of Standards and Technology (2002). The Keyed-hash
Message Authentication Code. NIST FIPS 198.
 National Institute of Standards and Technology (2005). NIST Comments on
Cryptanalytic Attacks on SHA-1. National Institute of Standards and Tech-
 National Institute of Standards and Technology (2005a). Recommendation
for Block Cipher Modes of Operation: The CMAC Mode for Authentication.
NIST SP 800-38B.
 National Institute of Standards and Technology (2005b). Recommendation
for the Triple Data Encryption Algorithm (TDEA) Block Cipher. NIST SP
 National Institute of Standards and Technology (2007). Recommendation
for Key Management. Part 1: General. NIST SP 800-57.
 National Institute of Standards and Technology (2012). NIST Selects
Winner of Secure Hash Algorithm (SHA-3) Competition. National Insti-
tute of Standards and Technology. http://www.nist.gov/itl/csd/
 National Institute of Standards and Technology (2012). Secure Hash Stan-
dard. NIST FIPS 180-4.
 National Institute of Standards and Technology (2013). Recommendation
for Pair-wise Key Establishment Schemes Using Discrete Logarithm Cryptog-
raphy. NIST SP 800-56A rev. 2.
 Ohta, H. and M. Matsui (2000). A Description of the MISTY1 Encryption Al-
gorithm. Internet Engineering Task Force, RFC 2994. http://www.ietf.
 Oracle Corp. (2013a). Java Platform SE 6 - System.http:
 Oracle Corp. (2013b). Java Technology.http://java.com/en/
 Oracle Corp. (2013c). Oracle Java Archive.http://www.oracle.
 Oracle Corporation (2012a). Java Card Classic Platform Speciﬁcation
 Oracle Corporation (2012b). Java Card Platform Speciﬁcation
 Quisquater, J. and F. Koeune (2002). ECIES - Security Evalua-
tion of the Encryption Scheme and Primitives. Cryptrec. http:
 Rackoff, C. and D. R. Simon (1992). Non-interactive zero-knowledge proof
of knowledge and chosen ciphertext attack. Lecture Notes in Computer Sci-
ence 576, 433–444.
 Rice, B. and B. Yankosky (2009). Elliptic Curve Cryptography with the
TI-83. Cryptologia 33(2), 125–141.
 Sanadhya, S. and P. Sarkar (2008). New collision attacks against up to 24-
step SHA-2. Lecture Notes in Computer Science 5365, 91–103.
 Schneier, B. (2011). Schneier on Security.http://www.schneier.
 Seroussi, G. (2001). Compression and Decompression of Elliptic Curve
Data Points. US Patent 6,252,960.
 Shoup, V. (2001). A Proposal for an ISO Standard for Public Key Encryp-
tion. Cryptology ePrint Archive, Report 2001/112. http://www.shoup.
 Standards for Efﬁcient Cryptography Group (1999). Test vectors for SEC 1.
SECG GEC 2. http://www.secg.org/download/aid-390/gec2.
 Standards for Efﬁcient Cryptography Group (2009). Recommended Elliptic
Curve Domain Parameters. SECG SEC 1 ver. 2. http://www.secg.org/
 Stern, J. (2002). Evaluation Report on the ECIES Cryptosystem. Cryp-
 Vanstone, S. A., R. C. Mullin, and G. B. Agnew (2000). Elliptic Curve
Encryption Systems. US Patent 6,141,420.
 Wang, X., D. Feng, X. Lai, and H. Yu (2004). Collisions for Hash Functions
MD4, MD5, HAVAL-128 and RIPEMD. Cryptology ePrint Archive, report
 Wang, X., X. Lai, D. Feng, H. Chen, and X. Yu (2005). Cryptanalysis of the
Hash Functions MD4 and RIPEMD. Lecture Notes in Computer Science 3494,
 Wang, X., Y. Yin, and H. Yu (2005). Finding Collisions in the Full SHA-1.
Lecture Notes in Computer Science 3621, 17–36.