ArticlePDF Available

Security and Practical Considerations When Implementing the Elliptic Curve Integrated Encryption Scheme


Abstract and Figures

The most popular encryption scheme based on elliptic curves is the Elliptic Curve Integrated Encryption Scheme (ECIES), which is included in ANSI X9.63, IEEE 1363a, ISO/IEC 18033-2, and SECG SEC 1. These standards offer many ECIES options, not always compatible, making it difficult to decide what parameters and cryptographic elements to use in a specific deployment scenario. In this work, the authors show that a secure and practical implementation of ECIES can only be compatible with two of the four previously mentioned standards. They also provide the list of functions and options that must be used in such an implementation. Finally, they present the results obtained when testing this ECIES version implemented as a Java application, which allows them to offer some comments about the performance and feasibility of their proposed solution.
Content may be subject to copyright.
Security and Practical Considerations when
Implementing the Elliptic Curve Integrated
Encryption Scheme
V. Gayoso Martínez, L. Hernández Encinas
Institute of Physical and Information Technologies (ITEFI)
Spanish National Research Council (CSIC), Spain
A. Queiruga Dios
E.T.S.I.I. Béjar
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 difficult
to decide what parameters and cryptographic elements to use in a specific
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,
1 Introduction
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 [4], IEEE 1363a [25], ISO/IEC 18033-2 [27], and SECG SEC1 [59].
Those versions offer a large number of implementation options, making it impos-
sible to define 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 efficient 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 [19] and [20], 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 [20]). 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 configuration; 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 configuration options for ECIES. Section
7 summarizes our proposed configuration 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 [35] and Koblitz [30] independently proposed a
cryptosystem based on elliptic curves, whose security relies on the Elliptic Curve
Discrete Logarithm Problem (ECDLP). This problem can be defined as follows:
given an elliptic curve Edefined over a finite field Fqof qelements, a point G
on the curve E(Fq)of order n, and a point Pon the same curve, find the integer
k[0, n 1] such that P=k·G[24].
So far, no algorithm is known that solves the ECDLP in an efficient way, and
it is supposed that this problem is more difficult to solve than other mathematical
problems used in Cryptography, such as the Integer Factorization Problem or the
Discrete Logarithm Problem [14]. 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 briefly present some basic definitions
and properties of elliptic curves. An elliptic curve over a finite field is defined by
the following general Weierstrass equation [34]:
E(Fq) : y2+a1x y +a3y=x3+a2x2+a4x+a6,(1)
where a1, a2, a3, a4, a6Fqand 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 finite field Fqare typically used:
If the finite field 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 finite field 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 finite field. When the field is Fp, the set of parameters that define
the curve is P= (p, a, b, G, n, h), whereas if the finite field 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 finite field Fp.
mis the integer number specifying the finite field F2m.
f(x)is the irreducible polynomial of degree mdefining F2m.
aand bare the elements of the finite field Fqtaking part in the equations (2)
and (3).
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 [7], and it was later improved in [1] and [2], though by then it was
renamed as the Diffie-Hellman Integrated Encryption Scheme (DHIES) in order
to avoid misunderstandings with the Advanced Encryption Standard (AES) [36].
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 [2].
DHIES represents the kernel of ECIES, which is the generic term used to
define 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
shared secret.
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 Diffie-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 Diffie-Hellman with cofactor (DHC) is used [44], 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, identified
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, identified 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 defined
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[24].
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
(Param #1).
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 verification 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 configuration. 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 [57]. More specifically, 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 [57]. 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 [59], 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 defined 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 [57], “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 [52], and implies other useful properties, like non-malleability”).
4.2 Malleability when using the XOR function
Shoup also proved in [57] 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 fixed length for all the plaintexts [57].
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 [1], [57], and [60].
3. Forbid the usage of stream ciphers in ECIES, allowing only block ciphers,
as recommended in [51] and [57].
As the main use case for ECIES consists in the encryption of text messages or
binary files 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 [24]. 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) [59].
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 infinity 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 [25].
In a typical scenario, the validity check on the public key Vwould be per-
formed by the trusted third party issuing certificates, 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
[27, 58].
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 [50]. However, this feature is
used in the test vectors of neither ISO/IEC 18033-2 [27] nor SECG GEC 2 [58],
and Java Card 3.0 has added another operation mode in which the output of the
KA function is not hashed [49].
From the three possible solutions, we have selected the first 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 fixed 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 [43], RIPEMD-128, RIPEMD-160
[16], and WHIRLPOOL [26]. Table 1 presents the hash functions used in each
ANSI X9.63 IEEE 1363a ISO/IEC 18033-2 SECG SEC 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 first 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 [38]), 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 [42]. As the decision on SHA-3 is very recent, so far none of the standards
where ECIES is described has updated their specifications in order to include the
winning algorithm.
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 [23], 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 [4],
NIST-800-56-Concatenation-KDF [44], KDF1, and KDF2 [27]. 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
KDF2 NIST-800-56
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 specific 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 specific 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 [37], HMAC-
RIPEMD-128, HMAC-RIPEMD-160 [31], CMAC-AES-128, CMAC-AES-192,
and CMAC-AES-256 [39]. 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-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 [40], AES-128, AES-192, AES-256 [36], MISTY1 [45],
CAST-128 [3], Camellia [6], and SEED [32]. 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 specification 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
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 [55].
Regarding the mode of operation, even though CTR offers some advantages
(it does not require padding, its implementation is more efficient, etc.) [33], 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.
SHA-384 HMAC-SHA-384
SHA-512 HMAC-SHA-512
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 fixed key lengths, so we consider that in this
particular case it is better to sacrifice 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 efficient 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 first coordinate of the point or both coordinates, in both cases together with
one byte that identifies the format that has been selected. The point compression
formats that can be used by developers, and that are defined 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 affine
coordinates xPand yP.
2. Compressed: Only the first 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 first coordinate [35], 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 first 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 first co-
ordinate of P=u·V,xUis the first coordinate of U, and P#1 represents the
optional parameters identified 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 xPinstead of xP.
With regards to the implications of using the whole point representing the
shared secret or only the first 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 [60], 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 first
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 efficient
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
first 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
available are:
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 specific 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
identified 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 specific key pair [57], 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 [57] 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 specific curve to use. Even though elliptic curve generation procedures
are defined 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
verifiable 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 define the underlying prime fields have a special form aimed
to facilitate efficient implementations.
The parameters specified 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 defined elliptic curve generation procedure. The group was
named ECC Brainpool (henceforth simply Brainpool), and in 2005 it delivered the
first version of a document entitled “ECC Brainpool standard curves and curve
generation” [12], 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” [13].
The Brainpool specification 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 efficient 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 defined 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 configuration
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 efficient and secure version of ECIES, which is
compliant with the version described in the standards IEEE 1363a and ISO/IEC
KA: the DH function.
Hash: SHA-512.
ENC: AES-128 in CBC mode with PKCS #5 padding.
Shared secret: use only the first 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 configuration 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 [47] that can be used to test different parameter combinations
for ECIES [22]. Figure 3 displays part of its Configuration 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 specific 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 [48], 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 finite field and associated field element representation.
2. The binary representation of the sender’s ephemeral public key (either com-
pressed or uncompressed).
3. The specific 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 defined over Fp, given by the expression
δ= 1 + 2 ·llog2p
8m+ 16 + 64 = 2 ·llog2p
8m+ 81,
where nrepresents 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
Plaintext (bytes)
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
Plaintext (bytes)
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
encryption/decryption processes.
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 finish 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 finish 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 figure 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
#5 padding.
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
the signature.
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
#5 padding.
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 [41]. 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: [41]).
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 figure as
it is very similar to the encryption time, making both charts to appear superim-
Encryption Decryption
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.
9 Conclusions
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 specific settings of the
scheme. This makes the selection of the proper configuration for a specific de-
ployment scenario a difficult 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 efficiency 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 efficient with today’s technology. If we
compare the results with the running time of our RSA-AES scheme, it can be
affirmed 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.
[1] Abdalla, M., M. Bellare, and P. Rogaway (1998). DHIES: An Encryption
Scheme Based on the Diffie-Hellman Problem. Contribution to IEEE P1363a.
[2] Abdalla, M., M. Bellare, and P. Rogaway (2001). The Oracle Diffie-Hellman
Assumptions and an Analysis of DHIES. Lecture Notes in Computer Sci-
ence 2020, 143–158.
[3] Adams, C. (1997). The CAST-128 Encryption Algorithm. Internet Engineer-
ing Task Force, RFC 2144.
[4] 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.
[5] 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.
[6] 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,
[7] 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.
[8] Biryukov, A. and D. Khovratovich (2009). Related-key Cryptanalysis of the
Full AES-192 and AES-256. Cryptology ePrint Archive, Report 2009/317.
[9] 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.
[10] Blake, I. F., G. Seroussi, and N. P. Smart (2004). Advances in Elliptic Curve
Cryptography. Cambridge, UK: Cambridge University Press.
[11] Bogdanov, A., D. Khovratovich, and C. Rechberger (2011). Biclique Cryp-
toanalysis of the Full AES. Cryptology ePrint Archive, Report 2011/449.
[12] Brainpool (2005). ECC Brainpool Standard Curves and Curve
[13] Brainpool (2010). Elliptic Curve Cryptography (ECC) Brainpool Standard
Curves and Curve Generation. IETF RFC 5639. http://tools.ietf.
[14] Bundesamt für Sicherheit in der Informationstechnik (2009). Elliptic Curve
Cryptography. BSI TR 03111.
[15] 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.
[16] Dobbertin, H., A. Bosselaers, and B. Preneel (1996). RIPEMD-160: A
Strengthened Version of RIPEMD. Lecture Notes in Computer Science 1039,
[17] 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.
[18] Elo, T. (2000). Lessons Learned on Implementing ECDSA on a Java Smart
Card. In Proceedings of NordSec2000. Reykjavik, Iceland.
[19] 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.
[20] 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.
[21] 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.
[22] 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.
[23] Gueron, S., S. Johnson, and J. Walker (2010). SHA-512/256. Cryptology
ePrint Archive, report 2010/548.
[24] Hankerson, D., A. J. Menezes, and S. Vanstone (2004). Guide to Elliptic
Curve Cryptography. New York, NY, USA: Springer-Verlag.
[25] Institute of Electrical and Electronics Engineers (2004). Standard Specifi-
cations for Public Key Cryptography - Amendment 1: Additional Techniques.
IEEE 1363a.
[26] International Organization for Standardization / International Electrotech-
nical Commission (2004). Information Technology – Security Techniques –
Hash-functions – Part 3: Dedicated Hash-functions. ISO/IEC 10118-3.
[27] International Organization for Standardization / International Electrotech-
nical Commission (2006). Information Technology – Security Techniques –
Encryption Algorithms – Part 2: Asymmetric Ciphers. ISO/IEC 18033-2.
[28] Jia, Z. and Y. Zhang (2006). An Elliptic Curve Based User Authentication
Scheme with Smart Cards. Journal of Information Assurance and Security 1,
[29] 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.
[30] Koblitz, N. (1987). Elliptic Curve Cryptosystems. Mathematics of Compu-
tation 48, 203–209.
[31] Krawczyk, H., M. Bellare, and R. Canetti (1997). HMAC: Keyed Hashing for
Message Authentication. Internet Engineering Task Force, RFC 2104. http:
[32] 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.
[33] 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:
[34] Menezes, A. J. (1993). Elliptic Curve Public Key Cryptosystems. Boston,
MA, USA: Kluwer Academic Publishers.
[35] Miller, V. S. (1986). Use of Elliptic Curves in Cryptography. Lecture Notes
in Computer Science 218, 417–426.
[36] National Institute of Standards and Technology (2001). Advanced Encryp-
tion Standard. NIST FIPS 197.
[37] National Institute of Standards and Technology (2002). The Keyed-hash
Message Authentication Code. NIST FIPS 198.
[38] National Institute of Standards and Technology (2005). NIST Comments on
Cryptanalytic Attacks on SHA-1. National Institute of Standards and Tech-
[39] National Institute of Standards and Technology (2005a). Recommendation
for Block Cipher Modes of Operation: The CMAC Mode for Authentication.
NIST SP 800-38B.
[40] National Institute of Standards and Technology (2005b). Recommendation
for the Triple Data Encryption Algorithm (TDEA) Block Cipher. NIST SP
[41] National Institute of Standards and Technology (2007). Recommendation
for Key Management. Part 1: General. NIST SP 800-57.
[42] National Institute of Standards and Technology (2012). NIST Selects
Winner of Secure Hash Algorithm (SHA-3) Competition. National Insti-
tute of Standards and Technology.
[43] National Institute of Standards and Technology (2012). Secure Hash Stan-
dard. NIST FIPS 180-4.
[44] 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.
[45] Ohta, H. and M. Matsui (2000). A Description of the MISTY1 Encryption Al-
gorithm. Internet Engineering Task Force, RFC 2994. http://www.ietf.
[46] Oracle Corp. (2013a). Java Platform SE 6 - System.http:
[47] Oracle Corp. (2013b). Java Technology.
[48] Oracle Corp. (2013c). Oracle Java Archive.
[49] Oracle Corporation (2012a). Java Card Classic Platform Specification
[50] Oracle Corporation (2012b). Java Card Platform Specification
[51] Quisquater, J. and F. Koeune (2002). ECIES - Security Evalua-
tion of the Encryption Scheme and Primitives. Cryptrec. http:
[52] 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.
[53] Rice, B. and B. Yankosky (2009). Elliptic Curve Cryptography with the
TI-83. Cryptologia 33(2), 125–141.
[54] Sanadhya, S. and P. Sarkar (2008). New collision attacks against up to 24-
step SHA-2. Lecture Notes in Computer Science 5365, 91–103.
[55] Schneier, B. (2011). Schneier on Security.http://www.schneier.
[56] Seroussi, G. (2001). Compression and Decompression of Elliptic Curve
Data Points. US Patent 6,252,960.
[57] Shoup, V. (2001). A Proposal for an ISO Standard for Public Key Encryp-
tion. Cryptology ePrint Archive, Report 2001/112. http://www.shoup.
[58] Standards for Efficient Cryptography Group (1999). Test vectors for SEC 1.
[59] Standards for Efficient Cryptography Group (2009). Recommended Elliptic
Curve Domain Parameters. SECG SEC 1 ver. 2.
[60] Stern, J. (2002). Evaluation Report on the ECIES Cryptosystem. Cryp-
[61] Vanstone, S. A., R. C. Mullin, and G. B. Agnew (2000). Elliptic Curve
Encryption Systems. US Patent 6,141,420.
[62] Wang, X., D. Feng, X. Lai, and H. Yu (2004). Collisions for Hash Functions
MD4, MD5, HAVAL-128 and RIPEMD. Cryptology ePrint Archive, report
[63] 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,
[64] Wang, X., Y. Yin, and H. Yu (2005). Finding Collisions in the Full SHA-1.
Lecture Notes in Computer Science 3621, 17–36.
... 2) Encryption Security: The ECIES encryption and decryption function used during the communications in the hypercube networks is proven to be secure in the literature [46]. ...
The privacy-preserving data aggregation is a critical problem for many applications where multiple parties need to collaborate with each other privately to arrive at certain results. Blockchain, as a database shared across the network, provides an underlying platform on which such aggregations can be carried out with a decentralized manner. Therefore, in this paper, we have proposed a scalable privacy-preserving data aggregation protocol for summation on the Ethereum blockchain by integrating several cryptographic primitives including commitment scheme, asymmetric encryption and zero-knowledge proof along with the hypercube network topology. The protocol consists of four stages as contract deployment, user registration, private submission and proof verification. The analysis of the protocol is made with respect to two main perspectives as security and scalability including computational, communicational and storage overheads. In the paper, the zero-knowledge proof, smart contract and web user interface models for the protocol are provided. We have performed an experimental study in order to identify the required gas costs per individual and per system. The general formulation is provided to characterize the changes in gas costs for the increasing number of users. The zero-knowledge proof generation and verification times are also measured.
... In the year 2020, Muttaqin et at. [12]. In the year 2016, Abbas et al. [13] have implemented Elliptic curve integrated encryption scheme with the help of identity-based encryption. ...
... The integrated encryption scheme has various implementation methods, even though it was standardized by ANSI, IEEE, SECG and ISO/IEC. A comparison of the requirements and implementation guidelines detailed by each standard is presented in [49], with the conclusion that a generic solution for fulfilling all these standards when implementing the encryption scheme cannot be provided, as also stated by [50]. The integrated encryption scheme was chosen based on ECC performance on low computational devices with low memory resources, described in the next section, which fits the specifications of legacy devices such as PLCs used in the industry. ...
Full-text available
Securing critical infrastructures and manufacturing plants in the Industrial-Internet-Of-Things and Industry 4.0 is a challenge today due to the increased number of attacks against automation and SCADA systems. These systems were built without any security considerations in mind, so the evolution towards interconnection and interoperability makes them vulnerable in the context of exposing data to the outside network. Even though new protocols are considering built-in security, the widely spread legacy standard protocols need to be protected. Hence, this paper attempts to offer a solution for securing the legacy insecure communication protocols based on elliptic curve cryptography while fulfilling the time constraints of a real SCADA network. Elliptic curve cryptography is chosen to respond to the low memory resources available for the low level devices of a SCADA network (e.g., PLCs), and also because it can achieve the same level of security as other cryptographic algorithms using smaller sizes for the secure keys. Furthermore, the proposed security methods have the purpose of assuring that the data transmitted between entities of a SCADA and automation system are authentic and confidential. The experimental results showed good timing performance for the cryptographic operations executed on Industruino and MDUINO PLCs, demonstrating that our proposed concept is deployable for Modbus TCP communication in a real automation/SCADA network on existing devices from the industry.
... A modified version of the elliptic curve variant of integrated encryption scheme (ECIES) is used to provide semantic security in this phase. Briefly, the standard ECIES encrypts a plaintext message and attaches a message authentication code (MAC) to this encrypted message [24]. The MAC is also known as a keyed hash function as it takes as input a secret key (i.e., MAC key) and the encrypted message to produce a hash i.e., MAC as the output. ...
Full-text available
The capacity of highways has been an ever-present constraint in the 21st century, bringing about the issue of safety with greater likelihoods of traffic accidents occurring. Furthermore, recent global oil prices have inflated to record levels. A potential solution lies in vehicular platooning, which has been garnering attention, but its deployment is uncommon due to cyber security concerns. One particular concern is a Sybil attack, by which the admission of fake virtual vehicles into the platoon allows malicious actors to wreak havoc on the platoon itself. In this paper, we propose a secure management scheme for platoons that can protect major events that occur in the platoon operations against Sybil attacks. Both vehicle identity and message exchanged are authenticated by adopting key exchange, digital signature and encryption schemes based on elliptic curve cryptography (ECC). Noteworthy features of the scheme include providing perfect forward secrecy and both group forward and backward secrecy to preserve the privacy of vehicles and platoons. Typical malicious attacks such as replay and man-in-the-middle attacks for example can also be resisted. A formal evaluation of the security functionality of the scheme by the Canetti–Krawczyk (CK) adversary and the random oracle model as well as a brief computational verification by CryptoVerif were conducted. Finally, the performance of the proposed scheme was evaluated to show its time and space efficiency.
A ‘1-out-of-n’ oblivious transfer (OT) protocol involves two participants: a sender, who provides a set of items as input, and a receiver. The protocol guarantees that the receiver gets exactly one of the items of the input set, while the sender is unable to determine which. Priced OT (POT) protocols further allow each item of the input set to be assigned a price in such a way that, after a proper execution of the protocol, the receiver gets the requested item if and only if the corresponding sum of money has been paid. In this paper, we present a construction which takes a ‘1-out-of-n’ OT protocol and transform it into a POT one. Moreover, the resulting system is unlinkable in the sense that the sender is unable to determine whether two executions of the protocol were run by the same receiver or not. When compared to existing unlinkable POT protocols, our construction offers a lower conceptual complexity as it does not involve the use of zero-knowledge proofs.
Security in web services is not well defined and is largely based on measures employed by the organization providing the service, the effectiveness of which vary greatly depending on the expertise, implementation, and business motivation. To address the mentioned issue, this paper proposes an open standard called Decentralized Open Web Cryptographic Standard (DOWCS) and reference implementation for decentralized protection of sensitive data. Services may adhere to the standards, to assure security to the end-user. Taking OAuth and PGP as reference models, the standard incorporates multiple layers of security to ensure secrecy of the said data while also decentralizing the key information required to derive the confidential data from the encrypted format.
In recent years, microgrids have attracted much attention as one of the typical applications of the Internet of Things (IoT). With the development of renewable energy, a bi-layer energy trading scenario of microgrids has emerged. In the upper layer, the microgrids trade energy with each other, and in the lower layer, users trade energy within the microgrid. Traditional management schemes based on the cooperation mode or island mode of the microgrids can no longer meet the needs of energy trading. In this paper, we propose an energy trading management solution for the bi-layer energy trading scenario. In order to maximize the bi-layer’s (i.e., users’ and microgrid operators’ (MGOs)) utility functions under the condition of the local energy supply and demand, we propose a multi-objective optimization model. To solve the optimization model, we give a solution Energy Trading Management Algorithm (ETMA) based on the Non-dominated Sorting Genetic Algorithm (NSGA). Moreover, the proposed energy trading framework which is based on multi-blockchain ensures the security and privacy of energy trading, and a consensus mechanism named Delegated Proof of Reputation (DPoR) is proposed to urge users to complete the transaction according to their promised trading schemes. Experiments based on the real data of Guizhou are done to evaluate the performance of the proposed optimization model. The results show that our proposed model can achieve better performance in terms of users’ and MGOs’ utility functions in the bi-layer energy trading scenario compared with the traditional models.
Full-text available
Nowadays, Morocco has adhered to a policy aimed at modernizing its cities in terms of smart city and green city to improve the quality of life, protect the environment, and compete with the world’s major cities in this promising field. In this perspective, our current work revolves around the innovation of smart cities via new technologies of interconnection between objects and man in maximum respect that possible of the environment and especially the air quality.
Full-text available
This paper describes a Diffie-Hellman based encryption scheme, DHIES (formerly named DHES and DHAES), which is now in several (draft) standards. The scheme is as efficient as ElGamal encryption, but has stronger security properties. Furthermore, these security properties are proven to hold under appropriate assumptions on the underlying primitive. DHIES is a Diffie-Hellman based scheme that combines a symmetric encryption method, a message authentication code, and a hash function, in addition to number-theoretic operations, in a way which is intended to provide security against chosenciphertext attacks. The proofs of security are based on the assumption that the underlying symmetric primitives are secure and on appropriate assumptions about the Diffie-Hellman problem. The latter are interesting variants of the customary assumptions on the Diffie-Hellman problem, and we investigate relationships among them, and provide security lower bounds. Our proofs are in the standard model; no random-oracle assumption is required.
Full-text available
Elliptic Curve Cryptography (ECC) can be used as a tool for encrypting data, creating digital signatures or performing key exchanges. Regarding the encryption procedure, the schemes currently used are known as hybrid cryptosystems, as they use both symmetric and asymmetric techniques. Among those hybrid cryptosystems based on ECC, the Elliptic Curve Integrated Encryption Scheme (ECIES) is the best known, and as such it can be found in several cryptographic standards. In this work, we present an extensive review and comparison of the versions of ECIES included in documents from ANSI, IEEE, ISO/IEC, and SECG, highlighting the main differences between them that may prevent fully interoperable implementations of ECIES. In addition, a detailed list of the functions and capabilities needed by ECIES and available in Java Card is presented, which allows to provide some conclusions about the practical limitations of a Java Card implementation of ECIES.
Full-text available
Elliptic Curve Cryptography (ECC) can be used as a tool for encrypting data, creating digital signatures or performing key exchanges. In relation to encryption, the Elliptic Curve Integrated Encryption Scheme (ECIES) is the best known scheme based on ECC, and as such it has been included in several cryptographic standards. In the present work, we provide an extensive review and comparison of the versions of ECIES included in documents from ANSI, IEEE, ISO/IEC, and SECG, highlighting the main differences between them that can prevent implementations of ECIES from being fully interoperable.
We discuss analogs based on elliptic curves over finite fields of public key cryptosystems which use the multiplicative group of a finite field. These elliptic curve cryptosystems may be more secure, because the analog of the discrete logarithm problem on elliptic curves is likely to be harder than the classical discrete logarithm problem, especially over GF(2"). We discuss the question of primitive points on an elliptic curve modulo p, and give a theorem on nonsmoothness of the order of the cyclic subgroup generated by a global point.
Part I. Protocols: 1. Elliptic curve base protocols N. P. Smart 2. On the provable security of ECDSA D. Brown 3. Proofs of security for ECIES A. W. Dent Part II. Implementation Techniques: 4. Side channel analysis E. Oswald 5. Defenses against side-channel analysis M. Joye Part III. Mathematical Foundations: 6. Advances in point counting F. Vercauteren 7. Hyperelliptic curves and the HCDLP P. Guadry 8. Weil descent attacks F. Hess Part IV. Pairing Based Techniques: 9. Pairings S. Galbraith 10. Cryptography from pairings K. G. Paterson.
We discuss analogs based on elliptic curves over finite fields of public key cryptosystems which use the multiplicative group of a finite field. These elliptic curve cryptosystems may be more secure, because the analog of the discrete logarithm problem on elliptic curves is likely to be harder than the classical discrete logarithm problem, especially over GF ( 2 n ) {\text {GF}}({2^n}) . We discuss the question of primitive points on an elliptic curve modulo p , and give a theorem on nonsmoothness of the order of the cyclic subgroup generated by a global point.