IN DEGREE PROJECT TECHNOLOGY,FIRST CYCLE, 15 CREDITS

, STOCKHOLM SWEDEN 2019

A Comparison of the Password-Authenticated Key Exchange Protocols, SRP-6a and PAKE2+

FREDIK SEBEK

OLIVER PETRI

KTH ROYAL INSTITUTE OF TECHNOLOGYSCHOOL OF ELECTRICAL ENGINEERING AND COMPUTER SCIENCE

A Comparison of thePassword-Authenticated KeyExchange Protocols, SRP-6aand PAKE2+

FREDRIK SEBEK

OLIVER PETRI

Bachelor in Computer ScienceDate: June 20, 2019Supervisor: Arvind KumarExaminer: Örjan EkebergSchool of Electrical Engineering and Computer ScienceSwedish title: En komparativ studie av lösenordsbaseradautentisering för nyckeldelning, SRP-6a och PAKE2+

iii

AbstractPrivacy is a rising concern globally, and more of our personal information isstored online. It is therefore, important to securely authenticate and encryptall communication between the client and the server. Password authenticatedkey-exchange (PAKE) protocols are promising schemes for more secure pass-word authentication on the web. This report looks at both the theoretical andpractical aspects of the PAKE protocols, SRP-6a and PAKE2+, from a busi-ness perspective. Benchmarks were used to determine the overall performanceof both the protocols using latency and memory as metrics. The benchmarkedimplementations are written in JavaScript. Furthermore, availability of proto-col implementations and theoretical security aspects such as crypto primitiveswere also analyzed. Our results indicate that SRP6-a is likely the more viablealternative for businesses today. Measured latencies ranged from 368 to 521ms for PAKE2+ and 114 to 230 ms for SRP-6a, depending on the browser.SRP-6a is not only significantly faster than PAKE2+, but it has greater mar-ket adoption and maturity, which PAKE2+ lacks in comparison. However,PAKE2+ has a stronger theoretical security footprint, which may make it astrong contender in the future.

iv

SammanfattningIntegritet på internet är en stigande oro och mer av vår personliga informationlagras på servrar online. Det är därför viktigt att säkert autentiera och krypteraall kommunikation mellan klienterna och servern. Protokoll för Lösenordsau-tentiserat Nyckelutbyte (PAKE) är lovande för säkrare lösenordsautentiseringpå webben. Denna rapport tittar på både de teoretiska och praktiska aspek-terna av PAKE-protokollen, SRP-6a och PAKE2+, ur ett företagsperspektiv.Benchmarks användes för att bestämma den övergripande prestandan för bådaprotokollen med avseende på hasighet och minne. De benchmarkerade imple-mentationerna är skrivna i JavaScript. Dessutom analyserades tillgänglighetenav protokollimplementeringarna och deras teoretiska säkerhetsaspekter. Våraresultat tyder på att SRP6-a sannolikt är det mer användbara alternativet förföretag idag. Mätvärdena varierade mellan 368 och 521 ms för PAKE2+ ochmellan 114 och 230 ms för SRP-6a, beroende på webbläsare. SRP6-a är intebara betydligt snabbare än PAKE2+ men har också större marknadsupptag-ning och mognad, vilket PAKE2+ saknar i jämförelse. PAKE2+ har dock ettstarkare teoretiskt säkerhetsfotavtryck, vilket kan göra det till en stark konkur-rent i framtiden.

Contents

1 Introduction 31.1 Privacy and Digitalization . . . . . . . . . . . . . . . . . . . 41.2 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 51.3 Limitations and scope . . . . . . . . . . . . . . . . . . . . . . 5

2 Background 62.1 Transport security layer (TLS) . . . . . . . . . . . . . . . . . 6

2.1.1 Password over TLS . . . . . . . . . . . . . . . . . . . 62.2 Zero Knowledge Proofs . . . . . . . . . . . . . . . . . . . . . 72.3 Password-authenticated key exchange . . . . . . . . . . . . . 8

2.3.1 Diffie–Hellman key exchange . . . . . . . . . . . . . 82.3.2 Types of PAKE . . . . . . . . . . . . . . . . . . . . . 92.3.3 Security . . . . . . . . . . . . . . . . . . . . . . . . . 92.3.4 PAKE in practice . . . . . . . . . . . . . . . . . . . . 102.3.5 Implementations . . . . . . . . . . . . . . . . . . . . 11

3 Method 163.1 Creating benchmarks . . . . . . . . . . . . . . . . . . . . . . 173.2 Benchmarking . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4 Results 184.1 Security analysis . . . . . . . . . . . . . . . . . . . . . . . . 20

4.1.1 Attributes . . . . . . . . . . . . . . . . . . . . . . . . 204.2 Elliptic Curve . . . . . . . . . . . . . . . . . . . . . . . . . . 214.3 Key confirmation . . . . . . . . . . . . . . . . . . . . . . . . 214.4 Salt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224.5 Server security . . . . . . . . . . . . . . . . . . . . . . . . . 22

i

ii CONTENTS

5 Discussion 235.1 "The first contact problem" . . . . . . . . . . . . . . . . . . . 235.2 Implementation details . . . . . . . . . . . . . . . . . . . . . 245.3 Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . 245.4 Adoption . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

6 Conclusion 26

Bibliography 27

A Code 31

Glossary

adversaries Plural form of adversary. 4, 7

adversary A malicious entity within in a cryptographic system. 1, 3, 9, 10,21, 22

brute force attack An attack to gain authentication to a system by consciouslytrying various combinations of passwords until it succeeds. 4

dictionary attack An attack to gain authentication to a system by generatingpotential passwords from a large subset of commonly used words. 4, 9,22

eavesdropper A third party listening in on other parties communication. 9

ECC Elliptic Curve Cryptography. 21

hash function A one way function, which takes a string as input and producesa fixed size string output, which seems random in relation to the originalinput. 9, 21

IETF Internet Engineering Task Force. 6, 25

JavaScript JavaScript is a programming language, which is widely used bywebsites and runs primarily in browsers. 5, 11, 14

man-in-the-middle (MITM) An attack where an adversary intercepts, re-lays, or alters the communication between the victim and the victim’sintended host. 6

PAKE Password-authenticated key exchange. A family of cryptographic pro-tocols that allows two parties to exchange a high entropy key using aweaker shared password. 3, 4, 13, 24

1

2 Glossary

PAKE2+ A more modern PAKE implementation of the type augmented. 20,22

password stretching The process of hashing a password recursively, thusmak-ing it more computationally demanding to guess. 21, 22

salt Random n-bit number to be concatenatedwith a password before hashing.9, 21, 22

SJCL Stanford JavaScript Crypto Library. "A secure, powerful, fast, small,easy-to-use, cross-browser library for cryptography in Javascript"[1]. 11

SRP Secure Remote Password Protocol. 10, 11

SRP-6a The latest augmented SRP protocol. 11, 20, 22

TLS Transport Layer Security. 4, 9, 11

Chapter 1

Introduction

Encryption is the process of encoding information in a way only authorizedparties can consume it. Encryption has been in the forefront of protecting hu-man privacy, by keeping confidential and sensitive information safe and secureon the internet [2]. Passwords are currently the go-to approach for handling au-thentication on the internet [2]. However, human chosen passwords are usuallyweak, frequently re-used, and even sent in clear-text [3]. That being throughan encrypted channel or not.

Today, websites use encrypted traffic over TLS (HTTPS) for security, buteven TLS has its problems. An encrypted channel may be established withan adversary server, allowing the adversary to decrypt the password sent [4].Evenwhen the password is sent to an honest server, it is decrypted at the server,which allows for password leaks or implementation bugs, such as logging orstoring plain text passwords. In 2016, Twitter urged all their users, 330million,to change their passwords, after logging them in plain text [5].

Using a password-authenticated key exchange (PAKE) protocol on top ofa TLS channel can provide a safer way for users to authenticate themselvesonline. A PAKE protocol allows two parties to establish an encrypted channelwithout the user having to send their actual password.

PAKE protocols date back as far as 1992 [6]. However, due to variousreasons such as patents and privacy concerns, growing interest in PAKE canbe seen. The latest PAKE protocol is OPAQUE, which was defined in 2018[4], the Internet Research Task Force published a requirements document forPAKE in 2017 [7] and multiple cryptography professors have recent (2018)blog posts advocating for PAKE [8][9].

3

4 CHAPTER 1. INTRODUCTION

1.1 Privacy and DigitalizationWith the increase in the amount of personal data we put online, especiallythat case of sensitive information, privacy has become a growing worry [10].Personal information is distributed and disseminated all over the world. Thispersonal data is collected by adversaries through data breaches. "Many com-panies face the risk of a data breach exposing stored personal information ofcustomers and employees. The frequency of such incidents has been increas-ing over time" [11] The internet has not just created the age of information,but also the age of information collection, "the big data age" [12].

Naturally, the strongest protection for privacy is strong encryption from theclient to the server. Today, single factor authentication (username and pass-word) are prone to vulnerabilities [2]. Users often chose weak passwords [2],which adversaries are able to steal using sophisticated techniques such as bruteforce attack and dictionary attacks [13]. Furthermore companies cannot andbe trusted to safely manage passwords. Even large companies such as Twitter,Facebook, and Amazon, face data breaches with twitter even logging pass-words in clear-text [5].

The European union article 8 states, "Everyone has the right to the protec-tion of personal data concerning him or her." [14]. With our current system,we do not have control over what happens to our passwords and informationat the other end (the server).

PAKE protocols can serve as an alternative to the common method of au-thenticating a client and server using passwords. Sending passwords overTLS in plain-text pose some security risks that PAKE protocols can elimi-nate. While password over TLS may be sufficient for some applications, itis unclear why PAKE is not used more in practice considering its theoreticalbenefits such as not sending passwords and beingmore resistant to adversaries.

Practical implementation details of the protocol have to be considered along-side theoretical proofs. A protocol proven secure mathematically can stillbreak and leak information if it is not implemented well [7].

To ensure a future where humans can share data with each other securelyand maintain their right to privacy, we explore the practicality and security oftwo PAKE protocols from a business perspective.

CHAPTER 1. INTRODUCTION 5

1.2 Problem StatementWhich of the two PAKE protocols, SRP-6a and PAKE2+ is the most suitablefor business applications with respect to latency, memory, and security?

1.3 Limitations and scopeThere are 12 well-documented PAKE protocols proposed and implemented invarious languages. Some of which not included in this research are:

• OPAQUE (briefly mentioned in the introduction)

• EKE

• AMP

• J-PAKE

• Dragonfly

• SPEKE

Only SRP-6a and PAKE2+ are closely investigated in the research. Theprogramming language, JavaScript, is the only programming language ex-plored. The reasoning for these limitations and choices are discussed in themethod chapter.

Chapter 2

Background

2.1 Transport security layer (TLS)TLS 1.0 was created in 1999 by Internet Engineering Task Force (IETF) asan successor of SSL created by Netscape in 1994 [15]. The purpose of TLSis to ensure information that goes from your device to any other device web-site is encrypted and secure [15]. However, encryption is not of much useif you aren’t communicating with the correct party (device, host, server etc)Therefore, TLS also manages the verification of identities and the preventionof man-in-the-middle (MITM) attacks, eavesdropping, tampering, and mes-sage forgery [15]. This is full-filled by ensuring integrity between both parties,and the data being transferred. The lastest standard of TLS 1.3 was defined inAugust of 2018 [16].

TLS is very widely adopted through HTTPS with 95% of popular websitessupporting at least TLS 1.2 [17]. Having a particular PAKE implementationintegrated into TLS is a large step towards a more widen adoption. Further-more, it drastically reduces and simplifies the implementation complicationsof having individual businesses create an own implementation.

2.1.1 Password over TLSToday, it is standard practice to send passwords in plain-text to a server. How-ever, this statement by itself is somewhat deceptive. Most communication be-tween two parties is transferred through an encrypted channel via TLS. Eventhough TLS greatly complicates attacks from dishonest parties, it is not per-fect by any means. In 2015 the IETF released a report, "Summarizing KnownAttacks on Transport Layer Security", which listed over 13 known vulnerabil-

6

CHAPTER 2. BACKGROUND 7

ities:

• Theft of RSA Private Keys: When TLS is used with most non-Diffie-Hellman cipher suites, it is sufficient to obtain the server’s private keyin order to decrypt any sessions [18]

• Renegotiation: A major attack on the TLS renegotiation mechanism ap-plies to all current versions of the protocol [18].

• ...

Passwords are a convenient way of handling authentication on the internet.However, they are frequently re-used, meaning a single successful attack by adishonest party leads to a user having to change their password everywhere.Therefore, avoiding sending the password as much as possible is an effectiveapproach of protecting users’ passwords from reaching adversaries. This isexactly what password-authenticated key exchange aims to do.

2.2 Zero Knowledge ProofsThe discovery of Zero Knowledge Proofs in 1989 by Shafi Goldwasser, SilvioMicali, and Charles Rackoff gave the rise to a new type of encryption, PAKE[19]. Zero Knowledge proof is a mathematical system in which one party canprove to another party that the given statement is valid or true, without con-veying any information except that the given statement is indeed true [19].Essentially, Zero knowledge proof allows for a shared agreement between twoparities without giving up the secret they share. Zero Knowledge proof pro-vides the following properties:

• Completeness: if the provided statement is true, an honest verifier willbe convinced.

• Soundness: if the provided statement is false, cheating cannot convincea honest provider. (except to some small probability).

• Zero-knowledge: if the statement is true, nothing else is conveyed ex-cept between the two parties.

[19]These properties in theory hold for PAKE.

8 CHAPTER 2. BACKGROUND

2.3 Password-authenticated key exchangeThe first type of Password-authenticated key exchange (PAKE) protocol en-crypted key exchange (EKE) was initially described by Bellovin and Merrittin 1992 [6].

PAKE protocols allows for two or more entities to authenticate each otherand create an encrypted channel for further communication using a sharedpassword. This is accomplished by creating a shared cryptographic key de-rived from a pre-shared human-memorable password. The password or keyis never sent, but parties in the exchange can prove possession of the sharedpassword and thus authenticate [20].

When both parties have computed the same session key, it is used to sym-metrically encrypt all data sent in the session. This encryption is strong as thegenerated key is high entropy, i.e seemingly random, long and hard to guess.No party has to remember or store the session key in between sessions as a newkey can and should be generated for every successful authentication (login).

Figure 2.1: Flow diagram of a generalized augmented PAKE implementation

PAKE protocols generally have two components, session key exchange andkey confirmation. An explicit key confirmation step is not necessary for settingup an encrypted channel but adds stronger authentication guarantees. If it isnot explicitly confirmed that both parties calculated the same session key, aserver will not immediately know that a bad password guess wasmade, makingit harder to detect an adversary online guessing attack.

2.3.1 Diffie–Hellman key exchangeThe Diffie-Hellman (DH) key exchange is a method of establishing a sharedsecret between to parties without sending the secret. Both parties derive thesame secret from random asymmetric keys sent over an insecure link [21].Diffie-Hellman key exchange on its own is vulnerable to man-in-the-middle

CHAPTER 2. BACKGROUND 9

attacks because the messages sent using the established shared key is not cryp-tographically signed, i.e it is unauthenticated.

PAKE protocols are typically extensions or variants of a Diffie-Hellmanexchange, using the shared password as part of the input for generating theshared secret (session key). This makes the key exchange authenticated andprevents against man-in-the-middle attacks, as the key depends on a passwordwhich is not sent.

2.3.2 Types of PAKEPAKE is not a complete protocol for communication over networks. It is inmost cases a part in a complete protocol like TLS. Depending on the settingin which PAKE is to be implemented, different types of PAKE may be used.An augmented PAKE may be the more secure option in a strict client-serversetting but impractical in a multi-party setting such as distributed systems. [7]

Balanced PAKE protocols rely on all parties knowing the password. Thesecurity of such protocol then depends on the security of password storage[22]. If a party is compromised the stored raw password may be leaked if theyare stored in plain-text. Any party can initiate the protocol in a balanced PAKEscheme. This may be a necessary property when client relationships are notknown.

Augmented PAKE assumes a two-party setting where one party may notknow the password, but only stores a derivative of the password [22]. This istypically a client-server relationship, where the server stores a hashed deriva-tive of the password [7].

For augmented PAKE, or aPAKE, a password verifier (a secret derivedfrom the password) is stored instead of a raw password. This is can be a hashof the password using a one way function. An attacker who knows the hashfunction can in this case pre-compute password hashes using a dictionary, anddecipher the passwords if the server is compromised. Some protocols use aunique salt for every client to protect against pre-computation attacks, but maysend that salt in plain-text if an attacker asks for it [23].

2.3.3 SecurityIdeally only an inevitable online guessing attack should be possible for anadversary. PAKE protocols are immune to offline dictionary attacks [4].

An eavesdropper in a PAKE setting does not learn anything about the pass-word by listening in on the communication between the two parties. The only

10 CHAPTER 2. BACKGROUND

way for the adversary to gain knowledge about the password is to guess andreceive a yes or no from interacting with the server. For example, sendingnetwork requests. Therefore, it is not possible to verify a guess without inter-acting with the server. This makes it impossible to run an offline dictionaryattack. An online guessing attack can be made, but that is detectable and hardto complete successfully [24].

While the communication channel may be secure, as discussed previouslya compromised server may leak passwords stored on file. Augmented PAKEprotocols address this issue with various degrees of security by using differentmethods of computing the password verifiers [4].

2.3.4 PAKE in practiceToday, as previously mentioned, the standard method for handling authenti-cation online is through a username (e-mail or free-text), and a password [2].Therefore, it would seem reasonable that PAKE based protocols were used ex-tensively to ensure safe password handling. "Given that many protocols aredesigned to use the user name and password method of authentication, beingable to safely use user names and passwords provides an easier route to addi-tional security." [25]. Even though there exist some usage of PAKE protocolsamong large companies such as Apple Inc. and 1Password, wide adoption isfar from reality. Apple Inc. and 1Password use variants of Secure RemotePassword Protocol (SRP) only in few selected services, where secure authen-tication is imperative [26].

With the current frequency of data breaches and the increasing storageof personal information online, it is reasonable for more businesses to con-sider using PAKE. The financial cost of data breaches and its toll on a com-panies reputation, is certainly becoming more costly. "The overall effect of adata breach on shareholder wealth is negative and statistically significant. Thenegative effect of a data breach on the firm’s stock price and that the negativemarket reaction to a data breach is more significant in the most recent timeperiods of the sample." [11]. Humans are increasingly valuing their right toprivacy. As a result companies are starting to take their security model intogreater consideration. Considerations such as using PAKE based protocol maylead to one of the PAKE implementations to become a standard in the future.

CHAPTER 2. BACKGROUND 11

2.3.5 ImplementationsThere exists many different implementations of PAKE protocols. Most imple-mentation also have different versions, which have been refined over time.

Based on availability and implementation consistency we limited the scopeof comparison to SRP-6a and PAKE2+. Both of these implementations aremature and have concrete mathematical proofs supporting their implementa-tions. Furthermore, Stanford University has readily available implementationsof both SRP-6a and PAKE2+ in JavaScript within SJCL.

Furthermore, only a few augmented PAKE protocols satisfies the securityrequirements of TLS 1.3. SRP and PAKE2+ are two of those. While the testsused for this report are not implemented in TLS, it is of great importance toachieve wide spread adoption [27].

SRP

SRP was created by Thomas J. Wu at Stanford University in 1997 [28]. SecureRemote Password (SRP) protocol is an augmented Password-based Authenti-cated Key Exchange (PAKE) protocol based on discrete logarithm problem(DLP) [28]. SRP was designed to work around existing patents, and be opensource. In an interview with Thomas J. Wu regarding SRP he stated, "OpenSource software has a big advantage, because it can move quickly on an ideaand not be burdened by bureaucracy or politics, but instead can focus on deliv-ering security to the end user using the best technical solution." [29]. Patentsand closed licences is a deterrent towards wider market adoption.

The flow diagram 2.2 details how a client and server reaches mutual agree-ment by deriving the same session key in SRP-6a. The diagram shows theverification and authentication steps, but ignores initial registration.

12 CHAPTER 2. BACKGROUND

Figure 2.2: Flow diagram of SRP-6a [30]

CHAPTER 2. BACKGROUND 13

In the original research paper, Thomas J. Wu states the following securityguarantees. This list excludes the standard benefits of a PAKE protocol.

• If the host’s password file is captured and the intruder learns the valueof v (shown in figure 2.2),it should still not allow the intruder to imper-sonate the user without an expensive dictionary search [28].

• If the session key of any past session is compromised, it should not helpthe intruder guess at or otherwise deduce the user’s password [28].

• If the user’s password itself is compromised, it should not allow theintruder to determine the session key K for past sessions and decryptthem. Even present sessions should at least be protected from passiveeavesdropping [28].

Like many protocols, SRP has had many iterations over its initial releasein 1997. Below you can find a summary of various changes that have beenmade in different versions. The purpose is to indicate that refinement takestime. Therefore protocol maturity is always a strength, as it is indicative thatrefinements have been made over time.

• SRP-1 was the original implementation of SRP. SRP-1 contained a vul-nerability that allowed an intruder to verify themselves as a particularuser given that the password database was compromised. This was re-solved in SRP-2 [31].

• SRP-2 does not contain any known security weaknesses. However, itsusage of composite modulus with unknown factorization makes param-eter certification an issue [32].

• ...

• SRP-6 is the newest version of SRP. It is resistant to all the well-knownpassive and active attacks over the network [33].

• SRP-6a is augmented based flavor of SRP-6.

Even the lastest verion of SRP, SRP6-a, has quite a wide range of availablelibraries in different languages.

• Nimbus SRP Implementation in Java

• csrp Implementation in C

14 CHAPTER 2. BACKGROUND

• Botan Implementation in C++

• pysrp Implementation in Python

• srp-rb Implementation in Ruby

• thinbus-srp-js Implementation in Javascript

• Crypt-SRP Implementation in Perl

This list is not exhaustive. It only serves to highlight the overall availabil-ity to developers, which is a great step towards adoption. Furthermore it isindicative of interest from the developer community. A large considerationwhy 1Password chose SRP was, "We didn’t want to roll our own solution"[34]. Developing your own implementation is not only time consuming, butrequires high expertise. Having a large selection of libraries in different lan-guages makes implementation more cost efficient and flexible for companies.Not only does SRP-6a have a large range of available libraries, SRP-6a is alsoreadily interchangeable with TLS. TLS-SRP is a set of ciphersuites for trans-port layer security, which is implemented in GnuTLS [25].

PAKE2+

PAKE2+ is an augmented variant of SPAKE2, a protocol proposed by Abdallain 2005. SPAKE2 is based on the first PAKE protocol, EKE, by Bellovin andMerritt [24]. The security of SPAKE2 relies on the hardness of the computa-tional Diffie-Hellman problem. The goal of SPAKE2was to achieve simplicityand strong security properties while minimizing the use of random oracles forefficiency. At the time of its proposal, Abdalla claims that SPAKE2 is as effi-cient, if not more efficient, than any other PAKE protocol [24].

This protocol doesn’t include a key authentication step, thus the SPAKE2protocol is secure under a threat of distinguishing a generated session key froma random string only.

There are two editions of implementation for the PAKE2+ protocol inJavaScript. PAKE2+EE is an alternative implementation of PAKE2+ whichuses Elligator for some operations. This may affect performance and security.According to Hamburg, the author of PAKE2+, the differences of PAKE2+and PAKE2+EE are as following:

"SPAKE2-EE is probably slightly better overall than SPAKE2. Itis slightly faster, has better security assumptions, and makes oneor two cases that can arise in SPAKE2 slightly easier. It is also

CHAPTER 2. BACKGROUND 15

more complicated to spec and implement, since you need Elli-gator. SPAKE2-vanilla needs more complicated optimizations toachieve its top speed, but at least you don’t have to spec them."

[35]Unlike SRP-6a, PAKE2+ has few revisions. There exists some libraries for

PAKE2+. Overall, the availability in quite limited. Especially with respect toSRP-6a. PAKE2+ is not available in TLS. However it is in theory compatiblewith a general PAKE extension as specified in a recent draft [27].

Chapter 3

Method

The implementations of PAKE2+, PAKE2+EE and SRP-6a compared werewritten in JavaScript using Standford JavaScript Crypto Library.

Both PAKE2+/PAKE2+EE and SRP-6a are augmented PAKE protocols.They are the augmented variants of SPAKE2 and SRP-6 respectively. Aug-mented protocols were chosen deliberately as they provide additional securityin the scenario of interest where a client gets the password from user input anda server stores a derivative of the password. If the server is compromised, thepassword derivatives can be exposed but not the plain passwords directly.

An important aspect when it comes to the practicality of an encryptionprotocol is performance. Therefore latency and memory usage of SRP-6aand PAKE2+/PAKE2+EE implementations were compared using tests. Thetests are small programs intended to mimic a real world scenario. PAKE2+EEor PAKE2+ Elligation Edition is conceptually the same as PAKE2+ but usesdifferent calculation at some points in the implementation, which may affectperformance.

It is of interest to benchmark JavaScript implementations that can run inthe browser since the that would allow for adoption of a protocol in internetapplications without the need for built-in browser support. It opens up for cus-tom implementations and support on systems where a native implementationcan’t be installed. It is also, like in the case with SJCL, possible to run thecode in a server environment such as NodeJS. This allows both the client andserver to have the same implementation making adoption easier.

The following metrics were used for benchmarking:

• Latency

• Memory

16

CHAPTER 3. METHOD 17

3.1 Creating benchmarksTo create a fair benchmark the SRP-6a and PAKE2+/PAKE2+EE implementa-tions were merged into a single project. The library was then recompiled. TheSJCL library has a built in test runner for testing in the browser. The next stepconsist of writing comparable tests for both SRP-6a and SPAKE2+. The codewith benchmarks respective benchmarks can be found on Github (https://gits-15.sys.kth.se/fsebek/kexjobbet-benchmarks) and inthe appendix.

3.2 BenchmarkingThe test case used is a full key exchange performed between a client and serverassuming both parties have knowledge of a shared password before the ex-change is initiated. It is also known beforehand which party is the client andwhich is the server since augmented PAKE protocols are designed with thisassumption in mind. Note that the client and server are not separate programsor even separate machines when testing. Client and server in the context of atest are data structures in the test program holding the necessary data for thekey exchange. This approach avoids external factors such as network latencyand concurrency.

All tests are run on a MacBook Pro 2017, 2.3 GHz Intel Core i5 machine.The built-in browser profilers were used for measuring latency of the differentparts of the tests. This allows for more detailed analysis of latency throughoutthe protocol execution.

Since the benchmark system itself takes time and usesmemory to initialize,the system was run without actually performing any of our own written tests.This was to done to ensure there was a basis to subtract our result from.

Some variation due to the operating system and hardware is unavoidable.To minimize this variance, the tests for latency and memory usage were run 10times for each respective implementations, resulting in a total of 40 trial runs.

Chapter 4

Results

Figure 4.1 below shows the average latency in Chrome for the 10 trial runs.SRP-6a was the fastest with an average speed of 114.5 ms, while PAKE2+ wasthe slowest with an average speed of 439 ms.

Figure 4.1: Latency - Chrome

Figure 4.2 below shows the average latency in Safari for the 10 trial runs.SRP-6a was the fastest with an average speed of 230.8 ms, while PAKE2+ wasthe slowest with an average speed of 521.3 ms.

18

CHAPTER 4. RESULTS 19

Figure 4.2: Latency - Safari

Table 4.1 summarizes all the trial runs, displaying the average and standarddeviation for each respective protocol and browser.

Chrome SafariProtocol µ (ms) σ (ms) µ (ms) σ (ms)PAKE2+ 439 8.8 521 9.0PAKE2+EE 368 7.6 418 6.9SRP-6a 114 1.3 231 1.8

Table 4.1: Average latency and standard deviation of trials by protocol and browser

20 CHAPTER 4. RESULTS

Besides password stretching, almost all compute time was spent multiply-ing points on curves, i.e doing the math necessary for generating the keys andkey material. Performance is thus closely tied to the protocol design.

It is clear from table 4.1 that performing the key exchange with SRP-6awas at least twice as fast as PAKE2+/PAKE2+EE. The standard deviation σ foreach set of 10 runs show that the variance in latency is largely negligible. SRP-6a is about twice as fast in Chrome as in Safari. The large difference betweenbrowsers may be due to differences in how Chrome’s V8 engine and Safari’sJavaScriptCore runs and potentially compiles the computation intensive partsof the code.

PAKE2+EE is slightly faster than standard PAKE2+ while still having atleast twice the latency of SRP-6a. The latencies are generally large enough tobe perceivable for a human user.

The average memory usage of the ten trials was 3353 Kb for PAKE2+ and3267 Kb for SRP-6a. The memory difference between the two implementa-tions are negligible. This outcome, in afterhand, is rather reasonable giventhat the calculated key and intermediate key material are the only values thatneeds to be stored in memory in the exchange. Saving values in memory mayactually pose a security risk. Therefore, memory usage between the two im-plementation will not be taken into strong consideration.

4.1 Security analysisIn order to evaluate the difference between the protocols with respect to la-tency, it was important for us to understand the security guarantees betweenthem. Slower performance may be justifiable in the case of guaranteeingstronger security. Therefore the following sections outlines the crypto primi-tives of each protocol.

4.1.1 AttributesThe protocols and their implementations share some structure, as they are bothaugmented PAKE protocols, but vary in implementation details which affectperformance and security. The cryptographically significant aspects of thebenchmarked implementations are compared in table 4.2:

CHAPTER 4. RESULTS 21

Property PAKE2+ SRP-6aEncryption support elliptic curve finite field

hash function SHA-256 (256 bit) SHA-1 (160 bit)password stretching PBKDF2 20000 iterations optionalKey confirmation implicit, optionally explicit explicit

Group 256 bit elliptic curve 1024 bit finite fieldsalt 128 bit 64 bit

Key size 256 bit 160 bitMessage count 3 + 2 for added explicit key conf 4

Table 4.2: Protocol implementation details

As shown in table 4.2, the bit lengths are generally larger for PAKE2+indicating stronger crypto primitives. Other differences in security propertiesare further analyzed below.

4.2 Elliptic CurveA major difference between the two protocols is that PAKE2+ uses ellipticcurve cryptography where as SRP-6a does not support it due to its mathemat-ical nature. Elliptic Curve Cryptography (ECC) uses smaller keys comparedto non-EC cryptography for equivalent security, which makes the use of ECCinteresting for PAKE implementations [7]. A 256-bit elliptic curve, whichPAKE2+ uses, is comparable to a 3072-bit group. The benchmarked imple-mentation of SRP-6a uses a 1024 bit group, providing weaker security thanthe elliptic curve. While it is possible to use larger groups with SRP, it wouldrequire more computations and negatively impact latency.

4.3 Key confirmationIn the original paper for SPAKE2 [24] explicit key confirmation is not includedin the protocol execution. However it can be added as an additional step inpractice.

If an adversary guesses a wrong password and computes an invalid ses-sion, the honest user does not know that a bad guess has been made unlessan explicit key confirmation is required by the user. If the adversary’s sessionkey is invalid, no communication can be decrypted and while this might bepossible to detect it can be more practical to have the PAKE protocol knowdirectly when this is the case. Enforcing explicit key confirmation thus makes

22 CHAPTER 4. RESULTS

detecting online dictionary attacks practical to implement while requiring twomore messages and computations, sacrificing performance and latency. ForPAKE2 and PAKE2+ explicit key confirmation is highly recommended [36].

In SRP-6a a variant of explicit key confirmation is performed during thekey exchange. The client sends an authentication messages created using itssession key along with other data. The server generates its own authenticationmessage using its session key and the clients authentication message. This issent back to the client so the client can check authentication of the server andvice versa, effectively confirming the session key.

4.4 SaltBoth PAKE2+ and SRP-6a assume that the server stores the salt and sendsthe salt in the clear to the client when requested before the session key is ex-changed. This allows an adversary to get the salt for a particular user andpre-compute a dictionary attack, which can be launched if the server is com-promised. Thus, effectively making the salt inadequate as a security feature ona user basis [4]. Since it is required to know the identity (username) of a userto retrieve the salt, it is non-trivial for an adversary to pre-compute passwordsof an entire user database if salts are used. The use of salts in the protocolstherefor significantly enhance security in common applications such as web-sites storing many user accounts.

4.5 Server securityBoth protocols use salts to force an adversary to compute guesses after theserver is compromised thus making it time consuming to guess. However,as previously described, the salt can in both cases easily be retrieved by theadversary before a server compromise.

PAKE2+ uses PKDF2 for password stretching which would make it morecomputationally intensive to launch a dictionary attack on the verifier database,making it less feasible to restore passwords in a given amount of time. If, how-ever, the salt is retrieved before compromise, guesses could be pre-computed.Password stretching would in this case only make the pre-computation moretime consuming, but passwords could be restored almost instantly on compro-mise using the pre-computed guesses.

Chapter 5

Discussion

5.1 "The first contact problem"A large security issue with PAKE, which is rarely mentioned in research pa-pers, is the "the first contact problem". This is especially significant with aug-mented protocols of PAKE. Where the initial registration, will occur throughthe internet. A plain-text password derivative is sent through, for exampleTLS, during registration. A dishonest party could eavesdrop the honest par-ties password derivative. Even though registration is only done once. A suc-cessful, but highly unlikely attack, would allow a dishonest party to deceivethe server into granting authentication until, the password is either changedby the honest or dishonest party. The honest and the dishonest party becomeessential indistinguishable to the server. In these situations a password resetemail would work, thus allowing the honest party to regain access to their ac-count. However, this assumes an account registration was done using email.Furthermore it would require a new registration over TLS. The "First contactproblem" is not something PAKE can solve by itself, since it relies on bothparties having shared derivatives to form a common secret.

One approach that can be taken to make registration more secure is to firstsend a random temporary password derivative, generate a shared session key,and then finalize the registration using the encrypted channel from the sharedsession key. The honest party can now more safely send their actual password.This works by assuming that eavesdroppers are always behind in the infor-mation flow. Therefore, even if the eavesdropper would have access to thetemporary password derivative, by the time the dishonest party were to use itagainst the server, the honesty party would have already set their actual pass-word. Thus rendering the shared session key from derived from temporary

23

24 CHAPTER 5. DISCUSSION

password useless to the dishonest party.

5.2 Implementation detailsFrom a theoretical perspective, PAKE offers great amount security benefits,which by now the reader should already be fully aware of. However, the sharedPAKE security guarantees will only hold, if what it is implemented by is se-cure as well. Therefore, if PAKE were to be integrated browser side the imple-mentermust carefully design anUIwhere the user enters their passwords. Oth-erwise, an attack may use to exploit weaknesses in the UI to confuse the userto input their password incorrectly [37]. Furthermore, handling authentica-tion in a browser’s JavaScript environment may pose additional security riskssuch as code injection, malicious servers and side-channel attacks which canbe avoided using a built in browser implementation or separate client. SincePAKE may be used by several applications, it would be desirable from a secu-rity perspective to implement a PAKE manager it into the browser application(Chrome, Firefox, Safari...) [37]. Such implementation would drastically im-prove the performance and avoid common vulnerabilities faced by HTML andJavaScript. However, a user may use more than one browser. Therefore, hav-ing a independent software client running on the operating system, fully man-aging the inter-layer communication mechanism between various applicationrequesting authentication would be most secure and convenient approach forthe user [37].

5.3 PerformanceIt is surprising that the PAKE2+ implementation was considering how effi-cient and simple it is in theory. An implementation of SRP-6a with strongerhash functions, salt, group etc can be tested to match the security propertiesof PAKE2+ as closely as possible to better understand how performance andsecurity relate and whether the choices of such implementation details are themain cause for the difference in performance.

The performance of particular parts of SCJL such as SHA-256 or exponen-tiation with big numbers could be a source of great variance in performancecompared to machine code. These details would have to be tested individuallyfor a more granular performance analysis. The low level operations commonin cryptographic computation can have some hardware support on common

CHAPTER 5. DISCUSSION 25

systems, which may greatly affect performance if the instructions are accessi-ble to the implementation.

5.4 AdoptionNative implementations, built in browsers support, and TLS 1.3 integrationare not necessary for PAKE protocols. However, it is important step to ensureother vulnerabilities doesn’t impact its security benefits. Furthermore, PAKEprotocols will presumably not achieve significant adoption unless the practicalcomplexities of using it is abstracted away from users and developers alikeby native integration. Adoption of HTTPS for example has taken a long timedespite beingmore secure and having significant browser/OS support. As longas standard TLS works well for most use cases, the lack of urgency can preventadoption of PAKE. Some other possible reasons for the lack of wide adoptionmay include:

• Patents - Several PAKE protocols have been patented preventing use

• Two-Factor Authentication - easier to implement and does not require aprotocol change

• Financial risks - Cost of implementation, and user migration to a newprotocol

• Lack of incentive - Why invest money into increasing users security ifit does not provide any direct monetary gains?

• Standards inertia - technical standards takes time to change, especiallyif the current solution “works”.

While we have seen interest for PAKE from the IETF though multipleRFCs proposing and defining their use, none of them seem to be near comple-tion for use as a standard.

PAKE2+ and SRP-6a can, despite its lacking support in implementation,be used through SJCL or other implementations to provide strong security forcertain applications where the additional security is worth the complexities ofgood implementation. A typical example of such application is a passwordmanager. 1Password and Apple’s iCloud keychain are examples of passwordmanagers already using PAKE. These implementations are however not stan-dard out-of-box.

Chapter 6

Conclusion

The PAKE protocols compared can provide additional security over standardpassword over TLS as the protocols never send the password, use strong cry-pographic primitives and store verifiers server side.

Both PAKE2+ and SRP-6a are useful implementations in practice. SRP-6a is, in the case of JavaScript implementation, significantly faster. It alsohas TLS integration. Having stronger crypto primitives and supporting ECC,PAKE2+ is a good candidate for practical use, although the particular imple-mentation used is lacking in performance compared to SRP-6a.

Performance is in some cases slow enough, about 0.5 seconds, to be no-ticeable to a user and varies greatly between browsers, making it unsuitablein applications where very low latency is important. In applications wheresecurity is of great concern and some noticeable latency is tolerated, these im-plementations can be used to improve security. Integrating any of the protocolsinto browsers would allow for better security and likely better performance.

When choosing between using SRP-6a or PAKE2+ in an application today,SRP-6a is likely the more practical choice as it has more available implemen-tations, built in integration with TLS, is faster and secure enough for commonuse.

As PAKE2+ reaches more maturity in implementation, its security bene-fits such as supporting elliptic curve cryptography and having stronger cryptoprimitives might make it a competitive option.

SRP-6a and PAKE2+ aside, there is a larger concern. There is not muchtalk about PAKE at all from businesses. In the words of Rick Fillion from1Password, "the marketing department of augmented password-authenticatedkey agreement protocols is underfunded" [34].

26

Bibliography

[1] E. Stark, M. Hamburg, and D. Boneh. “Symmetric Cryptography inJavascript”. In: 2009 Annual Computer Security Applications Confer-ence. Dec. 2009, pp. 373–381. doi: 10.1109/ACSAC.2009.42.

[2] Nicholas J. Hopper and Manuel Blum. “Secure Human IdentificationProtocols”. In: Advances in Cryptology — ASIACRYPT 2001. Ed. byColin Boyd. Berlin, Heidelberg: Springer BerlinHeidelberg, 2001, pp. 52–66. isbn: 978-3-540-45682-7.

[3] Richard Shay et al. “Encountering Stronger Password Requirements:User Attitudes and Behaviors”. In: Proceedings of the Sixth Sympo-sium on Usable Privacy and Security. SOUPS ’10. Redmond, Wash-ington, USA: ACM, 2010, 2:1–2:20. isbn: 978-1-4503-0264-7. doi:10.1145/1837110.1837113. url: http://doi.acm.org/10.1145/1837110.1837113.

[4] Stanislaw Jarecki, HugoKrawczyk, and JiayuXu. “OPAQUE:AnAsym-metric PAKE Protocol Secure Against Pre-computation Attacks”. In:Jan. 2018, pp. 456–486. isbn: 978-3-319-78371-0. doi: 10.1007/978-3-319-78372-7_15.

[5] Twitter Support. We recently found a bug that stored passwords un-masked in an internal log. 2018. url: https://twitter.com/TwitterSupport/status/992132808192634881.

[6] S. M. Bellovin and M. Merritt. “Encrypted key exchange: password-based protocols secure against dictionary attacks”. In:Proceedings 1992IEEE Computer Society Symposium on Research in Security and Pri-vacy. May 1992, pp. 72–84. doi: 10.1109/RISP.1992.213269.

[7] Joern-Marc Schmidt.Requirements for Password-AuthenticatedKey Agree-ment (PAKE) Schemes. RFC 8125. Apr. 2017. doi:10.17487/RFC8125.url: https://rfc-editor.org/rfc/rfc8125.txt.

27

28 BIBLIOGRAPHY

[8] Bill Buchanan. Why Do We Still Pass Passwords Over a Network —Meet PAKE? 2018.url:https://medium.com/asecuritysite-when-bob-met-alice/why-do-we-still-pass-passwords-over-a-network-meet-pake-f51b197e835f.

[9] Matthew Green. Let’s talk about PAKE. 2018. url: https://blog.cryptographyengineering . com / 2018 / 10 / 19 / lets -talk-about-pake/.

[10] Ulrike Hugl. “Reviewing person’s value of privacy of online social net-working”. In: Internet Research 21.4 (2011), pp. 384–407. doi: 10.1108/10662241111158290. eprint: https://doi.org/10.1108/10662241111158290. url: https://doi.org/10.1108/10662241111158290.

[11] KevinM.Gatzlaff andKathleenMccullough. “The Effect of Data Breacheson Shareholder Wealth”. In: Risk Management and Insurance Review13 (Mar. 2010). doi: 10.1111/j.1540-6296.2010.01178.x.

[12] Jiexin Zang. “Information Privacy, Data Surveillance and Security–HowAus-tralian Privacy Law Fully Plays Its Role in the Age of BigData”. In:Journal of Educational Theory and Management 3 (Apr. 2019), p. 22.doi: 10.26549/jetm.v3i1.1168.

[13] Manoj Jayabalan and Thomas O’Daniel. “A Study on AuthenticationFactors in Electronic Health Records”. In: (Mar. 2019).

[14] EuropeanUnion.Charter of Fundamental Rights of the EuropeanUnion.Vol. 53. Brussels: European Union, 2010, p. 380.

[15] Eric Rescorla and TimDierks. The Transport Layer Security (TLS) Pro-tocol Version 1.2. RFC 5246. Aug. 2008. doi: 10.17487/RFC5246.url: https://rfc-editor.org/rfc/rfc5246.txt.

[16] Eric Rescorla. The Transport Layer Security (TLS) Protocol Version 1.3.RFC 8446. Aug. 2018. doi: 10.17487/RFC8446. url: https://rfc-editor.org/rfc/rfc8446.txt.

[17] Qualys SSL Labs. SSL Pulse. Accessed: 2019-05-18. url: https ://www.ssllabs.com/ssl-pulse/.

[18] Yaron Sheffer, RalphHolz, and Peter Saint-Andre. Summarizing KnownAttacks on Transport Layer Security (TLS) and Datagram TLS (DTLS).RFC 7457. Feb. 2015. doi: 10.17487/RFC7457. url: https://rfc-editor.org/rfc/rfc7457.txt.

BIBLIOGRAPHY 29

[19] S Goldwasser, S Micali, and C Rackoff. “The Knowledge Complexityof Interactive Proof-systems”. In: Proceedings of the Seventeenth An-nual ACMSymposium on Theory of Computing. STOC ’85. Providence,Rhode Island, USA: ACM, 1985, pp. 291–304. isbn: 0-89791-151-2.doi: 10.1145/22145.22178. url: http://doi.acm.org/10.1145/22145.22178.

[20] Kazuki Yoneyama. “Cross-Realm Password-Based Server Aided KeyExchange”. In: Information Security Applications. Ed. byYongwhaChungand Moti Yung. Berlin, Heidelberg: Springer Berlin Heidelberg, 2011,pp. 322–336. isbn: 978-3-642-17955-6.

[21] W. Diffie andM.Hellman. “NewDirections in Cryptography”. In: IEEETrans. Inf. Theor. 22.6 (Sept. 2006), pp. 644–654. issn: 0018-9448. doi:10.1109/TIT.1976.1055638. url: http://dx.doi.org/10.1109/TIT.1976.1055638.

[22] X. Liu, F. Zhou, and G. Chang. “Verifier-based password-authenticatedkey exchange protocol in cross-realm setting”. In: 2009Chinese Controland Decision Conference. June 2009, pp. 5560–5563. doi: 10.1109/CCDC.2009.5195187.

[23] Dr. HugoKrawczyk. TheOPAQUEAsymmetric PAKEProtocol. Internet-Draft draft-krawczyk-cfrg-opaque-01. Work in Progress. Internet Engi-neering Task Force, Dec. 2018. 20 pp.url:https://datatracker.ietf.org/doc/html/draft-krawczyk-cfrg-opaque-01.

[24] Michel Abdalla and David Pointcheval. “Simple Password-based En-crypted Key Exchange Protocols”. In: Proceedings of the 2005 Interna-tional Conference on Topics in Cryptology. CT-RSA’05. San Francisco,CA: Springer-Verlag, 2005, pp. 191–208. isbn: 3-540-24399-2, 978-3-540-24399-1. doi: 10.1007/978-3-540-30574-3_14. url:http://dx.doi.org/10.1007/978-3-540-30574-3_14.

[25] David Taylor et al. Using the Secure Remote Password (SRP) Proto-col for TLS Authentication. RFC 5054. Nov. 2007. doi: 10.17487/RFC5054. url: https://rfc-editor.org/rfc/rfc5054.txt.

[26] Xinwei Gao et al. “Post-Quantum Secure Remote Password Protocolfrom RLWE Problem”. In: Jan. 2018, pp. 99–116. isbn: 978-3-319-75159-7. doi: 10.1007/978-3-319-75160-3_8.

30 BIBLIOGRAPHY

[27] Richard Barnes. Usage of PAKE with TLS 1.3. Internet-Draft draft-barnes-tls-pake-04. Work in Progress. Internet Engineering Task Force,July 2018. 20 pp. url: https://tools.ietf.org/id/draft-barnes-tls-pake-04.html.

[28] ThomasDWu et al. “The Secure Remote Password Protocol.” In:NDSS.Vol. 98. Citeseer. 1998, pp. 97–111.

[29] Clipperz. Interview with Tom Wu, inventor of the SRP protocol. 2007.url:https://clipperz.is/blog/2007/01/04/interview_tom_wu_inventor_srp_protocol/.

[30] Ondrej Uzovic. Communication using Secure Remote Password pro-tocol. 2016. url: https : / / www . codeproject . com / KB /security/1082676/SrpAuthenticationSequence.png.

[31] Thomas Wu. url: http://srp.stanford.edu/design1.html.

[32] Thomas Wu. url: http://srp.stanford.edu/design2.html.

[33] Thomas Wu. url: http : / / srp . stanford . edu / design .html.

[34] Rick Fillion.Developers: How we use SRP, and you can too. 2018. url:https://blog.1password.com/developers-how-we-use-srp-and-you-can-too/.

[35] MikeHamburg. [curves] SPAKE2 and SPAKE2Elligator Edition. 2015.url:https://moderncrypto.org/mail-archive/curves/2015/000424.html.

[36] Dan Boneh and Victor Shoup. “A Graduate Course in Applied Cryp-tography”. In: 0.4. Sept. 2017.

[37] John Engler et al. “Is it too late for PAKE?” In: indicators 5.9 (2009),p. 17.

Appendix A

Code

PAKE2+ test code

new s j c l . t e s t . Te s tCase ( " SPAKE2 /PAKE2+ t e s t " , f u n c t i o n ( cb ) {i f ( ! s j c l . pake | | ! s j c l . misc | | ! s j c l . misc . hkdf | |! s j c l . hash . sha256 | | ! s j c l . ecc | | ! s j c l . random ) {

t h i s . un implemented ( ) ;cb && cb ( ) ;r e t u r n ;

}

va r s t r e t c h = f a l s e ;v a r useEE = t r u e ;l e t sharedKey1 = " password1 " ;i f ( s t r e t c h ) {

va r s a l t =s j c l . codec . hex . t o B i t s ( ’ BEB25379D1A8581EB5A727673A2441EE ’ ) ;sharedKey1 = s j c l . misc . pbkdf2 ( sharedKey1 , s a l t , 2 0000 ) ;

}aPake = s j c l . pake . c r e a t e P a k e 2P l u s ( " A l i c e " , " example . com " ,useEE ) ;bPake = s j c l . pake . c r e a t e P a k e 2P l u s ( " A l i c e " , " example . com " ,useEE ) ;/ / send aData t o s e r v e raData = aPake . s t a r t C l i e n t ( sharedKey1 ) ;/ / r e ad from DBdbData = bPake . g e n e r a t e S e r v e rD a t a ( sharedKey1 ) ;/ / send bData t o c l i e n t

31

32 APPENDIX A. CODE

bData = bPake . s t a r t S e r v e r ( dbData . pw_M, dbData . pw_N ,dbData . pw , dbData . pw2_G ) ;aKey = aPake . f i n i s h ( bData ) ;bKey = bPake . f i n i s h ( aData ) ;t h i s . r e q u i r e ( s j c l . b i t A r r a y . e qu a l ( aKey , bKey ) ,’Key no t match ’ ) ;

cb && cb ( ) ;} ) ;

SRP test code

new s j c l . t e s t . Te s tCase ( " SRP known−answer t e s t s " , f u n c t i o n ( cb ) {i f ( ! s j c l . keyex . s r p ) {

t h i s . un implemented ( ) ;cb && cb ( ) ;r e t u r n ;

}

va r i , k a t = s j c l . t e s t . v e c t o r . s rp , tv , hash ,group , v e r i f i e r , c l i e n t , s e r v e r ;

f o r ( v a r j =0 ; j <1 ; j ++) {t v = k a t [ 0 ] ;hash = s j c l . hash [ t v . hash ] ;group = s j c l . keyex . s r p . ge tGroup ( t v . group ) ;

s a l t = s j c l . codec . hex . t o B i t s ( t v . s ) ;

/∗ check c a l c u l a t e V e r i f i e r ∗ /c l i e n t = new s j c l . keyex . s r p . c l i e n t ( t v . I , t v . P ,hash , group ) ;v a r r e s = c l i e n t . c a l c u l a t e V e r i f i e r ( s a l t ) ;v e r i f i e r = s j c l . codec . hex . t o B i t s ( t v . v ) ;

/∗ check _ c a l c u l a t eX ∗ /c l i e n t = new s j c l . keyex . s r p . c l i e n t ( t v . I , t v . P ,hash , group ) ;v a r srpX = c l i e n t . c a l c u l a t eX ( s a l t ) . t o B i t s ( ) ;

APPENDIX A. CODE 33

/∗ check group . c a l c u l a t eK ∗ /v a r k = group . c a l c u l a t eK ( hash ) ;

/∗ check s u c c e s s ∗ /c l i e n t = new s j c l . keyex . s r p . c l i e n t ( t v . I , t v . P ,hash , group ) ;v a r c l i e n tA = c l i e n t . g e t C l i e n t C h a l l e n g e (s j c l . codec . hex . t o B i t s ( t v . a ) ) ;

s e r v e r = new s j c l . keyex . s r p . s e r v e r ( t v . I , s a l t ,v e r i f i e r , hash , group ) ;v a r s e r v e rB = s e r v e r . g e t S e r v e rCh a l l e n g e (s j c l . codec . hex . t o B i t s ( t v . b ) ) ;

v a r c l i e n tK = c l i e n t . s e t S e r v e rR e s p on s e ( s a l t ,s e r v e rB ) ;

v a r s e rve rK = s e r v e r . s e t C l i e n t R e s p o n s e ( c l i e n tA ) ;

t h i s . r e q u i r e ( s j c l . b i t A r r a y . e qu a l ( c l i e n tK , s e rve rK ) ," s r p K #" + i ) ;

}cb && cb ( ) ;

} ) ;

www.kth.se

TRITA-EECS-EX-2019:363