Pownie/functionalenc
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

More more corrections

Browse Source
This commit is contained in:
Alexander Munch-Hansen 2019-12-27 23:05:23 +01:00
parent fb3e35cee1
commit d0f4aeabb5
1 changed files with 19 additions and 32 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

51
report.tex
View File

@ -52,7 +52,7 @@
\textsc{Aarhus University} \\ [20pt] \textsc{Aarhus University} \\ [20pt]
\horrule{0.5pt} \\[0.4cm] % Thin top horizontal rule \horrule{0.5pt} \\[0.4cm] % Thin top horizontal rule
\huge Beyond Public Key Cryptography \\ % The assignment main title \huge Beyond Public Key Cryptography \\ % The assignment main title
\large A study of various extensions of public key crypto, with focus on Broadcast Encryption schemes \\ % The assignment sub title \large A Study of Various Extensions of Public Key Cryptography, With Focus on Broadcast Encryption Schemes \\ % The assignment sub title
\horrule{2pt} \\[0.5cm] % Thick bottom horizontal rule \horrule{2pt} \\[0.5cm] % Thick bottom horizontal rule
} }
@ -64,11 +64,11 @@
\tableofcontents \tableofcontents
\newpage \newpage
\section{Introduction} \section{Introduction}
By definition, \emph{Encryption} is the process of converting information into a \emph{ciphertext} with the purpose of preventing unauthorised 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 however eventually challenged by the new idea 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. By definition, \emph{Encryption} is the process of converting information into a \emph{ciphertext} with the purpose of preventing unauthorised 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 however eventually challenged by the new idea 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, as opposed to \emph{Data Encapsulation Mechnanisms}, \texttt{DEM}. This naturally solves one of the underlying issues of \texttt{PKE}, as we can now encrypt a symmetric key via a \texttt{KEM} and then change our way of communication after the first message to that of \texttt{DEM}.
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 symmetric 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 change, at which point a new symmetric 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, and there is only a single message which can easily 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 symmetric 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 change, at which point a new symmetric 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, and there is only a single message which can easily 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. 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 and extension of these.
\section{Syntax and Preliminaries} \section{Syntax and Preliminaries}
@ -77,7 +77,7 @@ In this paper we first cover the concept of \emph{Identity Based Encryption}, \t
Let $p$ be a large prime number. Let $\mathbb{G}_1, \mathbb{G}_2, \mathbb{G}_T$ be three groups of order $p$. Let $g_1$ be a generator of $\mathbb{G}_1$ and let $g_2$ be a generator of $\mathbb{G}_2$. $e : \mathbb{G}_1 \times \mathbb{G}_2 \ra \mathbb{G}_T$ is then a bilinear map satisfying the following properties \cite{BMDef}: Let $p$ be a large prime number. Let $\mathbb{G}_1, \mathbb{G}_2, \mathbb{G}_T$ be three groups of order $p$. Let $g_1$ be a generator of $\mathbb{G}_1$ and let $g_2$ be a generator of $\mathbb{G}_2$. $e : \mathbb{G}_1 \times \mathbb{G}_2 \ra \mathbb{G}_T$ is then a bilinear map satisfying the following properties \cite{BMDef}:
\begin{itemize} \begin{itemize}
\item \emph{Bilinearity}: For all $u \in \mathbb{G}_1$, $v \in \mathbb{G}_2$ and $a,b \in \mathbb{Z}$; $e(u^a, v^b) = e(u,v)^{ab}$ \item \emph{Bilinearity}: For all $u \in \mathbb{G}_1$, $v \in \mathbb{G}_2$ and $a,b \in \mathbb{Z}$; $e(u^a, v^b) = e(u,v)^{ab}$
\item \emph{Non-degeneracy}: $e(g_1,g_2) \neq $The identity of $\mathbb{G}_T$ \item \emph{Non-Degeneracy}: $e(g_1,g_2) \neq $ The identity of $\mathbb{G}_T$
\item \emph{Computability}: For all $u \in \mathbb{G}_1$, $v \in \mathbb{G}_2$, $e(u,v)$ should be efficiently computable. \item \emph{Computability}: For all $u \in \mathbb{G}_1$, $v \in \mathbb{G}_2$, $e(u,v)$ should be efficiently computable.
\end{itemize} \end{itemize}
A bilinear map satisfying all the above three properties is said to be \emph{admissible}. A bilinear map satisfying all the above three properties is said to be \emph{admissible}.
@ -121,7 +121,6 @@ We want to note that the paper does not define either $\alpha$ or $\gamma$, whic
We would like to note that whenever something is prefixed with a capital B, it is in the context of \emph{Broadcast Encryption}. Furthermore we would like to note that for all setup algorithms mentioned, the security parameter will be implicit, but naturally all schemes relies on one in some shape or form, to either denote a bit length, graph size or whatever makes sense within the context. We would like to note that whenever something is prefixed with a capital B, it is in the context of \emph{Broadcast Encryption}. Furthermore we would like to note that for all setup algorithms mentioned, the security parameter will be implicit, but naturally all schemes relies on one in some shape or form, to either denote a bit length, graph size or whatever makes sense within the context.
% TODO: Write up all of the mathematical assumptions
\section{Identity Based Encryption} \section{Identity Based Encryption}
We will cover an identity based encryption scheme which illustrates a basic usage of bilinear maps as well as one way to extend the \emph{Diffie-Hellman Assumption} known from Public Key Encryption. This scheme is not secure against an adaptive chosen ciphertext attack (\texttt{IND-ID-CCA}). The scheme can however be extended to cover this, but this is out of the scope of this paper. We note that although this scheme is not awfully relevant for the rest of the paper, it still is something we covered throughout the semester and it offers a delicate and simple introduction to some of the mathematical concepts and encryption schemes which will be used throughout this paper, specifically that of bilinear maps and public key cryptography. We will cover an identity based encryption scheme which illustrates a basic usage of bilinear maps as well as one way to extend the \emph{Diffie-Hellman Assumption} known from Public Key Encryption. This scheme is not secure against an adaptive chosen ciphertext attack (\texttt{IND-ID-CCA}). The scheme can however be extended to cover this, but this is out of the scope of this paper. We note that although this scheme is not awfully relevant for the rest of the paper, it still is something we covered throughout the semester and it offers a delicate and simple introduction to some of the mathematical concepts and encryption schemes which will be used throughout this paper, specifically that of bilinear maps and public key cryptography.
@ -136,7 +135,7 @@ We will cover an identity based encryption scheme which illustrates a basic usag
\item[Encrypt$(\text{params}, \mathtt{ID}, M)$] Takes the system parameters, some \texttt{ID}, and an $M \in \mathcal{M}$. Returns some ciphertext $C \in \mathcal{C}$. \item[Encrypt$(\text{params}, \mathtt{ID}, M)$] Takes the system parameters, some \texttt{ID}, and an $M \in \mathcal{M}$. Returns some ciphertext $C \in \mathcal{C}$.
\item[Decrypt$(\text{params}, C, d)$] Takes the system parameters, some private key $d$ and $C \in \mathcal{C}$. Returns the corresponding plaintext $M \in \mathcal{M}$. \item[Decrypt$(\text{params}, C, d)$] Takes the system parameters, some private key $d$ and $C \in \mathcal{C}$. Returns the corresponding plaintext $M \in \mathcal{M}$.
\item[Correctness] Naturally, these algorithms must satisfy that: \item[Correctness] Naturally, these algorithms must satisfy that:
$$ \forall M \in M\ :\ \text{Decrypt}(\text{params}, C, d) = M\quad \text{where}\quad C = \text{Encrypt}(\text{params}, ID, M)$$ I.e. for all messages $M \in \mathcal{M}$, if this is encrypted for some id \ID, then it decrypts to the same message $M$, if the correct decryption key $d$ for the \ID is used. $$ \forall M \in M\ :\ \text{Decrypt}(\mathbf{params}, C, d) = M\quad \text{where}\quad C = \text{Encrypt}(\mathbf{params}, ID, M)$$ I.e. for all messages $M \in \mathcal{M}$, if this is encrypted for some id \ID, then it decrypts to the same message $M$, if the correct decryption key $d$ for the \ID is used.
\end{description} \end{description}
@ -151,7 +150,7 @@ An Identity-Based Encryption scheme is semantically secure against an adaptive c
\item A decryption query run on $\ID_i$ and some ciphertext $C_i$. First the challenger runs the \emph{Extract} algorithm to get the decryption key $d_i$ corresponding to the given $\ID_i$. The Challenger then runs the \emph{Decrypt} algorithm on $d_i$ and $C_i$, resulting in a plaintext. This plaintext is returned to the adversary. \item A decryption query run on $\ID_i$ and some ciphertext $C_i$. First the challenger runs the \emph{Extract} algorithm to get the decryption key $d_i$ corresponding to the given $\ID_i$. The Challenger then runs the \emph{Decrypt} algorithm on $d_i$ and $C_i$, resulting in a plaintext. This plaintext is returned to the adversary.
\end{itemize} \end{itemize}
\hsp{6mm} These queries may be run \emph{adaptively}, hence the name of the security definition, thus, each query $q_i$ may depend on the previous queries $q_1,\dots,q_{i-1}$, if the adversary so desires. \hsp{6mm} These queries may be run \emph{adaptively}, hence the name of the security definition, thus, each query $q_i$ may depend on the previous queries $q_1,\dots,q_{i-1}$, if the adversary so desires.
\item[Challenge] Once the adversary deems that Phase 1 is over, he outputs two plaintexts of equal length; $M_0, M_1 \in \mathcal{M}$, as well as an \ID on which he desires to be challenged. The single constraint, is that the adversary is not allowed to have queried this \ID before in Phase 1. The Challenger then picks a bit $b \in_R \{0,1\}$ and sets $C = Encrypt(params, \ID, M_b)$. $C$ is then send to the adversary. \item[Challenge] Once the adversary deems that Phase 1 is over, he outputs two plaintexts of equal length; $M_0, M_1 \in \mathcal{M}$, as well as an \ID on which he desires to be challenged. The single constraint, is that the adversary is not allowed to have queried this \ID before in Phase 1. The Challenger then picks a bit $b \in_R \{0,1\}$ and sets $C = Encrypt(\mathbf{params}, \ID, M_b)$. $C$ is then send to the adversary.
\item[Phase 2] The adversary is allowed to issue additional $n-l$ queries; $q_{l+1},\dots,q_n$, where query $q_i$ is either of: \item[Phase 2] The adversary is allowed to issue additional $n-l$ queries; $q_{l+1},\dots,q_n$, where query $q_i$ is either of:
\begin{itemize} \begin{itemize}
\item An extraction query run on $\ID_i$. The same query, except $\ID_i \neq \ID$, where \ID is the \ID of the challenge. \item An extraction query run on $\ID_i$. The same query, except $\ID_i \neq \ID$, where \ID is the \ID of the challenge.
@ -165,7 +164,7 @@ These queries may be run adaptively, as in Phase 1.
This definition closely resembles the standard definition of \texttt{IND-CPA} but extended with the addition of extraction queries and that the challenger is now challenged on an \ID picked by the adversary. The addition of the extraction queries is supported by \cite{ExtractionDef}, when the scheme is to support multiple users, which is likely the case for any IBE scheme. Furthermore, the weaker notion of security known as \emph{Semantic Security} (\texttt{IND-ID-CPA}) can be defined based on \texttt{IND-ID-CCA}, except now the adversary is not allowed to issue any decryption queries, i.e. he is only allowed extraction queries. This definition closely resembles the standard definition of \texttt{IND-CPA} but extended with the addition of extraction queries and that the challenger is now challenged on an \ID picked by the adversary. The addition of the extraction queries is supported by \cite{ExtractionDef}, when the scheme is to support multiple users, which is likely the case for any IBE scheme. Furthermore, the weaker notion of security known as \emph{Semantic Security} (\texttt{IND-ID-CPA}) can be defined based on \texttt{IND-ID-CCA}, except now the adversary is not allowed to issue any decryption queries, i.e. he is only allowed extraction queries.
\subsection{A Instantiation of \texttt{IBE}} \subsection{An Instantiation of \texttt{IBE}}
\label{sec:IBEConst} \label{sec:IBEConst}
The scheme we will focus on is that of Boneh and Franklin as described in \cite{WeilIBE}. The structure will be as defined in Section \ref{sec:IBEStruct}. We let $\lambda$ be the given security parameter given implicitly to the setup algorithm. We let $\mathcal{G}$ be a BDH parameter generator. The scheme we will focus on is that of Boneh and Franklin as described in \cite{WeilIBE}. The structure will be as defined in Section \ref{sec:IBEStruct}. We let $\lambda$ be the given security parameter given implicitly to the setup algorithm. We let $\mathcal{G}$ be a BDH parameter generator.
\begin{description} \begin{description}
@ -232,9 +231,6 @@ Static security is the least strongest type and it requires the adversary to com
% TODO: Consider using description environment or https://tex.stackexchange.com/questions/436977/how-to-insert-multiple-hspace-into-one-row-line
% TODO, maybe new page this
\subsection{Their construction} \subsection{Their construction}
\label{sec:GentryWatersConst} \label{sec:GentryWatersConst}
Let $GroupGen(\lambda,n)$ be an algorithm which generates a group \G and \Gp{_T} of prime order $p = \text{poly}(\lambda, n) > n$ with a bilinear map $e : \mathbb{G} \times \mathbb{G} \rightarrow \mathbb{G}_T$, based on a security parameter $\lambda$. Let $GroupGen(\lambda,n)$ be an algorithm which generates a group \G and \Gp{_T} of prime order $p = \text{poly}(\lambda, n) > n$ with a bilinear map $e : \mathbb{G} \times \mathbb{G} \rightarrow \mathbb{G}_T$, based on a security parameter $\lambda$.
@ -255,9 +251,9 @@ Let $GroupGen(\lambda,n)$ be an algorithm which generates a group \G and \Gp{_T}
\subsection{Proof of Security} \subsection{Proof of Security}
The proof is a reduction from their construction to the \emph{BDHE}-problem. The scheme is proven secure in the semi-static model. We note that the proof in the original paper does not hold, likely due to a typo, but we'll emphasise the fix. The proof is a reduction from their construction to the \emph{BDHE}-problem of Section \ref{sec:BDHE}. The scheme is proven secure in the Semi-Static model. We note that the proof in the original paper does not hold, likely due to a typo, but we'll emphasise the fix.
We wish to build an algorithm \adv{B}, which will use an adversary \adv{A} who we assume to have a non-negligible advantage in breaking the construction described in \ref{sec:GentryWatersConst}, to break the \emph{BDHE} problem. By breaking the construction in Section \ref{sec:GentryWatersConst}, we mean that \adv{A} will be able to somehow distinguish what is encrypted within an \hdr. \\ \\ We wish to build an algorithm \adv{B}, which will use an adversary \adv{A} who we assume to have a non-negligible advantage in breaking the construction described in \ref{sec:GentryWatersConst}, to break the \emph{BDHE} problem. By breaking the construction in Section \ref{sec:GentryWatersConst}, we mean that \adv{A} will be able to somehow distinguish what is encrypted within an header \hdr. \\ \\
\adv{B} receives a problem instance which contains $g^s, Z, \{g^{a^i}: i \in [0,m] \cup [m+2, 2m]\}$, where $Z$ is either $e(g,g)^{a^{n+1}\cdot s}$ or random in $\Gm_T$. \adv{B} receives a problem instance which contains $g^s, Z, \{g^{a^i}: i \in [0,m] \cup [m+2, 2m]\}$, where $Z$ is either $e(g,g)^{a^{n+1}\cdot s}$ or random in $\Gm_T$.
\begin{description} \begin{description}
\item[Init] \adv{A} commits to a set $\tilde{S} \subseteq [1,n]$. \item[Init] \adv{A} commits to a set $\tilde{S} \subseteq [1,n]$.
@ -303,8 +299,6 @@ A \texttt{DTPKE}-scheme consist of $7$ algorithms: \texttt{DTPKE} $= ($\texttt{S
\end{description} \end{description}
% TODO: Make sure Hdr is consistently either texttt/mathtt or just text.
\subsection{Security Model} \subsection{Security Model}
\begin{description} \begin{description}
@ -332,7 +326,7 @@ A \texttt{DTPKE}-scheme consist of $7$ algorithms: \texttt{DTPKE} $= ($\texttt{S
% 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? % 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} \subsection{A Construction 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). 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).
\begin{theorem} \begin{theorem}
@ -403,13 +397,6 @@ It should be noted that this scheme is very long and as such will be left out of
Is exactly equal to $$2 \cdot (\frac{1}{2} \times (Pr(b'=1 | b=1 \wedge \text{real}) + Pr(b'=1 | b=0 \wedge \text{real})).$$ Is exactly equal to $$2 \cdot (\frac{1}{2} \times (Pr(b'=1 | b=1 \wedge \text{real}) + Pr(b'=1 | b=0 \wedge \text{real})).$$
\end{proof} \end{proof}
% TODO: Consider giving some outro to this
% TODO: Explain this scheme and their security proof which doesn't work. Yikes.
% TODO: Consider making all upk and usk bold
\section{Ad-Hoc Broadcast Encryption} \section{Ad-Hoc Broadcast Encryption}
\label{sec:AHBE} \label{sec:AHBE}
@ -429,7 +416,7 @@ An \emph{Ad-Hoc Broadcast Encryption} system is defined to be \textbf{correct} i
\end{description} \end{description}
\subsection{Definition of Adaptive Security in AHBE} \subsection{Definition of Adaptive Security in \AHBE}
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$. \\ % Both the Challenger and an adversary \adv{A} are given the security parameter $\lambda$. \\
@ -461,7 +448,7 @@ As mentioned, the authors present a transformation for any key homomorphic BE sc
\end{enumerate} \end{enumerate}
\end{definition} \end{definition}
\subsection{Transforming KHBE to AHBE} \subsection{Transforming \KHBE to \AHBE}
The main idea behind their proposed transformation is to use the homomorphic property of the keys of the underlying \KHBE scheme, as illustrated in Figure \ref{fig:KHBEMatrix}, where a question mark (?) indicates that, that specific key is not published, i.e. $d_i(i)$ for $i = 1,\dots,n$, thus, every other key is published as a part of the different public keys. The main idea behind their proposed transformation is to use the homomorphic property of the keys of the underlying \KHBE scheme, as illustrated in Figure \ref{fig:KHBEMatrix}, where a question mark (?) indicates that, that specific key is not published, i.e. $d_i(i)$ for $i = 1,\dots,n$, thus, every other key is published as a part of the different public keys.
\begin{figure} \begin{figure}
@ -480,11 +467,11 @@ The main idea behind their proposed transformation is to use the homomorphic pro
\label{fig:KHBEMatrix} \label{fig:KHBEMatrix}
\end{figure} \end{figure}
Within Figure \ref{fig:KHBEMatrix}, the $PK_i$ is the public key of the BE instance specifically generated by user $i$. A decryption key $d_i(j)$ is generated by user $i$ for user $j$, in the underlying scheme. Each row is then published ($PK_i$) by the corresponding member of the group of broadcast receivers, $\U_i$, but their own specific decryption key , $d_i(i)$ is not published. The key homomorphism then allow for an arbitrary receiver set $S$, as all of the public keys for $i \in S$ can be easily aggregated; $\oplus_{i \in S} PK_i = PK_{\mathtt{AHBE}}$ into a new public key of a new instance of the underlying BE scheme, such that the $j$'th column $\{d_i(j)\}^n_{i=1}$ can be aggregated into a decryption key for this instance; $d(j) = \odot_{i \in S}d_i(j)$, i.e. a decryption key for the public key $PK_{\mathtt{AHBE}}$. Since the diagonal of the matrix is not published, only user $\U_i$ knows $d_i(i)$ and is thus the only one who can compute $d(i)$. This results in a system where a sender can choose any receiver set $S \subseteq[1,N]$ and broadcast to this set under the key $PK_{\mathtt{AHBE}} = \oplus_{i \in S} PK_i$ and only users $\U_i$ for $i \in S$ can decrypt using their decryption key $d(i)$. As $PK_{\mathtt{AHBE}}$ functions like a public key for a regular BE scheme where all users have decryption keys, if $j \not\in S$, user $\U_j$ won't be able use her decryption key $d(j) = \odot_{i \in S}d_i(j)$, as only users in the intended recipient set can decrypt in the new scheme. Note that it is a requirement of the scheme, that all $PK_i$ should be computationally independent and \emph{different}. Intuiviely, if they are not different such that $d_1(1) = d_2(1)$, it's trivial to compute the decryption key of user $\U_1$, by simply looking at the data published by $\U_2$. Within Figure \ref{fig:KHBEMatrix}, the $PK_i$ is the public key of the BE instance specifically generated by user $i$. A decryption key $d_i(j)$ is generated by user $i$ for user $j$, in the underlying scheme. Each row is then published ($PK_i$) by the corresponding member of the group of broadcast receivers, $\U_i$, but their own specific decryption key , $d_i(i)$ is not published. The key homomorphism then allow for an arbitrary receiver set $S$, as all of the public keys for $i \in S$ can be easily aggregated; $\oplus_{i \in S} PK_i = PK_{\mathtt{AHBE}}$ into a new public key of a new instance of the underlying BE scheme, such that the $j$'th column $\{d_i(j)\}^n_{i=1}$ can be aggregated into a decryption key for this instance; $d(j) = \odot_{i \in S}d_i(j)$, i.e. a decryption key for the public key $PK_{\mathtt{AHBE}}$. Since the diagonal of the matrix is not published, only user $\U_i$ knows $d_i(i)$ and is thus the only one who can compute $d(i)$. This results in a system where a sender can choose any receiver set $S \subseteq[1,N]$ and broadcast to this set under the key $PK_{\mathtt{AHBE}} = \oplus_{i \in S} PK_i$ and only users $\U_i$ for $i \in S$ can decrypt using their decryption key $d(i)$. As $PK_{\mathtt{AHBE}}$ functions like a public key for a regular BE scheme where all users have decryption keys, if $j \not\in S$, user $\U_j$ won't be able use her decryption key $d(j) = \odot_{i \in S}d_i(j)$, as only users in the intended recipient set can decrypt in the new scheme. Note that it is a requirement of the scheme, that all $PK_i$ should be computationally independent and \emph{different}. Intuitively, if they are not different such that $d_1(1) = d_2(1)$, it's trivial to compute the decryption key of user $\U_1$, by simply looking at the data published by $\U_2$.
% TODO: Be very consistent in what you call the public keys of the AHBE scheme! % TODO: Be very consistent in what you call the public keys of the AHBE scheme!
\subsubsection{Formal Conversion from KHBE to AHBE} \subsubsection{Formal Conversion from \KHBE to \AHBE}
As discussed, an \AHBE scheme consist of three algorithms; \textbf{KeyGen, AHBEnc, AHBDec}. As discussed, an \AHBE scheme consist of three algorithms; \textbf{KeyGen, AHBEnc, AHBDec}.
\begin{description} \begin{description}
@ -575,7 +562,8 @@ We will describe a game where this homomorphic operation operation breaks the se
\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. \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} \end{description}
\subsection{An AHBE Implementation} \subsection{An \AHBE Implementation}
\label{sec:AHBEImpl}
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}$. 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}$.
We define all algoritms prefixed by $AB$ to be an \emph{adaptively secure} \texttt{BE} algorithm. We define all algoritms prefixed by $AB$ to be an \emph{adaptively secure} \texttt{BE} algorithm.
@ -625,9 +613,10 @@ $$k = \mathtt{ABDec}(S, i, d(i), Hdr, PK_{AHBE}) $$
\subsection{Attempt at Reducing the \AHBE Instantion to BDHE-Problem} \subsection{Attempt at Reducing the \AHBE Instantion to BDHE-Problem}
Seeing that the reduction had some non-salveable issues regarding the decryption keys of the target set $S^*$, we attempted to reduce their instantiation directly to the BDHE problem, which the original scheme due to Gentry and Waters was originally reduced to, to prove its Semi-static security. We recall why the original reduction worked: The values $h_1, \dots, h_n$ are originally picked completely at random from the target group of the bilinear map, $\Gm_T$, which allowed the original reduction to sample $y_1, \dots, y_n$ and lift the generator of the group $\Gm$, $g$, to specific values of $y_i$, whenever we needed to know the discrete log of $h_i$, specifically when $i \in \tilde{S}$, i.e. the set of potential receivers, $h_i = g^{y_i}$. Furthermore, for the rest of the users, $i \not\in \tilde{S}$, they generated the values of $h_i = g^{y_i + a^i}$ meaning that the adversary \adv{B} could in fact not compute the discrete log and would thus not have a chance of computing the header information, if the adversary \adv{A} decided to attack this user. Due to the semi-static nature however, this is not something they have to worry of, as \adv{A} has already commited to $\tilde{S}$. The definition of the $h_i$ for $i \not\in \tilde{S}$, means that \adv{B} can properly answer the extraction queries for these users, as \adv{B} defines the values $r_i$ in such a way, that the exponents cancels out in $d_{i,i} = g^{\alpha}h^{r_i}_i$ and we do not have to bother trying to compute the discrete log of $g^\alpha$, specically the $a^{n+1}$ part of $\alpha = y_0 \cdot a^{n+1}$. The issues then arise, as all the $h_i$ values are required for the \AHBE scheme, essentially meaning we can not fake some and define some in a very specific way, as they are \emph{all} used for the different keys, regardless of the user $i$ being in the attack set $i \in \tilde{S}$, as all the users are using the same underlying \KHBE scheme. This results in the algorthim \adv{B} not being capable of answering extraction queries for any user i outside of the attack set, $i \not\in \tilde{S}$, as \adv{B} also has to generate all the $h$ values in such a way that he can compute the discrete log. Seeing that the reduction had some non-salvageable issues regarding the decryption keys of the target set $S^*$, we attempted to reduce their instantiation from Section \ref{sec:AHBEImpl} directly to the BDHE problem from Section \ref{sec:BDHE}, which the original scheme due to Gentry and Waters from Section \ref{sec:GentryWatersConst} was originally reduced to, to prove the Semi-Static security of it. We recall why the original reduction worked: The values $h_1, \dots, h_n$ are picked completely at random from the target group of the bilinear map, $\Gm_T$, which allowed the original reduction to sample $y_1, \dots, y_n$ and lift the generator of the group $\Gm$, $g$, to specific values of $y_i$, whenever we needed to know the discrete log of $h_i$, specifically when $i \in \tilde{S}$, i.e. the set of potential receivers, $h_i = g^{y_i}$. Particularly, we need to know the discrete log, as we will need to be able to create an ``encryption'' of the $Z$ given from the BDHE instantiation, such that the \hdr will correctly hide the $Z$, if this $Z$ is produced in a proper way and is not in fact random in $\Gm_T$.
Furthermore, for the rest of the users, $i \not\in \tilde{S}$, they generated the values of $h_i = g^{y_i + a^i}$ meaning that the adversary \adv{B} could in fact not compute the discrete log and would thus not have a chance of computing the header information, if the adversary \adv{A} decided to have this user $i$ within the challenge receiver set. Due to the Semi-Static security however, this is not something they have to worry of, as \adv{A} has already commited to $\tilde{S}$. The definition of the $h_i$ for $i \not\in \tilde{S}$, means that \adv{B} can properly answer the extraction queries for these users, as \adv{B} defines the values $r_i$ in such a way, that the exponents cancels out in $d_{i,i} = g^{\alpha}h^{r_i}_i$ and we do not have to bother trying to compute the discrete log of $g^\alpha$, specically the $a^{n+1}$ part of $\alpha = y_0 \cdot a^{n+1}$. The issues then arise, as all the $h_i$ values are required for the \AHBE scheme, essentially meaning we can not fake some and define some in a very specific way, as they are \emph{all} used for the different keys, regardless of the user $i$ being in the attack set $i \in \tilde{S}$, as all the users are using the same underlying \KHBE scheme. This results in the algorthim \adv{B} not being capable of answering extraction queries for any user i outside of the attack set, $i \not\in \tilde{S}$, as \adv{B} also has to generate all the $h$ values in such a way that he can compute the discrete log, which he can not accomplish, if \adv{B} also wants to be able to answer any extraction queries, as he then will neen something which cancels out the value $\alpha$, which has to be defined in a certain way, constrained by the value of $Z$.
We note, that it is not obvious if the value of all the different $\alpha$'s can be changed. For the \AHBE scheme, every single user $i$ has their own value of $\alpha_i$ and one might be able to hide something within these values, but it is doubtful, as they have to be generated from the exponentiations of $g$ we are given through the BDHE problem, $\{g^{a^i} : i \in [0,n] \cup [n+2,2n]\}$ for the values to properly match the decision problem, whether $Z = e(g,g)^{a^{n+1} \cdot s}$. However, if this was successful, one could hide either an easily computable discrete log here or something which could cancel out with $r_i$, which would make it much easier to answer the extraction queries. We note, that it is not obvious if the value of all the different $\alpha$'s can be changed. For the \AHBE scheme, every single user $i$ has their own value of $\alpha_i$ and one might be able to hide something within these values, but it is doubtful, as they have to be generated from the exponentiations of $g$ which we are given through the BDHE problem, $\{g^{a^i} : i \in [0,n] \cup [n+2,2n]\}$ for the values to properly match the decision problem, whether $Z = e(g,g)^{a^{n+1} \cdot s}$. However, if this was successful, one could hide either an easily computable discrete log here or something which could cancel out with $r_i$, which would make it much easier to answer the extraction queries.
As such, we conclude that, if there is a reduction to be found from the \AHBE instantiation directly to the BDHE problem, then we were not to find this. As such, we conclude that, if there is a reduction to be found from the \AHBE instantiation directly to the BDHE problem, then we were not to find this.
@ -649,8 +638,6 @@ As such, we conclude that, if there is a reduction to be found from the \AHBE in
\includepdf[pages=2-,pagecommand={},width=\textwidth]{papers/IBESecProof.pdf} \includepdf[pages=2-,pagecommand={},width=\textwidth]{papers/IBESecProof.pdf}
% TODO: Properly crop the construction
\includepdf[pages=1,pagecommand={\section{\texttt{DTPKE} Scheme} \label{app:DTPKE-Scheme}},width=\textwidth]{papers/DTPKE-Const.pdf} \includepdf[pages=1,pagecommand={\section{\texttt{DTPKE} Scheme} \label{app:DTPKE-Scheme}},width=\textwidth]{papers/DTPKE-Const.pdf}