Compare commits
81 Commits
Author | SHA1 | Date | |
---|---|---|---|
064c6bf599 | |||
b01f672c15 | |||
f798fd98a2 | |||
546f20f261 | |||
37e7b11a7f | |||
a2ca86c82e | |||
5597311f67 | |||
c3149da051 | |||
6911a16ab1 | |||
c7f331cb56 | |||
c8acc8a00d | |||
0afb4d093a | |||
aac17e07fb | |||
506076f5a4 | |||
2374a814b5 | |||
64be075085 | |||
ac6f905357 | |||
866b5dbbfa | |||
545b8c9957 | |||
39a6fbde61 | |||
d21224ac4c | |||
87d7795a89 | |||
9487e5feab | |||
c36b958325 | |||
bbe07d7a4b | |||
3ba9a63d96 | |||
0b78d472b6 | |||
0086817700 | |||
f659cc4180 | |||
96941cad0f | |||
846f869ef1 | |||
816eab7635 | |||
f4d8e4e8d4 | |||
8147d4ec4a | |||
ec37a83922 | |||
52425244ef | |||
4e8b1cb8e7 | |||
5686bb6d7b | |||
ce95a4a48a | |||
3e026be138 | |||
9a895e0c42 | |||
e21c23b10f | |||
5315cb3d36 | |||
0450cf7c19 | |||
0a7061f2e7 | |||
11a6d28027 | |||
979001de64 | |||
88727cf006 | |||
2c9def1484 | |||
d9f6ba5be9 | |||
150c3f5a9d | |||
065fac349d | |||
1004ddabea | |||
b7a041f7c2 | |||
edd6460beb | |||
3e9fc57d28 | |||
baaeb3612a | |||
83a8289370 | |||
2447e63705 | |||
b5b4abc98d | |||
a71a69000a | |||
6668056791 | |||
8beaf5194a | |||
1c50f38721 | |||
7bf948a6f4 | |||
66f7a9b8b3 | |||
d691b2c0b7 | |||
1ee9867861 | |||
dd85244796 | |||
8941c51699 | |||
ec741eb394 | |||
0f6bea0a04 | |||
988a290b8d | |||
2b136b3966 | |||
4db4524dff | |||
7674362b6e | |||
c607ab6d7d | |||
14d21c050b | |||
f132feca53 | |||
1b2ee7fc14 | |||
0e4f4e4303 |
122
.drone.yml
122
.drone.yml
@ -4,68 +4,76 @@ type: exec
|
||||
name: Build and deploy
|
||||
|
||||
steps:
|
||||
- name: Linting
|
||||
commands:
|
||||
- bash linting.sh
|
||||
- name: Build Cw1
|
||||
commands:
|
||||
- cd firstcw/cw
|
||||
- pdflatex cw.tex
|
||||
# Prepare bib
|
||||
- /usr/bin/vendor_perl/biber cw
|
||||
# Compile twice for the table of contents and for bib text
|
||||
- pdflatex cw.tex
|
||||
- pdflatex cw.tex
|
||||
- cd -
|
||||
|
||||
- name: Build UPDS-1
|
||||
commands:
|
||||
- cd projectsynopsis
|
||||
- pdflatex project-synopsis.tex
|
||||
# Prepare bib
|
||||
- /usr/bin/vendor_perl/biber project-synopsis
|
||||
# Compile twice for the table of contents and for bib text
|
||||
- pdflatex project-synopsis.tex
|
||||
- cd -
|
||||
- name: Build Cw2
|
||||
commands:
|
||||
- cd secondcw/cw
|
||||
- pdflatex cw.tex
|
||||
# Prepare bib
|
||||
- /usr/bin/vendor_perl/biber cw
|
||||
# Compile twice for the table of contents and for bib text
|
||||
- pdflatex cw.tex
|
||||
- pdflatex cw.tex
|
||||
- mv cw.pdf cw2.pdf
|
||||
- cd -
|
||||
|
||||
# - name: Build Report
|
||||
# commands:
|
||||
# - cd report
|
||||
# - cp ../upds-1/UPDS-content.tex UPDS-1-content.tex
|
||||
# - cp ../upds-2/UPDS-content.tex UPDS-2-content.tex
|
||||
# - pdflatex report.tex
|
||||
# # Prepare bib
|
||||
# - /usr/bin/vendor_perl/biber report
|
||||
# # Compile twice for the table of contents and for bib text
|
||||
# - pdflatex report.tex
|
||||
# - cd -
|
||||
#
|
||||
# - name: Generate text
|
||||
# commands:
|
||||
# - pnpm i
|
||||
# - pnpm ts-node main.ts report/report.tex
|
||||
# - name: Build Report
|
||||
# commands:
|
||||
# - cd report
|
||||
# - cp ../upds-1/UPDS-content.tex UPDS-1-content.tex
|
||||
# - cp ../upds-2/UPDS-content.tex UPDS-2-content.tex
|
||||
# - pdflatex report.tex
|
||||
# # Prepare bib
|
||||
# - /usr/bin/vendor_perl/biber report
|
||||
# # Compile twice for the table of contents and for bib text
|
||||
# - pdflatex report.tex
|
||||
# - cd -
|
||||
#
|
||||
# - name: Generate text
|
||||
# commands:
|
||||
# - pnpm i
|
||||
# - pnpm ts-node main.ts report/report.tex
|
||||
|
||||
- name: gitea_release
|
||||
environment:
|
||||
TOKEN:
|
||||
from_secret: token
|
||||
commands:
|
||||
- tea login add --url https://git.andr3h3nriqu3s.com --token "$TOKEN"
|
||||
- tea r rm -y current || echo "Release not found"
|
||||
# - tea r c --title "Latest Report" --asset report/report.pdf --asset upds-1/UPDS12-1.pdf --asset upds-2/UPDS12-2.pdf --asset results.txt --asset poster/poster.pdf current
|
||||
- tea r c --title "Latest Report" --asset projectsynopsis/project-synopsis.pdf current
|
||||
- name: gitea_release
|
||||
environment:
|
||||
TOKEN:
|
||||
from_secret: token
|
||||
commands:
|
||||
- tea login add --url https://git.andr3h3nriqu3s.com --token "$TOKEN"
|
||||
- tea r rm -y latest || echo "Release not found"
|
||||
- tea r c --title "Latest" --asset firstcw/cw/cw.pdf --asset secondcw/cw/cw2.pdf latest
|
||||
|
||||
- name: Remove current on failure
|
||||
environment:
|
||||
TOKEN:
|
||||
from_secret: token
|
||||
commands:
|
||||
- tea login add --url https://git.andr3h3nriqu3s.com --token "$TOKEN"
|
||||
- tea r rm -y current || echo "Release not found"
|
||||
trigger:
|
||||
status:
|
||||
- failure
|
||||
when:
|
||||
status:
|
||||
- failure
|
||||
- name: Remove current on failure
|
||||
environment:
|
||||
TOKEN:
|
||||
from_secret: token
|
||||
commands:
|
||||
- tea login add --url https://git.andr3h3nriqu3s.com --token "$TOKEN"
|
||||
- tea r rm -y latest || echo "Release not found"
|
||||
trigger:
|
||||
status:
|
||||
- failure
|
||||
when:
|
||||
status:
|
||||
- failure
|
||||
|
||||
#- name: latest
|
||||
# environment:
|
||||
# TOKEN:
|
||||
# from_secret: token
|
||||
# commands:
|
||||
# - tea r rm -y "3rd-metting" || echo "Release not found"
|
||||
# - tea r c --title "Last Metting Report" --asset report/report.pdf --asset upds-1/UPDS12-1.pdf --asset upds-2/UPDS12-2.pdf "3rd-metting"
|
||||
# - name: latest
|
||||
# environment:
|
||||
# TOKEN:
|
||||
# from_secret: token
|
||||
# commands:
|
||||
# - tea r rm -y "3rd-metting" || echo "Release not found"
|
||||
# - tea r c --title "Last Metting Report" --asset report/report.pdf --asset upds-1/UPDS12-1.pdf --asset upds-2/UPDS12-2.pdf "3rd-metting"
|
||||
|
||||
trigger:
|
||||
branch:
|
||||
|
382
firstcw/cw/cw.tex
Normal file
382
firstcw/cw/cw.tex
Normal file
@ -0,0 +1,382 @@
|
||||
%%% Preamble
|
||||
\documentclass[11pt, a4paper]{article}
|
||||
|
||||
\usepackage[english]{babel} % English language/hyphenation
|
||||
\usepackage{url}
|
||||
\usepackage{tabularx}
|
||||
\usepackage{pdfpages}
|
||||
\usepackage{float}
|
||||
\usepackage{amsmath, amssymb}
|
||||
\usepackage{systeme}
|
||||
|
||||
\usepackage{graphicx}
|
||||
\graphicspath{ {../images for report/} }
|
||||
\usepackage[margin=2cm]{geometry}
|
||||
|
||||
\usepackage{hyperref}
|
||||
\hypersetup{
|
||||
colorlinks,
|
||||
citecolor=black,
|
||||
filecolor=black,
|
||||
linkcolor=black,
|
||||
urlcolor=black
|
||||
}
|
||||
|
||||
\usepackage{cleveref}
|
||||
|
||||
%%% Custom headers/footers (fancyhdr package)
|
||||
\usepackage{fancyhdr}
|
||||
\pagestyle{fancyplain}
|
||||
\fancyhead{} % No page header
|
||||
\fancyfoot[L]{} % Empty
|
||||
\fancyfoot[C]{\thepage} % Pagenumbering
|
||||
\fancyfoot[R]{} % Empty
|
||||
\renewcommand{\headrulewidth}{0pt} % Remove header underlines
|
||||
\renewcommand{\footrulewidth}{0pt} % Remove footer underlines
|
||||
\setlength{\headheight}{13.6pt}
|
||||
|
||||
% numeric
|
||||
\usepackage[style=ieee,sorting=none,backend=biber]{biblatex}
|
||||
\addbibresource{../main.bib}
|
||||
|
||||
% Write the approved title of your dissertation
|
||||
\title{Automated image classification with expandable models}
|
||||
|
||||
% Write your full name, as in University records
|
||||
\author{Andre Henriques, 6644818}
|
||||
|
||||
\date{}
|
||||
|
||||
%%% Begin document
|
||||
\begin{document}
|
||||
\section*{1}
|
||||
\subsection*{1.1}
|
||||
key: JDQLWBSNZM
|
||||
|
||||
w1: MONISTICAL
|
||||
|
||||
w2: APHRODITES
|
||||
\subsection*{1.2}
|
||||
The first step was to load all the words from the word list into a tree, where each depth of the tree corresponds with an $i$th letter of the word. The branches that come off each node correspond to the next letter of the word.i.e.
|
||||
\begin{itemize}
|
||||
\item aa…
|
||||
\item ab…
|
||||
\item ba…
|
||||
\end{itemize}
|
||||
|
||||
Would generate a tree that looks like:
|
||||
|
||||
$$()\to(a\to(a, b), b\to(a))$$
|
||||
|
||||
Since the words were encrypted with the same key, that means if we were to generate a possible key, that key would need to decrypt both ciphertexts such that when the tree is navigated we navigate to nodes that exist. If the key results in a path in the tree that does not exist, then we can disregard that answer as a possible key and continue with the possible next key.
|
||||
Once you find a key that is the same length as the cipher text, we know that we found the right key.
|
||||
|
||||
\section*{2}
|
||||
\subsection*{2.1}
|
||||
Ciphertext:
|
||||
6cea122f3b42975bdbbeb7f2c6efaf9fd5a54fdd62\textbf{3c}27\textbf{6f}55358f4fbcb7a9492d0451b7019c69faef5fd23103ff7ec521fbbc6516ca2cb2ca663d5dbff86bcf
|
||||
|
||||
T=2nd block
|
||||
|
||||
U=6th byte from the 2nd block (38th bit overall)
|
||||
|
||||
V=0x33
|
||||
|
||||
W=0x3c
|
||||
|
||||
X=8th byte from the 2nd block (40th bit overall)
|
||||
|
||||
Y=0x6c
|
||||
|
||||
Z=0x6f
|
||||
|
||||
To change the given cipher text, we need to first find the block we want to change and go to the previous block, this only works for blocks after the first one, after that, we need to find the value that comes out of the Encryption function, and we can do that if we follow this formula:
|
||||
$$\text{After Encryption}\oplus\text{Previous Block Original Ciphertext}=\text{PlainText}\iff\text{After Encryption}=\text{Previous Block Original Ciphertext}\oplus\text{PlainText}$$
|
||||
After we calculate the value that comes out of the encryption function and before we xor with the previous block, we can now calculate the value that we need to change the previous block in the cipher text to:
|
||||
$$\text{After Encryption}\oplus\text{Previous Block Altered Ciphertext}=\text{Altered PlainText}\iff\text{Previous Block Altered Ciphertext}=\text{After Encryption}\oplus\text{Altered PlainText}$$
|
||||
|
||||
\subsection*{2.2}
|
||||
The plaintext will change in the sections that we want to change; "7:00'' to "8:30''; and "t Guildford Stat'' will change to random values.
|
||||
|
||||
\subsection*{2.3}
|
||||
The change is similar to the one described in 2.1 but with the iv value instead of the previous block
|
||||
$$\text{After Encryption}\oplus\text{Original IV value}=\text{PlainText}\iff\text{After Encryption}=\text{Original IV value}\oplus\text{PlainText}$$
|
||||
After we calculate the value that comes out of the encryption function and before we xor with IV value, we can now calculate the value that we need to change the IV value to:
|
||||
$$\text{After Encryption}\oplus\text{New IV value}=\text{Altered PlainText}\iff\text{New IV value}=\text{After Encryption}\oplus\text{Altered PlainText}$$
|
||||
|
||||
|
||||
\subsection*{2.4}
|
||||
You cannot change the location word "station'' because the word is spread between 2 blocks, which means that to change the second part of the word "ion'', you need to change the previos block but by changing the previous block the rest of the word "stat'' would have become garbled.
|
||||
|
||||
\section*{3}
|
||||
\subsection*{3.1}
|
||||
The computational hard problem is factorization
|
||||
|
||||
\subsection*{3.2}
|
||||
I used factorization to obtain the private key. After obtaining the private key, I can decrypt the cipher text and obtain "handlebars''
|
||||
|
||||
\subsection*{3.3}
|
||||
I used the general number sieve\cite{cadonfs} to factorize the public modulus and obtained:
|
||||
$$p=112546167358047505471958486197519319605436748416824057782825895564365669780011$$
|
||||
and
|
||||
$$q=65802972772386034028625679514602920156340140357656235951559577501150333990623$$
|
||||
with p and q I calculated
|
||||
$$d=15456539435705642462121419885899941392796455594867269122932971401500915$$
|
||||
$$98977726717239879077953798120855868459360771804433616650588668281034152580212290153$$
|
||||
with d you can decrypt the ciphertext
|
||||
I used the OpenSSL crypto library with the $p,q,d,m,e$ to decrypt the cipher text
|
||||
|
||||
\subsection*{3.4}
|
||||
While factorizing the numbers takes more time, than a dictionary attack, it allows me to decrypt any message that was encrypted with this public key. It also allows me to decrypt messages that have different padding, including padding methods that use random values.
|
||||
|
||||
\subsection*{3.5}
|
||||
Yes, since I know the private key I can just decrypt the message.
|
||||
|
||||
\section*{4}
|
||||
\subsection*{4.1}
|
||||
$$P||R = E(K,C)$$
|
||||
then you can remove the $R$ part and the $P$ can be obtained
|
||||
|
||||
\subsection*{4.2}
|
||||
The q pairs could look like: $${(1, k),(2,k),(3,k)\cdots(q, k)}$$
|
||||
where k is a constant value for simplicity sets say $k=0$
|
||||
|
||||
$E_b$ is the list of encrypted values returned by the oracle
|
||||
|
||||
These q pairs work because when the oracle selects b=0:
|
||||
|
||||
There will be no collisions:
|
||||
$$\forall i,k : i \ne j \land P_{0i} \ne P_{0j} \implies E_{0i} \ne E_{0j}$$
|
||||
|
||||
therefore if you don't find any colissions you can assume that the the oracle selected b=0
|
||||
|
||||
if the oracle selects b=1 and if q is big enough, there will be colissions:
|
||||
|
||||
$$\exists i,k : i \ne j \land P_{1i} = P_{1j} \land R_i = R_j \implies E_{1i} = E_{1j}$$
|
||||
where $R$ is the list of random values generated for each pair
|
||||
|
||||
\subsection*{4.3}
|
||||
Our random value is $R = u-bit long digit$ which means that it has $2^u$ possible values.
|
||||
And since we know that if we throw $q$ balls into $p$ holes, a collision is bound to happen at the probability of $\frac{q^2}{2p}$, that guessing a $2^u$ random value by doing $q$ guesses is:
|
||||
$$\frac{q^2}{2(2^u)}$$
|
||||
We can calculate:
|
||||
$$\frac{q^2}{2(2^u)}>\frac{1}{2}\iff q> 2^{\frac{u}{2}}$$
|
||||
|
||||
|
||||
\subsection*{4.4}
|
||||
The size of TripleDES is 64 bit long which makes $u=64/2=32$ making the q
|
||||
$$q> 2^\frac{32}{2}\iff q > 65536$$
|
||||
|
||||
\subsection*{4.5}
|
||||
The size of AES is 128 bit long which makes $u=128/2=64$ making the q
|
||||
$$q>t 2^\frac{64}{2}\iff q > 4294967296$$
|
||||
|
||||
\subsection*{4.6}
|
||||
Since in both 4.4 and 4.5 the value of $q$ is not large enough, the scheme is not CPA secure
|
||||
|
||||
\section*{5}
|
||||
\subsection*{5.1}
|
||||
The hash function is collision resistant for $n=1$, since if the block size is one of, the hash function is the encryption. Therefore:
|
||||
if the message is only one block long:
|
||||
|
||||
$$H=E$$
|
||||
$$m\ne m'$$
|
||||
$$H(m)=E(K, IV \oplus m) = C_1$$
|
||||
$$H(m')=E(K, IV \oplus m') = C_2$$
|
||||
And if the hashing function was not collision resistant, that would imply
|
||||
$$C_1=C_2\implies D(C_1)=D(C_2) \implies m=m'$$
|
||||
and since $m\ne m'$ the hash function is collision resistant, for messages with 1 block.
|
||||
|
||||
For if the block size is bigger than one we can say
|
||||
$$H(m)=E(m)_{\text{Last Block}}$$
|
||||
$$E(m)=E(K, m)$$
|
||||
$$\exists a,b,c,d : m = a||b \land m' = c||d$$
|
||||
where a,b,c,d are the size of one block
|
||||
$$H(m)=E(b \oplus E(a \oplus IV)) = C_1$$
|
||||
$$H(m')=E(d \oplus E(c \oplus IV)) = C_2$$
|
||||
since it's possible to have:
|
||||
$$b \oplus E(a \oplus IV) = d \oplus E(c \oplus IV) \implies$$
|
||||
$$\implies C_1=C_2$$
|
||||
with:
|
||||
$$a \ne b \ne c \ne d$$
|
||||
therefore
|
||||
$$H(m)=H(m') \land m\ne m'$$
|
||||
therefore, the hash function is not collision resistant.
|
||||
Since this can be expanded with more than 2 blocks, the hash function is not collision resistant for any message bigger than 1 block.
|
||||
|
||||
\subsection*{5.2}
|
||||
When the message has the size of a block, the authenticated encryption system scheme has both data confidentiality and integrity because the hash function is only collision resistant with messages of block size 1. As a result, it is impossible to change the ciphertext in away that when the MAC is generated on the receiver side, the mac will not be the same. And since the mac key is not public, the attacker cannot generate a new mac to authenticate the fake message.
|
||||
|
||||
When the message has a bigger size than one block, the scheme still has data confidentiality because the message can still not be decrypted without knowing the key. But it has no longer data integrity because the attacker can change the message in such a way that it would generate a hash collision; therefore the receiver could not prove that the information that was received was not sent that way by the sender; therefore the encryption system does not have data integrity.
|
||||
|
||||
\section*{6}
|
||||
\subsection*{Senario 1}
|
||||
\subsubsection*{6.1.1}
|
||||
Bob can check if the equation holds then Bob knows that Alice signed the Contract
|
||||
$$h = H(g^s\times y^h \text{ mod } p || C)$$
|
||||
where y is Alice's pub key.
|
||||
|
||||
\subsubsection*{6.1.2}
|
||||
If the Alice used the the same r then this equation would only have 2 variables to solve, $a$ and $r$ which makes this equation possible to solve.
|
||||
$$\begin{cases}
|
||||
s = r - h \times a \text{ mod } q\\
|
||||
s' = r - h' \times a \text{ mod } q
|
||||
\end{cases} \iff
|
||||
\begin{cases}
|
||||
r = s + h \times a \\
|
||||
a = \frac{s' - s}{h - h'} \land h \ne h'
|
||||
\end{cases}
|
||||
$$
|
||||
therefor Alice private key $a$ is:
|
||||
$$
|
||||
a = \frac{s' - s}{h - h'}
|
||||
$$
|
||||
|
||||
\subsection*{Senario 2}
|
||||
\subsubsection*{6.2.1}
|
||||
To sign a contract $C$ Alice first chooses 2 random values $r$ and $c_2$ then $z$ is calculated $z=g^r\times y_b^{c_2}$. After we have $z$ we can calculate the intermediary value $c$, $c = H(y_a, y_b, C, z)$. After having $c$ we calculate $c_1$, $c_1 = c - c_2$. $c_1$ is then used to calculate $s = r - c1 \times a mod q$. The signature is $(c_1, c_2, s)$
|
||||
|
||||
\subsubsection*{6.2.2}
|
||||
No because Alice only needs Bob's public key which is publicly avaiable
|
||||
|
||||
\subsubsection*{6.2.3}
|
||||
The signature is verified if the equation holds
|
||||
$$c_1 + c_2 = H(y_a, y_b, C, g^s\times y_a^{c_1} \times y_b^{c_2} mod p )$$
|
||||
|
||||
\subsubsection*{6.2.4}
|
||||
No, because the signature is generated from multiple public keys and Alice's private key; therefore Chris will not be able to tell who signed the contract
|
||||
|
||||
\subsection*{Senario 3}
|
||||
\subsubsection*{6.3.1}
|
||||
The encryption works because the numbers that were chosen by Alice and Bob make this equation work
|
||||
$$(m^{r_a})^{r_b} = m (\text{mod } p)$$
|
||||
|
||||
which means that
|
||||
|
||||
$$(((m^{r_{a1}})^{r_{b1}})^{r_{a2}})^{r_{b2}} = m (\text{mod } p)$$
|
||||
|
||||
in this case, $r_{a1}$ from Alice cancels $r_{a2}$ from Alice, and $r_{b1}$ from Bob cancels $r_{b2}$ from Bob.
|
||||
|
||||
\subsubsection*{6.3.2}
|
||||
To send an encrypted message using this system between 2 people, i.e. Alice and Bob:
|
||||
|
||||
\begin{enumerate}
|
||||
\item Bob and Alice choose a prime $p$
|
||||
\item The sender, let's say Alice, selects $m$ and two random values $r_{a1}$ and $r_{a2}$ such that $(m^{r_{a1}})^{r_{a2}} = m (\text{mod } p)$
|
||||
\item Alice then calculates $t1 = m^{r_{a1}} (\text{mod } p)$, Alice sends $t1$ to bob.
|
||||
\item Bob selects two random values $r_{b1}$ and $r_{b2}$ such that $(m^{r_{b1}})^{r_{b2}} = m (\text{mod } p)$
|
||||
\item Bob then calculates $t2 = t1^{r_{b1}} (\text{mod } p)$, Bob sends $t2$ to Alice
|
||||
\item Alice then calculates $t3 = t2^{r_{a2}} (\text{mod } p)$, this undoes step 3, then Alice sends $t3$ to bob
|
||||
\item Bob then calculates $m = t3^{r_{b2}} (\text{mod } p)$, this undoes step 5
|
||||
\end{enumerate}
|
||||
|
||||
\subsubsection*{6.3.3}
|
||||
Information is exchanged 4 times with this crypto system, they choose the primes and then 3 exchanges happen during the encryption process.
|
||||
|
||||
While for ElGamal you need to exchange information only twice, once to exchange public keys and the second to exchange the encrypted message
|
||||
|
||||
\subsubsection*{6.3.4}
|
||||
If the discrete logarithm problem is easy to solve, then Elgamal is also easy to solve. While for this case, the being able to solve the discrete logarithm problem does not help an attacker with breaking the algorithm; because the attacker only knows the result of the exponentiation and does not know the value of the base. This is not the case with Elgamal, where the base is publicly known.
|
||||
|
||||
The Diffie-Hellman problem also does not apply, since that problem relies on. If we know $g^x$ and $g^y$ being able to figure out $g^{xy}$ but in this case the problem is slightly different. In this case the base, $m$ is not public therefore being able to solve the Diffie-Hellman problem, does not help with this encryption problem.
|
||||
|
||||
|
||||
\section*{7}
|
||||
\subsection*{7.1}
|
||||
$$v1 = (137, 312), v2 = (215, -187)$$
|
||||
$$u1 = (1975,438), u2 = (7548, 1627)$$
|
||||
|
||||
$$B = \begin{pmatrix}
|
||||
137 & 312 \\
|
||||
215 & -187 \\
|
||||
\end{pmatrix}$$
|
||||
$$U = \begin{pmatrix}
|
||||
1975 & 438\\
|
||||
7548 & 1627\\
|
||||
\end{pmatrix}$$
|
||||
|
||||
A:
|
||||
|
||||
$$det(L)=|det(B)|=|-92699|=92699$$
|
||||
|
||||
$$H(B)=(\frac{det(L)}{\|v1\|\times\|v2\|})^\frac{1}{n}=(\frac{92699}{\sqrt{v1_1^2 + v1_2^2}\times\sqrt{v2_1^2 + v2_2^2}})^\frac{1}{2}=$$
|
||||
|
||||
$$=\frac{\sqrt{92699}}{9427678922^{\frac{1}{4}}}\approx0.977094\approx0.98$$
|
||||
|
||||
The Hadamard ration for the private bias is $0.98$
|
||||
|
||||
$$H(U)=(\frac{det(L)}{\|u1\|\times\|u2\|})^\frac{1}{n}=(\frac{92699}{\sqrt{u1_1^2 + u1_2^2}\times\sqrt{u2_1^2 + u2_2^2}})^\frac{1}{2}=$$
|
||||
$$=\frac{\sqrt{92699}}{243990681350077^{\frac{1}{4}}}\approx0.0770361\approx0.077$$
|
||||
|
||||
The Hadamard ration for the public bias is $0.077$
|
||||
|
||||
B:
|
||||
$$w = (30548, 6642)$$
|
||||
$$\begin{cases}
|
||||
30548=137t_1 + 215t_2\\
|
||||
6642=312t_1 + -187t_2\\
|
||||
\end{cases}= \begin{cases}
|
||||
t_1 = \frac{7140506}{92699}\\
|
||||
t_2 = \frac{8621022}{92699}\\
|
||||
\end{cases}=\begin{cases}
|
||||
t_1 \approx 77.03\\
|
||||
t_2 \approx 93\\
|
||||
\end{cases}=\begin{cases}
|
||||
t_1 \approx 77\\
|
||||
t_2 \approx 93\\
|
||||
\end{cases}$$
|
||||
|
||||
$$v'=77(137,312) + 93(215,-187)=(30544, 6633)$$
|
||||
$$r=w-v'=(4, 9)$$
|
||||
|
||||
$$w = v'\times m + r\iff
|
||||
m= (30544, 6633)\times\begin{pmatrix}
|
||||
1975 & 438\\
|
||||
7548 & 1627\\
|
||||
\end{pmatrix}^{-1}\iff
|
||||
m=(4,3)$$
|
||||
|
||||
The plaintext is $(4, 3)$ and the $r=(4,9)$
|
||||
|
||||
C:
|
||||
$$\begin{cases}
|
||||
30548=1975t_1 + 7548t_2\\
|
||||
6642=438t_1 + 1627t_2\\
|
||||
\end{cases}= \begin{cases}
|
||||
t_1 = \frac{432220}{92699}\\
|
||||
t_2 = \frac{262074}{92699}\\
|
||||
\end{cases}=\begin{cases}
|
||||
t_1 \approx 4.66\\
|
||||
t_2 \approx 2.83\\
|
||||
\end{cases}=\begin{cases}
|
||||
t_1 \approx 5\\
|
||||
t_2 \approx 3\\
|
||||
\end{cases}
|
||||
$$
|
||||
|
||||
$$v'=5(1975,438) + 3(7548, 1627)=(32519, 7071)$$
|
||||
|
||||
|
||||
$$
|
||||
w = v'\times m' + r\iff
|
||||
m'= (32519, 7071)\times\begin{pmatrix}
|
||||
1975 & 438\\
|
||||
7548 & 1627\\
|
||||
\end{pmatrix}^{-1}\iff
|
||||
m'=(5,3)
|
||||
$$
|
||||
|
||||
Using $u_1$ and $u_2$ we do not dectypt correctly $m\ne m'$
|
||||
|
||||
\subsection*{7.2}
|
||||
No, he should not.
|
||||
If $r$ is not changed, then we could submit to the oracle $(1,0)$ and $(2,0)$ and if the oracle gives us 2 cipher texts that are the same then we know that $b = 1$ and if they are different, then we know its $b=0$ therefore not changing the $r$ is not secure.
|
||||
|
||||
|
||||
|
||||
\section*{References}
|
||||
\printbibliography[heading=none]
|
||||
|
||||
\end{document}
|
||||
|
||||
|
@ -77,7 +77,7 @@ pub fn main() !void {
|
||||
}
|
||||
|
||||
for (changes.items) |a| {
|
||||
println("Change on pos: {} '{c}'(0x{x:0>2}) -> '{c}'(0x{x:0>2})", .{ a, plain[a], plain[a], plair[a], plair[a] });
|
||||
println("Change on pos: {} '{c}'(0x{x:0>2}) -> '{c}'(0x{x:0>2})", .{ a + 1, plain[a], plain[a], plair[a], plair[a] });
|
||||
println("This will update on block {} at pos {}", .{ 1 + (a - 16) / 16, 1 + (a - 16) % 16 });
|
||||
println("Current cypher 0x{x:0>2}", .{cipher[a - 16]});
|
||||
var after_aes = cipher[a - 16] ^ plain[a];
|
8
firstcw/main.bib
Normal file
8
firstcw/main.bib
Normal file
@ -0,0 +1,8 @@
|
||||
@misc{cadonfs,
|
||||
author={The CADO-NFS Development Team},
|
||||
title={{CADO-NFS}, An Implementation of the Number Field Sieve
|
||||
Algorithm},
|
||||
note={Release 2.3.0},
|
||||
year={2017},
|
||||
url={http://cado-nfs.inria.fr/}
|
||||
}
|
104
main.bib
104
main.bib
@ -1,104 +0,0 @@
|
||||
@online{google-vision-api,
|
||||
author ={Google},
|
||||
title ={Vision AI | Google Cloud},
|
||||
year ={2023},
|
||||
url ={https://cloud.google.com/vision?hl=en}
|
||||
}
|
||||
|
||||
@article{amazon-rekognition,
|
||||
author ={Amazon},
|
||||
title ={Image Recognition Software - ML Image \& Video Analysis - Amazon Rekognition - AWS},
|
||||
year ={2023},
|
||||
url ={https://aws.amazon.com/rekognition/}
|
||||
}
|
||||
@article{lecun1989handwritten,
|
||||
title={Handwritten digit recognition with a back-propagation network},
|
||||
author={LeCun, Yann and Boser, Bernhard and Denker, John and Henderson, Donnie and Howard, Richard and Hubbard, Wayne and Jackel, Lawrence},
|
||||
journal={Advances in neural information processing systems},
|
||||
volume={2},
|
||||
year={1989}
|
||||
}
|
||||
@article{krizhevsky2012imagenet,
|
||||
title={Imagenet classification with deep convolutional neural networks},
|
||||
author={Krizhevsky, Alex and Sutskever, Ilya and Hinton, Geoffrey E},
|
||||
journal={Advances in neural information processing systems},
|
||||
volume={25},
|
||||
year={2012}
|
||||
}
|
||||
@article{fukushima1980neocognitron,
|
||||
title={Neocognitron: A self-organizing neural network model for a mechanism of pattern recognition unaffected by shift in position},
|
||||
author={Fukushima, Kunihiko},
|
||||
journal={Biological cybernetics},
|
||||
volume={36},
|
||||
number={4},
|
||||
pages={193--202},
|
||||
year={1980},
|
||||
publisher={Springer}
|
||||
}
|
||||
@misc{tensorflow2015-whitepaper,
|
||||
title={ {TensorFlow}: Large-Scale Machine Learning on Heterogeneous Systems},
|
||||
url={https://www.tensorflow.org/},
|
||||
note={Software available from tensorflow.org},
|
||||
author={
|
||||
Mart\'{i}n~Abadi and
|
||||
Ashish~Agarwal and
|
||||
Paul~Barham and
|
||||
Eugene~Brevdo and
|
||||
Zhifeng~Chen and
|
||||
Craig~Citro and
|
||||
Greg~S.~Corrado and
|
||||
Andy~Davis and
|
||||
Jeffrey~Dean and
|
||||
Matthieu~Devin and
|
||||
Sanjay~Ghemawat and
|
||||
Ian~Goodfellow and
|
||||
Andrew~Harp and
|
||||
Geoffrey~Irving and
|
||||
Michael~Isard and
|
||||
Yangqing Jia and
|
||||
Rafal~Jozefowicz and
|
||||
Lukasz~Kaiser and
|
||||
Manjunath~Kudlur and
|
||||
Josh~Levenberg and
|
||||
Dandelion~Man\'{e} and
|
||||
Rajat~Monga and
|
||||
Sherry~Moore and
|
||||
Derek~Murray and
|
||||
Chris~Olah and
|
||||
Mike~Schuster and
|
||||
Jonathon~Shlens and
|
||||
Benoit~Steiner and
|
||||
Ilya~Sutskever and
|
||||
Kunal~Talwar and
|
||||
Paul~Tucker and
|
||||
Vincent~Vanhoucke and
|
||||
Vijay~Vasudevan and
|
||||
Fernanda~Vi\'{e}gas and
|
||||
Oriol~Vinyals and
|
||||
Pete~Warden and
|
||||
Martin~Wattenberg and
|
||||
Martin~Wicke and
|
||||
Yuan~Yu and
|
||||
Xiaoqiang~Zheng},
|
||||
year={2015},
|
||||
}
|
||||
@misc{chollet2015keras,
|
||||
title={Keras},
|
||||
author={Chollet, Fran\c{c}ois and others},
|
||||
year={2015},
|
||||
howpublished={\url{https://keras.io}},
|
||||
}
|
||||
@misc{htmx,
|
||||
title = {{{$<$}/{$>$} htmx - high power tools for html}},
|
||||
year = {2023},
|
||||
month = nov,
|
||||
note = {[Online; accessed 1. Nov. 2023]},
|
||||
url = {https://htmx.org}
|
||||
}
|
||||
@misc{go,
|
||||
title = {{The Go Programming Language}},
|
||||
year = {2023},
|
||||
month = nov,
|
||||
note = {[Online; accessed 1. Nov. 2023]},
|
||||
url = {https://go.dev}
|
||||
}
|
@ -1,194 +0,0 @@
|
||||
%%% Preamble
|
||||
\documentclass[11pt, a4paper]{article}
|
||||
|
||||
\usepackage[english]{babel} % English language/hyphenation
|
||||
\usepackage{url}
|
||||
\usepackage{tabularx}
|
||||
\usepackage{pdfpages}
|
||||
\usepackage{float}
|
||||
|
||||
\usepackage{graphicx}
|
||||
\graphicspath{ {../images for report/} }
|
||||
\usepackage[margin=2cm]{geometry}
|
||||
|
||||
\usepackage{hyperref}
|
||||
\hypersetup{
|
||||
colorlinks,
|
||||
citecolor=black,
|
||||
filecolor=black,
|
||||
linkcolor=black,
|
||||
urlcolor=black
|
||||
}
|
||||
|
||||
\usepackage{cleveref}
|
||||
|
||||
%%% Custom headers/footers (fancyhdr package)
|
||||
\usepackage{fancyhdr}
|
||||
\pagestyle{fancyplain}
|
||||
\fancyhead{} % No page header
|
||||
\fancyfoot[L]{} % Empty
|
||||
\fancyfoot[C]{\thepage} % Pagenumbering
|
||||
\fancyfoot[R]{} % Empty
|
||||
\renewcommand{\headrulewidth}{0pt} % Remove header underlines
|
||||
\renewcommand{\footrulewidth}{0pt} % Remove footer underlines
|
||||
\setlength{\headheight}{13.6pt}
|
||||
|
||||
% numeric
|
||||
\usepackage[style=ieee,sorting=none,backend=biber]{biblatex}
|
||||
\addbibresource{../main.bib}
|
||||
|
||||
% Write the approved title of your dissertation
|
||||
\title{Automated image classification with expandable models}
|
||||
|
||||
% Write your full name, as in University records
|
||||
\author{Andre Henriques, 6644818}
|
||||
|
||||
\date{}
|
||||
|
||||
%%% Begin document
|
||||
\begin{document}
|
||||
|
||||
\maketitle
|
||||
\newpage
|
||||
|
||||
\tableofcontents
|
||||
\newpage
|
||||
|
||||
|
||||
\section{Introduction}
|
||||
% This section should contain an introduction to the problem aims and objectives (0.5 page)
|
||||
The aim of this project is to create a classification service that has 0 requires zero user knowledge about machine learning, image classification or data analysis.
|
||||
The system should allow the user to create a reasonable accurate model that can satisfy the users' need.
|
||||
The system should also allow the user to create expandable models; models where classes can be added after the model has been created.
|
||||
|
||||
\subsection{Aims}
|
||||
The project aims to create a platform where users can create different types of classification models without the users having any knowledge of image classification.
|
||||
|
||||
\subsection{Objectives}
|
||||
This project's primary objectives are to:
|
||||
\begin{itemize}
|
||||
\item Create platform where the users can create and manage their models.
|
||||
\item Create a system to automatically create and train.
|
||||
\item Create a system to automatically create and train models.
|
||||
\item Create a system to automatically expand and reduce models without fully retraining the models.
|
||||
\item Create an API so that users can interact programatically with the system.
|
||||
\end{itemize}
|
||||
This project extended objectives are to:
|
||||
\begin{itemize}
|
||||
\item Create a system to automatically to merge modules to increase efficiency
|
||||
\item Create a system to distribute the load of training the model's among multiple services.
|
||||
\end{itemize}
|
||||
\section{Literature and Techincal Review}
|
||||
% 1 page of background and literature review. Here you will need to references things. Gamal et al.~\cite{gamal} introduce the concept of \ldots
|
||||
|
||||
\subsection{Alternatives to my Project}
|
||||
There currently exist systems that do image classification, like Google Vision AI\cite{google-vision-api}, and Amazon's Rekoginition\cite{amazon-rekognition}.
|
||||
Their tools, while providing similar services to what my project is supposed to do, it mostly focusses on general image classification rather than specific image classification, i.e. Car vs Boat, vs, Car model X vs Car model Y.
|
||||
|
||||
\subsection{Creation Models}
|
||||
The models that I will be creating will be Convolutional Neural Network(CNN)\cite{lecun1989handwritten,fukushima1980neocognitron}.
|
||||
The system will be creating two types of models that cannot be expanded and models that can be expanded. For the models that can be expanded, see the section about expandable models.
|
||||
The models that cannot be expanded will use a simple convolution blocks, with a similar structure as the AlexNet\cite{krizhevsky2012imagenet} ones, as the basis for the model. The size of the model will be controlled by the size of the input image, where bigger images will generate more deep and complex models.
|
||||
The models will be created using TensorFlow\cite{tensorflow2015-whitepaper} and Keras\cite{chollet2015keras}. These theologies are chosen since they are both robust and used in industry.
|
||||
|
||||
\subsection{Expandable Models}
|
||||
The current most used approach for expanding a CNN model is to retrain the model. This is done by, recreating an entire new model that does the new task, using the older model as a base for the new model\cite{amazon-rekognition}, or using a pretrained model as a base and training the last few layers.
|
||||
|
||||
There are also unsupervised learning methods that do not have a fixed number of classes. While this method would work as an expandable model method, it would not work for the purpose of this project. This project requires that the model has a specific set of labels which does not work with unsupervised learning which has unlabelled data. Some technics that are used for unsupervised learning might be useful in the process of creating expandable models.
|
||||
|
||||
|
||||
\section{Technical overview}
|
||||
% 1 page of overview. My approach is shown in Figure~\ref{fig:sample}. You can draw the diagram in powerpoint and save the picture
|
||||
\subsection{Web Interface}
|
||||
The user will interact with the platform form via a web portal.
|
||||
The web platform will be designed using HTML and a JavaScript library called HTMX\cite{htmx} for the reactivity that the pagers requires.
|
||||
The web server that will act as controller will be implemented using go\cite{go}, due to its ease of use.
|
||||
The web server will also interact with python to create models. Then to run the models, it will use the libraries that are available to run TensorFlow\cite{tensorflow2015-whitepaper} models for that in go.
|
||||
|
||||
\subsection{Creating Models}
|
||||
The models will be created using TensorFlow.
|
||||
The original plan was to use go and TensorFlow, but the go library was lacking that ability. Therefore, I chose to use python to create the models.
|
||||
The go server starts a new process, running python, that creates and trains the TensorFlow model. Once the training is done, the model is saved to disk which then can be loaded by the go TensorFlow library.
|
||||
|
||||
\subsection{Expandable Models}
|
||||
The approach would be based on multiple models. The first model is a large model that will work as a feature traction model, the results of this model are then given to other smaller models. These model's purpose is to classify the results of the feature extraction model into classes.
|
||||
The first model would either be an already existent pretrained model or a model that is automatically created by the platform.
|
||||
The smaller models would all be all generated by the platform, this model's purpose would be actually classification.
|
||||
This approach would offer a lot of expandability, as it makes the addition of a new class as easy as creating a new small model.
|
||||
|
||||
\section{Workplan}
|
||||
\subsection{Timeline}
|
||||
% The following work plan is what I will be using for the project is shown in Figure~\ref{fig:sample2}.
|
||||
\begin{tabular}{ |m{0.5\textwidth}|m{0.5\textwidth}| }
|
||||
\hline
|
||||
Month & Goals \\
|
||||
\hline
|
||||
September & \begin{itemize}
|
||||
\item Experimenting with web development frameworks.
|
||||
\item Started working on code development.
|
||||
\end{itemize} \\
|
||||
\hline
|
||||
October & \begin{itemize}
|
||||
\item Starting working on Project Synopsis.
|
||||
\item Continue working on project development.
|
||||
\item Finish user management system and basic ui decisions.
|
||||
\item Finish data upload section of the website.
|
||||
\end{itemize} \\
|
||||
\hline
|
||||
November & \begin{itemize}
|
||||
\item Finish writing on Project Synopsis.
|
||||
\item Finish coding the basic model generation and training.
|
||||
\end{itemize} \\
|
||||
\hline
|
||||
December & \begin{itemize}
|
||||
\item Improve basic model generation.
|
||||
\end{itemize} \\
|
||||
\hline
|
||||
January & \begin{itemize}
|
||||
\item Add api support.
|
||||
\item Started working on the final report
|
||||
\end{itemize} \\
|
||||
\hline
|
||||
Feburary & \begin{itemize}
|
||||
\item Start working on expandable models generation
|
||||
\end{itemize} \\
|
||||
\hline
|
||||
March & \begin{itemize}
|
||||
\item Create systems to expand the expandable models and contract models
|
||||
\item Review draft submissions
|
||||
\end{itemize} \\
|
||||
\hline
|
||||
April & \begin{itemize}
|
||||
\item Basic final report finish
|
||||
\item Create systems to expand and reduce expandable models
|
||||
\end{itemize} \\
|
||||
\hline
|
||||
May & \begin{itemize}
|
||||
\item Finish and submit final report
|
||||
\end{itemize} \\
|
||||
\hline
|
||||
\end{tabular}
|
||||
|
||||
\subsection{Risks}
|
||||
\begin{tabular}{ |c| }
|
||||
\hline
|
||||
Risk \\
|
||||
\hline
|
||||
Automatic model generation is not feasable\\
|
||||
\hline
|
||||
Easy model expancion is not feasble\\
|
||||
\hline
|
||||
Not enough compute power to train models fast enough to develop the program\\
|
||||
\hline
|
||||
\end{tabular}
|
||||
|
||||
\appendix
|
||||
\newpage
|
||||
|
||||
\section{References}
|
||||
\printbibliography[heading=none]
|
||||
|
||||
% TODO add my job title
|
||||
\end{document}
|
||||
|
||||
|
1
secondcw/aes256key
Normal file
1
secondcw/aes256key
Normal file
@ -0,0 +1 @@
|
||||
e><3E>Џ<EFBFBD>2<EFBFBD>Yu<>уW<D183> UФИ( `НЕ№ШЙТ<D099>м<EFBFBD>
|
74
secondcw/ag01598_6644818_1_1.spdl
Normal file
74
secondcw/ag01598_6644818_1_1.spdl
Normal file
@ -0,0 +1,74 @@
|
||||
/*
|
||||
* Coursework 2 PI protocol
|
||||
*/
|
||||
usertype String;
|
||||
usertype Timestamp;
|
||||
usertype Sessionkey;
|
||||
|
||||
hashfunction Mac;
|
||||
|
||||
protocol protocolPI(Network, Application, Phone) {
|
||||
|
||||
/* Role R - Phone
|
||||
*
|
||||
* has keys k(N,R)
|
||||
*
|
||||
*/
|
||||
role Phone {
|
||||
|
||||
var SesK: SessionKey;
|
||||
var tl: Timestamp;
|
||||
|
||||
recv_keysPhone(Network, Phone, {Mac(SesK, tl)}k(Network, Phone), {SesK, tl}k(Network, Phone));
|
||||
|
||||
var mApp: String;
|
||||
|
||||
recv_1(Application,Phone, {mApp}SesK);
|
||||
|
||||
fresh mPhone: String;
|
||||
|
||||
send_2(Phone,Application, {mApp, mPhone}SesK);
|
||||
}
|
||||
|
||||
/* Role S - Application
|
||||
*
|
||||
* has keys k(N,S)
|
||||
*
|
||||
*/
|
||||
role Application {
|
||||
|
||||
send_refreshKeys(Application,Network, Application, Phone);
|
||||
|
||||
var SesK: SessionKey;
|
||||
var tl: Timestamp;
|
||||
|
||||
recv_keysApp(Network,Application, {Mac(SesK, tl)}k(Network, Application), {SesK, tl}k(Network, Application));
|
||||
|
||||
fresh mApp: String;
|
||||
var mPhone: String;
|
||||
|
||||
send_1(Application,Phone, {mApp}SesK);
|
||||
|
||||
recv_2(Phone,Application, {mApp, mPhone}SesK);
|
||||
}
|
||||
|
||||
/* Role N - Network
|
||||
*
|
||||
* has keys k(N,R) and k(N,S)
|
||||
*
|
||||
*/
|
||||
role Network {
|
||||
|
||||
recv_refreshKeys(Application,Network, Application, Phone);
|
||||
|
||||
fresh SesK: SessionKey;
|
||||
fresh tl: Timestamp;
|
||||
|
||||
send_keysApp(Network,Application, {Mac(SesK, tl)}k(Network, Application), {SesK, tl}k(Network, Application));
|
||||
|
||||
send_keysPhone(Network,Phone, {Mac(SesK, tl)}k(Network, Phone), {SesK, tl}k(Network, Phone));
|
||||
}
|
||||
|
||||
|
||||
}
|
||||
|
93
secondcw/ag01598_6644818_1_2.spdl
Normal file
93
secondcw/ag01598_6644818_1_2.spdl
Normal file
@ -0,0 +1,93 @@
|
||||
/*
|
||||
* Coursework 2 PI protocol
|
||||
*/
|
||||
usertype String;
|
||||
usertype Timestamp;
|
||||
usertype Sessionkey;
|
||||
|
||||
hashfunction Mac;
|
||||
|
||||
protocol protocolPI(Network, Application, Phone) {
|
||||
|
||||
/* Role R - Phone
|
||||
*
|
||||
* has keys k(N,R)
|
||||
*
|
||||
*/
|
||||
role Phone {
|
||||
|
||||
var SesK: SessionKey;
|
||||
var tl: Timestamp;
|
||||
|
||||
recv_keysPhone(Network, Phone, {Mac(SesK, tl)}k(Network, Phone), {SesK, tl}k(Network, Phone));
|
||||
|
||||
var mApp: String;
|
||||
|
||||
recv_1(Application,Phone, {mApp}SesK);
|
||||
|
||||
fresh mPhone: String;
|
||||
|
||||
claim_phone1(Phone, Running, Application, mApp);
|
||||
|
||||
send_2(Phone,Application, {mApp, mPhone}SesK);
|
||||
|
||||
claim_phone2(Phone, Secret, SesK);
|
||||
claim_application1(Phone, Commit, Application, mApp);
|
||||
claim_network2(Phone, Commit, Network, SesK, tl);
|
||||
claim_phone3(Phone, Nisynch);
|
||||
}
|
||||
|
||||
/* Role S - Application
|
||||
*
|
||||
* has keys k(N,S)
|
||||
*
|
||||
*/
|
||||
role Application {
|
||||
|
||||
send_refreshKeys(Application,Network, Application, Phone);
|
||||
|
||||
var SesK: SessionKey;
|
||||
var tl: Timestamp;
|
||||
|
||||
recv_keysApp(Network,Application, {Mac(SesK, tl)}k(Network, Application), {SesK, tl}k(Network, Application));
|
||||
|
||||
fresh mApp: String;
|
||||
var mPhone: String;
|
||||
|
||||
claim_application1(Application, Running, Phone, mApp);
|
||||
|
||||
send_1(Application,Phone, {mApp}SesK);
|
||||
|
||||
recv_2(Phone,Application, {mApp, mPhone}SesK);
|
||||
|
||||
claim_application2(Application, Secret, SesK);
|
||||
claim_phone1(Application, Commit, Phone, mApp);
|
||||
claim_network1(Application, Commit, Network, SesK, tl);
|
||||
|
||||
claim_application3(Application, Nisynch);
|
||||
}
|
||||
|
||||
/* Role N - Network
|
||||
*
|
||||
* has keys k(N,R) and k(N,S)
|
||||
*
|
||||
*/
|
||||
role Network {
|
||||
|
||||
recv_refreshKeys(Application,Network, Application, Phone);
|
||||
|
||||
fresh SesK: SessionKey;
|
||||
fresh tl: Timestamp;
|
||||
|
||||
claim_netwrok1(Network, Running, Application, SesK, tl);
|
||||
send_keysApp(Network,Application, {Mac(SesK, tl)}k(Network, Application), {SesK, tl}k(Network, Application));
|
||||
|
||||
claim_network2(Network, Running, Phone, SesK, tl);
|
||||
send_keysPhone(Network,Phone, {Mac(SesK, tl)}k(Network, Phone), {SesK, tl}k(Network, Phone));
|
||||
|
||||
claim_network3(Network, Secret, SesK);
|
||||
}
|
||||
|
||||
|
||||
}
|
||||
|
99
secondcw/ag01598_6644818_1_3.spdl
Normal file
99
secondcw/ag01598_6644818_1_3.spdl
Normal file
@ -0,0 +1,99 @@
|
||||
/*
|
||||
* Coursework 2 PI protocol
|
||||
*/
|
||||
usertype String;
|
||||
usertype Timestamp;
|
||||
usertype Sessionkey;
|
||||
|
||||
hashfunction H1;
|
||||
|
||||
protocol protocolPI(Network, Application, Phone) {
|
||||
|
||||
/* Role R - Phone
|
||||
*
|
||||
* has keys k(N,R)
|
||||
*
|
||||
*/
|
||||
role Phone {
|
||||
|
||||
var SesK: SessionKey;
|
||||
var tl: Timestamp;
|
||||
|
||||
recv_keysPhone(Network,Phone, {H1(SesK, tl, Application)}k(Network, Phone), {SesK, tl, Application}k(Network, Phone));
|
||||
|
||||
var mApp: String;
|
||||
|
||||
recv_1(Application,Phone, {mApp, Application, Phone }SesK);
|
||||
|
||||
fresh mPhone: String;
|
||||
|
||||
claim_phone1(Phone, Running, Application, mApp, SesK);
|
||||
|
||||
send_2(Phone,Application, {mApp, mPhone}SesK);
|
||||
|
||||
claim_phone2(Phone, Secret, SesK);
|
||||
claim_application1(Phone, Commit, Application, mApp, SesK);
|
||||
claim_network2(Phone, Commit, Network, SesK, tl);
|
||||
claim_phone3(Phone, Nisynch);
|
||||
|
||||
}
|
||||
|
||||
/* Role S - Application
|
||||
*
|
||||
* has keys k(N,S)
|
||||
*
|
||||
*/
|
||||
role Application {
|
||||
|
||||
fresh nApp: Nonce;
|
||||
|
||||
send_refreshKeys(Application,Network, Application, Phone, nApp);
|
||||
|
||||
var SesK: SessionKey;
|
||||
var tl: Timestamp;
|
||||
|
||||
recv_keysApp(Network,Application, {H1(SesK, tl, nApp, Phone)}k(Network, Application), {SesK, tl, nApp, Phone}k(Network, Application));
|
||||
|
||||
fresh mApp: String;
|
||||
var mPhone: String;
|
||||
|
||||
claim_application1(Application, Running, Phone, mApp, SesK);
|
||||
|
||||
send_1(Application,Phone, {mApp, Application, Phone}SesK);
|
||||
|
||||
recv_2(Phone,Application, {mApp, mPhone}SesK);
|
||||
|
||||
claim_application2(Application, Secret, SesK);
|
||||
claim_phone1(Application, Commit, Phone, mApp, SesK);
|
||||
claim_network1(Application, Commit, Network, SesK, tl);
|
||||
|
||||
claim_application3(Application, Nisynch);
|
||||
}
|
||||
|
||||
/* Role N - Network
|
||||
*
|
||||
* has keys k(N,R) and k(N,S)
|
||||
*
|
||||
*/
|
||||
role Network {
|
||||
|
||||
var nApp: Nonce;
|
||||
|
||||
recv_refreshKeys(Application,Network, Application, Phone, nApp);
|
||||
|
||||
fresh SesK: SessionKey;
|
||||
fresh tl: Timestamp;
|
||||
|
||||
claim_netwrok1(Network, Running, Application, SesK, tl);
|
||||
|
||||
send_keysApp(Network,Application, { H1(SesK, tl, nApp, Phone) }k(Network, Application) , {SesK, tl, nApp, Phone}k(Network, Application));
|
||||
|
||||
claim_network2(Network, Running, Phone, SesK, tl);
|
||||
send_keysPhone(Network,Phone, {H1(SesK, tl, Application)}k(Network, Phone), {SesK, tl, Application}k(Network, Phone));
|
||||
|
||||
claim_network3(Network, Secret, SesK);
|
||||
}
|
||||
|
||||
|
||||
}
|
||||
|
113
secondcw/ag01598_6644818_1_3_complex_solution.spdl
Normal file
113
secondcw/ag01598_6644818_1_3_complex_solution.spdl
Normal file
@ -0,0 +1,113 @@
|
||||
/*
|
||||
* Coursework 2 PI protocol
|
||||
*/
|
||||
usertype String;
|
||||
usertype Timestamp;
|
||||
usertype Sessionkey;
|
||||
|
||||
hashfunction H1;
|
||||
|
||||
protocol protocolPI(Network, Application, Phone) {
|
||||
|
||||
/* Role R - Phone
|
||||
*
|
||||
* has keys k(N,R)
|
||||
*
|
||||
*/
|
||||
role Phone {
|
||||
|
||||
var SesK: SessionKey;
|
||||
var tl: Timestamp;
|
||||
|
||||
var TApp: Ticket;
|
||||
|
||||
recv_keysPhone(Network,Phone, {H1(SesK, tl)}k(Network, Phone), {SesK, tl}k(Network, Phone), TApp);
|
||||
|
||||
var mApp: String;
|
||||
|
||||
var temp: Ticket;
|
||||
|
||||
recv_1(Application,Phone, {mApp, {Network, Application, Phone, tl}k(Network, Phone), Application, Phone }SesK);
|
||||
|
||||
fresh mPhone: String;
|
||||
|
||||
claim_phone1(Phone, Running, Application, mApp);
|
||||
|
||||
fresh nApp3: Nonce;
|
||||
|
||||
send_2(Phone,Application, {mApp, mPhone, TApp, nApp3}SesK);
|
||||
|
||||
recv_3(Application,Phone, {nApp3}SesK);
|
||||
|
||||
claim_phone2(Phone, Secret, SesK);
|
||||
claim_application1(Phone, Commit, Application, mApp);
|
||||
claim_network2(Phone, Commit, Network, SesK, tl);
|
||||
claim_phone3(Phone, Nisynch);
|
||||
|
||||
}
|
||||
|
||||
/* Role S - Application
|
||||
*
|
||||
* has keys k(N,S)
|
||||
*
|
||||
*/
|
||||
role Application {
|
||||
|
||||
fresh nApp: Nonce;
|
||||
|
||||
send_refreshKeys(Application,Network, Application, Phone, nApp);
|
||||
|
||||
var SesK: SessionKey;
|
||||
var tl: Timestamp;
|
||||
|
||||
var TPhone: Ticket;
|
||||
|
||||
recv_keysApp(Network,Application, {H1(SesK, tl)}k(Network, Application), {SesK, tl, nApp}k(Network, Application), TPhone);
|
||||
|
||||
fresh mApp: String;
|
||||
var mPhone: String;
|
||||
|
||||
claim_application1(Application, Running, Phone, mApp);
|
||||
|
||||
send_1(Application,Phone, {mApp, TPhone, Application, Phone}SesK);
|
||||
|
||||
var nApp3: Nonce;
|
||||
|
||||
recv_2(Phone,Application, {mApp, mPhone, {Network, Application, Phone, tl}k(Network, Application), nApp3}SesK);
|
||||
|
||||
send_3(Application,Phone, {nApp3}SesK);
|
||||
|
||||
claim_application2(Application, Secret, SesK);
|
||||
claim_phone1(Application, Commit, Phone, mApp);
|
||||
claim_network1(Application, Commit, Network, SesK, tl);
|
||||
|
||||
claim_application3(Application, Nisynch);
|
||||
}
|
||||
|
||||
/* Role N - Network
|
||||
*
|
||||
* has keys k(N,R) and k(N,S)
|
||||
*
|
||||
*/
|
||||
role Network {
|
||||
|
||||
var nApp: Nonce;
|
||||
|
||||
recv_refreshKeys(Application,Network, Application, Phone, nApp);
|
||||
|
||||
fresh SesK: SessionKey;
|
||||
fresh tl: Timestamp;
|
||||
|
||||
claim_netwrok1(Network, Running, Application, SesK, tl);
|
||||
|
||||
send_keysApp(Network,Application, { H1(SesK, tl) }k(Network, Application) , {SesK, tl, nApp}k(Network, Application), {Network, Application, Phone, tl}k(Network, Phone));
|
||||
|
||||
claim_network2(Network, Running, Phone, SesK, tl);
|
||||
send_keysPhone(Network,Phone, {H1(SesK, tl)}k(Network, Phone), {SesK, tl}k(Network, Phone), {Network, Application, Phone, tl}k(Network, Application));
|
||||
|
||||
claim_network3(Network, Secret, SesK);
|
||||
}
|
||||
|
||||
|
||||
}
|
||||
|
94
secondcw/ag01598_6644818_1_5.spdl
Normal file
94
secondcw/ag01598_6644818_1_5.spdl
Normal file
@ -0,0 +1,94 @@
|
||||
/*
|
||||
* Coursework 2 PI protocol
|
||||
*/
|
||||
usertype String;
|
||||
usertype Timestamp;
|
||||
usertype Sessionkey;
|
||||
|
||||
hashfunction H1;
|
||||
|
||||
protocol protocolPI(Network, Application, Phone) {
|
||||
|
||||
/* Role R - Phone
|
||||
*
|
||||
* has keys k(N,R)
|
||||
*
|
||||
*/
|
||||
role Phone {
|
||||
|
||||
var SesK: SessionKey;
|
||||
var tl: Timestamp;
|
||||
|
||||
var mApp: String;
|
||||
|
||||
recv_1(Application,Phone, ({H1(SesK, tl, Application)}k(Network, Phone), {SesK, tl, Application}k(Network, Phone)), {mApp, Application, Phone }SesK);
|
||||
|
||||
fresh mPhone: String;
|
||||
|
||||
claim_phone1(Phone, Running, Application, mApp, SesK);
|
||||
|
||||
send_2(Phone,Application, {mApp, mPhone}SesK);
|
||||
|
||||
claim_phone2(Phone, Secret, SesK);
|
||||
claim_application1(Phone, Commit, Application, mApp, SesK);
|
||||
//claim_network2(Phone, Commit, Network, SesK, tl);
|
||||
claim_phone3(Phone, Nisynch);
|
||||
|
||||
}
|
||||
|
||||
/* Role S - Application
|
||||
*
|
||||
* has keys k(N,S)
|
||||
*
|
||||
*/
|
||||
role Application {
|
||||
|
||||
fresh nApp: Nonce;
|
||||
|
||||
send_refreshKeys(Application,Network, Application, Phone, nApp);
|
||||
|
||||
var SesK: SessionKey;
|
||||
var tl: Timestamp;
|
||||
|
||||
var T1: Ticket;
|
||||
|
||||
recv_keysApp(Network,Application, {H1(SesK, tl, nApp, Phone, T1)}k(Network, Application), {SesK, tl, nApp, Phone, T1}k(Network, Application));
|
||||
|
||||
fresh mApp: String;
|
||||
var mPhone: String;
|
||||
|
||||
claim_application1(Application, Running, Phone, mApp, SesK);
|
||||
|
||||
send_1(Application,Phone, T1, {mApp, Application, Phone}SesK);
|
||||
|
||||
recv_2(Phone,Application, {mApp, mPhone}SesK);
|
||||
|
||||
claim_application2(Application, Secret, SesK);
|
||||
claim_phone1(Application, Commit, Phone, mApp, SesK);
|
||||
claim_network1(Application, Commit, Network, SesK, tl);
|
||||
|
||||
claim_application3(Application, Nisynch);
|
||||
}
|
||||
|
||||
/* Role N - Network
|
||||
*
|
||||
* has keys k(N,R) and k(N,S)
|
||||
*
|
||||
*/
|
||||
role Network {
|
||||
|
||||
var nApp: Nonce;
|
||||
|
||||
recv_refreshKeys(Application,Network, Application, Phone, nApp);
|
||||
|
||||
fresh SesK: SessionKey;
|
||||
fresh tl: Timestamp;
|
||||
|
||||
claim_netwrok1(Network, Running, Application, SesK, tl);
|
||||
|
||||
send_keysApp(Network,Application, { H1(SesK, tl, nApp, Phone, ({H1(SesK, tl, Application)}k(Network, Phone), {SesK, tl, Application}k(Network, Phone))) }k(Network, Application) , {SesK, tl, nApp, Phone, ({H1(SesK, tl, Application)}k(Network, Phone), {SesK, tl, Application}k(Network, Phone))}k(Network, Application));
|
||||
|
||||
claim_network3(Network, Secret, SesK);
|
||||
}
|
||||
}
|
||||
|
216
secondcw/cw/cw.tex
Normal file
216
secondcw/cw/cw.tex
Normal file
@ -0,0 +1,216 @@
|
||||
%%% Preamble
|
||||
\documentclass[11pt, a4paper]{article}
|
||||
|
||||
\usepackage[english]{babel} % English language/hyphenation
|
||||
\usepackage{url}
|
||||
\usepackage{tabularx}
|
||||
\usepackage{pdfpages}
|
||||
\usepackage{float}
|
||||
\usepackage{amsmath, amssymb}
|
||||
\usepackage{systeme}
|
||||
|
||||
\usepackage{graphicx}
|
||||
\graphicspath{ {../images for report/} }
|
||||
\usepackage[margin=2cm]{geometry}
|
||||
|
||||
\usepackage{hyperref}
|
||||
\hypersetup{
|
||||
colorlinks,
|
||||
citecolor=black,
|
||||
filecolor=black,
|
||||
linkcolor=black,
|
||||
urlcolor=black
|
||||
}
|
||||
|
||||
\usepackage{cleveref}
|
||||
|
||||
%%% Custom headers/footers (fancyhdr package)
|
||||
\usepackage{fancyhdr}
|
||||
\pagestyle{fancyplain}
|
||||
\fancyhead{} % No page header
|
||||
\fancyfoot[L]{} % Empty
|
||||
\fancyfoot[C]{\thepage} % Pagenumbering
|
||||
\fancyfoot[R]{} % Empty
|
||||
\renewcommand{\headrulewidth}{0pt} % Remove header underlines
|
||||
\renewcommand{\footrulewidth}{0pt} % Remove footer underlines
|
||||
\setlength{\headheight}{13.6pt}
|
||||
|
||||
% numeric
|
||||
\usepackage[style=ieee,sorting=none,backend=biber]{biblatex}
|
||||
\addbibresource{../main.bib}
|
||||
|
||||
% Write the approved title of your dissertation
|
||||
\title{Automated image classification with expandable models}
|
||||
|
||||
% Write your full name, as in University records
|
||||
\author{Andre Henriques, 6644818}
|
||||
|
||||
\date{}
|
||||
|
||||
%%% Begin document
|
||||
\begin{document}
|
||||
\section*{1}
|
||||
\subsection*{1.1}
|
||||
The file ag01598\_6644818\_1\_1.spdl contains the base model of $\text{protocol}\Pi$.
|
||||
|
||||
I choose the names of the roles based on their functions since it would make the file more readable, so R is Phone, S is Application, N is Network.
|
||||
|
||||
As the diagram shows, the first message is sent from the phone to the network to request the generation of a new session key.
|
||||
|
||||
The keys were modelled using a custom usertype called ``SessionKey'' and the time to live has modelled using a custom usertype called ``Timestamp''
|
||||
|
||||
The network then answers to the Phone and the Application the keys and the time to live and the hashed value of that using a hash function named ``Mac''.
|
||||
|
||||
The Phone and the Application verify the Mac and then the phone sends a nonce to the phone and the phone answers back with a new nonce and the original nonce.
|
||||
|
||||
The Mac was modelled as a hashing function, then encryption. This was done this way because Scyther does not have a way of creating a mac function with keys, so the hashing is done first followed by the encrypted so that an attacker cannot modify it.
|
||||
|
||||
Scyther does not have a way to model the refresh/time to live parts, so that was not modelled.
|
||||
|
||||
\subsection*{1.2}
|
||||
The file ag01598\_6644818\_1\_2.spdl contains the base model of $\text{protocol}\Pi$ and the claims.
|
||||
|
||||
I added non-injective synchronization(nisynch) to the Phone and Network, at least, some roles communicated as described by the protocol.
|
||||
I added a secret claim to SesK (Session key) to all roles, as the session key should be private.
|
||||
Furthermore, I added Commit and Running claims between some roles to check for agreement between some variables:
|
||||
\begin{itemize}
|
||||
\item{Agreement between Phone and Network over the time to live and the session key}
|
||||
\item{Agreement between Application and Network over the time to live and the session key}
|
||||
\item{Agreement between Application and Phone over the message and the message m}
|
||||
\end{itemize}
|
||||
|
||||
These claims were chosen because they check agreement on message m between the Application Function and the Phone; The secrecy of SesK; And the synchronization and agreement between the Application Function, Phone, and Network.
|
||||
|
||||
There are 9 overall claims, where only three do not fail. The secrecy of SesK from the perspective of the Network. And agreement over the SesK and the time to live between the Phone and the Network, and the Application and the Network.
|
||||
|
||||
The protocol as it stands does not guarantee secrecy and agreement.
|
||||
|
||||
\subsection*{1.3}
|
||||
The file ag01598\_6644818\_1\_3.spdl contains the fixed version of $\text{protocol}\Pi$.
|
||||
|
||||
The first change was to require the refresh keys request was to require the application to send a nonce. This nonce is then sent back to the application to verify that the key was generated, was requested by the application and not by the attacker.
|
||||
|
||||
The second change was to make the network send the identity of the other party to the party that is receiving the message. i.e. Sending the identity of the Phone to the Application encrypted with the key Network, Application. This is done to guarantee that the Party receiving the communication is using a key that was intended for this communication.
|
||||
|
||||
\subsection*{1.4}
|
||||
|
||||
The original $\text{protocol}\Pi$ is not an appropriate solution to the third-party problem as it cannot guarantee the secrecy of the session key, and since an attacker can obtain the session key, $\text{protocol}\Pi$ is not an appropriate solution to the presented problem. As Scyther, showed that there are attacks on the Dolev-Yao model. There are also some attacks outside the Dolev-Yao model.
|
||||
|
||||
For example:
|
||||
|
||||
With the assumptions, that:
|
||||
\begin{itemize}
|
||||
\item{Dolev-Yao attacker.}
|
||||
\item{Strong cryptographic primitives}
|
||||
\item{The time to live is implemented as a counter, and not as an end date timestamp.}
|
||||
\item{One of the previous keys, where the encrypted version of the key and timestamp were recorded and leaked.}
|
||||
\end{itemize}
|
||||
|
||||
In this scenario, an attacker can record the messages where the key and the time to live were encrypted. When the key gets leaked, the attacker can perform a replay attack.
|
||||
|
||||
The attacker resends the previously recorded keys to the application server and the phone because the time to live is based on a counter and not on a timestamp, the phone, and the server accept the ``new'' key. And since the attacker already knows this key, the protocol failed to guarantee, the secrecy of the session key.
|
||||
|
||||
% Other possible attacks are possible, for example a senario where the time to live is large, and the cryptographic primitives are weak for that time frame, i.e. RSA with 100 decimal digits and time to live of 2 days, an attacter with enought computer power would be abble to obtain the key
|
||||
|
||||
But it can be improved, as we saw in the answers for the question 1.3 by modifying the protocol slightly we can achieve secrecy of the session key in the Dolev-Yao model. Although it does not resolve issues related with the time to live if the protocol was implemented with counters for time to live instead of timestamp.
|
||||
|
||||
\subsection*{1.5}
|
||||
The file ag01598\_6644818\_1\_5.spdl contains a more communication efficient version of the $\text{protocol}\Pi$.
|
||||
|
||||
This version trades off computational power for communication efficiency. This version creates bigger encrypted messages, and as a trade-off reduces the number of messages that are sent.
|
||||
|
||||
The message that is removed is the message where the network sends the key to the phone. This data in this message is still sent, but it's sent when the application sends the m message.
|
||||
|
||||
And the data is sent to the Application inside the encrypted packed that is already sent to the Application when the phone receives the keys from the network.
|
||||
|
||||
It sends the session key that was sent by the network, to the phone, with the message m.
|
||||
|
||||
\section*{2}
|
||||
\subsection*{2.1}
|
||||
Using a system like GPG, you can generate keys by running the command \begin{verbatim}gpg --gen-key\end{verbatim}.
|
||||
|
||||
\subsection*{2.2}
|
||||
There are multiple ways of securely exchanging the keys.
|
||||
For example, if meeting in person was a possibility, the keys cloud be put onto USB drives and the drives exchanged in person. And this would guarantee 100\% authentication, but meeting in person could not be feasible.
|
||||
|
||||
If meeting in person is not feasible, an alterative method would be sending the public key via email, and then calling the colleague on the phone. Both parties would then hash key using for example \begin{verbatim}sha512sum key\end{verbatim} and both parties would read out their public keys hash to each other. Since the parties know each other, and would recognize the voice, this would be a feasible way to exchange the public keys. With this, they could verify that the key came from the correct person.
|
||||
|
||||
\subsection*{2.3}
|
||||
|
||||
Assuming that the peers were able to exchange public keys.
|
||||
|
||||
One of the Peer A would generate a random 256-bit key.
|
||||
|
||||
Peer A would then encrypt the key using Peer B's public key, and sign it using its own private key.
|
||||
|
||||
Peer A would then send the signed and encrypted symmetric key to Peer B in an insecure channel.
|
||||
|
||||
Peer B upon receiving the encrypted and signed symmetric key, would verify the signature, and decrypt the message and obtain the key.
|
||||
|
||||
After this, both A and B can communicate using the symmetric key.
|
||||
|
||||
Example:
|
||||
|
||||
Peer A:
|
||||
\begin{verbatim}
|
||||
head -c32 /dev/random > aes256key
|
||||
|
||||
gpg --output key.gpg --encrypt --recipient b@example.com aes256key
|
||||
|
||||
gpg --output key.gpg.sig --sign key.gpg
|
||||
\end{verbatim}
|
||||
|
||||
send key.gpg.sig to peer b
|
||||
|
||||
Peer B:
|
||||
\begin{verbatim}
|
||||
|
||||
gpg --output key.gpg.sig --decrypt key.gpg
|
||||
|
||||
gpg --output key.gpg --decrypt key
|
||||
|
||||
\end{verbatim}
|
||||
|
||||
Now both Peer A and Peer B have the same key and can start communicating between each other.
|
||||
|
||||
\begin{verbatim}
|
||||
# Encrypting
|
||||
openssl aes-256-cbc -in message.file -out message.file.enc -iter 10000 -kfile aes256key
|
||||
|
||||
# Decrypting
|
||||
openssl aes-256-cbc -in message.file.enc -out message.file -d -iter 10000 -kfile aes256key
|
||||
\end{verbatim}
|
||||
|
||||
\subsection*{2.4}
|
||||
|
||||
A secure communication channel for the purposes of this answer is a communication channel that can maintain the secrecy, and integrity.
|
||||
|
||||
A communication channel can be achieved by trading 2 symmetric keys.
|
||||
|
||||
One of the keys would be used to encrypt the messages and the other would be used to MAC the messages. This would guarantee that the messages are secret because of the encryption and that they have integrity because of the MAC.
|
||||
|
||||
The 2 different keys guarantee that the MAC that is generated is significantly different from the encrypted message.
|
||||
|
||||
In this system, messages should also contain the timestamp of when the messages were sent. This is useful to maintain freshness, it's also useful to provide different messages every time.
|
||||
|
||||
\subsection*{2.5}
|
||||
|
||||
The system would work under a computational system, as the cryptographic primitives that were selected are computationally challenging to break.
|
||||
|
||||
The system would also work with a man in the middle attacker, as the attacker cannot change the messages without one of the people feeling suspicious and calling for a restart of the system.
|
||||
|
||||
This system would not work if the method for exchanging keys was via phone, and the attacker had a method of replicating the voice of one of the participants of the system, i.e. using an AI.
|
||||
|
||||
The system can maintain integrality, in the public key exchange phase with the phone call and the hash, in the symmetric key exchange phase with the signatures, and in the message exchange phase with the MAC.
|
||||
|
||||
The system can maintain secrecy throughout the entire process by using strong cryptographic functions, and having all messages that are sent that contain sensitive information encrypted.
|
||||
|
||||
\subsection*{2.6}
|
||||
|
||||
An alterative solution to the problem is if both parties have a third party that they both know and trust. This system would have less communication and computational overhead, as the public key exchange could have been skipped and the symmetric key could have been exchanged from the begging.
|
||||
|
||||
This solution would have a less level of security as the system relies on the trust of a third party, this includes more levels of failures as the third party could get corrupted, making the system less secure.
|
||||
|
||||
|
||||
\end{document}
|
||||
|
68
secondcw/lab9.spdl
Normal file
68
secondcw/lab9.spdl
Normal file
@ -0,0 +1,68 @@
|
||||
/*usertype Timestamp;
|
||||
|
||||
protocol LaTe(C, S)
|
||||
{
|
||||
role C {
|
||||
fresh nc: Nonce;
|
||||
|
||||
var ts: Timestamp;
|
||||
|
||||
send_1(C,S, C, nc);
|
||||
|
||||
recv_2(S,C, nc, ts, {nc, ts}k(S, C));
|
||||
|
||||
claim_C1(C,Nisynch);
|
||||
claim_C2(C,Niagree);
|
||||
claim_C3(C,Alive);
|
||||
claim_C4(C,Weakagree);
|
||||
claim_C5(C, Commit, S, nc, ts);
|
||||
}
|
||||
|
||||
role S {
|
||||
var nc: Nonce;
|
||||
|
||||
fresh ts: Timestamp;
|
||||
|
||||
//send_!timestampSet(S,S, ts);
|
||||
|
||||
recv_1(C,S, C, nc);
|
||||
|
||||
claim_C5(S, Running, C, nc, ts);
|
||||
|
||||
send_2(S,C, nc, ts, {nc, ts}k(S, C));
|
||||
|
||||
claim_S1(S,Nisynch);
|
||||
claim_S2(S,Niagree);
|
||||
claim_S3(S,Alive);
|
||||
claim_S4(S,Weakagree);
|
||||
}
|
||||
}*/
|
||||
|
||||
usertype TimeStamp;
|
||||
hashfunction H1;
|
||||
|
||||
|
||||
protocol LATe(I,R)
|
||||
{
|
||||
role I # Time Client - Initiator
|
||||
{
|
||||
fresh Na : Nonce;
|
||||
var T : TimeStamp;
|
||||
send_1(I,R,I,Na);
|
||||
recv_2(R,I,Na,T,H1({Na,T}k(I,R)));#encrypt-then-hash
|
||||
claim_I1(I,Nisynch); #encrypt-then-hash
|
||||
claim_I2(I,Niagree);
|
||||
claim_I3(I,Alive);
|
||||
claim_I4(I,Weakagree);
|
||||
claim_I5(I, Commit, R, Na, T);
|
||||
}
|
||||
|
||||
role R # Time Server - Responder
|
||||
{
|
||||
var Na : Nonce;
|
||||
fresh T : TimeStamp;
|
||||
recv_1(I,R,I,Na);
|
||||
claim_C5(R, Running, I, Na, T);
|
||||
send_2(R,I,Na,T,H1({Na,T}k(I,R)));#encrypt-then-hash
|
||||
}
|
||||
}
|
8
secondcw/main.bib
Normal file
8
secondcw/main.bib
Normal file
@ -0,0 +1,8 @@
|
||||
@misc{cadonfs,
|
||||
author={The CADO-NFS Development Team},
|
||||
title={{CADO-NFS}, An Implementation of the Number Field Sieve
|
||||
Algorithm},
|
||||
note={Release 2.3.0},
|
||||
year={2017},
|
||||
url={http://cado-nfs.inria.fr/}
|
||||
}
|
1
secondcw/test
Normal file
1
secondcw/test
Normal file
@ -0,0 +1 @@
|
||||
This is a message
|
1
secondcw/test.enc
Normal file
1
secondcw/test.enc
Normal file
@ -0,0 +1 @@
|
||||
Salted__E–õ›a…g!/úŸ‰éÇì{ûi;N„vhÚ,Šæ2jç‚WêeËœ
|
1
secondcw/test.out
Normal file
1
secondcw/test.out
Normal file
@ -0,0 +1 @@
|
||||
This is a message
|
Reference in New Issue
Block a user