On TLS 1.3

Early Performance Analysis in the IoT Field

Simone Bossi

, Tea Anselmo

and Guido Bertoni

Department of Computer Science, Universit

a degli studi di Milano, Milan, Italy

STMicroelectronics, Via Olivetti 2, Agrate B.za, Italy

Keywords:

TLS 1.3, Authenticated Encryption, IoT, Performance Analysis, Data Security.

Abstract:

The TLS 1.3 speciﬁcations are subject to change before the ﬁnal release, and there are still details to be

clariﬁed, but yet some directions have been stated. In the IoT scenario, where devices are constrained, it is

important and critical that the added security beneﬁts of the new TLS 1.3 does not increase complexity and

power consumption signiﬁcantly compared to TLS 1.2. This paper provides an overview of the novelties intro-

duced in TLS 1.3 draft ﬁnalized to improve security and latency of the protocol: the reworked handshake ﬂows

and the newly adopted cryptographic algorithms are analyzed and compared in terms of security and latency

to the current TLS in use. In particular, the analysis is focused on performance and memory requirements

overhead introduced by the TLS 1.3 current speciﬁcations, and the ﬁnal section reports simulation results of a

commercial cryptographic library running on a low end device with an STM32 microcontroller.

1 INTRODUCTION

The emerging technology of the Internet of Things

(IoT) is having a huge impact on the generated data

volume, on network trafﬁc and the way of handling

them. We are experiencing an extraordinary diffusion

of smartphones and tablets, of new devices such as

wearables, environmental sensors, smart-home sys-

tems. They are all part of a vast set of devices requir-

ing a connection - possibly even to the Internet - for

purposes of data communication, remote monitoring,

management, and accounting. In this complex and

intricate context of technologies and protocols, it is

unanimously recognized that security is a key enabler

for success of IoT and for end user acceptance. In

particular, securing the communications that involve

constrained low-end devices is an hard task since the

enhancements of security network protocols always

introduce additional workload and memory require-

ments.

The paper focuses on the TLS (Transport Layer

Security) protocol because it is probably the most

popular security network protocol in the plethora of

existing protocols, and because a new version, TLS

1.3 (Rescorla, 2015), is under development (still a

draft) to respond to security issues and needs. TLS is

implemented on top of the transport layer and used to

secure a wide range of TCP/IP protocols as for exam-

ple HTTP (Rescorla, 2000), FTP (Ford-Hutchinson,

2005), SMTP (Hoffman, 2002), and XMPP (Saint-

Andre, 2011).

The main purpose of the TLS protocol is to pro-

vide communication security in terms of privacy and

authenticity between hosts communicating over inse-

cure channels. In order to achieve this goal TLS pro-

vides three sub-protocols: handshake, record and alert

protocols. We will focus our analysis on handshake

and record layers which make use of cryptographic

primitives.

This paper will treat the main novelties introduced

in the TLS 1.3 draft and discussed by the TLS work-

ing group in the mailing list, focusing on performance

and memory requirements of constrained devices, and

supporting the analysis with test results.

The reminder of this paper is organized as fol-

lows. Section 2 compares the message ﬂows of TLS

1.2 and 1.3 handshake protocols explaining the main

differences proposed in the draft. Section 3 gives an

overview on the record layer focusing on Authenti-

cated Encryption problematic, current solutions, and

its adoption in TLS. Section 4 summarizes the state of

the art security requirements for algorithms employed

in the protocol in terms of key sizes. In Section 5 and

6 we present and comment our work of analysis and

benchmark respectively on TLS 1.2 handshake and

TLS 1.3 additional overhead. Finally Section 7 de-

Bossi, S., Anselmo, T. and Bertoni, G.

On TLS 1.3 - Early Performance Analysis in the IoT Field.

DOI: 10.5220/0005688901170125

In Proceedings of the 2nd International Conference on Information Systems Security and Privacy (ICISSP 2016), pages 117-125

ISBN: 978-989-758-167-0

117

Figure 1: Message ﬂow comparison between TLS 1.2 and 1.3 for a full handshake. + indicates extensions sent in the

previously noted message, ∗ indicates optional or situation-dependent messages, {} indicates messages protected using keys

derived from the ephemeral secret, and [] indicates messages protected using keys derived from the master secret.

scribes use cases for TLS on IoT devices motivating

the choice of the discussed algorithms in different sit-

uations and gives some concluding remarks.

2 TLS HANDSHAKE PROTOCOL

The handshake protocol determines the agreement of

cryptographic algorithms, the mutual setting of com-

mon cryptographic parameters, including the keys

that will be used to encrypt the communication and to

authenticate the involved parties. Beside traditional

purposes of the TLS protocol (Dierks and Rescorla,

2008), which are cryptographic security, interoper-

ability and extensibility, the main goals deﬁned for

the new TLS version 1.3 concern the reduction of the

n-RTT (number of Round Trip Time) required for the

handshake, and the encryption of the sensitive infor-

mation exchanged in this phase. Figure 1 provides a

comparative view of the TLS 1.2 handshake and the

novel TLS 1.3 scheme as is in current protocol draft.

The new proposed handshake ﬂow provides a 1-RTT

full handshake solution against the 2-RTT of the pre-

vious version. The rearranged ﬂow includes the trans-

mission of the client key parameters during its ﬁrst

ﬂight within the new extension KeyShare, thus antic-

ipating the shared key computation on the server side

just after its KeyShare packet. At this point, the server

can already compute the shared secret (or premaster

secret), derive the Ephemeral Secret (ES) and start to

encrypt all remaining handshake trafﬁc. Furthermore

the ServerConﬁguration packet will be introduced for

the purpose of enabling 0-RTT exchange upon subse-

quent connections. However our performance analy-

sis is focused on the full handshake which represents

the worst case.

Among the new security features proposed in the

draft (Rescorla, 2015), it’s also worth noting that all

non-ephemeral key exchange algorithms (including

RSA) have been removed from the cipher suites. The

aim here is to provide Perfect Forward Secrecy (PFS),

that guarantees the agreed key will not be compro-

mised even when agreed keys derived from the same

long-term keying material in a subsequent run are

compromised.

All these security enhancements necessarily

comes with an increased workload for both the client

and the server. In Section 5 we present our analysis

methodology and results for the handshake protocol.

3 TLS RECORD PROTOCOL

The record protocol takes as input uninterpreted data

from higher layers, fragments it into blocks of maxi-

mum 2

bytes, and applies the symmetric encryption

algorithm as established in the initial handshake. In

TLS 1.3, as opposed to previous versions, all symmet-

ric ciphers are modeled as ”Authenticated Encryption

with Additional Data” (McGrew, 2008). In the rest of

this section we summarize the properties of authenti-

cated encryption and the solutions developed over the

time.

3.1 Authenticated Encryption

In the context of communication over unsecure chan-

nels, the need for privacy and authenticity led to the

rise of scrappy combination of separate encryption

and message authentication techniques. As a result

the confusion in the user community brought to a

number of security break, as for example the break

of WEP protocol in 802.11 (Borisov et al., 2001).

To overcome these ﬂaws there have been various

ICISSP 2016 - 2nd International Conference on Information Systems Security and Privacy

118

attempts to give a standardized way to combine Mes-

sage authentication codes (MAC) and ciphers, in or-

der to provide Authenticated Encryption (AE) through

a ”generic composition” design. The main ap-

proaches are MAC-and-Encrypt (M&E), MAC-then-

Encrypt (MtE), and Encrypt-then-MAC (EtM). In

M&E, adopted by the SSH protocol (Ylonen and Lon-

vick, 2006), the original message is encrypted and au-

thenticated through the MAC function, and the con-

catenation of ciphertext and authentication tag are

given as output. MtE instead appends authentication

tag to the plaintext and then encrypt the whole. This

is the approach used by TLS 1.2 and prior (Dierks

and Rescorla, 2006), (Dierks and Rescorla, 2008). Fi-

nally EtM differs from the previous since it does not

authenticate the plaintext, but, as the name suggests,

it ﬁrst encrypts the message, then calculates the au-

thentication tag over the ciphertext and outputs the

concatenation of ciphertext and tag. Old versions of

the IPSec protocol implement EtM ((Kent and Atkin-

son, 1998)). A detailed analysis on the security of au-

thenticated encryption schemes designed by generic

composition is presented in (Bellare and Namprem-

pre, 2000). The paper acknowledges the EtM as the

only secure strategy against both privacy and integrity

attacks providing the proof for this case, and counter-

examples for M&E and MtE. This analysis has been

also conﬁrmed by (Krawczyk, 2001), and a series of

attacks has exploited the weaknesses of MtE such as

(Al Fardan and Paterson, 2013),(M

oller et al., 2014),

(Degabriele and Paterson, 2010), and M&E (Bellare

et al., 2004).

Alongside with these threats that afﬂicts AE ci-

phers built on the generic composition paradigm, the

need to handle associated-data when using AE modes

became clear. This is particularly useful in network

communications where there are non-sensitive data

(e.g. IP addresses, headers, etc.) that does not re-

quire privacy protection, but rather authentication.

In (Rogaway, 2002) this problematic is formalized

and named authenticated-encryption with associated-

data (AEAD). The paper investigates the importance

and the goals of AEAD ciphers, providing a provable-

security treatment. Furthermore solutions to the prob-

lem of translating an AE-scheme to an AEAD-scheme

are presented.

3.2 Authenticated Encryption in TLS

Even if AEAD ciphers are allowed (Salowey et al.,

2008), as previously mentioned the TLS protocol

version 1.2 mandates an MtE construction based

on AES128-CBC cipher and HMAC authentica-

tion. Since this strategy has been proved not to

be secure over the time ((Bellare and Namprempre,

2000), (Krawczyk, 2001), (Al Fardan and Paterson,

2013),(M

oller et al., 2014), (Degabriele and Paterson,

2010)) the TLS working group has provided a way to

negotiate the use of EtM mechanism via speciﬁcation

in HelloExtensions (Gutmann, 2014).

In the new TLS version 1.3 the intent is to provide

authenticated encryption only via AEAD ciphers. At

the time of writing, the main symmetric ciphers in-

cluded are AES operated in the Galois Counter Mode

(GCM) (McGrew and Viega, 2004)(Dworkin, 2007),

and Chacha20-Poly1305 (Nir and Langley, 2015)

which is a construction of Chacha20 cipher (Bern-

stein, 2008) and Poly1305 message authentication

code (Bernstein, 2005). Chacha20-Poly1035 AEAD

cipher has been employed since 2014 by some famous

and widely used web services like Google, Cloud-

Flare and openSSH claiming its high throughput and

security. In particular Google and CloudFlare make

use of this cipher in HTTPS connections even if it was

not yet referred into IANA registered cipher list for

TLS, since the cipher suite description for the proto-

col is today still in draft (Langley et al., 2015). Actu-

ally an approved RFC (Nir and Langley, 2015) for this

AEAD cipher gives a generic implementation guide

for IETF protocols.

An important feature used to promote Chacha20

is the possibility of being constant time by design. In

facts, as highlighted in Section 5 of (Nir and Langley,

2015), all the operations involved in Chacha20 are ad-

ditions, XORs and ﬁxed rotations, which can be easily

implemented in constant time in software. Cryptanal-

ysis on Chacha20 can be found in (Aumasson et al.,

2007), (Ishiguro, 2012), (Shi et al., 2013).

In Section 6.3 we report our benchmarks for

AES128-GCM and Chacha20-Poly1305 AEAD ci-

phers.

4 THE SECURITY LEVEL OF A

TLS CONNECTION

In this section we will discuss how to establish the

security level of a TLS connection in relation to the

negotiated cipher suite.

In (Barker et al., 2012) the authors provide a

global view of the security strength and a key-size

comparison between different public and private key

algorithms binding them to the bit of security they

give as summarized in Table 1. We can note that in or-

der to provide 128 bit-security, the equivalent of AES-

128, we have to choose at least a 3072-bit key for

asymmetric ciphers like RSA or DH, and only a 256-

bit key for ECC. Since in a TLS connection the master

On TLS 1.3 - Early Performance Analysis in the IoT Field

119

Figure 2: Benchmark of TLS 1.2 full handshake with one-way authentication.

Table 1: Comparable strengths.

Bits of

security

Symmetric key

algorithms

FFC/

IFC

ECC

80 2TDEA 1,024 160-223

112 3TDEA 2,048 224-255

128 AES-128 3,072 256-383

192 AES-192 7,680 384-511

256 AES-256 15,360 512+

secret used to generate the symmetric key is negoti-

ated by employing public key algorithms, the security

level of the connection is indeed upper bounded by

the asymmetric cipher employed which can represent

the bottle neck in terms of computational effort and

memory requirements especially for IoT devices.

In the third part of the same NIST special publi-

cation (Barker et al., 2015), the authors describe the

recommended key size for key establishment as RSA

2048, DH 2048 and ECDH P-256 or P-384. Note that

for RSA 2048 and DH 2048 the equivalent symmet-

ric key size is 112 bit, and in the case of ECC is 128

bit, thus employing a stronger symmetric cipher is not

enough to provide more security to the connection,

but also key sizes for asymmetric algorithms have to

be incremented. This is the case, for example, of

Chacha20-Poly1305 which is designed to provide 256

bit-security, but if the shared secret is negotiated with

asymmetric algorithms like ECC 256, RSA 2048 or

DH 2048, the security level of the connection is only

128 bit.

5 TLS 1.2: HANDSHAKE

PERFORMANCE ANALYSIS

We started our work of analysis by performing bench

marks for the TLS version 1.2. We build our test-

ing environment by connecting our STM32F217IG

with an Intel Pentium M powered PC running Linux

Ubuntu 12.04 LTS by an Ethernet cable. For crypto-

graphic primitives and TLS implementation we em-

ployed the wolfSSL library

version 3.4.6 on the

device and the OpenSSL library

version 1.0.2a on

the PC. All the measurements reported in this article

refers to the device side.

A previous similar work in which handshake per-

formance are analyzed is (Koschuch et al., 2012), and

this section can be an extension of Koschuch et al. pa-

per, considering the new security standards discussed

in Section 4. In fact it is important to note that in

the choice of key sizes we followed the NIST recom-

mendation reported in (Barker et al., 2015). In this

respect, it is emphasised that due to the recent ﬁnding

reported in (Adrian et al., 2015), the recommended

key size for Difﬁe-Hellman key exchange algorithm

has grown from 1024, which was used by millions

of TLS, SSH, and VPN servers, to 2048. Figure

2 and 3 depict the clock cycles needed to complete

an handshake when different cipher suites are nego-

tiated, respectively for one way and mutual authen-

tication schemes, while Table 6 in Appendix reports

the values of memory usage. In case of one-way au-

thentication, Figure 2 shows that the Difﬁe-Hellman

exponentiation (see DH RSA) is about 2.5 slower

than the ECC (NIST P-256) scalar multiplication (e.g.

ECDH RSA), and when it comes to the ephemeral

version, as in DH ANON or DHE RSA, an additional

scalar multiplication is required for the key gener-

ation, increasing clock cycles of key exchange at a

comparable level with RSA private key operations.

www.st.com

www.wolfssl.com

www.openssl.org

ICISSP 2016 - 2nd International Conference on Information Systems Security and Privacy

120

Figure 3: Benchmark of TLS 1.2 full handshake with mutual authentication.

Another aspect to be considered is the memory re-

quirement: we observed that a Difﬁe-Hellman solu-

tion requires almost 1.5 times more RAM than the re-

lated ECC version. In particular, the DHE RSA con-

ﬁguration demands the highest workload and memory

occupation both for server and client, instead switch-

ing to Elliptic Curve induces a sensible reduction even

with the ephemeral version.

When mutual authentication is employed (Figure

3), the client is required to perform private-key oper-

ations, and the clock cycles are mostly equivalent for

client and server. In this case is even more evident

the beneﬁt of an Elliptic Curve solution. Compar-

ing the ECDHE ECDSA case with RSA RSA one,

we note that the former provide higher security by

granting Perfect Forward Secrecy (PFS), and requires

less computational effort and RAM for both client

and server. Finally if we compare it with DHE RSA,

which also provides PFS, the ECC version requires

half the time and less than 1.5 times the RAM. We

also recall that, as discussed in Section 4, ECC P-256

provides 128 bit of security while DH 2048 and RSA

2048 only 112.

6 TLS 1.3 OVERHEAD ANALYSIS

Our aim is to evaluate the extent to which the novel-

ties expected in TLS version 1.3 can impact on hand-

shake and record protocols. For the evaluations pre-

sented in Subsections 6.2 and 6.3 we extended the

wolfSSL library with our own cryptographic library

by including the support for our new generation hard-

ware accelerators.

Figure 4: Elliptic curves benchmark.

6.1 On Ed25519 and Curve25519

Another important discussion among TLS experts

concerns the adoption of new Elliptic Curves algo-

rithms, in particular Curve25519 (Bernstein, 2006)

for key exchange, and Ed25519 (Bernstein et al.,

2012) for signature. The internet drafts that illustrate

the use of such algorithms in TLS can be found at

(Josefsson and Pegourie-Gonnard, 2015) and (Josef-

sson and Mavrogiannopoulos, 2015). These curves

provide at least 128 bit security as NIST P-256, so

we made some speed test and memory requirements

comparison between them.

Figure 4 highlights that Curve25519 is 6 times

faster than P-256 in a typical ephemeral key exchange

which involves two exponentiations, one for generat-

ing the public key, and the other for shared key com-

putation. Very impressive is the gap between NIST P-

256 and Ed25519, in fact the latter is about 15 times

faster in signature generation, and almost 8 times in

signature veriﬁcation. Another advantage of these

new algorithms is the memory required at run-time,

which is approximately a third for the key exchange,

On TLS 1.3 - Early Performance Analysis in the IoT Field

121

and about half for signature (Table 4 in the Appendix).

If we take into account ﬂash memory requirements

like code size and constant data we note that NIST

P-256 requires a little less than 20 KB for both key

exchange and signature against the 70 KB needed by

Curve25519 and Ed25519.

6.2 Handshake Encryption

As discussed in Section 2, the new TLS version 1.3

will introduce a new handshake ﬂow in which all

packets exchanged after the ServerKeyShare will be

encrypted. This additional layer of encryption, in par-

ticular, allows the server to encrypt the response to

any client’s extensions which are not necessary to es-

tablish the Cipher Suite. The questions we want to

answer are: a) how much this security improvement

affects the time required for complete the handshake?

b) Can this represent a problem for IoT devices?

Table 2: Overhead introduced for handshake encryption.

Certiﬁcate type

clock cycles

ECDSA 1,531,996 23,354

RSA 2,772,785 42,268

In order to evaluate the introduced overhead we

simulated the encryption of a full TLS 1.2 handshake

with AES128-GCM. Obviously the packets that re-

quire much workload are those who contain certiﬁ-

cates, and, as reported in Table 2, the type of the cer-

tiﬁcates exchanged can impact on the computation.

In fact the encryption of a certiﬁcate containing an

RSA key requires almost double effort with respect to

the one containing an ECC key. The Table further-

more illustrates the difference between clock cycles

needed by software and hardware-accelerated imple-

mentations of the cipher.

Anyway even in the worst case (handshake involv-

ing an RSA-based certiﬁcate and no accelerators), the

number of clock cycles is less than 3 Million. Com-

paring this value with the hundreds of millions clock

cycles needed to carry out an handshake is clear that

this additional layer does not introduce a sensible

overhead and does not represent a bottle neck.

6.3 Application Data Encryption

The last evaluation is focused on application data en-

cryption. Once the handshake is terminated, almost

all the delay introduced by the TLS protocol towards

a traditional non-secure socket is due to authenticated

encryption. Hence the choice of symmetric cipher and

authentication function is fundamental for both pro-

viding a security level commensurate with the asym-

metric algorithm employed in the handshake, and en-

suring throughput as high as possible.

In this section we present a performance analysis

of AES128-GCM, Chacha20-Poly1305 and AES128-

CBC-SHA which is the mandatory cipher for TLS 1.2

and relays on HMAC-SHA1 for the authentication,

adopting a MtE strategy.

Table 3: Throughput comparison (Bytes/second) between

Software and Hardware implementations of authenticated

ciphers at 120MHz.

Algorithm

throughput

AES128-CBC+HMAC 578,726 6,142,506

AES128-GCM 304,216 8,757,487

Chacha20-Poly1305 771,962 NA

Table 3 reports the throughput of the ciphers at

120MHz encrypting packet of 15Kb. From the ta-

ble it is evident that the software implementation of

AES128 operated in GCM mode is almost 2 times

slower than the CBC+HMAC version and 2.5 times

than Chacha20-Poly1305. If we take a look at the

hardware implementations the GCM mode of opera-

tion has the advantage that the authentication can be

done in parallel with the encryption and the algorithm

becomes faster than the CBC + HMAC variant.

With regard to memory requirements reported

in Table 5 in the Appendix, we highlight that the

tested software implementations requirements are:

for AES128-GCM 16,4Kb of RAM and 14Kb of

ﬂash, for AES128-CBC 4.5Kb of RAM and 14.8Kb

of ﬂash, and for Chacha20-Poly1305 604 bytes of

RAM and 3.3Kb of ﬂash. Using the hardware accel-

erator makes possible to remove the software imple-

mentations of AES, HMAC and SHA1 and this results

in improved code size for the AES-based ciphers,

even less than the Chacha20-Poly1305 requirements.

The reader should note that we are comparing algo-

rithms of different key sizes. In fact, Chacha20 pro-

vides 256-bit security against the 128-bit of AES128-

GCM and AES128-CBC.

7 DISCUSSION AND

CONCLUSIONS

We can ﬁgure out two scenarios where IoT devices

are employed in which different conﬁguration can

give their best. A ﬁrst typical situation is video-

surveillance in which high throughput is required and

cryptography can really be a bottleneck. For this

ICISSP 2016 - 2nd International Conference on Information Systems Security and Privacy

122

kind of application a device external-powered and

equipped with cryptographic hardware accelerators

is preferable, and a hardware-accelerated cipher like

AES128-GCM should be employed. Otherwise in sit-

uations where battery life and economic factors are

more important than throughput (e.g. wearables or

environmental sensors), and amount of data to trans-

mit are generally limited, it is reasonable to employ

devices without criptographic hardware accelerators,

and resources even more limited. Under these con-

ditions a cipher like Chacha20-Poly1305 can be to-

day a more suitable solution as it requires less re-

sources both in space and clock cycles than the soft-

ware AES-based implementations, allowing to save

memory and reduce power consumption. Today AES-

GCM and Chacha20-Poly1305 are the only two op-

tions as AEAD available in TLS. This might change

in the coming years thanks to a competition called

CAESAR

. In this competition there is an effort from

researchers in evaluating new advanced AEAD ci-

phers.

In our analysis we focused on performances and

memory requirements overhead introduced by the

proposals in the TLS 1.3 draft, and we observed that

even where the new security standards introduce an

higher workload there is always an alternative that

best matches IoT requirements.

The basic TLS 1.3 handshake ﬂows introduce

some new message types, as ServerConﬁguration and

EncryptedExtensions, and the encryption of sensitive

handshake information, covering nearly two-thirds of

the handshake messages. This solutions may bur-

den low end devices. But on the side of crypto-

graphic computations, the preference for AEAD ci-

phers and the adoption of new signature algorithms,

as Curve25519 and Ed25519, may balance the in-

crease in complexity, as shown by the simulation re-

sults of a commercial cryptographic library over an

STM32 microcontroller.

Furthermore we provided use cases that let us con-

clude that the protocol still remain suitable for differ-

ent classes of IoT devices.

REFERENCES

Adrian, D., Bhargavan, K., Durumeric, Z., Gaudry, P.,

Green, M., Halderman, J. A., Heninger, N., Springall,

D., Thom

e, E., Valenta, L., et al. (2015). Imperfect

forward secrecy: How difﬁe-hellman fails in practice.

Al Fardan, N. J. and Paterson, K. G. (2013). Lucky thirteen:

Breaking the tls and dtls record protocols. In Security

competitions.cr.yp.to/caesar.html

and Privacy (SP), 2013 IEEE Symposium on, pages

526–540. IEEE.

Aumasson, J.-P., Fischer, S., Khazaei, S., Meier, W.,

and Rechberger, C. (2007). New features of

latin dances: Analysis of salsa, chacha, and

rumba. Cryptology ePrint Archive, Report 2007/472.

http://eprint.iacr.org/.

Barker, E., Barker, W., Burr, W., Polk, W., Smid, M., Gal-

lagher, P. D., et al. (2012). Recommendation for key

management – part 1: General. NIST special publica-

tion, 800:57. Revision 3.

Barker, E., Burr, W., Jones, A., Polk, T., Rose, S., Smid,

M., and Dang, Q. (2015). Recommendation for key

management – part 3: Application-speciﬁc key man-

agement guidance. NIST special publication, 800:57.

Revision 1.

Bellare, M., Kohno, T., and Namprempre, C. (2004). Break-

ing and provably repairing the ssh authenticated en-

cryption scheme: A case study of the encode-then-

encrypt-and-mac paradigm. ACM Transactions on In-

formation and System Security (TISSEC), 7(2):206–

241.

Bellare, M. and Namprempre, C. (2000). Authenticated en-

cryption: Relations among notions and analysis of the

generic composition paradigm. In Advances in Cryp-

tology—ASIACRYPT 2000, pages 531–545. Springer.

Bernstein, D. J. (2005). The poly1305-aes message-

authentication code. In Fast Software Encryption,

pages 32–49. Springer.

Bernstein, D. J. (2006). Curve25519: new difﬁe-hellman

speed records. In Public Key Cryptography-PKC

2006, pages 207–228. Springer.

Bernstein, D. J. (2008). Chacha, a variant of salsa20. In

Workshop Record of SASC, volume 8.

Bernstein, D. J., Duif, N., Lange, T., Schwabe, P., and Yang,

B.-Y. (2012). High-speed high-security signatures.

Journal of Cryptographic Engineering, 2(2):77–89.

Borisov, N., Goldberg, I., and Wagner, D. (2001). Intercept-

ing mobile communications: the insecurity of 802.11.

In Proceedings of the 7th annual international con-

ference on Mobile computing and networking, pages

180–189. ACM.

Degabriele, J. P. and Paterson, K. G. (2010). On the (in)

security of ipsec in mac-then-encrypt conﬁgurations.

In Proceedings of the 17th ACM conference on Com-

puter and communications security, pages 493–504.

ACM.

Dierks, T. and Rescorla, E. (2006). The transport layer secu-

rity (tls) protocol version 1.1. RFC 4346, RFC Editor.

http://www.rfc-editor.org/rfc/rfc4346.txt.

Dierks, T. and Rescorla, E. (2008). The transport layer secu-

rity (tls) protocol version 1.2. RFC 5246, RFC Editor.

http://www.rfc-editor.org/rfc/rfc5246.txt.

Dworkin, M. (2007). Recommendation for block cipher

modes of operation: Galois/Counter Mode (GCM)

and GMAC. US Department of Commerce, National

Institute of Standards and Technology.

Ford-Hutchinson, P. (2005). Securing ftp with tls. RFC

4217, RFC Editor. http://www.rfc-editor.org/rfc/

rfc4217.txt.

On TLS 1.3 - Early Performance Analysis in the IoT Field

123

Gutmann, P. (2014). Encrypt-then-mac for transport

layer security (tls) and datagram transport layer se-

curity (dtls). RFC 7366, RFC Editor. http://

www.rfc-editor.org/rfc/rfc7366.txt.

Hoffman, P. (2002). Smtp service extension for secure smtp

over transport layer security. RFC 3207, RFC Editor.

http://www.rfc-editor.org/rfc/rfc3207.txt.

Ishiguro, T. (2012). Modiﬁed version of” latin dances re-

visited: New analytic results of salsa20 and chacha”.

IACR Cryptology ePrint Archive, 2012:65.

Josefsson, S. and Mavrogiannopoulos, N. (2015). Using

eddsa with ed25519/ed448 in the internet x.509 pub-

lic key infrastructure. Internet-Draft draft-josefsson-

pkix-eddsa-04, IETF Secretariat. http://www.ietf.org/

internet-drafts/draft-josefsson-pkix-eddsa-04.txt.

Josefsson, S. and Pegourie-Gonnard, M. (2015).

Curve25519 and curve448 for transport layer security

(tls). Internet-Draft draft-ietf-tls-curve25519-01,

IETF Secretariat. http://www.ietf.org/internet-drafts/

draft-ietf-tls-curve25519-00.txt.

Kent, S. and Atkinson, R. (1998). Ip encapsulating

security payload (esp). RFC 2406, RFC Editor.

http://www.rfc-editor.org/rfc/rfc2406.txt.

Koschuch, M., Hudler, M., and Kr

uger, M. (2012). The

price of security: A detailed comparison of the

tls handshake performance on embedded devices

when using elliptic curve cryptography and rsa. In

e-Business and Telecommunications, pages 71–83.

Springer.

Krawczyk, H. (2001). The order of encryption and authenti-

cation for protecting communications (or: How secure

is ssl?). In Advances in Cryptology—CRYPTO 2001,

pages 310–331. Springer.

Langley, A., Chang, W.-T., Mavrogiannopoulos, N.,

Strombergson, J., and Josefsson, S. (2015).

Chacha20-poly1305 cipher suites for transport layer

security (tls). Internet-Draft draft-ietf-tls-chacha20-

poly1305-03, IETF Secretariat. http://www.ietf.org/

internet-drafts/draft-ietf-tls-chacha20-poly1305-

03.txt.

McGrew, D. (2008). An interface and algorithms for

authenticated encryption. RFC 5116, RFC Editor.

http://www.rfc-editor.org/rfc/rfc5116.txt.

McGrew, D. and Viega, J. (2004). The galois/counter

mode of operation (gcm). Submission to NIST. http://

csrc.nist.gov/CryptoToolkit/modes/proposedmodes/

gcm/gcm-spec. pdf.

oller, B., Duong, T., and Kotowicz, K. (2014). This poo-

dle bites: Exploiting the ssl 3.0 fallback.

Nir, Y. and Langley, A. (2015). Chacha20 and poly1305

for ietf protocols. RFC 7539, RFC Editor. http://

www.rfc-editor.org/rfc/rfc7539.txt.

Rescorla, E. (2000). Http over tls. RFC 2818, RFC Editor.

http://www.rfc-editor.org/rfc/rfc2818.txt.

Rescorla, E. (2015). The transport layer security (tls) proto-

col version 1.3. Internet-Draft draft-ietf-tls-tls13-10,

IETF Secretariat. http://www.ietf.org/internet-drafts/

draft-ietf-tls-tls13-10.txt.

Rogaway, P. (2002). Authenticated-encryption with

associated-data. In Proceedings of the 9th ACM con-

ference on Computer and communications security,

pages 98–107. ACM.

Saint-Andre, P. (2011). Extensible messaging and pres-

ence protocol (xmpp): Core. RFC 6120, RFC Editor.

http://www.rfc-editor.org/rfc/rfc6120.txt.

Salowey, J., Choudhury, A., and McGrew, D. (2008).

Aes galois counter mode (gcm) cipher suites for tls.

RFC 5288, RFC Editor. http://www.rfc-editor.org/

rfc/rfc5288.txt.

Shi, Z., Zhang, B., Feng, D., and Wu, W. (2013). Im-

proved key recovery attacks on reduced-round salsa20

and chacha. In Proceedings of the 15th Interna-

tional Conference on Information Security and Cryp-

tology, ICISC’12, pages 337–351, Berlin, Heidelberg.

Springer-Verlag.

Ylonen, T. and Lonvick, C. (2006). The secure shell (ssh)

transport layer protocol. RFC 4253, RFC Editor.

http://www.rfc-editor.org/rfc/rfc4253.txt.

APPENDIX

This Appendix reports the space requirements for el-

liptic curves primitives when performing signature

and key exchange, AEAD ciphers software and -

where is possible - hardware implementations, and

negotiated cipher suite for completing a full TLS 1.2

handshake.

ICISSP 2016 - 2nd International Conference on Information Systems Security and Privacy

124

Table 4: Space requirements for elliptic curves expressed in bytes.

Algorithm Stack Heap Total RAM Code Const. data Total FLASH

NIST P-256 Key exchange 2,188 7,108 9,296

15,810 3,520 19,330

NIST P-256 Signature 2,052 9,316 11,368

Curve25519 2,948 144 3,092

39,122 32,155 71,277

Ed25519 5,356 96 5,452

Table 5: Space requirements for authenticated ciphers expressed in bytes.

Algorithm Stack Heap Total RAM Code Const. data Total FLASH

Chacha20-poly1305 604 0 604 3,300 52 3,352

AES128-GCM SW 4,804 11,644 16,448 3,288 10,846 14,134

AES128-CBC-HMAC-SHA1 SW 1,004 3,841 4,845 4,502 10,360 14,862

AES128-GCM HW 440 0 440 978 0 978

AES128-CBC-HMAC-SHA1 HW 712 0 712 2,180 10 2,190

Table 6: Space requirements for TLS 1.2 full handshake expressed in KBytes.

Cipher suite Authentication

Client Server

Stack Heap Total RAM Stack Heap Total RAM

DH ANON None 2.64 19.53 22.17 2.75 22.77 25.52

DH RSA

One way 3.91 21.27 25.18 2.75 22.79 25.54

Mutual 3.91 22.47 26.38 3.96 23.13 27.09

DHE RSA

One way 3.91 21.48 25.39 2.75 22.78 25.53

Mutual 3.92 24.37 28.29 3.96 24.64 28.6

RSA RSA

One way 3.91 13.55 17.46 2.75 18.55 21.3

Mutual 3.91 21.16 25.07 3.96 20.41 24.37

ECDH ANON None 2.53 10.37 12.80 2.69 12.36 15.05

ECDH ECDSA

One way 3.58 13.73 17.31 2.81 11.38 14.19

Mutual 3.63 14.61 18.24 3.63 14.67 18.3

ECDH RSA

One way 3.91 13.41 17.32 2.75 11.86 14.61

Mutual 3.92 14.62 18.54 3.96 15.69 19.65

ECDHE ECDSA

One way 3.58 13.79 17.37 2.75 12.06 14.81

Mutual 3.58 14.67 18.25 3.63 14.98 18.61

ECDHE RSA

One way 3.91 13.66 17.57 2.75 19.1 21.85

Mutual 3.91 21.27 25.18 3.96 19.1 23.06

On TLS 1.3 - Early Performance Analysis in the IoT Field

125