main.tex

\documentclass[journal]{IEEEtran}

\begin{document}
\title{Peer-to-Peer Distributed Storage System}
%\title{Encrypted Distributed Data Storage\\with Regenerative Blocks}

\author{
        Matthew~Olan, %~\IEEEmembership{Member,~IEEE,}
        William~Mak,
        and~John-Alan~Simmons
}

%\markboth{Journal of \LaTeX\ Class Files,~Vol.~6, No.~1, January~2013}{Olan \MakeLowercase{\textit{et al.}}: Bare Demo of IEEEtran.cls for Journals}

% make the title area
\maketitle

\begin{abstract} % Lots taken from Bitcoin documentation, to be modified
A purely peer-to-peer data storage network would allow data to be distributed across multiple parties, without the requirement of a dedicated server. Current solutions exist for file sharing and local cloud storage, but fail to provide secure storage for sensitive data while using the potential power of the Internet or other large networks of computers. Distributed hash tables, used in current file networks, provide part of the solution but, on its own, falls short if a unknown third party is introduced. Further, there is no control over when a connected node will leave the network, effectively destroying the data stored on it. The proposed solution to these issues uses the Advanced Encryption Standard (AES) and forward error correction (FEC), along with the Hermes network model. A network wide manifest of data transactions is generated by hashing them into an ongoing chain of hash-based proof-of-work, forming a record that cannot be changed without redoing the proof-of-work. The longest chain not only serves as proof of the sequence of events witnessed, but proof that it came from the largest pool of CPU power. As long as a majority of CPU power is controlled by nodes that are not cooperating to attack the network, they'll generate the longest chain and outpace attackers. Messages are broadcast on a best effort basis, and nodes can leave and rejoin the network at will, accepting the longest proof-of-work chain as proof of what happened while they were gone.
\end{abstract}

% keywords Distributed Storage, Peer-to-peer storage

\IEEEpeerreviewmaketitle

\section{Introduction}
\IEEEPARstart{L}{orem} ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum. Sed ut perspiciatis unde omnis iste natus error sit voluptatem accusantium doloremque laudantium, totam rem aperiam, eaque ipsa quae ab illo inventore veritatis et quasi architecto beatae vitae dicta sunt explicabo. Nemo enim ipsam voluptatem quia voluptas sit aspernatur aut odit aut fugit, sed quia consequuntur magni dolores eos qui ratione voluptatem sequi nesciunt. Neque porro quisquam est, qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit, sed quia non numquam eius modi tempora incidunt ut labore et dolore magnam aliquam quaerat voluptatem. Ut enim ad minima veniam, quis nostrum exercitationem ullam corporis suscipit laboriosam, nisi ut aliquid ex ea commodi consequatur? Quis autem vel eum iure reprehenderit qui in ea voluptate velit esse quam nihil molestiae consequatur, vel illum qui dolorem eum fugiat quo voluptas nulla pariatur?

\section{Requirements Notation}
The key words ``MUST", ``MUST NOT", ``REQUIRED", ``SHALL", ``SHALL NOT", ``SHOULD", ``SHOULD NOT", ``RECOMMENDED", ``MAY", and ``OPTIONAL" in this document are to be interpreted as described in [RFC2119].

\section{Formats and Codes}

\subsection{Introduction}
The octet order of all fields is network byte order, i.e., big-endian.

% data signatures on blocks

\section{Preprocessor}
We define the \textit{network} to be the peer-to-peer connection between clients. Data to be inserted into the network must first undergo a multistage encoding process to ensure its security and integrity. We define the client-side of the implementation to be anything that must first be executed before contacting peers on the rest of the network. These stages are in order of optimal execution. Out of order execution may cause unknown or unusable results. We define the \textit{source data} to be the data inputted by the user in its original state to be sent to the network.

\subsection{Hash Function}
Over the course of this document, a cryptographic hash function, $H($message$) \rightarrow$ digest, will be required for implementation of certain components of this system. While no specific function is required, it MUST be infeasible to generate a message that has a given hash, to modify a message without changing the hash, must be a consisten hash function, and to find two different messages with the same hash.

\subsection{Client IDs}
Each client, or \textit{node} on the network must have a unique identifier in order to distinguish itself, and assert ownership over its data being stored on other nodes. Upon creation of a new node, it must generate both a private and public key-pair using a unique seed as follows,

\begin{center}
$K_{private} = H(IV)$\\
$K_{public} = H(K_{private})$
\end{center}



\subsection{Data Compression}
Compression of source data is RECOMMENDED as it aims to reduce the size of the data. While this may seem optimal to reduce network and storage loads, this also adds additional load on the client's CPU. The recommended compression algorithm is the Lempel-Ziv-Markov Chain Algorithm (LZMA), an advanced version of LZ77 [RFC1951]. The hermes network only source of storage is that which is contributed by the individual nodes, and each node is allow to consume as much storage in the network as they contribute. If each node used all their available storage, then all the networks resources would be consumed. This wouldnt make the the regenerative block functionality possible if nodes were to leave the network.

\subsection{Data Encryption} % Read RFC3602 section 2.1
Encryption is Advanced Encryption Standard with Cipher-Block Chaining (AES-CBC). This mode of AES works such that,

\begin{center}
$C_i = E_{K_{private}}(P_i \oplus{} C_{i-1})$, $C_0 = IV$\\
$P_i = D_{K_{private}}(C_i) \oplus{} C_{i-1}$, $C_0 = IV$
\end{center}

\noindent
where $C$ is the cipher-text, and $P$ is the plain-text. This is to prevent data blocks from being independently decrypted with malicious intent. This also does not allow for partial decryption of user data, so if even a single data block is lost, none of the original data can be recovered. This problem will be addressed by Fountain Codes in section 1.5.

\subsection{Fountain Code}


\subsection{Payload IDs}
The Payload ID MUST be a 64-octet field defined as follows:

diagram

Each of the resulting payloads, $P_i$, from the fountain code algorithm are then assigned a ID, and signed by the node with a 64-octet field.

\begin{center}
$ID_i = H(ID_{i-1})$, $ID_0 = H(P)$\\
$S_i = H(P + K_{private})$
\end{center}

\section{Network}
Once the data has been processed by the preprocessor, it is then inserted into the network through the node's peers.

\subsection{Peer Discovery} % Taken from BitTorrent Sync
The underlying Chord DHT only requires knowledge of a single node in the network to be able to connect and join. A similar method to that of the Bitcoin crpytocurrency is implemented for peer discovery. Using SeedNodes one can register several known and trusted peers IP Address established in the network to several domain names using the DNS system. This allows a new node to query the DNS of the specified domain (ie. dnsseed.hermesproject.org) and return a list of connected nodes. Local network discovery will work in tandem for performance reasons since connections are faster in a LAN. A broadcast message can be sent through the subnet to identity potential peers. The SeedNodes also have the potential to act as STUN servers to allow peers behind NATs without UPNP directly communicate.

% \subsection{Distributed networks and DHTs}

% \subsection{Network Coding}

% \subsection{Degree of distribution}

% \subsection{Network algorithms (EMAs, ...)}

\section{Conclusion}
Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum. Sed ut perspiciatis unde omnis iste natus error sit voluptatem accusantium doloremque laudantium, totam rem aperiam, eaque ipsa quae ab illo inventore veritatis et quasi architecto beatae vitae dicta sunt explicabo. Nemo enim ipsam voluptatem quia voluptas sit aspernatur aut odit aut fugit, sed quia consequuntur magni dolores eos qui ratione voluptatem sequi nesciunt. Neque porro quisquam est, qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit, sed quia non numquam eius modi tempora incidunt ut labore et dolore magnam aliquam quaerat voluptatem. Ut enim ad minima veniam, quis nostrum exercitationem ullam corporis suscipit laboriosam, nisi ut aliquid ex ea commodi consequatur? Quis autem vel eum iure reprehenderit qui in ea voluptate velit esse quam nihil molestiae consequatur, vel illum qui dolorem eum fugiat quo voluptas nulla pariatur?


%\appendices
%\section{Proof of the First Zonklar Equation}
%Appendix one text goes here.

%\section{}
%Appendix two text goes here.

%\section*{Acknowledgment}
%The authors would like to thank Gray Graffam for supporting the development of the project.


% Can use something like this to put references on a page
% by themselves when using endfloat and the captionsoff option.
%\ifCLASSOPTIONcaptionsoff
%  \newpage
%\fi

\begin{thebibliography}{1}

%\bibitem{IEEEhowto:kopka}
%H.~Kopka and P.~W. Daly, \emph{A Guide to \LaTeX}, 3rd~ed.\hskip 1em plus
%  0.5em minus 0.4em\relax Harlow, England: Addison-Wesley, 1999.
 
\bibitem{}
I. Stoica, R. Morris, D. Karger, M. F. Kaashoek, H. Balakrishnan, \emph{Chord: A Scalable Peer-to-peer Lookup Service for Internet Applications}, Proceedings of the 2001 Conference on Applications, Technologies, Architectures, and Protocols for Computer Communications, (San Diego, California), August 2001

\bibitem{}
A. G. Dimakis , P. G. Godfrey , M. J. Wainwright and K. Ramchandran  \emph{Network coding for distributed storage systems},  IEEE INFOCOM,  2007 

%http://www.bms.bc.ca/resources/library/pdf/GuidelinesScientificPapers.pdf
%http://tools.ietf.org/html/rfc6330
%http://users.ece.utexas.edu/~dimakis/RC_Journal.pdf

\end{thebibliography}

\end{document}