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

pls

This commit is contained in:
= 2019-12-19 01:03:50 +01:00
parent 6c168e80bf
commit 7862b06c59
2 changed files with 2 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

BIN
papers/307.PDF Normal file
View File

Binary file not shown.

5
report.tex
View File

@ -196,7 +196,6 @@ The advantage of \adv{A} is as expected; $Adv^{\texttt{AHBE}}_{\mathcal{A},n,N}(
% TODO: Write up all of the mathematical assumptions
% TODO: Write of the Threshold Public Key Encryption Scheme; https://www.di.ens.fr/david.pointcheval/Documents/Papers/2008_crypto.pdf
\section{Identity Based Encryption}
We will cover a basic 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}). Note that it can be extended to cover this, but this is out of the scope of this paper. We note that although this scheme is not awefully relevant for the rest of this 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.
@ -234,7 +233,7 @@ The scheme can be shown to be semantically secure (\texttt{IND-ID-CPA}), assumin
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}.
\subsection{Modelling \texttt{DTPKE}}
A \texttt{DTPKE}-scheme consist of $7$ algorithms: $\mathtt{DTPKE} = (Setup, Join, Encrypt, ValidateCT, ShareDecrypt, ShareVerify, Combine)$. \vsp{4mm}
A \texttt{DTPKE}-scheme consist of $7$ algorithms: \texttt{DTPKE} $= ($\texttt{Setup}, \texttt{Join}, \texttt{Encrypt}, \texttt{ValidateCT}, \texttt{ShareDecrypt}, \texttt{ShareVerify}, \texttt{Combine}$)$. \vsp{4mm}
\hsp{5mm}\textbf{Setup$(\lambda)$:}\quad 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. \vsp{3mm}
\hsp{5mm}\textbf{Join$(MK, \mathtt{ID})$:}\quad 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.\vsp{3mm}
\hsp{5mm}\textbf{Encryptp$(EK, S, t, M)$:}\quad 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.\vsp{3mm}
@ -303,7 +302,7 @@ 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.
% TODO: Fix those [1,n]. I want [n] everywhere, instead. Also mention that [n] is shorthand for it
% TODO: The dynamic threshold encryption scheme
\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$.