Corrections

report.tex

@@ -62,9 +62,9 @@
 \tableofcontents
 \newpage
 \section{Introduction}
-By definition, \emph{Encryption} is the process of converting information into a \emph{code} with the purpose of preventing unauthorized access \cite{oxford}. Traditionally, the way this was accomplished was via some a priori established secret key $k$, which could then be used both for \emph{encryption}, but also for \emph{decryption}. This concept was then challenged by the concept of \emph{Public Key Cryptography}, \texttt{PKE}, which allows two parties to communicate with each other in a secure and private fashion, without having already shared the aforementioned secret key. This allowed each party to have a \emph{Public Key} and a \emph{Secret Key}, which could then be used to encrypt and decrypt, respectively. This works well and is used in many applications, such as \emph{SSH} and \emph{SSL}. It does however have one caveat. \emph{Public Key Encryption} is notoriusly slow, compared to the \emph{Symmetrical}-scheme with only a single key. Thus, we introduce the concept of \emph{Key Encapsulation Mechanisms}, or \texttt{KEM}, in which a decryption key is now what is sent, rather than a message. This naturally solves one of the underlying issues of \texttt{PKE}, as we can now encrypt a symmetrical key and change our way of communication after the first message.
+By definition, \emph{Encryption} is the process of converting information into a \emph{ciphertext} with the purpose of preventing unauthorized access \cite{oxford}. Traditionally, the way this was accomplished was via some a priori established secret key $k$, which could then be used both for \emph{encryption} to turn some \emph{plaintext} into the ciphertext, but also for \emph{decryption}, to turn the ciphertext back into the plaintext. This concept was then challenged by the concept of \emph{Public Key Encryption}, \texttt{PKE}, which allows two parties to communicate with each other in a secure and private fashion, without having already shared the aforementioned secret key. This allowed each party to have a \emph{Public Key} and a \emph{Secret Key}, which could then be used to encrypt and decrypt, respectively. This works well and is used in many applications, such as \emph{SSH} and \emph{SSL}. It does however have one caveat. \emph{Public Key Encryption} is notoriusly slow, compared to the \emph{Symmetric}-scheme with only a single key. Thus, we introduce the concept of \emph{Key Encapsulation Mechanisms}, or \texttt{KEM}, in which a decryption key is now what is sent, rather than a message. This naturally solves one of the underlying issues of \texttt{PKE}, as we can now encrypt a symmetric key and change our way of communication after the first message.
 
-Now, imagine a scenario where a user has an entire network of people in which he only wishes to send to a subset of these at a time. In the world of \texttt{PKE}, this user will have to fetch each users public key and encrypt the same symmetrical key for each user, resulting in a ciphertext for the same key for each user. This is highly inefficient, and becomes even worse if the \emph{authorised set} of receivers changes, at which point a new symmetrical key must be created and sent to each user. To this end, \emph{Broadcast Encryption}, \texttt{BE}, can be adopted as a solution. In such a scheme, a user will pick his set of recievers, $S$, fetch their public keys, but only encrypt the key once and broadcast this. Hence, there is only a single message and this can be broadcasted to all users of the system, but only those users within the set $S$ can decrypt it.
+Now, imagine a scenario where a user has an entire network of people in which he only wishes to send to a subset of these at a time. In the world of \texttt{PKE}, this user will have to fetch each users public key and encrypt the same symmetrical key for each user, resulting in a ciphertext for the same key for each user. This is highly inefficient, and becomes even worse if the \emph{authorised set} of receivers changes, at which point a new symmetrical key must be created and sent to each user. To this end, \emph{Broadcast Encryption}, \texttt{BE}, can be adopted as a solution. In such a scheme, a user will pick his set of recievers, $S$, fetch their public keys, but only encrypt the key once and broadcast this. Thus, the resulting ciphertext of the key, does not depend in any way on the number of users. Hence, there is only a single message and this can be broadcasted to all users of the system, but only those users within the set $S$ can decrypt it.
 
 In this paper we first cover the concept of \emph{Identity Based Encryption}, \texttt{IBE}, as an introduction to some of the mathmatical concepts used within the paper, such as that of \emph{bilinear maps} and the mathmatical assumption that is the \emph{Bilinear Diffie Hellman}-problem. These two concepts can be extended and applied to many branches of encryption, such as \texttt{BE} or \emph{Threshold Public Key Encryption}, \texttt{TPKE}, both of which will also be introduced in this paper. Thus, we wish to introduce three different types of encryption schemes, \texttt{IBE, BE} and  \texttt{TE}, give a notion of what security is defined to be for these as well as an actual construction. 
 
@@ -279,9 +279,11 @@ Note that $g^s$ comes from the original challenge and due to the construction of
 This construction we'll be the foundation of the \emph{Ad-Hoc Broadcast Encryption} which we will explore shortly and likewise will this proof be brought up when exploring possible proofs of security of said \emph{Ad-Hoc Broadcast Encryption} scheme.
 
 \section{Dynamic Threshold Public-Key Encryption}
-In a Threshold Public-Key Encryption (\texttt{TPKE}) scheme, the decryption key corresponding to a public key is shared among a set of $n$ users \cite{TPKE}. Specifically for \texttt{TPKE} is that for any ciphertext to be correctly decrypted, $t$ receivers has to participate and cooperate. Thus, if any number of users less than $t$ try to decrypt, they will gain nothing, hence the threshold part of \texttt{TPKE}. A limitation of existing \texttt{TPKE} schemes however, is that the threshold value of $t$ is tightly connected to the public key of the system, as such, one has to fix the threshold for good, when setting up the system. Many applications would benefit from a flexibility to choose $t$ whenever broadcasting. As such Dynamic Threshold Public-Key Encryption (\texttt{DTPKE}) is proposed \cite{DTPKE}.
+In a Threshold Public-Key Encryption (\texttt{TPKE}) scheme, the decryption key corresponding to a public key is shared among a set of $n$ users \cite{TPKE}. Specifically for \texttt{TPKE} is that for any ciphertext to be correctly decrypted, $t$ receivers has to participate and cooperate. Thus, if any number of users less than $t$ try to decrypt, they will gain nothing, hence the threshold part of \texttt{TPKE}. A limitation of existing \texttt{TPKE} schemes however, is that the threshold value of $t$ is tightly connected to the public key of the system, as such, one has to fix the threshold for good, when setting up the system. Furthermore, existing schemes also has the limitation of being set up for a specific receiver set of $n$ users. As such, if the receiver set changes, a new scheme will have to be created, which naturally brings an overhead whenever any receiver exits or joins the system. Many applications would benefit from a flexibility to choose $t$ whenever broadcasting. As such \emph{Dynamic Threshold Public-Key Encryption} (\texttt{DTPKE}) is proposed \cite{DTPKE}.
 
-In a sense, Broadcast Encryption Systems can be related to notion of \emph{Threshold Public Key Encryption Systems} (\texttt{TPKE}) if we define the authorized set of the \texttt{TPKE} system to be equal to $S$ and the threshold parameter $t$ is set to be $1$. This is only true however, for the specific value of $t=1$, thus, specialized systems can be designed for the purpose of being broadcast encryption systems and \texttt{TPKE} can be seen as a general case of \texttt{BE}.
+In a sense, Broadcast Encryption Systems can be related to notion of \emph{Threshold Public Key Encryption Systems} (\texttt{TPKE}) if we define the authorized set of the \texttt{TPKE} system to be equal to $S$ and the threshold parameter $t$ is set to be $1$. This is only true however, for the specific value of $t=1$, thus, specialized systems can be designed for the purpose of being broadcast encryption systems and \texttt{TPKE} can be seen as a general case of \texttt{BE}. However, as \texttt{BE} schemes also bring the flexibility of choosing the recipient set $S$, we need something stronger than \texttt{TPKE}, to define \texttt{BE} as a special case. To this end we introduce \texttt{DTPKE}.
+
+% TODO: Consistency with encryption key or Encryption Key. Likely the former.
 
 \subsection{Modelling Dynamic Threshold Public-Key Encryption}
 A \texttt{DTPKE}-scheme consist of $7$ algorithms: \texttt{DTPKE} $= ($\texttt{Setup}, \texttt{Join}, \texttt{Encrypt}, \texttt{ValidateCT}, \texttt{ShareDecrypt}, \texttt{ShareVerify}, \texttt{Combine}$)$.
@@ -289,26 +291,26 @@ A \texttt{DTPKE}-scheme consist of $7$ algorithms: \texttt{DTPKE} $= ($\texttt{S
 \begin{description}
 \item[Setup$(\lambda)$] Takes security parameter $\lambda$. Outputs a set of system parameters: $$\mathtt{params} = (MK,EK,DK,VK,CK).$$ $MK$ is a Master Secret Key, $EK$ is the Encryption Key, $DK$ is the Decryption Key, $VK$ is the Validation Key and $CK$ is the Combination Key. $MK$ is kept secret by the issuer, but the other four are public parameters.
 \item[Join$(MK, \mathtt{ID})$] Takes the $MK$ and an identity \ID of a user. Outputs the user's keys $(usk, upk, uvk)$, where $usk$ is the secret key used for decryption, $upk$ is the public key used for encrypting and $uvk$ is the verification key. $upk, uvk$ are both public, whereas $usk$ is given privately to the user.
-\item[Encrypt$(EK, S, t, M)$] Takes the Encryption Key, the public keys of the users within the receiver set $S$, a threshold $t$ and a message to be encrypted, $M$. Outputs a ciphertext.
+\item[Encrypt$(EK, S, t, M)$] Takes the encryption key, the public keys of the users within the receiver set $S$, a threshold $t$ and a message to be encrypted, $M$. Outputs a ciphertext.
 \item[ValidateCT$(EK, S, t, C)$] Takes the encryption key, the public keys of the receiver set, a threshold and a ciphertext. Checks whether $C$ is a valid ciphertext with respect to $EK, S$ and $t$.
 \item[ShareDecrypt$(DK, \mathtt{ID}, usk, C)$] Takes the decryption key, a user id \ID and his private key $usk$, as well as a ciphertext $C$. Outputs a decryption share $\sigma$ or $\perp$.
 \item[ShareVerify$(VK, \mathtt{ID}, uvk, C, \sigma)$] Takes the verification key $VK$, a user id \ID and his verification key $uvk$ plus a ciphertext $C$ and decryption share $\sigma$. Checks whether $\sigma$ is a valid decryption share with respect to $uvk$.
-\item[Combine$(CK, S, t, C, T, \Sigma)$] Takes the combination key $CK$, a ciphertext $C$, some subset $T \subseteq S$ of $t$ authorised users and $\Sigma = (\sigma_1, \dots, \sigma_t)$ which is a list of $t$ decryption share. Outputs the plaintext $M$ or $\perp$.
+\item[Combine$(CK, S, t, C, T, \Sigma)$] Takes the combination key $CK$, a ciphertext $C$, some subset $T \subseteq S$ of $t$ authorised users and $\Sigma = (\sigma_1, \dots, \sigma_t)$ which is a list of $t$ decryption shares. Outputs the plaintext $M$ or $\perp$.
 \end{description}
 
 
 \subsection{Security Model}
 
 \begin{description}
-\item[Setup] The challenger runs Setup$(\lambda)$ of the \texttt{DTPKE} scheme, obtaining the $$\mathtt{params} = (MK,EK,DK,VK,CK)$$. All the public parameters (all except for $MK$) are given to the adversary \adv{A}.
+\item[Setup] The challenger runs Setup$(\lambda)$ of the \texttt{DTPKE} scheme, obtaining the $$\mathtt{params} = (MK,EK,DK,VK,CK).$$ All the public parameters (all except for $MK$) are given to the adversary \adv{A}.
 \item[Phase 1] The adversary is allowed to adaptively issue queries where query $q_i$ is one of three queries;
 \begin{itemize}
 \item A \texttt{Join} query on an id \texttt{ID}; The challenger runs the \texttt{Join} algorithm on input $(MK,\mathtt{ID})$, to create a new user in the system. Note that the challenger has $MK$ from the setup step.
 \item A \texttt{Corrupt} query on an id \texttt{ID}: The challenger forwards the corresponding private key to the adversary.
 \item A \texttt{ShareDecrypt} query on an id \texttt{ID} and a header \texttt{Hdr}: The challenger runs the \texttt{ShareDecrypt} algorithm of the \texttt{DTPKE} scheme on \texttt{Hdr}, using the corresponding private key, and forwards the partial decryption to the adversary.
 \end{itemize}
-\item[Challenge] The adversary \adv{A} outputs a target set of users $S^*$ as well as a threshold $t^*$. The challenger selects $b \in_R \set{0, 1}$ and then runs \texttt{Encrypt} to obtain $\mathtt{Hdr}^*, k_0) \la \mathtt{Encrypt}(EK, S^*, t^*)$. Furthermore, he picks another key $k_1 \in_R \mathcal{K}$. The challenger outsputs $(\mathtt{Hdr}^*, k_b)$ to \adv{A}.
-\item[Phase 2] The adversary \adv{A} is allowed to continue adaptively issuing \texttt{Join, Corrupt} and \texttt{ShareDecrypt} queries, with the only constraint that he asks less than or equal to $t^*-1$.
+\item[Challenge] The adversary \adv{A} outputs a target set of users $S^*$ as well as a threshold $t^*$, with the constraint that $|S^*| \leq t^*$. The challenger selects $b \in_R \set{0, 1}$ and then runs \texttt{Encrypt} to obtain $\mathtt{Hdr}^*, k_0) \la \mathtt{Encrypt}(EK, S^*, t^*)$. Furthermore, he picks another key $k_1 \in_R \mathcal{K}$. The challenger outsputs $(\mathtt{Hdr}^*, k_b)$ to \adv{A}.
+\item[Phase 2] The adversary \adv{A} is allowed to continue adaptively issuing \texttt{Join, Corrupt} and \texttt{ShareDecrypt} queries, with the only constraint that he asks queries for less than or equal to $t^*-1$ $\mathtt{IDs} \in S^*$.
 \item[Guess] The adversary outputs a guess bit $b' \in \{0,1\}$ and he will win the game if $b' = b$.
 
   From this basic description, we can define three sub definitions:
@@ -324,7 +326,7 @@ A \texttt{DTPKE}-scheme consist of $7$ algorithms: \texttt{DTPKE} $= ($\texttt{S
 % TODO: Consider having parameters for all modelling or none!
 
 
-
+% TODO: Consider moving this to the appendix and perhaps just note in the body of the report an informal description of the errors you found?
 
 \subsection{A scheme and the Security Thereof}
 It should be noted that this scheme is very long and as such will be left out of the report, but it will be included in the appendix, completely as the original authors wrote it. We will instead list their security proof, which contains an error worth of noting. Their proof is a reduction to the \texttt{MSE-DDH} problem, as defined in Section \ref{sec:MSE-DDH}. Regardless, their security proof states that the \texttt{DTPKE} scheme has \texttt{IND-NAA-NAC-CPA} security (Non-adaptive adversary, non-adaptive corruption, chosen-plaintext attack).
@@ -406,22 +408,24 @@ It should be noted that this scheme is very long and as such will be left out of
 
 
 \section{Ad-Hoc Broadcast Encryption}
-The scheme presented in \ref{sec:BE} requires a \emph{trusted dealer} to perform its \emph{setup} and \emph{keygen}. It goes for a lot of \emph{Broadcast Encryption} systems, that they require a trusted entity to generate and distribute secret keys to all users. This tends to make the system very rigid and not applicable to ad hoc networks or peer-to-peer networks. A \emph{potential} solution to this is presented by \cite{AHBE}. They present a solution to the fully dynamic case of broadcast encryption. This has significant ties to the \emph{Dynamic Threshold Encryption} scheme in which users could freely join and leave, however they did not quite get rid of the trusted dealer. This is accomplished here. Keep in mind that broadcast encryption is simply threshold encryption for the threshold of $t=1$.
+The scheme presented in \ref{sec:BE} requires a \emph{trusted dealer} to perform its \emph{setup} and \emph{keygen}. It goes for all of \emph{Broadcast Encryption} systems, that they require a trusted entity to generate and distribute secret keys to all users. This tends to make the system very rigid and not applicable to ad hoc networks or peer-to-peer networks. A \emph{potential} solution to this is presented by \cite{AHBE}. They present a solution to the fully dynamic case of broadcast encryption. This has significant ties to the \emph{Dynamic Threshold Encryption} scheme in which users could freely join and leave, however they did not quite get rid of the trusted dealer. This is accomplished here. Keep in mind that broadcast encryption is simply threshold encryption for the threshold of $t=1$.
 
-In an Ad-Hoc Broadcast Encryption (\texttt{AHBE}) scheme all users possess a public key and by only seeing the public keys of users, a sender can securely broadcast to \emph{any} subset of the users. Only users within the picked subset can decrypt the message. To accomplish this, the authors create a generic transformation from any \emph{key homomorphic} BE scheme to an \texttt{AHBE} scheme. It turns out that the scheme of Gentry and Waters presented in \ref{sec:BE} is just this and the transformation will be performed on this.
+In an Ad-Hoc Broadcast Encryption (\texttt{AHBE}) scheme all users possess their own public key, which is independently generated by themselves with no need of a trusted authority or setup. Then, by only seeing the public keys of users, a sender can securely broadcast to \emph{any} subset of the users. Only users within the picked subset can decrypt the message. To accomplish this, the authors create a generic transformation from any \emph{key homomorphic} BE scheme to an \texttt{AHBE} scheme. It turns out that the scheme of Gentry and Waters presented in \ref{sec:BE} is just this and the transformation will be performed on this.
 
 \subsection{Modelling Ad-Hoc Broadcast Encryption}
 As an \texttt{AHBE} system eliminate the trusted dealer, the \emph{setup} and \emph{keygen} step morph together, as there is no global \emph{setup} step required, but merely something each user should locally run. As all other schemes defined in this paper, this too is defined to be a \emph{Key Encapsulation Method} (\texttt{KEM}).
 
 \begin{description}
 \item[KeyGen$(i,n,N)$] Let $N$ be defined as the number of potential receivers of the scheme and let $n \leq N$ be defined as the maximum number of receivers of an ad-hoc broadcast recipient group. The \emph{KeyGen} (this) algorithm is run by each user $i \in [1,N]$ to create her own public/secret key pair. A user takes $n, N$ as well as her own index $i \in [1,N]$. It's not mentioned how the user receives this index in practice, without simply having a central authority giving them, but one could imagine the users being aware of how many recipients there are in total and simply increment this to get their own index, if one disregards the issues of people joining the peer-to-peer network at the same time. The \emph{KeyGen} algorithm outputs the users public/secret key pair $(PK_i,SK_i)$. We define a shorthand for several users key pairs; $\{(PK_i, SK_i) | i \in S \subseteq [1,N] $ as $(PK_i,SK_i)_{S}$ and likewise only for the public keys; $(PK_i)_{S}$. All of this depends on a security parameter $\lambda$, which is implicitly given to the algorithm.
-\item[AHBEnc$(\mathbb{S}, (PK_i)_{S})$] This is run by any sender who may or may not be in $[1,N]$, as long as the sender knows the public keys of the receivers. It takes the recipient set $S \subseteq [1,N]$ and the public keys for $i \in S$; $(PK_i)_{S}$. Given that $|S| \leq n$, the algorithm returns a pair $(\text{Hdr}, K)$ where Hdr is the header, the encapsulated key, and $K$ is the message encryption key.
+\item[AHBEnc$(S, (PK_i)_{S})$] This is run by any sender who may or may not be in $[1,N]$, as long as the sender knows the public keys of the receivers. It takes the recipient set $S \subseteq [1,N]$ and the public keys for $i \in S$; $(PK_i)_{S}$. Given that $|S| \leq n$, the algorithm returns a pair $(\text{Hdr}, K)$ where Hdr is the header, the encapsulated key, and $K$ is the message encryption key.
 \item[AHBDec$(\mathbb{S}, j, sk_j, \text{Hdr}, (PK_i)_{S})$] This allows each recipient $i \in S$ to decrypt the message encryption key which is hidden in the header. If $|S| \leq n, j \in S$, then the algorithm returns the message encryption key $k$.
+
+An \emph{Ad-Hoc Broadcast Encryption} system is defined to be \textbf{correct} if any user within the receiver set $S$ can decrypt a valid header.
 \end{description}
 
 
 \subsection{Definition of Adaptive Security in AHBE}
-An \emph{Ad-Hoc Broadcast Encryption} system is defined to be \textbf{correct} if any user within the receiver set $S$ can decrypt a valid header. In an adaptively secure ad-hoc broadcast encryption system, the adversary is allowed access to all the public keys of the receivers and to ask for several secret keys before choosing the set of indices that the adversary wishes to attack.
+In an adaptively secure ad-hoc broadcast encryption system, the adversary is allowed access to all the public keys of the receivers and to ask for several secret keys before choosing the set of indices that the adversary wishes to attack.
 
 % Both the Challenger and an adversary \adv{A} are given the security parameter $\lambda$. \\
 \begin{description}
@@ -430,7 +434,7 @@ An \emph{Ad-Hoc Broadcast Encryption} system is defined to be \textbf{correct} i
 \item[Challenge] \adv{A} specifies some challenge set $S^* \subseteq [1,N]$ s.t. \adv{A} has corrupted none of the users $i$ within $S^*$. The challenger sets $(\text{Hdr}^*, k_0) \leftarrow \mathtt{AHBEnc}(S^*, (PK_i)_{S^*})$ and $k_1 \in_R \mathbb{K}$. The challenger sets $b \in_R \{0,1\}$. It gives $(\text{Hdr}^*, k_b)$ to the adversary \adv{A}.
 \item[Guess] The adversary \adv{A} will output a bit $b' \in \{0,1\}$ as an attempt to guess the bit $b$. \adv{A} wins if $b' = b$.
 
-  The advantage of \adv{A} is as expected; $Adv^{\texttt{AHBE}}_{\mathcal{A},n,N}(1^\lambda) = |Pr(b = b') - \frac{1}{2}|$.
+  The advantage of \adv{A} is as expected; $Adv^{\texttt{AHBE}}_{\mathcal{A},n,N}(1^\lambda) = |Pr(b = b') - \frac{1}{2}|$ and the scheme is deemed adaptively secure if this advantage is negligible in the security parameter $\lambda$.
 \end{description}
 
 
@@ -506,10 +510,11 @@ $$k = BDec(S, i, d(i), Hdr, K) $$
 The security of the AHBE scheme is proven by a reduction to the underlying KHBE scheme. As such, if the underlying KHBE scheme is presumed to be secure, so should the AHBE scheme. Furthermore, the AHBE scheme has semi-static security, if the KHBE scheme has adaptive security.
 
 \begin{theorem}
-  The generic AHBE scheme has semi-static security if the underlying KHBE scheme has adaptive security. Do note that something is wrong within this proof, which we will point out in a leter section.
+  The generic AHBE scheme has semi-static security if the underlying KHBE scheme has adaptive security.
 \end{theorem}
 
 \begin{proof}
+We note that something is wrong within this proof, which we will point out in Section \ref{sec:ProofIssues}.
   We wish to construct an adversary \adv{B} who can break the security of the underlying KHBE scheme, by utilising the adversary \adv{A} who is assumed to be able to break the security of the AHBE scheme. In the initialisation phase, \adv{A} will commit to a set $\tilde{S} \subseteq [1,n]$. Keep in mind that \adv{A} is a semi-static adversary, so he has to commit to a set of which he wishes to attack a subset of.
 
   In the setup phase, \adv{B} picks a user at randomly from within $\tilde{S}$; $i* \in_R \tilde{S}$. \adv{B} then sets up the \emph{adaptive} game with the KHBE challenger \CH. \CH returns the system parameters and the KHBE public key, denoted by $PK_{i^*}$. \adv{B} then queries for the secret key $d_{i^*}(j)$ for each index $j \not\in \tilde{S}$.
@@ -518,7 +523,7 @@ The security of the AHBE scheme is proven by a reduction to the underlying KHBE
 
   In the corruption phase, \adv{A} may corrupt any user $i \in \{1,\dots,n\} \setminus \tilde{S}$. These users are all however fabricated by the \adv{B}, so \adv{B} has the public/private key pairs for any user outside of $\tilde{S}$, thus it is no issue to yield the decryption key $d_i(i)$ and answer the query correctly.
 
-  In the challenge phase, the adversary \adv{A} decides upon an attack set $S^* \subset \tilde{S}$. This is given to \adv{B} who then has two options. Either $i^* \not\in S^*$ and \adv{B} reports failure, as the answer from the AHBE adversary \adv{A} will not be of any help to \adv{B} in breaking the underlying KHBE scheme. On the other hand, if $i^* \in S^*$, \adv{B} simply forwards the set $S^*$ to the challenger \CH and requests for a KHBE header and key from \CH. \adv{B} receives a pair $(\hdr^*, k_b)$ under $(S^*, PK_{i^*})$. \adv{B} then has to convert this into a wellformed challenge header for $(S^*, \oplus_{j \in S^*} PK_j)$ meant for the adversary \adv{A}. To this end, we note that the underlying scheme is a KHBE, thus, the header $\hdr^*$ will always be for a correct key, but the question is whether it is the key $k_b$. Furthermore, as we know all of the public/private key pairs, we can compute $BDec(S^*, i^*, d_i(i^*), \hdr^*, PK_i) = k_{b,i}$ for $i \in S^* \setminus \{i^*\}$, noting that, due to the second property of the key homomorphism, we have for all $j \in S^*$; $BDec(S^*, j, d_i(j), \hdr^*, PK_i) = k_{b,i}$. \adv{B} then sets $k^*_b = k_b \ocircle \{\ocircle_{i \in S^* \setminus \{i^*\}} k_{b,i}\}$ and then send $(\hdr^*, k^*_b)$ as a challenge to \adv{A}. Due to the homomorphic properties, if $\hdr^*$ hides the key $k_b$ under $(S^*, PK_{i^*})$, then it also hides the key $k^*_b$ under $(S^*, \oplus_{i \in S^*} PK_i)$, else the key $k_b$ is picked uniformly from the keyspace, so the aggregation of keys $k_b \ocircle \ocircle_{i \in S^* \setminus \{i^*\}} k_{b,i}$ still makes sense and will have the correct distribution, it will just be independent on $\hdr^*$.
+  In the challenge phase, the adversary \adv{A} decides upon an attack set $S^* \subseteq \tilde{S}$. This is given to \adv{B} who then has two options. Either $i^* \not\in S^*$ and \adv{B} reports failure, as the answer from the AHBE adversary \adv{A} will not be of any help to \adv{B} in breaking the underlying KHBE scheme. On the other hand, if $i^* \in S^*$, \adv{B} simply forwards the set $S^*$ to the challenger \CH and requests for a KHBE header and key from \CH. \adv{B} receives a pair $(\hdr^*, k_b)$ under $(S^*, PK_{i^*})$. \adv{B} then has to convert this into a wellformed challenge header for $(S^*, \oplus_{j \in S^*} PK_j)$ meant for the adversary \adv{A}. Thus, as we know all of the public/private key pairs, we can compute $BDec(S^*, i^*, d_i(i^*), \hdr^*, PK_i) = k_{b,i}$ for $i \in S^* \setminus \{i^*\}$, noting that, due to the second property of the key homomorphism, we have for all $j \in S^*$; $BDec(S^*, j, d_i(j), \hdr^*, PK_i) = k_{b,i}$. \adv{B} then sets $k^*_b = k_b \ocircle \{\ocircle_{i \in S^* \setminus \{i^*\}} k_{b,i}\}$ and then send $(\hdr^*, k^*_b)$ as a challenge to \adv{A}. Due to the homomorphic properties, if $\hdr^*$ hides the key $k_b$ under $(S^*, PK_{i^*})$, then it also hides the key $k^*_b$ under $(S^*, \oplus_{i \in S^*} PK_i)$, else the key $k_b$ is picked uniformly from the keyspace, so the aggregation of keys $k_b \ocircle \ocircle_{i \in S^* \setminus \{i^*\}} k_{b,i}$ still makes sense and will have the correct distribution, it will just be independent on $\hdr^*$.
 
   Finally, when \adv{A} guesses bit $b'$, this is forwarded by \adv{B} to the KHBE challenger \CH. Intuitively, \adv{B} will guess correct, if adversary \adv{A} guesses correct. Thus, if we assume adversary \adv{A} has advantage $\epsilon$, then the advantage of \adv{B} is $\frac{1}{n} \epsilon$, due to \adv{B} aborting in the case of $i^* \not\in S^*$, thus incurring a factor $\frac{1}{n}$. 
 \end{proof}
@@ -526,6 +531,7 @@ The security of the AHBE scheme is proven by a reduction to the underlying KHBE
 % TODO: Fix (?) proof
 
 \subsection{Issues with the Proof}
+\label{sec:ProofIssues}
 The primary issue of this proof arises when the following question is raised: "How can B get the keys $d_{i^*}(j)$ for $j \in \tilde{S}$". These decryption keys will have to be a part of the public keys that \adv{B} has to present to \adv{A} in the beginning of the setup of the AHBE scheme? The only key which is supposed to be private in the AHBE scheme is $d_{i^*}(i^*)$, which is an issue, as \adv{B} eventually wants to attack the set $S^*$, which contains several of the users of which he will have to corrupt to get the missing keys. Specifically:
 \begin{figure}
 
@@ -546,13 +552,23 @@ If we consider the user $i^*$ to be $\U_1$ and $\tilde{S}$ to simply be all $n$
 
 To remedy this, we considered primarily one thing; Adding another homomorphic property such that we can safely use \emph{only} $\{i^*\}$ as the recipient set we sent to \CH.
 
-\begin{theorem}
+\begin{definition}
   If $\hdr^*$ is a header for $k_{i^*}$ under $(i^*, PK_{i^*})$, then it can be transformed into a header under $(S^*, PK)$ where $i^* \in S^*$ where the underlying key is allowed to change.
-\end{theorem}
+\end{definition}
 This would allow \adv{B} to challenge for a header for a receiver set only containing $i^*$, which means he does not have to worry of querying for the decryption keys of the other receivers within $S^*$. When \adv{B} receives the challenge header from the challenger, this can be transformed into a proper header for the adversary \adv{A}.
-This transformation would have to be both randomised and OTP, as otherwise if we sent a header encrypting some key, it should not be allowed to transform this header into another one, then decrypting it for the key and then recovering the old key from this. This is however not quite strong enough. There are two potential augments. Either the transformation should keep the underlying key, in which case an adversary could add himself to the set of receivers, perform the homomorphic operation on the header and then decrypt to get the original underlying key. This is obviously not safe. On the other hand, if the operation changes the underlying key, then we run into another issue. If the key changes, this homomorphic transformation can instead be used as a distinguisher.
-\\ TODO: FIX! \\
-Something something game where the algorithm can use this adversary to transform the header and thus the key into something else which he can then use to distinguish if the original underlying key was random or was constructed properly regarding the rest of the receiver set.
+This transformation would have to be both randomised and one-way, as otherwise the following attacks could take place;
+
+\begin{description}
+\item The adversary is a part of the set $[1,n]$, but not a part of the set $S^*$. If then a message containing some header $\hdr$ is sent out to the set $S^*$, the adversary should not be allowed to decrypt the header $\hdr$ and recover the underlying key $k$ intended for the receiver set $S^*$. Now, if the transformation is not \emph{one-way} and the transformation \emph{did not} change the value of the underlying key, it would be simple for the adversary to \emph{artifically add} himself to the set $S^*$, by simply performing the homomorphic operation on the header \hdr achieving some header $\hdr^*$ and then decrypt it, achieving the underlying key $k$. Thus, the transformation necessarily must change the underlying value of the key. Thus, if the transformation is not \emph{one-way}, but does in fact alter the underlying key, a similiar attack can be staged, with a little more effort from the adversary. Say the adversary is in the total set of receivers, but not in the set $S^*$. When he then receives the broadcasted message containing \hdr, he can perform the homomorphic operation as before to the header \hdr and achieve a new header $\hdr^*$ for an altered key $k^*$. However, as the transformation is \emph{not} one-way, the adversary can then perform the inverse homomorphic operation on the key $k^*$ and get back the original key, $k$. This is naturally not desirable either. 
+\end{description}
+
+As such, we conclude that this homomorphic operation must be randomised, one-way and it must alter the value of the underlying key. However, on the other hand, if the operation changes the underlying key, then we run into another issue. If the key changes, this homomorphic transformation can instead be used as a distinguisher.
+
+We will describe a game where this homomorphic operation operation breaks the security of the underlying \texttt{BE}-scheme.
+
+\begin{description}
+\item An adversary \adv{A} will try to break the semantic security of a \texttt{BE}-scheme which posses the homomorphic properties with the addition of the one described above, by being able to recognise if a key is random or constructed for a specific receiver set. The adversary \adv{A} will receive a \hdr for some set $S$ which hides some key $k_b$, as well as a key $k$, which is either $k_b$ or $k_{1-b}$, from the challenger \CH. This \hdr is then transformed by \adv{A}, who will perform the homomorphic operations on the header \hdr and the key $k$, gaining a new pair $(\hdr^*, k^*)$. He can now decrypt the header $\hdr^*$ and check if the resulting key is $k^*$, if so, he knows the original \hdr and key $k$ must be corresponding, and otherwise they are not.
+\end{description}
 
 \subsection{An AHBE Implementation}
 To end up with a Semi-statically secure AHBE scheme, we first need to produce an adaptively secure BE scheme which is key homomorphic. To this end, we use the scheme defined in \ref{sec:BE} coupled with the generic transformation from Semi-static to Adaptive by Gentry and Waters \cite{GentryWaters}. Note that $g, h_{i,s} \text{ for } i \in [1,n], s \in \{0,1\}$ be independent generators of a group $\mathbb{G}$ of prime order $p$, with a bilinear map $e : \Gm \times Gm \ra \Gm_{T}$.
@@ -618,6 +634,7 @@ As such, we conclude that, if there is a reduction to be found from the \AHBE in
 
 \newpage
 % https://tex.stackexchange.com/questions/49643/making-appendix-for-thesis
+
 \begin{appendices}