This commit is contained in:
parent
37e7b11a7f
commit
546f20f261
1
secondcw/aes256key
Normal file
1
secondcw/aes256key
Normal file
@ -0,0 +1 @@
|
|||||||
|
e><3E>Џ<EFBFBD>2<EFBFBD>Yu<>уW<D183> UФИ( `НЕ№ШЙТ<D099>м<EFBFBD>
|
@ -164,13 +164,55 @@
|
|||||||
\begin{verbatim}
|
\begin{verbatim}
|
||||||
|
|
||||||
gpg --output key.gpg.sig --decrypt key.gpg
|
gpg --output key.gpg.sig --decrypt key.gpg
|
||||||
|
\
|
||||||
gpg --output key.gpg --decrypt key
|
gpg --output key.gpg --decrypt key
|
||||||
|
|
||||||
\end{verbatim}
|
\end{verbatim}
|
||||||
|
|
||||||
Now both Peer A and Peer B have the same key and can start communicating between each other.
|
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 purpoposes of this answer is a communication channel that can maitain the secrecy, and integtaty.
|
||||||
|
|
||||||
|
A communication channel can be achived by trading 2 semetric keys.
|
||||||
|
|
||||||
|
One of the keys would be used to encrypt the messages and the other would be used to MAC the messages this would gurantee that the messages are secret because of the encryption and that they have integraty because of the MAC.
|
||||||
|
|
||||||
|
The 2 diferent keys guarantee that the MAC that is generated is significanfly diferent than the encrypted message.
|
||||||
|
|
||||||
|
In this system messages should also contain the timestamp of when the messages was send this is usefull to maintain freshness.
|
||||||
|
|
||||||
|
\subsection*{2.5}
|
||||||
|
|
||||||
|
The system would work under a computational system as the cryptographic primitives that were selected are computationaly hard to break.
|
||||||
|
|
||||||
|
The system would also work with a man in the midle attacker as the attacker can not change the messages witout one of the people feeling suspicios and calling for a restart of the system.
|
||||||
|
|
||||||
|
This system would not work if the method for exachaging 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 integratity, in the public key exachange phase with the phone call and the hash, in the semetric key exahange phase with the signatures, and in the message exchange phase with the MACs.
|
||||||
|
|
||||||
|
%The system can maintain secrecy throughout the entire process by using strong cryptographic functions, and having all messages that are send that contain sentive information encrypted.
|
||||||
|
|
||||||
|
%The system can
|
||||||
|
|
||||||
|
\subsection*{2.6}
|
||||||
|
|
||||||
|
An altertive solution to the problem is if both parties have a third party that they both know and trust. This system would have less comunication and computaional overhead as the public key exchange could have been skiped and the the semetric 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 currupted makeing the system less secure.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
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