Appendix 8

Note:- Since Google blog does not support mathematical symbols support (or maybe I could not find any method for that, so I am pasting all the appendices in the form of Pictures. They were originally written in MS Word.

First, we consider PAKE Protocols that are proven secure in the implicit authentication model. Our enhancement is essentially the transformation by Bellare, Rogaway, and Pointcheval [BPR00] that adds mutual authentication to a PAKE protocol.

Appendix 7

Note:- Since Google blog does not support mathematical symbols support (or maybe I could not find any method for that, so I am pasting all the appendices in the form of Pictures. They were originally written in MS Word.

Appendix 6

Note:- Since Google blog does not support mathematical symbols support (or maybe I could not find any method for that, so I am pasting all the appendices in the form of Pictures. They were originally written in MS Word.

---------------------------------------------------------------------------------------------------------------------

Appendix 5

Note:- Since Google blog does not support mathematical symbols support (or maybe I could not find any method for that, so I am pasting all the appendices in the form of Pictures. They were originally written in MS Word.

------------------------------------------------------------------------------------------------------------------------------

Theorem 3.1

PAKE security in non-corruption model implies forward security in the weak corruption model (proof of the theorem provided in section 3.6)

Result Privacy. Let us assume that 2 honest users are having a communication where password for both of them is the same, in that scenario, a perpetrator who was observing the communication should not come to know about the fact that both users were using the same session key and hence the same password. In other words, we can say that if somehow, the perpetrator gets to know that both users are not sharing the same session key, he knows passwords are also different and vice versa.

Sadly, this idea of Result Privacy did not get much attention before due to the authentication problem for 2 reasons. First, it is quite evident to share the same password while interacting. Secondly, 2 users who regularly had successful communication in the past are more likely to interact successfully in the future. So, the chances of being recognized by an attacker are more. On the other hand, the idea of matching result privacy is a vital security property of our problem. Also, unlike traditional PAKE applications, the interaction between 2 users having matching wishes is also assumed to be anonymous. So, in our problem communication between 2 such users cannot be learned by the attacker. Therefore, result privacy is a very important property for a PAKE protocol in case where protocol us used as a foundation for privacy amplified matchmaking.

Appendix 4

Note:- Since Google blog does not support mathematical symbols support (or maybe I could not find any method for that, so I am pasting all the appendices in the form of Pictures. They were originally written in MS Word.