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.
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.
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:
The block before the block where change happens become altered as well.
\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.
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.
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:
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.
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
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.
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.
