dropbear: crypt.tex comparison

comparison crypt.tex @ 381:999a5eb4ed10 libtomcrypt-dropbear

propagate from branch 'au.asn.ucc.matt.ltc.orig' (head 52840647ac7f5c707c3bd158d119a15734a7ef28) to branch 'au.asn.ucc.matt.ltc.dropbear' (head 20dccfc09627970a312d77fb41dc2970b62689c3)

author	Matt Johnston <matt@ucc.asn.au>
date	Thu, 11 Jan 2007 02:39:21 +0000
parents	d5faf4814ddb
children

comparison

equal deleted inserted replaced

-:997e6f7dc01e
+:999a5eb4ed10
-\documentclass[a4paper]{book}
+\documentclass[synpaper]{book}
+\usepackage[dvips]{geometry}
 \usepackage{hyperref}
 \usepackage{makeidx}
 \usepackage{amssymb}
 \usepackage{color}
 \usepackage{alltt}
 \usepackage{graphicx}
 \usepackage{layout}
+\usepackage{fancyhdr}
 \def\union{\cup}
 \def\intersect{\cap}
 \def\getsrandom{\stackrel{\rm R}{\gets}}
 \def\cross{\times}
 \def\cat{\hspace{0.5em} \| \hspace{0.5em}}
 \newcommand{\ceil}[1]{\left\lceil{#1}\right\rceil}
 \def\Or{{\rm\ or\ }}
 \def\And{{\rm\ and\ }}
 \def\iff{\hspace{1em}\Longleftrightarrow\hspace{1em}}
 \def\implies{\Rightarrow}
-\def\undefined{{\rm ``undefined"}}
+\def\undefined{{\rm \textit{undefined}}}
 \def\Proof{\vspace{1ex}\noindent {\bf Proof:}\hspace{1em}}
 \let\oldphi\phi
 \def\phi{\varphi}
 \def\Pr{{\rm Pr}}
 \newcommand{\str}[1]{{\mathbf{#1}}}
 \def\N{{\mathbb N}}
 \def\Z{{\mathbb Z}}
 \def\R{{\mathbb R}}
 \def\C{{\mathbb C}}
 \def\Q{{\mathbb Q}}
+\definecolor{DGray}{gray}{0.5}
+\newcommand{\emailaddr}[1]{\mbox{$<${#1}$>$}}
 \def\twiddle{\raisebox{0.3ex}{\mbox{\tiny $\sim$}}}
 \def\gap{\vspace{0.5ex}}
 \makeindex
+\newcommand{\mysection}[1]    % Re-define the chaptering command to use
+	{                   % THESE headers.
+	\section{#1}
+\markboth{\textsf{www.libtom.org}}{\thesection ~ {#1}}
+	}
+\newcommand{\mystarsection}[1]    % Re-define the chaptering command to use
+	{                   % THESE headers.
+	\section*{#1}
+\markboth{\textsf{www.libtom.org}}{{#1}}
+	}
+\pagestyle{empty}
 \begin{document}
-\title{LibTomCrypt \\ Version 1.05}
+\frontmatter
-\author{Tom St Denis \\
+\pagestyle{empty}
-\\
-[email protected] \\
+~
-http://libtomcrypt.org
-}
+\vspace{2in}
-\maketitle
-This text and source code library are both hereby placed in the public domain.  This book has been
+~
-formatted for A4 paper using the \LaTeX{} {\em book} macro package.
+\begin{center}
-\vspace{15cm}
+\begin{Huge}LibTomCrypt\end{Huge}
-\begin{flushright}Open Source.  Open Academia.  Open Minds.
+~
-\mbox{ }
+\begin{large}Developer Manual\end{large}
-Tom St Denis,
+~
-Phone: 1-613-836-3160
+\vspace{15mm}
-111 Banning Rd
+\begin{tabular}{c}
-Kanata, Ontario
+Tom St Denis \\
+LibTom Projects
-K2L 1C3
+\end{tabular}
+\end{center}
+\vfil
+\newpage
+This document is part of the LibTomCrypt package and is hereby released into the public domain.
+~
+Open Source.  Open Academia.  Open Minds.
+~
+\begin{flushright}
+Tom St Denis
+~
+Ottawa, Ontario
+~
 Canada
+~
+\vfil
 \end{flushright}
 \newpage
 \tableofcontents
+\listoffigures
+\pagestyle{myheadings}
+\mainmatter
 \chapter{Introduction}
-\section{What is the LibTomCrypt?}
+\mysection{What is the LibTomCrypt?}
-LibTomCrypt is a portable ISO C cryptographic library that is meant to be a toolset for cryptographers who are
+LibTomCrypt is a portable ISO C cryptographic library meant to be a tool set for cryptographers who are
-designing a cryptosystem.  It supports symmetric ciphers, one-way hashes, pseudo-random number generators,
+designing cryptosystems.  It supports symmetric ciphers, one-way hashes, pseudo-random number generators,
-public key cryptography (via PKCS \#1 RSA, DH or ECCDH) and a plethora of support
+public key cryptography (via PKCS \#1 RSA, DH or ECCDH), and a plethora of support routines.
-routines.
+The library was designed such that new ciphers/hashes/PRNGs can be added at run-time and the existing API
-The library was designed such that new ciphers/hashes/PRNGs can be added at runtime and the existing API
 (and helper API functions) are able to use the new designs automatically.  There exists self-check functions for each
 block cipher and hash function to ensure that they compile and execute to the published design specifications.  The library
-also performs extensive parameter error checking to prevent any number of runtime exploits or errors.
+also performs extensive parameter error checking to prevent any number of run-time exploits or errors.
 \subsection{What the library IS for?}
 The library serves as a toolkit for developers who have to solve cryptographic problems.  Out of the box LibTomCrypt
-does not process SSL or OpenPGP messages, it doesn't read x.591 certificates or write PEM encoded data.  It does, however,
+does not process SSL or OpenPGP messages, it doesn't read X.509 certificates, or write PEM encoded data.  It does, however,
 provide all of the tools required to build such functionality.  LibTomCrypt was designed to be a flexible library that
 was not tied to any particular cryptographic problem.
-\section{Why did I write it?}
+\mysection{Why did I write it?}
-You may be wondering, ``Tom, why did you write a crypto library.  I already have one.''.  Well the reason falls into
+You may be wondering, \textit{Tom, why did you write a crypto library.  I already have one.}  Well the reason falls into
 two categories:
 \begin{enumerate}
 \item I am too lazy to figure out someone else's API.  I'd rather invent my own simpler API and use that.
 \item It was (still is) good coding practice.
 \end{enumerate}
 The idea is that I am not striving to replace OpenSSL or Crypto++ or Cryptlib or etc.  I'm trying to write my
 {\bf own} crypto library and hopefully along the way others will appreciate the work.
-With this library all core functions (ciphers, hashes, prngs) have the {\bf exact} same prototype definition.  They all load
+With this library all core functions (ciphers, hashes, prngs, and bignum) have the same prototype definition.  They all load
 and store data in a format independent of the platform.  This means if you encrypt with Blowfish on a PPC it should decrypt
-on an x86 with zero problems.  The consistent API also means that if you learn how to use Blowfish with my library you
+on an x86 with zero problems.  The consistent API also means that if you learn how to use Blowfish with the library you
-know how to use Safer+ or RC6 or Serpent or ... as well.  With all of the core functions there are central descriptor tables
+know how to use Safer+, RC6, or Serpent as well.  With all of the core functions there are central descriptor tables
-that can be used to make a program automatically pick between ciphers, hashes and PRNGs at runtime.  That means your
+that can be used to make a program automatically pick between ciphers, hashes and PRNGs at run-time.  That means your
-application can support all ciphers/hashes/prngs without changing the source code.
+application can support all ciphers/hashes/prngs/bignum without changing the source code.
-Not only did I strive to make a consistent and simple API to work with but I also strived to make the library
+Not only did I strive to make a consistent and simple API to work with but I also attempted to make the library
 configurable in terms of its build options.  Out of the box the library will build with any modern version of GCC
 without having to use configure scripts.  This means that the library will work with platforms where development
 tools may be limited (e.g. no autoconf).
-On top of making the build simple and the API approachable I've also strived for a reasonably high level of
+On top of making the build simple and the API approachable I've also attempted for a reasonably high level of
 robustness and efficiency.  LibTomCrypt traps and returns a series of errors ranging from invalid
 arguments to buffer overflows/overruns.  It is mostly thread safe and has been clocked on various platforms
-with ``cycles per byte'' timings that are comparable (and often favourable) to other libraries such as OpenSSL and
+with \textit{cycles per byte} timings that are comparable (and often favourable) to other libraries such as OpenSSL and
 Crypto++.
 \subsection{Modular}
-The LibTomCrypt package has also been written to be very modular.  The block ciphers, one--way hashes and
+The LibTomCrypt package has also been written to be very modular.  The block ciphers, one--way hashes,
-pseudo--random number generators (PRNG) are all used within the API through ``descriptor'' tables which
+pseudo--random number generators (PRNG), and bignum math routines are all used within the API through \textit{descriptor} tables which
 are essentially structures with pointers to functions.  While you can still call particular functions
 directly (\textit{e.g. sha256\_process()}) this descriptor interface allows the developer to customize their
 usage of the library.
 For example, consider a hardware platform with a specialized RNG device.  Obviously one would like to tap
 that for the PRNG needs within the library (\textit{e.g. making a RSA key}).  All the developer has to do
 is write a descriptor and the few support routines required for the device.  After that the rest of the
-API can make use of it without change.  Similiarly imagine a few years down the road when AES2
+API can make use of it without change.  Similarly imagine a few years down the road when AES2
 (\textit{or whatever they call it}) has been invented.  It can be added to the library and used within applications
 with zero modifications to the end applications provided they are written properly.
 This flexibility within the library means it can be used with any combination of primitive algorithms and
 unlike libraries like OpenSSL is not tied to direct routines.  For instance, in OpenSSL there are CBC block
 you have to update the associated support code as well.  In LibTomCrypt the associated code (\textit{chaining modes in this case})
 are not directly tied to the ciphers.  That is a new cipher can be added to the library by simply providing
 the key setup, ECB decrypt and encrypt and test vector routines.  After that all five chaining mode routines
 can make use of the cipher right away.
-\section{License}
+\mysection{License}
-All of the source code except for the following files have been written by the author or donated to the project
-under a public domain license:
-\begin{enumerate}
-\item rc2.c
-\end{enumerate}
-`mpi.c'' was originally written by Michael Fromberger ([email protected]) but has since been replaced with
-my LibTomMath library which is public domain.
-``rc2.c'' is based on publicly available code that is not attributed to a person from the given source.
 The project is hereby released as public domain.
-\section{Patent Disclosure}
+\mysection{Patent Disclosure}
 The author (Tom St Denis) is not a patent lawyer so this section is not to be treated as legal advice.  To the best
 of the authors knowledge the only patent related issues within the library are the RC5 and RC6 symmetric block ciphers.
-They can be removed from a build by simply commenting out the two appropriate lines in ``tomcrypt\_custom.h''.  The rest
+They can be removed from a build by simply commenting out the two appropriate lines in \textit{tomcrypt\_custom.h}.  The rest
 of the ciphers and hashes are patent free or under patents that have since expired.
 The RC2 and RC4 symmetric ciphers are not under patents but are under trademark regulations.  This means you can use
 the ciphers you just can't advertise that you are doing so.
-\section{Thanks}
+\mysection{Thanks}
 I would like to give thanks to the following people (in no particular order) for helping me develop this project from
 early on:
 \begin{enumerate}
 \item Richard van de Laarschot
 \item Richard Heathfield
 There have been quite a few other people as well.  Please check the change log to see who else has contributed from
 time to time.
 \chapter{The Application Programming Interface (API)}
-\section{Introduction}
+\mysection{Introduction}
 \index{CRYPT\_ERROR} \index{CRYPT\_OK}
 In general the API is very simple to memorize and use.  Most of the functions return either {\bf void} or {\bf int}.  Functions
-that return {\bf int} will return {\bf CRYPT\_OK} if the function was successful or one of the many error codes
+that return {\bf int} will return {\bf CRYPT\_OK} if the function was successful, or one of the many error codes
 if it failed.  Certain functions that return int will return $-1$ to indicate an error.  These functions will be explicitly
 commented upon.  When a function does return a CRYPT error code it can be translated into a string with
 \index{error\_to\_string()}
 \begin{verbatim}
 const char *error_to_string(int err);
 \end{verbatim}
 An example of handling an error is:
+\begin{small}
 \begin{verbatim}
 void somefunc(void)
 {
 int err;
 /* call a cryptographic function */
 if ((err = some_crypto_function(...)) != CRYPT_OK) {
-printf("A crypto error occured, %s\n", error_to_string(err));
+printf("A crypto error occurred, %s\n", error_to_string(err));
 /* perform error handling */
 }
-/* continue on if no error occured */
+/* continue on if no error occurred */
 }
 \end{verbatim}
+\end{small}
 There is no initialization routine for the library and for the most part the code is thread safe.  The only thread
 related issue is if you use the same symmetric cipher, hash or public key state data in multiple threads.  Normally
 that is not an issue.
-To include the prototypes for ``LibTomCrypt.a'' into your own program simply include ``tomcrypt.h'' like so:
+To include the prototypes for \textit{LibTomCrypt.a} into your own program simply include \textit{tomcrypt.h} like so:
+\begin{small}
 \begin{verbatim}
 #include <tomcrypt.h>
 int main(void) {
 return 0;
 }
 \end{verbatim}
+\end{small}
-The header file ``tomcrypt.h'' also includes ``stdio.h'', ``string.h'', ``stdlib.h'', ``time.h'', ``ctype.h'' and
-``ltc\_tommath.h'' (the bignum library routines).
+The header file \textit{tomcrypt.h} also includes \textit{stdio.h}, \textit{string.h}, \textit{stdlib.h}, \textit{time.h} and \textit{ctype.h}.
-\section{Macros}
+\mysection{Macros}
 There are a few helper macros to make the coding process a bit easier.  The first set are related to loading and storing
 32/64-bit words in little/big endian format.  The macros are:
 \index{STORE32L} \index{STORE64L} \index{LOAD32L} \index{LOAD64L} \index{STORE32H} \index{STORE64H} \index{LOAD32H} \index{LOAD64H} \index{BSWAP}
+\newpage
+\begin{figure}[hpbt]
 \begin{small}
 \begin{center}
 \begin{tabular}{|c|c|c|}
 \hline STORE32L(x, y) & {\bf unsigned long} x, {\bf unsigned char} *y & $x \to y[0 \ldots 3]$ \\
 \hline STORE64L(x, y) & {\bf unsigned long long} x, {\bf unsigned char} *y & $x \to y[0 \ldots 7]$ \\
 \hline LOAD64L(x, y) & {\bf unsigned long long} x, {\bf unsigned char} *y & $y[0 \ldots 7] \to x$ \\
 \hline STORE32H(x, y) & {\bf unsigned long} x, {\bf unsigned char} *y & $x \to y[3 \ldots 0]$ \\
 \hline STORE64H(x, y) & {\bf unsigned long long} x, {\bf unsigned char} *y & $x \to y[7 \ldots 0]$ \\
 \hline LOAD32H(x, y) & {\bf unsigned long} x, {\bf unsigned char} *y & $y[3 \ldots 0] \to x$ \\
 \hline LOAD64H(x, y) & {\bf unsigned long long} x, {\bf unsigned char} *y & $y[7 \ldots 0] \to x$ \\
-\hline BSWAP(x) & {\bf unsigned long} x & Swaps byte order (32--bits only) \\
+\hline BSWAP(x) & {\bf unsigned long} x & Swap bytes \\
 \hline
 \end{tabular}
+\caption{Load And Store Macros}
 \end{center}
 \end{small}
+\end{figure}
 There are 32 and 64-bit cyclic rotations as well:
 \index{ROL} \index{ROR} \index{ROL64} \index{ROR64} \index{ROLc} \index{RORc} \index{ROL64c} \index{ROR64c}
+\begin{figure}[hpbt]
+\begin{small}
 \begin{center}
 \begin{tabular}{|c|c|c|}
 \hline ROL(x, y) & {\bf unsigned long} x, {\bf unsigned long} y & $x << y, 0 \le y \le 31$ \\
 \hline ROLc(x, y) & {\bf unsigned long} x, {\bf const unsigned long} y & $x << y, 0 \le y \le 31$ \\
 \hline ROR(x, y) & {\bf unsigned long} x, {\bf unsigned long} y & $x >> y, 0 \le y \le 31$ \\
 \hline ROL64c(x, y) & {\bf unsigned long} x, {\bf const unsigned long} y & $x << y, 0 \le y \le 63$ \\
 \hline ROR64(x, y) & {\bf unsigned long} x, {\bf unsigned long} y & $x >> y, 0 \le y \le 63$ \\
 \hline ROR64c(x, y) & {\bf unsigned long} x, {\bf const unsigned long} y & $x >> y, 0 \le y \le 63$ \\
 \hline
 \end{tabular}
+\caption{Rotate Macros}
 \end{center}
+\end{small}
-\section{Functions with Variable Length Output}
+\end{figure}
-Certain functions such as (for example) ``rsa\_export()'' give an output that is variable length.  To prevent buffer overflows you
-must pass it the length of the buffer\footnote{Extensive error checking is not in place but it will be in future releases so it is a good idea to follow through with these guidelines.} where
+\mysection{Functions with Variable Length Output}
-the output will be stored.  For example:
+Certain functions such as (for example) \textit{rsa\_export()} give an output that is variable length.  To prevent buffer overflows you
+must pass it the length of the buffer where the output will be stored.  For example:
+\index{rsa\_export()} \index{error\_to\_string()} \index{variable length output}
 \begin{small}
 \begin{verbatim}
 #include <tomcrypt.h>
 int main(void) {
 rsa_key key;
 unsigned long x;
 int err;
 /* ... Make up the RSA key somehow ... */
-/* lets export the key, set x to the size of the output buffer */
+/* lets export the key, set x to the size of the
+* output buffer */
 x = sizeof(buffer);
 if ((err = rsa_export(buffer, &x, PK_PUBLIC, &key)) != CRYPT_OK) {
 printf("Export error: %s\n", error_to_string(err));
 return -1;
 }
-/* if rsa_export() was successful then x will have the size of the output */
+/* if rsa_export() was successful then x will have
+* the size of the output */
 printf("RSA exported key takes %d bytes\n", x);
 /* ... do something with the buffer */
 return 0;
 }
 \end{verbatim}
 \end{small}
 In the above example if the size of the RSA public key was more than 1024 bytes this function would return an error code
-indicating a buffer overflow would have occurred.  If the function succeeds it stores the length of the output
+indicating a buffer overflow would have occurred.  If the function succeeds, it stores the length of the output back into
-back into ``x'' so that the calling application will know how many bytes were used.
+\textit{x} so that the calling application will know how many bytes were used.
-\section{Functions that need a PRNG}
+As of v1.13, most functions will update your length on failure to indicate the size required by the function.  Not all functions
+support this so please check the source before you rely on it doing that.
+\mysection{Functions that need a PRNG}
 \index{Pseudo Random Number Generator} \index{PRNG}
-Certain functions such as ``rsa\_make\_key()'' require a Pseudo Random Number Generator (PRNG).  These functions do not setup
+Certain functions such as \textit{rsa\_make\_key()} require a Pseudo Random Number Generator (PRNG).  These functions do not setup
 the PRNG themselves so it is the responsibility of the calling function to initialize the PRNG before calling them.
-Certain PRNG algorithms do not require a ``prng\_state'' argument (sprng for example).  The ``prng\_state'' argument
+Certain PRNG algorithms do not require a \textit{prng\_state} argument (sprng for example).  The \textit{prng\_state} argument
 may be passed as \textbf{NULL} in such situations.
-\section{Functions that use Arrays of Octets}
+\index{register\_prng()} \index{rsa\_make\_key()}
-Most functions require inputs that are arrays of the data type ``unsigned char''.  Whether it is a symmetric key, IV
+\begin{small}
-for a chaining mode or public key packet it is assumed that regardless of the actual size of ``unsigned char'' only the
+\begin{verbatim}
-lower eight bits contain data.  For example, if you want to pass a 256 bit key to a symmetric ciphers setup routine
+#include <tomcrypt.h>
-you must pass it in (a pointer to) an array of 32 ``unsigned char'' variables.  Certain routines
+int main(void) {
-(such as SAFER+) take special care to work properly on platforms where an ``unsigned char'' is not eight bits.
+rsa_key key;
+int     err;
-For the purposes of this library the term ``byte'' will refer to an octet or eight bit word.  Typically an array of
-type ``byte'' will be synonymous with an array of type ``unsigned char''.
+/* register the system RNG */
+register_prng(&sprng_desc)
+/* make a 1024-bit RSA key with the system RNG */
+if ((err = rsa_make_key(NULL, find_prng("sprng"), 1024/8, 65537, &key))
+!= CRYPT_OK) {
+printf("make_key error: %s\n", error_to_string(err));
+return -1;
+}
+/* use the key ... */
+return 0;
+}
+\end{verbatim}
+\end{small}
+\mysection{Functions that use Arrays of Octets}
+Most functions require inputs that are arrays of the data type \textit{unsigned char}.  Whether it is a symmetric key, IV
+for a chaining mode or public key packet it is assumed that regardless of the actual size of \textit{unsigned char} only the
+lower eight bits contain data.  For example, if you want to pass a 256 bit key to a symmetric ciphers setup routine, you
+must pass in (a pointer to) an array of 32 \textit{unsigned char} variables.  Certain routines (such as SAFER+) take
+special care to work properly on platforms where an \textit{unsigned char} is not eight bits.
+For the purposes of this library, the term \textit{byte} will refer to an octet or eight bit word.  Typically an array of
+type \textit{byte} will be synonymous with an array of type \textit{unsigned char.}
 \chapter{Symmetric Block Ciphers}
-\section{Core Functions}
+\mysection{Core Functions}
+LibTomCrypt provides several block ciphers with an ECB block mode interface.  It is important to first note that you
-LibTomCrypt provides several block ciphers with an ECB block mode interface.  It's important to first note that you
+should never use the ECB modes directly to encrypt data.  Instead you should use the ECB functions to make a chaining mode,
-should never use the ECB modes directly to encrypt data.  Instead you should use the ECB functions to make a chaining mode
 or use one of the provided chaining modes.  All of the ciphers are written as ECB interfaces since it allows the rest of
 the API to grow in a modular fashion.
 \subsection{Key Scheduling}
-All ciphers store their scheduled keys in a single data type called ``symmetric\_key''.  This allows all ciphers to
+All ciphers store their scheduled keys in a single data type called \textit{symmetric\_key}.  This allows all ciphers to
 have the same prototype and store their keys as naturally as possible.  This also removes the need for dynamic memory
-allocation and allows you to allocate a fixed sized buffer for storing scheduled keys.  All ciphers provide five visible
+allocation, and allows you to allocate a fixed sized buffer for storing scheduled keys.  All ciphers must provide six visible
-functions which are (given that XXX is the name of the cipher):
+functions which are (given that XXX is the name of the cipher) the following:
 \index{Cipher Setup}
 \begin{verbatim}
-int XXX_setup(const unsigned char *key, int keylen, int rounds,
+int XXX_setup(const unsigned char *key,
-symmetric_key *skey);
+int  keylen,
+int  rounds,
+symmetric_key *skey);
 \end{verbatim}
 The XXX\_setup() routine will setup the cipher to be used with a given number of rounds and a given key length (in bytes).
 The number of rounds can be set to zero to use the default, which is generally a good idea.
-If the function returns successfully the variable ``skey'' will have a scheduled key stored in it.  It's important to note
+If the function returns successfully the variable \textit{skey} will have a scheduled key stored in it.  It's important to note
-that you should only used this scheduled key with the intended cipher.  For example, if you call ``blowfish\_setup()'' do not
+that you should only used this scheduled key with the intended cipher.  For example, if you call \textit{blowfish\_setup()} do not
-pass the scheduled key onto ``rc5\_ecb\_encrypt()''.  All setup functions do not allocate memory off the heap so when you are
+pass the scheduled key onto \textit{rc5\_ecb\_encrypt()}.  All built--in setup functions do not allocate memory off the heap so
-done with a key you can simply discard it (e.g. they can be on the stack).
+when you are done with a key you can simply discard it (e.g. they can be on the stack).  However, to maintain proper coding
+practices you should always call the respective XXX\_done() function.  This allows for quicker porting to applications with
+externally supplied plugins.
 \subsection{ECB Encryption and Decryption}
-To encrypt or decrypt a block in ECB mode there are these two function classes
+To encrypt or decrypt a block in ECB mode there are these two functions per cipher:
 \index{Cipher Encrypt} \index{Cipher Decrypt}
 \begin{verbatim}
-void XXX_ecb_encrypt(const unsigned char *pt, unsigned char *ct,
+int XXX_ecb_encrypt(const unsigned char *pt,
-symmetric_key *skey);
+unsigned char *ct,
+symmetric_key *skey);
-void XXX_ecb_decrypt(const unsigned char *ct, unsigned char *pt,
-symmetric_key *skey);
+int XXX_ecb_decrypt(const unsigned char *ct,
+unsigned char *pt,
+symmetric_key *skey);
 \end{verbatim}
 These two functions will encrypt or decrypt (respectively) a single block of text\footnote{The size of which depends on
-which cipher you are using.} and store the result where you want it.  It is possible that the input and output buffer are
+which cipher you are using.}, storing the result in the \textit{ct} buffer (\textit{pt} resp.).  It is possible that the input and output buffer are
-the same buffer.  For the encrypt function ``pt''\footnote{pt stands for plaintext.} is the input and
+the same buffer.  For the encrypt function \textit{pt}\footnote{pt stands for plaintext.} is the input and
-``ct''\footnote{ct stands for ciphertext.} is the output.  For the decryption function it's the opposite.  To test a particular
+\textit{ct}\footnote{ct stands for ciphertext.} is the output.  For the decryption function it's the opposite.  They both
-cipher against test vectors\footnote{As published in their design papers.} call the self-test function
+return \textbf{CRYPT\_OK} on success.  To test a particular cipher against test vectors\footnote{As published in their design papers.}
+call the following self-test function.
 \subsection{Self--Testing}
 \index{Cipher Testing}
 \begin{verbatim}
 int XXX_test(void);
 \end{verbatim}
 This function will return {\bf CRYPT\_OK} if the cipher matches the test vectors from the design publication it is
 based upon.
 \subsection{Key Sizing}
-For each cipher there is a function which will help find a desired key size:
+For each cipher there is a function which will help find a desired key size.  It is specified as follows:
+\index{Key Sizing}
 \begin{verbatim}
 int XXX_keysize(int *keysize);
 \end{verbatim}
-Essentially it will round the input keysize in ``keysize'' down to the next appropriate key size.  This function
+Essentially, it will round the input keysize in \textit{keysize} down to the next appropriate key size.  This function
-return {\bf CRYPT\_OK} if the key size specified is acceptable.  For example:
+will return {\bf CRYPT\_OK} if the key size specified is acceptable.  For example:
 \begin{small}
 \begin{verbatim}
 #include <tomcrypt.h>
 int main(void)
 {
 printf("Twofish suggested a key size of %d\n", keysize);
 return 0;
 }
 \end{verbatim}
 \end{small}
-This should indicate a keysize of sixteen bytes is suggested.
+This should indicate a keysize of sixteen bytes is suggested by storing 16 in \textit{keysize.}
 \subsection{Cipher Termination}
 When you are finished with a cipher you can de--initialize it with the done function.
 \begin{verbatim}
 void XXX_done(symmetric_key *skey);
 \end{verbatim}
-For the software based ciphers within LibTomCrypt this function will not do anything.  However, user supplied
+For the software based ciphers within LibTomCrypt, these functions will not do anything.  However, user supplied
-cipher descriptors may require calls to it for resource management.  To be compliant all functions which call a cipher
+cipher descriptors may require to be called for resource management purposes.  To be compliant, all functions which call a cipher
 setup function must also call the respective cipher done function when finished.
 \subsection{Simple Encryption Demonstration}
-An example snippet that encodes a block with Blowfish in ECB mode is below.
+An example snippet that encodes a block with Blowfish in ECB mode.
+\index{blowfish\_setup()} \index{blowfish\_ecb\_encrypt()} \index{blowfish\_ecb\_decrypt()} \index{blowfish\_done()}
 \begin{small}
 \begin{verbatim}
 #include <tomcrypt.h>
 int main(void)
 {
 unsigned char pt[8], ct[8], key[8];
 symmetric_key skey;
 int err;
-/* ... key is loaded appropriately in ``key'' ... */
+/* ... key is loaded appropriately in key ... */
-/* ... load a block of plaintext in ``pt'' ... */
+/* ... load a block of plaintext in pt ... */
 /* schedule the key */
-if ((err = blowfish_setup(key,     /* the key we will use */
+if ((err = blowfish_setup(key, /* the key we will use */
-8,     /* key is 8 bytes (64-bits) long */
+8, /* key is 8 bytes (64-bits) long */
-0,     /* 0 == use default # of rounds */
+0, /* 0 == use default # of rounds */
-&skey)     /* where to put the scheduled key */
+&skey) /* where to put the scheduled key */
 ) != CRYPT_OK) {
 printf("Setup error: %s\n", error_to_string(err));
 return -1;
 }
 /* encrypt the block */
-blowfish_ecb_encrypt(pt,             /* encrypt this 8-byte array */
+blowfish_ecb_encrypt(pt,       /* encrypt this 8-byte array */
-ct,             /* store encrypted data here */
+ct,       /* store encrypted data here */
-&skey);         /* our previously scheduled key */
+&skey);   /* our previously scheduled key */
 /* now ct holds the encrypted version of pt */
 /* decrypt the block */
-blowfish_ecb_decrypt(ct,             /* decrypt this 8-byte array */
+blowfish_ecb_decrypt(ct,       /* decrypt this 8-byte array */
-pt,             /* store decrypted data here */
+pt,       /* store decrypted data here */
-&skey);         /* our previously scheduled key */
+&skey);   /* our previously scheduled key */
 /* now we have decrypted ct to the original plaintext in pt */
 /* Terminate the cipher context */
 blowfish_done(&skey);
 return 0;
 }
 \end{verbatim}
 \end{small}
-\section{Key Sizes and Number of Rounds}
+\mysection{Key Sizes and Number of Rounds}
 \index{Symmetric Keys}
-As a general rule of thumb do not use symmetric keys under 80 bits if you can.  Only a few of the ciphers support smaller
+As a general rule of thumb, do not use symmetric keys under 80 bits if you can help it.  Only a few of the ciphers support smaller
-keys (mainly for test vectors anyways).  Ideally your application should be making at least 256 bit keys.  This is not
+keys (mainly for test vectors anyways).  Ideally, your application should be making at least 256 bit keys.  This is not
-because you're supposed to be paranoid.  It's because if your PRNG has a bias of any sort the more bits the better.  For
+because you are to be paranoid.  It is because if your PRNG has a bias of any sort the more bits the better.  For
 example, if you have $\mbox{Pr}\left[X = 1\right] = {1 \over 2} \pm \gamma$ where $\vert \gamma \vert > 0$ then the
 total amount of entropy in N bits is $N \cdot -log_2\left ({1 \over 2} + \vert \gamma \vert \right)$.  So if $\gamma$
 were $0.25$ (a severe bias) a 256-bit string would have about 106 bits of entropy whereas a 128-bit string would have
 only 53 bits of entropy.
 The number of rounds of most ciphers is not an option you can change.  Only RC5 allows you to change the number of
 rounds.  By passing zero as the number of rounds all ciphers will use their default number of rounds.  Generally the
 ciphers are configured such that the default number of rounds provide adequate security for the given block and key
 size.
-\section{The Cipher Descriptors}
+\mysection{The Cipher Descriptors}
 \index{Cipher Descriptor}
-To facilitate automatic routines an array of cipher descriptors is provided in the array ``cipher\_descriptor''.  An element
+To facilitate automatic routines an array of cipher descriptors is provided in the array \textit{cipher\_descriptor}.  An element
-of this array has the following format:
+of this array has the following (partial) format (See Section \ref{sec:cipherdesc}):
 \begin{small}
 \begin{verbatim}
 struct _cipher_descriptor {
+/** name of cipher */
 char *name;
+/** internal ID */
 unsigned char ID;
+/** min keysize (octets) */
 int  min_key_length,
+/** max keysize (octets) */
 max_key_length,
+/** block size (octets) */
 block_length,
+/** default number of rounds */
 default_rounds;
-int  (*setup)(const unsigned char *key, int keylen, int num_rounds, symmetric_key *skey);
+...<snip>...
-void (*ecb_encrypt)(const unsigned char *pt, unsigned char *ct, symmetric_key *skey);
-void (*ecb_decrypt)(const unsigned char *ct, unsigned char *pt, symmetric_key *skey);
-int (*test)(void);
-void (*done)(symmetric_key *skey);
-int  (*keysize)(int *keysize);
-void (*accel_ecb_encrypt)(const unsigned char *pt,
-unsigned char *ct,
-unsigned long blocks, symmetric_key *skey);
-void (*accel_ecb_decrypt)(const unsigned char *ct,
-unsigned char *pt,
-unsigned long blocks, symmetric_key *skey);
-void (*accel_cbc_encrypt)(const unsigned char *pt,
-unsigned char *ct,
-unsigned long blocks, unsigned char *IV,
-symmetric_key *skey);
-void (*accel_cbc_decrypt)(const unsigned char *ct,
-unsigned char *pt,
-unsigned long blocks, unsigned char *IV,
-symmetric_key *skey);
-void (*accel_ctr_encrypt)(const unsigned char *pt,
-unsigned char *ct,
-unsigned long blocks, unsigned char *IV,
-int mode, symmetric_key *skey);
-void (*accel_ccm_memory)(
-const unsigned char *key,    unsigned long keylen,
-const unsigned char *nonce,  unsigned long noncelen,
-const unsigned char *header, unsigned long headerlen,
-unsigned char *pt,     unsigned long ptlen,
-unsigned char *ct,
-unsigned char *tag,    unsigned long *taglen,
-int  direction);
 };
 \end{verbatim}
 \end{small}
-Where ``name'' is the lower case ASCII version of the name.  The fields ``min\_key\_length'' and ``max\_key\_length''
+Where \textit{name} is the lower case ASCII version of the name.  The fields \textit{min\_key\_length} and \textit{max\_key\_length}
-are the minimum and maximum key sizes in bytes.  The ``block\_length'' member is the block size of the cipher
+are the minimum and maximum key sizes in bytes.  The \textit{block\_length} member is the block size of the cipher
 in bytes.  As a good rule of thumb it is assumed that the cipher supports
-the min and max key lengths but not always everything in between.  The ``default\_rounds'' field is the default number
+the min and max key lengths but not always everything in between.  The \textit{default\_rounds} field is the default number
 of rounds that will be used.
+For a plugin to be compliant it must provide at least each function listed before the accelerators begin.  Accelerators are optional,
+and if missing will be emulated in software.
 The remaining fields are all pointers to the core functions for each cipher.  The end of the cipher\_descriptor array is
-marked when ``name'' equals {\bf NULL}.
+marked when \textit{name} equals {\bf NULL}.
-As of this release the current cipher\_descriptors elements are
+As of this release the current cipher\_descriptors elements are the following:
+\vfil
 \index{Cipher descriptor table}
+\index{blowfish\_desc} \index{xtea\_desc} \index{rc2\_desc} \index{rc5\_desc} \index{rc6\_desc} \index{saferp\_desc} \index{aes\_desc} \index{twofish\_desc}
+\index{des\_desc} \index{des3\_desc} \index{noekeon\_desc} \index{skipjack\_desc} \index{anubis\_desc} \index{khazad\_desc} \index{kseed\_desc} \index{kasumi\_desc}
+\begin{figure}[hpbt]
 \begin{small}
 \begin{center}
 \begin{tabular}{|c|c|c|c|c|c|}
-\hline Name & Descriptor Name & Block Size & Key Range & Rounds \\
+\hline \textbf{Name} & \textbf{Descriptor Name} & \textbf{Block Size} & \textbf{Key Range} & \textbf{Rounds} \\
 \hline Blowfish & blowfish\_desc & 8 & 8 $\ldots$ 56 & 16 \\
 \hline X-Tea & xtea\_desc & 8 & 16 & 32 \\
 \hline RC2 & rc2\_desc & 8 & 8 $\ldots$ 128 & 16 \\
 \hline RC5-32/12/b & rc5\_desc & 8 & 8 $\ldots$ 128 & 12 $\ldots$ 24 \\
 \hline RC6-32/20/b & rc6\_desc & 16 & 8 $\ldots$ 128 & 20 \\
 \hline CAST5 (CAST-128) & cast5\_desc & 8 & 5 $\ldots$ 16 & 12, 16 \\
 \hline Noekeon & noekeon\_desc & 16 & 16 & 16 \\
 \hline Skipjack & skipjack\_desc & 8 & 10 & 32 \\
 \hline Anubis & anubis\_desc & 16 & 16 $\ldots$ 40 & 12 $\ldots$ 18 \\
 \hline Khazad & khazad\_desc & 8 & 16 & 8 \\
+\hline SEED   & kseed\_desc & 16 & 16 & 16 \\
+\hline KASUMI & kasumi\_desc & 8 & 16 & 8 \\
 \hline
 \end{tabular}
 \end{center}
 \end{small}
+\caption{Built--In Software Ciphers}
+\end{figure}
 \subsection{Notes}
 \begin{small}
 \begin{enumerate}
 \item
-For AES (also known as Rijndael) there are four descriptors which complicate issues a little.  The descriptors
+For AES, (also known as Rijndael) there are four descriptors which complicate issues a little.  The descriptors
-rijndael\_desc and rijndael\_enc\_desc provide the cipher named ``rijndael''.  The descriptors aes\_desc and
+rijndael\_desc and rijndael\_enc\_desc provide the cipher named \textit{rijndael}.  The descriptors aes\_desc and
-aes\_enc\_desc provide the cipher name ``aes''.  Functionally both ``rijndael'' and ``aes'' are the same cipher.  The
+aes\_enc\_desc provide the cipher name \textit{aes}.  Functionally both \textit{rijndael} and \textit{aes} are the same cipher.  The
-only difference is when you call find\_cipher() you have to pass the correct name.  The cipher descriptors with ``enc''
+only difference is when you call find\_cipher() you have to pass the correct name.  The cipher descriptors with \textit{enc}
 in the middle (e.g. rijndael\_enc\_desc) are related to an implementation of Rijndael with only the encryption routine
-and tables.  The decryption and self--test function pointers of both ``encrypt only'' descriptors are set to \textbf{NULL} and
+and tables.  The decryption and self--test function pointers of both \textit{encrypt only} descriptors are set to \textbf{NULL} and
 should not be called.
-The ``encrypt only'' descriptors are useful for applications that only use the encryption function of the cipher.  Algorithms such
+The \textit{encrypt only} descriptors are useful for applications that only use the encryption function of the cipher.  Algorithms such
-as EAX, PMAC and OMAC only require the encryption function.  So far this ``encrypt only'' functionality has only been implemented for
+as EAX, PMAC and OMAC only require the encryption function.  So far this \textit{encrypt only} functionality has only been implemented for
 Rijndael as it makes the most sense for this cipher.
 \item
-Note that for ``DES'' and ``3DES'' they use 8 and 24 byte keys but only 7 and 21 [respectively] bytes of the keys are in
+Note that for \textit{DES} and \textit{3DES} they use 8 and 24 byte keys but only 7 and 21 [respectively] bytes of the keys are in
 fact used for the purposes of encryption.  My suggestion is just to use random 8/24 byte keys instead of trying to make a 8/24
 byte string from the real 7/21 byte key.
 \item
-Note that ``Twofish'' has additional configuration options that take place at build time.  These options are found in
+Note that \textit{Twofish} has additional configuration options (Figure \ref{fig:twofishopts}) that take place at build time.  These options are found in
-the file ``tomcrypt\_cfg.h''.  The first option is ``TWOFISH\_SMALL'' which when defined will force the Twofish code
+the file \textit{tomcrypt\_cfg.h}.  The first option is \textit{TWOFISH\_SMALL} which when defined will force the Twofish code
-to not pre-compute the Twofish ``$g(X)$'' function as a set of four $8 \times 32$ s-boxes.  This means that a scheduled
+to not pre-compute the Twofish \textit{$g(X)$} function as a set of four $8 \times 32$ s-boxes.  This means that a scheduled
-key will require less ram but the resulting cipher will be slower.  The second option is ``TWOFISH\_TABLES'' which when
+key will require less ram but the resulting cipher will be slower.  The second option is \textit{TWOFISH\_TABLES} which when
 defined will force the Twofish code to use pre-computed tables for the two s-boxes $q_0, q_1$ as well as the multiplication
 by the polynomials 5B and EF used in the MDS multiplication.  As a result the code is faster and slightly larger.  The
-speed increase is useful when ``TWOFISH\_SMALL'' is defined since the s-boxes and MDS multiply form the heart of the
+speed increase is useful when \textit{TWOFISH\_SMALL} is defined since the s-boxes and MDS multiply form the heart of the
 Twofish round function.
-\index{Twofish build options}
+\begin{figure}[hpbt]
+\index{Twofish build options} \index{TWOFISH\_SMALL} \index{TWOFISH\_TABLES}
 \begin{small}
 \begin{center}
 \begin{tabular}{|l|l|l|}
-\hline TWOFISH\_SMALL & TWOFISH\_TABLES & Speed and Memory (per key) \\
+\hline \textbf{TWOFISH\_SMALL} & \textbf{TWOFISH\_TABLES} & \textbf{Speed and Memory (per key)} \\
 \hline undefined & undefined & Very fast, 4.2KB of ram. \\
-\hline undefined & defined & Faster keysetup, larger code. \\
+\hline undefined & defined & Faster key setup, larger code. \\
 \hline defined & undefined & Very slow, 0.2KB of ram. \\
 \hline defined & defined & Faster, 0.2KB of ram, larger code. \\
 \hline
 \end{tabular}
 \end{center}
 \end{small}
+\caption{Twofish Build Options}
+\label{fig:twofishopts}
+\end{figure}
 \end{enumerate}
 \end{small}
 To work with the cipher\_descriptor array there is a function:
 \index{find\_cipher()}
 \begin{verbatim}
 int find_cipher(char *name)
 \end{verbatim}
-Which will search for a given name in the array.  It returns negative one if the cipher is not found, otherwise it returns
+Which will search for a given name in the array.  It returns $-1$ if the cipher is not found, otherwise it returns
 the location in the array where the cipher was found.  For example, to indirectly setup Blowfish you can also use:
 \begin{small}
+\index{register\_cipher()} \index{find\_cipher()} \index{error\_to\_string()}
 \begin{verbatim}
 #include <tomcrypt.h>
 int main(void)
 {
 unsigned char key[8];
 if (register_cipher(&blowfish_desc)) == -1) {
 printf("Unable to register Blowfish cipher.");
 return -1;
 }
-/* generic call to function (assuming the key in key[] was already setup) */
+/* generic call to function (assuming the key
-if ((err = cipher_descriptor[find_cipher("blowfish")].setup(key, 8, 0, &skey)) !=
+* in key[] was already setup) */
-CRYPT_OK) {
+if ((err =
+cipher_descriptor[find_cipher("blowfish")].
+setup(key, 8, 0, &skey)) != CRYPT_OK) {
 printf("Error setting up Blowfish: %s\n", error_to_string(err));
 return -1;
 }
 /* ... use cipher ... */
 }
 \end{verbatim}
 \end{small}
-A good safety would be to check the return value of ``find\_cipher()'' before accessing the desired function.  In order
+A good safety would be to check the return value of \textit{find\_cipher()} before accessing the desired function.  In order
 to use a cipher with the descriptor table you must register it first using:
 \index{register\_cipher()}
 \begin{verbatim}
 int register_cipher(const struct _cipher_descriptor *cipher);
 \end{verbatim}
 than once it will just return the index of the first copy.  To remove a cipher call:
 \index{unregister\_cipher()}
 \begin{verbatim}
 int unregister_cipher(const struct _cipher_descriptor *cipher);
 \end{verbatim}
-Which returns {\bf CRYPT\_OK} if it removes it otherwise it returns {\bf CRYPT\_ERROR}.  Consider:
+Which returns {\bf CRYPT\_OK} if it removes the cipher, otherwise it returns {\bf CRYPT\_ERROR}.
 \begin{small}
 \begin{verbatim}
 #include <tomcrypt.h>
 int main(void)
 {
 return 0;
 }
 \end{verbatim}
 \end{small}
-This snippet is a small program that registers only Rijndael only.
+This snippet is a small program that registers Rijndael.
-\section{Symmetric Modes of Operations}
+\mysection{Symmetric Modes of Operations}
 \subsection{Background}
 A typical symmetric block cipher can be used in chaining modes to effectively encrypt messages larger than the block
 size of the cipher.  Given a key $k$, a plaintext $P$ and a cipher $E$ we shall denote the encryption of the block
 $P$ under the key $k$ as $E_k(P)$.  In some modes there exists an initial vector denoted as $C_{-1}$.
 \end{enumerate}
 The CTR, CFB and OFB routines provided allow you to encrypt block sizes that differ from the ciphers block size.  They
 accomplish this by buffering the data required to complete a block.  This allows you to encrypt or decrypt any size
 block of memory with either of the three modes.
-The ECB and CBC modes process blocks of the same size as the cipher at a time.  Therefore they are less flexible than the
+The ECB and CBC modes process blocks of the same size as the cipher at a time.  Therefore, they are less flexible than the
 other modes.
+\subsection{Ciphertext Stealing}
+\index{Ciphertext stealing}
+Ciphertext stealing is a method of dealing with messages in CBC mode which are not a multiple of the block length.  This is accomplished
+by encrypting the last ciphertext block in ECB mode, and XOR'ing the output against the last partial block of plaintext.  LibTomCrypt does not
+support this mode directly but it is fairly easy to emulate with a call to the cipher's ecb\_encrypt() callback function.
+The more sane way to deal with partial blocks is to pad them with zeroes, and then use CBC normally.
 \subsection{Initialization}
 \index{CBC Mode} \index{CTR Mode}
 \index{OFB Mode} \index{CFB Mode}
 The library provides simple support routines for handling CBC, CTR, CFB, OFB and ECB encoded messages.  Assuming the mode
-you want is XXX there is a structure called ``symmetric\_XXX'' that will contain the information required to
+you want is XXX there is a structure called \textit{symmetric\_XXX} that will contain the information required to
 use that mode.  They have identical setup routines (except CTR and ECB mode):
 \index{ecb\_start()} \index{cfb\_start()} \index{cbc\_start()} \index{ofb\_start()} \index{ctr\_start()}
 \begin{verbatim}
-int XXX_start(int cipher, const unsigned char *IV,
+int XXX_start(                int  cipher,
-const unsigned char *key, int keylen,
+const unsigned char *IV,
-int num_rounds, symmetric_XXX *XXX);
+const unsigned char *key,
+int  keylen,
-int ctr_start(               int   cipher,
+int  num_rounds,
+symmetric_XXX *XXX);
+int ctr_start(                int  cipher,
 const unsigned char *IV,
-const unsigned char *key,       int keylen,
+const unsigned char *key,
-int  num_rounds, int ctr_mode,
+int  keylen,
-symmetric_CTR *ctr);
+int  num_rounds,
+int  ctr_mode,
-int ecb_start(int cipher, const unsigned char *key, int keylen,
+symmetric_CTR *ctr);
-int num_rounds, symmetric_ECB *ecb);
-\end{verbatim}
+int ecb_start(                int  cipher,
+const unsigned char *key,
-In each case ``cipher'' is the index into the cipher\_descriptor array of the cipher you want to use.  The ``IV'' value is
+int  keylen,
+int  num_rounds,
+symmetric_ECB *ecb);
+\end{verbatim}
+In each case, \textit{cipher} is the index into the cipher\_descriptor array of the cipher you want to use.  The \textit{IV} value is
 the initialization vector to be used with the cipher.  You must fill the IV yourself and it is assumed they are the same
-length as the block size\footnote{In otherwords the size of a block of plaintext for the cipher, e.g. 8 for DES, 16 for AES, etc.}
+length as the block size\footnote{In other words the size of a block of plaintext for the cipher, e.g. 8 for DES, 16 for AES, etc.}
 of the cipher you choose.  It is important that the IV  be random for each unique message you want to encrypt.  The
-parameters ``key'', ``keylen'' and ``num\_rounds'' are the same as in the XXX\_setup() function call.  The final parameter
+parameters \textit{key}, \textit{keylen} and \textit{num\_rounds} are the same as in the XXX\_setup() function call.  The final parameter
 is a pointer to the structure you want to hold the information for the mode of operation.
-In the case of CTR mode there is an additional parameter ``ctr\_mode'' which specifies the mode that the counter is to be used in.
+In the case of CTR mode there is an additional parameter \textit{ctr\_mode} which specifies the mode that the counter is to be used in.
-If \textbf{CTR\_COUNTER\_LITTLE\_ENDIAN} was specified then the counter will be treated as a little endian value.  Otherwise, if
+If \textbf{CTR\_COUNTER\_ LITTLE\_ENDIAN} was specified then the counter will be treated as a little endian value.  Otherwise, if
-\textbf{CTR\_COUNTER\_BIG\_ENDIAN} was specified the counter will be treated as a big endian value.
+\textbf{CTR\_COUNTER\_BIG\_ENDIAN} was specified the counter will be treated as a big endian value.  As of v1.15 the RFC 3686 style of
+increment then encrypt is also supported.  By OR'ing \textbf{LTC\_CTR\_RFC3686} with the CTR \textit{mode} value, ctr\_start() will increment
-The routines return {\bf CRYPT\_OK} if the cipher initialized correctly, otherwise they return an error code.
+the counter before encrypting it for the first time.
+The routines return {\bf CRYPT\_OK} if the cipher initialized correctly, otherwise, they return an error code.
 \subsection{Encryption and Decryption}
 To actually encrypt or decrypt the following routines are provided:
 \index{ecb\_encrypt()} \index{ecb\_decrypt()} \index{cfb\_encrypt()} \index{cfb\_decrypt()}
 \index{cbc\_encrypt()} \index{cbc\_decrypt()} \index{ofb\_encrypt()} \index{ofb\_decrypt()} \index{ctr\_encrypt()} \index{ctr\_decrypt()}
 \begin{verbatim}
-int XXX_encrypt(const unsigned char *pt, unsigned char *ct,
+int XXX_encrypt(const unsigned char *pt,
-unsigned long len, symmetric_YYY *YYY);
+unsigned char *ct,
-int XXX_decrypt(const unsigned char *ct, unsigned char *pt,
+unsigned long  len,
-unsigned long len, symmetric_YYY *YYY);
+symmetric_YYY *YYY);
-\end{verbatim}
-Where ``XXX'' is one of $\lbrace ecb, cbc, ctr, cfb, ofb \rbrace$.
+int XXX_decrypt(const unsigned char *ct,
+unsigned char *pt,
-In all cases ``len'' is the size of the buffer (as number of octets) to encrypt or decrypt.  The CTR, OFB and CFB modes are order sensitive but not
+unsigned long  len,
-chunk sensitive.  That is you can encrypt ``ABCDEF'' in three calls like ``AB'', ``CD'', ``EF'' or two like ``ABCDE'' and ``F''
+symmetric_YYY *YYY);
-and end up with the same ciphertext.  However, encrypting ``ABC'' and ``DABC'' will result in different ciphertexts.  All
+\end{verbatim}
+Where \textit{XXX} is one of $\lbrace ecb, cbc, ctr, cfb, ofb \rbrace$.
+In all cases, \textit{len} is the size of the buffer (as number of octets) to encrypt or decrypt.  The CTR, OFB and CFB modes are order sensitive but not
+chunk sensitive.  That is you can encrypt \textit{ABCDEF} in three calls like \textit{AB}, \textit{CD}, \textit{EF} or two like \textit{ABCDE} and \textit{F}
+and end up with the same ciphertext.  However, encrypting \textit{ABC} and \textit{DABC} will result in different ciphertexts.  All
 five of the modes will return {\bf CRYPT\_OK} on success from the encrypt or decrypt functions.
-In the ECB and CBC cases ``len'' must be a multiple of the ciphers block size.  In the CBC case you must manually pad the end of your message (either with
+In the ECB and CBC cases, \textit{len} must be a multiple of the ciphers block size.  In the CBC case, you must manually pad the end of your message (either with
 zeroes or with whatever your protocol requires).
-To decrypt in either mode you simply perform the setup like before (recall you have to fetch the IV value you used)
+To decrypt in either mode, perform the setup like before (recall you have to fetch the IV value you used), and use the decrypt routine on all of the blocks.
-and use the decrypt routine on all of the blocks.
 \subsection{IV Manipulation}
 To change or read the IV of a previously initialized chaining mode use the following two functions.
 \index{cbc\_setiv()} \index{cbc\_getiv()} \index{ofb\_setiv()} \index{ofb\_getiv()} \index{cfb\_setiv()} \index{cfb\_getiv()}
 \index{ctr\_setiv()} \index{ctr\_getiv()}
 \begin{verbatim}
-int XXX_getiv(unsigned char *IV, unsigned long *len, symmetric_XXX *XXX);
+int XXX_getiv(unsigned char *IV,
-int XXX_setiv(const unsigned char *IV, unsigned long len, symmetric_XXX *XXX);
+unsigned long *len,
-\end{verbatim}
+symmetric_XXX *XXX);
-The XXX\_getiv() functions will read the IV out of the chaining mode and store it into ``IV'' along with the length of the IV
+int XXX_setiv(const unsigned char *IV,
-stored in ``len''.  The XXX\_setiv will initialize the chaining mode state as if the original IV were the new IV specified.  The length
+unsigned long  len,
+symmetric_XXX *XXX);
+\end{verbatim}
+The XXX\_getiv() functions will read the IV out of the chaining mode and store it into \textit{IV} along with the length of the IV
+stored in \textit{len}.  The XXX\_setiv will initialize the chaining mode state as if the original IV were the new IV specified.  The length
 of the IV passed in must be the size of the ciphers block size.
 The XXX\_setiv() functions are handy if you wish to change the IV without re--keying the cipher.
+What the \textit{setiv} function will do depends on the mode being changed.  In CBC mode, the new IV replaces the existing IV as if it
+were the last ciphertext block.  In CFB mode, the IV is encrypted as if it were the prior encrypted pad.  In CTR mode, the IV is encrypted without
+first incrementing it (regardless of the LTC\_RFC\_3686 flag presence).  In F8 mode, the IV is encrypted and becomes the new pad.  It does not change
+the salted IV, and is only meant to allow seeking within a session.  In LRW, it changes the tweak, forcing a computation of the tweak pad, allowing for
+seeking within the session.  In OFB mode, the IV is encrypted and becomes the new pad.
 \subsection{Stream Termination}
 To terminate an open stream call the done function.
 \index{ecb\_done()} \index{cbc\_done()}\index{cfb\_done()}\index{ofb\_done()} \index{ctr\_done()}
 int XXX_done(symmetric_XXX *XXX);
 \end{verbatim}
 This will terminate the stream (by terminating the cipher) and return \textbf{CRYPT\_OK} if successful.
+\newpage
 \subsection{Examples}
-\newpage
 \begin{small}
 \begin{verbatim}
 #include <tomcrypt.h>
 int main(void)
 {
 /* start up CTR mode */
 if ((err = ctr_start(
 find_cipher("twofish"), /* index of desired cipher */
 IV, /* the initial vector */
 key, /* the secret key */
-16, /* length of secret key (16 bytes, 128 bits) */
+16, /* length of secret key (16 bytes) */
 0, /* 0 == default # of rounds */
 CTR_COUNTER_LITTLE_ENDIAN, /* Little endian counter */
-&ctr)  /* where to store initialized CTR state */
+&ctr)  /* where to store the CTR state */
 ) != CRYPT_OK) {
 printf("ctr_start error: %s\n", error_to_string(err));
 return -1;
 }
 /* somehow fill buffer than encrypt it */
 if ((err = ctr_encrypt(        buffer, /* plaintext */
 buffer, /* ciphertext */
-sizeof(buffer), /* length of data to encrypt */
+sizeof(buffer), /* length of plaintext pt */
-&ctr)  /* previously initialized CTR state */
+&ctr)  /* CTR state */
 ) != CRYPT_OK) {
 printf("ctr_encrypt error: %s\n", error_to_string(err));
 return -1;
 }
 return -1;
 }
 if ((err = ctr_decrypt(        buffer, /* ciphertext */
 buffer, /* plaintext */
-sizeof(buffer), /* length of data to encrypt */
+sizeof(buffer), /* length of plaintext */
-&ctr)  /* previously initialized CTR state */
+&ctr)  /* CTR state */
 ) != CRYPT_OK) {
 printf("ctr_decrypt error: %s\n", error_to_string(err));
 return -1;
 }
 return 0;
 }
 \end{verbatim}
 \end{small}
-\section{Encrypt and Authenticate Modes}
+\subsection{LRW Mode}
+LRW mode is a cipher mode which is meant for indexed encryption like used to handle storage media.  It is meant to have efficient seeking and overcome the
+security problems of ECB mode while not increasing the storage requirements.  It is used much like any other chaining mode except with two key differences.
+The key is specified as two strings the first key $K_1$ is the (normally AES) key and can be any length (typically 16, 24 or 32 octets long).  The second key
+$K_2$ is the \textit{tweak} key and is always 16 octets long.  The tweak value is \textbf{NOT} a nonce or IV value it must be random and secret.
+To initialize LRW mode use:
+\index{lrw\_start()}
+\begin{verbatim}
+int lrw_start(                int  cipher,
+const unsigned char *IV,
+const unsigned char *key,
+int  keylen,
+const unsigned char *tweak,
+int  num_rounds,
+symmetric_LRW *lrw);
+\end{verbatim}
+This will initialize the LRW context with the given (16 octet) \textit{IV}, cipher $K_1$ \textit{key} of length \textit{keylen} octets and the (16 octet) $K_2$ \textit{tweak}.
+While LRW was specified to be used only with AES, LibTomCrypt will allow any 128--bit block cipher to be specified as indexed by \textit{cipher}.  The
+number of rounds for the block cipher \textit{num\_rounds} can be 0 to use the default number of rounds for the given cipher.
+To process data use the following functions:
+\index{lrw\_encrypt()} \index{lrw\_decrypt()}
+\begin{verbatim}
+int lrw_encrypt(const unsigned char *pt,
+unsigned char *ct,
+unsigned long  len,
+symmetric_LRW *lrw);
+int lrw_decrypt(const unsigned char *ct,
+unsigned char *pt,
+unsigned long  len,
+symmetric_LRW *lrw);
+\end{verbatim}
+These will encrypt (or decrypt) the plaintext to the ciphertext buffer (or vice versa).  The length is specified by \textit{len} in octets but must be a multiple
+of 16.  The LRW code uses a fast tweak update such that consecutive blocks are encrypted faster than if random seeking where used.
+To manipulate the IV use the following functions:
+\index{lrw\_getiv()} \index{lrw\_setiv()}
+\begin{verbatim}
+int lrw_getiv(unsigned char *IV,
+unsigned long *len,
+symmetric_LRW *lrw);
+int lrw_setiv(const unsigned char *IV,
+unsigned long  len,
+symmetric_LRW *lrw);
+\end{verbatim}
+These will get or set the 16--octet IV.  Note that setting the IV is the same as \textit{seeking} and unlike other modes is not a free operation.  It requires
+updating the entire tweak which is slower than sequential use.  Avoid seeking excessively in performance constrained code.
+To terminate the LRW state use the following:
+\index{lrw\_done()}
+\begin{verbatim}
+int lrw_done(symmetric_LRW *lrw);
+\end{verbatim}
+\subsection{F8 Mode}
+\index{F8 Mode}
+The F8 Chaining mode (see RFC 3711 for instance) is yet another chaining mode for block ciphers.  It behaves much like CTR mode in that it XORs a keystream
+against the plaintext to encrypt.  F8 mode comes with the additional twist that the counter value is secret, encrypted by a \textit{salt key}.  We
+initialize F8 mode with the following function call:
+\index{f8\_start()}
+\begin{verbatim}
+int f8_start(                int  cipher,
+const unsigned char *IV,
+const unsigned char *key,
+int  keylen,
+const unsigned char *salt_key,
+int  skeylen,
+int  num_rounds,
+symmetric_F8 *f8);
+\end{verbatim}
+This will start the F8 mode state using \textit{key} as the secret key, \textit{IV} as the counter.  It uses the \textit{salt\_key} as IV encryption key
+(\textit{m} in the RFC 3711).  The salt\_key can be shorter than the secret key but it should not be longer.
+To encrypt or decrypt data we use the following two functions:
+\index{f8\_encrypt()} \index{f8\_decrypt()}
+\begin{verbatim}
+int f8_encrypt(const unsigned char *pt,
+unsigned char *ct,
+unsigned long  len,
+symmetric_F8 *f8);
+int f8_decrypt(const unsigned char *ct,
+unsigned char *pt,
+unsigned long  len,
+symmetric_F8 *f8);
+\end{verbatim}
+These will encrypt or decrypt a variable length array of bytes using the F8 mode state specified.  The length is specified in bytes and does not have to be a multiple
+of the ciphers block size.
+To change or retrieve the current counter IV value use the following functions:
+\index{f8\_getiv()} \index{f8\_setiv()}
+\begin{verbatim}
+int f8_getiv(unsigned char *IV,
+unsigned long *len,
+symmetric_F8 *f8);
+int f8_setiv(const unsigned char *IV,
+unsigned long  len,
+symmetric_F8 *f8);
+\end{verbatim}
+These work with the current IV value only and not the encrypted IV value specified during the call to f8\_start().  The purpose of these two functions is to be
+able to seek within a current session only.  If you want to change the session IV you will have to call f8\_done() and then start a new state with
+f8\_start().
+To terminate an F8 state call the following function:
+\index{f8\_done()}
+\begin{verbatim}
+int f8_done(symmetric_F8 *f8);
+\end{verbatim}
+\vfil
+\mysection{Encrypt and Authenticate Modes}
 \subsection{EAX Mode}
 LibTomCrypt provides support for a mode called EAX\footnote{See
-M. Bellare, P. Rogaway, D. Wagner, A Conventional Authenticated-Encryption Mode.} in a manner similar to the
+M. Bellare, P. Rogaway, D. Wagner, A Conventional Authenticated-Encryption Mode.} in a manner similar to the way it was intended to be used
-way it was intended to be used by the designers.  First a short description of what EAX mode is before I explain how to use it.
+by the designers.  First, a short description of what EAX mode is before we explain how to use it.  EAX is a mode that requires a cipher,
-EAX is a mode that requires a cipher, CTR and OMAC support and provides encryption and authentication\footnote{Note that since EAX only requires OMAC and CTR you may use ``encrypt only'' cipher descriptors with this mode.}.
+CTR and OMAC support and provides encryption and
-It is initialized with a random ``nonce'' that can be shared publicly as well as a ``header'' which can be fixed and public as well as a random
+authentication\footnote{Note that since EAX only requires OMAC and CTR you may use \textit{encrypt only} cipher descriptors with this mode.}.
-secret symmetric key.
+It is initialized with a random \textit{nonce} that can be shared publicly, a \textit{header} which can be fixed and public, and a random secret symmetric key.
-The ``header'' data is meant to be meta-data associated with a stream that isn't private (e.g. protocol messages).  It can
+The \textit{header} data is meant to be meta--data associated with a stream that isn't private (e.g., protocol messages).  It can
-be added at anytime during an EAX stream and is part of the authentication tag.  That is, changes in the meta-data can
+be added at anytime during an EAX stream, and is part of the authentication tag.  That is, changes in the meta-data can be detected by changes in the output tag.
-be detected by changes in the output tag.
 The mode can then process plaintext producing ciphertext as well as compute a partial checksum.  The actual checksum
-called a ``tag'' is only emitted when the message is finished.  In the interim though the user can process any arbitrary
+called a \textit{tag} is only emitted when the message is finished.  In the interim, the user can process any arbitrary
 sized message block to send to the recipient as ciphertext.  This makes the EAX mode especially suited for streaming modes
 of operation.
 The mode is initialized with the following function.
 \index{eax\_init()}
 \begin{verbatim}
-int eax_init(eax_state *eax, int cipher,
+int eax_init(          eax_state *eax,
-const unsigned char *key, unsigned long keylen,
+int  cipher,
-const unsigned char *nonce, unsigned long noncelen,
+const unsigned char *key,
-const unsigned char *header, unsigned long headerlen);
+unsigned long  keylen,
-\end{verbatim}
+const unsigned char *nonce,
+unsigned long  noncelen,
-Where ``eax'' is the EAX state.  ``cipher'' is the index of the desired cipher in the descriptor table.
+const unsigned char *header,
-``key'' is the shared secret symmetric key of length ``keylen''.  ``nonce'' is the random public string of
+unsigned long  headerlen);
-length ``noncelen''.  ``header'' is the random (or fixed or \textbf{NULL}) header for the message of length
+\end{verbatim}
-``headerlen''.
+Where \textit{eax} is the EAX state.  The \textit{cipher} parameter is the index of the desired cipher in the descriptor table.
-When this function completes ``eax'' will be initialized such that you can now either have data decrypted or
+The \textit{key} parameter is the shared secret symmetric key of length \textit{keylen} octets.  The \textit{nonce} parameter is the
-encrypted in EAX mode.  Note that if ``headerlen'' is zero you may pass ``header'' as \textbf{NULL} to indicate
+random public string of length \textit{noncelen} octets.  The \textit{header} parameter is the random (or fixed or \textbf{NULL}) header for the
-there is no initial header data.
+message of length \textit{headerlen} octets.
+When this function completes, the \textit{eax} state will be initialized such that you can now either have data decrypted or
+encrypted in EAX mode.  Note: if \textit{headerlen} is zero you may pass \textit{header} as \textbf{NULL} to indicate there is no initial header data.
 To encrypt or decrypt data in a streaming mode use the following.
 \index{eax\_encrypt()} \index{eax\_decrypt()}
 \begin{verbatim}
-int eax_encrypt(eax_state *eax, const unsigned char *pt,
+int eax_encrypt(          eax_state *eax,
-unsigned char *ct, unsigned long length);
+const unsigned char *pt,
+unsigned char *ct,
-int eax_decrypt(eax_state *eax, const unsigned char *ct,
+unsigned long  length);
-unsigned char *pt, unsigned long length);
-\end{verbatim}
+int eax_decrypt(          eax_state *eax,
-The function ``eax\_encrypt'' will encrypt the bytes in ``pt'' of ``length'' bytes and store the ciphertext in
+const unsigned char *ct,
-``ct''.  Note that ``ct'' and ``pt'' may be the same region in memory.   This function will also send the ciphertext
+unsigned char *pt,
-through the OMAC function.  The function ``eax\_decrypt'' decrypts ``ct'' and stores it in ``pt''.  This also allows
+unsigned long  length);
-``pt'' and ``ct'' to be the same region in memory.
+\end{verbatim}
+The function \textit{eax\_encrypt} will encrypt the bytes in \textit{pt} of \textit{length} octets, and store the ciphertext in
-You cannot both encrypt or decrypt with the same ``eax'' context.  For bi-directional communication you
+\textit{ct}.  Note: \textit{ct} and \textit{pt} may be the same region in memory.   This function will also send the ciphertext
-will need to initialize two EAX contexts (preferably with different headers and nonces).
+through the OMAC function.  The function \textit{eax\_decrypt} decrypts \textit{ct}, and stores it in \textit{pt}.  This also allows
+\textit{pt} and \textit{ct} to be the same region in memory.
-Note that both of these functions allow you to send the data in any granularity but the order is important.  While
+You cannot both encrypt or decrypt with the same \textit{eax} context.  For bi--directional communication you will need to initialize
+two EAX contexts (preferably with different headers and nonces).
+Note: both of these functions allow you to send the data in any granularity but the order is important.  While
 the eax\_init() function allows you to add initial header data to the stream you can also add header data during the
 EAX stream with the following.
 \index{eax\_addheader()}
 \begin{verbatim}
-int eax_addheader(eax_state *eax,
+int eax_addheader(          eax_state *eax,
-const unsigned char *header, unsigned long length);
+const unsigned char *header,
-\end{verbatim}
+unsigned long  length);
+\end{verbatim}
-This will add the ``length'' bytes from ``header'' to the given ``eax'' stream.  Once the message is finished the
+This will add the \textit{length} octet from \textit{header} to the given \textit{eax} header.  Once the message is finished, the
-``tag'' (checksum) may be computed with the following function.
+\textit{tag} (checksum) may be computed with the following function:
 \index{eax\_done()}
 \begin{verbatim}
-int eax_done(eax_state *eax,
+int eax_done(    eax_state *eax,
-unsigned char *tag, unsigned long *taglen);
+unsigned char *tag,
-\end{verbatim}
+unsigned long *taglen);
-This will terminate the EAX state ``eax'' and store upto ``taglen'' bytes of the message tag in ``tag''.  The function
+\end{verbatim}
-then stores how many bytes of the tag were written out back into ``taglen''.
+This will terminate the EAX state \textit{eax}, and store up to \textit{taglen} bytes of the message tag in \textit{tag}.  The function
+then stores how many bytes of the tag were written out back in to \textit{taglen}.
-The EAX mode code can be tested to ensure it matches the test vectors by calling the following function.
+The EAX mode code can be tested to ensure it matches the test vectors by calling the following function:
 \index{eax\_test()}
 \begin{verbatim}
 int eax_test(void);
 \end{verbatim}
 This requires that the AES (or Rijndael) block cipher be registered with the cipher\_descriptor table first.
 }
 /* ... make up random nonce and key ... */
 /* initialize context */
-if ((err = eax_init(            &eax,  /* the context */
+if ((err = eax_init(            &eax,  /* context */
-find_cipher("rijndael"),  /* cipher we want to use */
+find_cipher("rijndael"),  /* cipher id */
-nonce,  /* our state nonce */
+nonce,  /* the nonce */
-16,  /* none is 16 bytes */
+16,  /* nonce is 16 bytes */
-"TestApp",  /* example header, identifies this program */
+"TestApp",  /* example header */
-7)  /* length of the header */
+7)  /* header length */
 ) != CRYPT_OK) {
 printf("Error eax_init: %s", error_to_string(err));
 return EXIT_FAILURE;
 }
 /* now encrypt data, say in a loop or whatever */
-if ((err = eax_encrypt(     &eax,      /* eax context */
+if ((err = eax_encrypt(     &eax, /* eax context */
-pt,      /* plaintext  (source) */
+pt, /* plaintext  (source) */
-ct,      /* ciphertext (destination) */
+ct, /* ciphertext (destination) */
-sizeof(pt)      /* size of plaintext */
+sizeof(pt) /* size of plaintext */
 ) != CRYPT_OK) {
 printf("Error eax_encrypt: %s", error_to_string(err));
 return EXIT_FAILURE;
 }
 /* finish message and get authentication tag */
 taglen = sizeof(tag);
-if ((err = eax_done(   &eax,           /* eax context */
+if ((err = eax_done(   &eax,      /* eax context */
-tag,           /* where to put tag */
+tag,      /* where to put tag */
-&taglen            /* length of tag space */
+&taglen       /* length of tag space */
 ) != CRYPT_OK) {
 printf("Error eax_done: %s", error_to_string(err));
 return EXIT_FAILURE;
 }
-/* now we have the authentication tag in "tag" and it's taglen bytes long */
+/* now we have the authentication tag in "tag" and
+* it's taglen bytes long */
 }
 \end{verbatim}
 You can also perform an entire EAX state on a block of memory in a single function call with the
 following functions.
 \index{eax\_encrypt\_authenticate\_memory} \index{eax\_decrypt\_verify\_memory}
 \begin{verbatim}
-int eax_encrypt_authenticate_memory(int cipher,
+int eax_encrypt_authenticate_memory(
+int  cipher,
 const unsigned char *key,    unsigned long keylen,
 const unsigned char *nonce,  unsigned long noncelen,
 const unsigned char *header, unsigned long headerlen,
 const unsigned char *pt,     unsigned long ptlen,
 unsigned char *ct,
 unsigned char *tag,    unsigned long *taglen);
-int eax_decrypt_verify_memory(int cipher,
+int eax_decrypt_verify_memory(
+int  cipher,
 const unsigned char *key,    unsigned long keylen,
 const unsigned char *nonce,  unsigned long noncelen,
 const unsigned char *header, unsigned long headerlen,
 const unsigned char *ct,     unsigned long ctlen,
 unsigned char *pt,
 Both essentially just call eax\_init() followed by eax\_encrypt() (or eax\_decrypt() respectively) and eax\_done().  The parameters
 have the same meaning as with those respective functions.
 The only difference is eax\_decrypt\_verify\_memory() does not emit a tag.  Instead you pass it a tag as input and it compares it against
-the tag it computed while decrypting the message.  If the tags match then it stores a $1$ in ``res'', otherwise it stores a $0$.
+the tag it computed while decrypting the message.  If the tags match then it stores a $1$ in \textit{res}, otherwise it stores a $0$.
 \subsection{OCB Mode}
 LibTomCrypt provides support for a mode called OCB\footnote{See
-P. Rogaway, M. Bellare, J. Black, T. Krovetz, ``OCB: A Block Cipher Mode of Operation for Efficient Authenticated Encryption''.}
+P. Rogaway, M. Bellare, J. Black, T. Krovetz, \textit{OCB: A Block Cipher Mode of Operation for Efficient Authenticated Encryption}.}
 .  OCB is an encryption protocol that simultaneously provides authentication.  It is slightly faster to use than EAX mode
 but is less flexible.  Let's review how to initialize an OCB context.
 \index{ocb\_init()}
 \begin{verbatim}
-int ocb_init(ocb_state *ocb, int cipher,
+int ocb_init(          ocb_state *ocb,
-const unsigned char *key, unsigned long keylen,
+int  cipher,
+const unsigned char *key,
+unsigned long  keylen,
 const unsigned char *nonce);
 \end{verbatim}
-This will initialize the ``ocb'' context using cipher descriptor ``cipher''.  It will use a ``key'' of length ``keylen''
+This will initialize the \textit{ocb} context using cipher descriptor \textit{cipher}.  It will use a \textit{key} of length \textit{keylen}
-and the random ``nonce''.  Note that ``nonce'' must be a random (public) string the same length as the block ciphers
+and the random \textit{nonce}.  Note that \textit{nonce} must be a random (public) string the same length as the block ciphers
 block size (e.g. 16 bytes for AES).
-This mode has no ``Associated Data'' like EAX mode does which means you cannot authenticate metadata along with the stream.
+This mode has no \textit{Associated Data} like EAX mode does which means you cannot authenticate metadata along with the stream.
 To encrypt or decrypt data use the following.
 \index{ocb\_encrypt()} \index{ocb\_decrypt()}
 \begin{verbatim}
-int ocb_encrypt(ocb_state *ocb, const unsigned char *pt, unsigned char *ct);
+int ocb_encrypt(          ocb_state *ocb,
-int ocb_decrypt(ocb_state *ocb, const unsigned char *ct, unsigned char *pt);
+const unsigned char *pt,
-\end{verbatim}
+unsigned char *ct);
-This will encrypt (or decrypt for the latter) a fixed length of data from ``pt'' to ``ct'' (vice versa for the latter).
+int ocb_decrypt(          ocb_state *ocb,
-They assume that ``pt'' and ``ct'' are the same size as the block cipher's block size.  Note that you cannot call
+const unsigned char *ct,
-both functions given a single ``ocb'' state.  For bi-directional communication you will have to initialize two ``ocb''
+unsigned char *pt);
-states (with different nonces).  Also ``pt'' and ``ct'' may point to the same location in memory.
+\end{verbatim}
+This will encrypt (or decrypt for the latter) a fixed length of data from \textit{pt} to \textit{ct} (vice versa for the latter).
+They assume that \textit{pt} and \textit{ct} are the same size as the block cipher's block size.  Note that you cannot call
+both functions given a single \textit{ocb} state.  For bi-directional communication you will have to initialize two \textit{ocb}
+states (with different nonces).  Also \textit{pt} and \textit{ct} may point to the same location in memory.
 \subsubsection{State Termination}
 When you are finished encrypting the message you call the following function to compute the tag.
 \index{ocb\_done\_encrypt()}
 \begin{verbatim}
-int ocb_done_encrypt(ocb_state *ocb,
+int ocb_done_encrypt(          ocb_state *ocb,
-const unsigned char *pt, unsigned long ptlen,
+const unsigned char *pt,
+unsigned long  ptlen,
 unsigned char *ct,
-unsigned char *tag, unsigned long *taglen);
+unsigned char *tag,
-\end{verbatim}
+unsigned long *taglen);
+\end{verbatim}
-This will terminate an encrypt stream ``ocb''.  If you have trailing bytes of plaintext that will not complete a block
-you can pass them here.  This will also encrypt the ``ptlen'' bytes in ``pt'' and store them in ``ct''.  It will also
+This will terminate an encrypt stream \textit{ocb}.  If you have trailing bytes of plaintext that will not complete a block
-store upto ``taglen'' bytes of the tag into ``tag''.
+you can pass them here.  This will also encrypt the \textit{ptlen} bytes in \textit{pt} and store them in \textit{ct}.  It will also
+store up to \textit{taglen} bytes of the tag into \textit{tag}.
-Note that ``ptlen'' must be less than or equal to the block size of block cipher chosen.  Also note that if you have
+Note that \textit{ptlen} must be less than or equal to the block size of block cipher chosen.  Also note that if you have
 an input message equal to the length of the block size then you pass the data here (not to ocb\_encrypt()) only.
 To terminate a decrypt stream and compared the tag you call the following.
 \index{ocb\_done\_decrypt()}
 \begin{verbatim}
-int ocb_done_decrypt(ocb_state *ocb,
+int ocb_done_decrypt(          ocb_state *ocb,
-const unsigned char *ct,  unsigned long ctlen,
+const unsigned char *ct,
+unsigned long  ctlen,
 unsigned char *pt,
-const unsigned char *tag, unsigned long taglen,
+const unsigned char *tag,
-int *res);
+unsigned long  taglen,
-\end{verbatim}
+int *res);
+\end{verbatim}
 Similarly to the previous function you can pass trailing message bytes into this function.  This will compute the
-tag of the message (internally) and then compare it against the ``taglen'' bytes of ``tag'' provided.  By default
+tag of the message (internally) and then compare it against the \textit{taglen} bytes of \textit{tag} provided.  By default
-``res'' is set to zero.  If all ``taglen'' bytes of ``tag'' can be verified then ``res'' is set to one (authenticated
+\textit{res} is set to zero.  If all \textit{taglen} bytes of \textit{tag} can be verified then \textit{res} is set to one (authenticated
 message).
 \subsubsection{Packet Functions}
 To make life simpler the following two functions are provided for memory bound OCB.
-\index{ocb\_encrypt\_authenticate\_memory()}
+%\index{ocb\_encrypt\_authenticate\_memory()}
 \begin{verbatim}
-int ocb_encrypt_authenticate_memory(int cipher,
+int ocb_encrypt_authenticate_memory(
+int  cipher,
 const unsigned char *key,    unsigned long keylen,
 const unsigned char *nonce,
 const unsigned char *pt,     unsigned long ptlen,
 unsigned char *ct,
 unsigned char *tag,    unsigned long *taglen);
 \end{verbatim}
-This will OCB encrypt the message ``pt'' of length ``ptlen'' and store the ciphertext in ``ct''.  The length ``ptlen''
+This will OCB encrypt the message \textit{pt} of length \textit{ptlen}, and store the ciphertext in \textit{ct}.  The length \textit{ptlen}
 can be any arbitrary length.
 \index{ocb\_decrypt\_verify\_memory()}
 \begin{verbatim}
-int ocb_decrypt_verify_memory(int cipher,
+int ocb_decrypt_verify_memory(
+int  cipher,
 const unsigned char *key,    unsigned long keylen,
 const unsigned char *nonce,
 const unsigned char *ct,     unsigned long ctlen,
 unsigned char *pt,
 const unsigned char *tag,    unsigned long taglen,
 int           *res);
 \end{verbatim}
-Similarly this will OCB decrypt and compare the internally computed tag against the tag provided. ``res'' is set
+Similarly, this will OCB decrypt, and compare the internally computed tag against the tag provided. \textit{res} is set
 appropriately.
 \subsection{CCM Mode}
-CCM is a NIST proposal for Encrypt+Authenticate that is centered around using AES (or any 16--byte cipher) as a primitive.  Unlike EAX and OCB mode
+CCM is a NIST proposal for encrypt + authenticate that is centered around using AES (or any 16--byte cipher) as a primitive.  Unlike EAX and OCB mode,
-it is only meant for ``packet'' mode where the length of the input is known in advance.  Since it is a packet mode function CCM only has one
+it is only meant for \textit{packet} mode where the length of the input is known in advance.  Since it is a packet mode function, CCM only has one
 function that performs the protocol.
 \index{ccm\_memory()}
 \begin{verbatim}
-int ccm_memory(int cipher,
+int ccm_memory(
+int  cipher,
 const unsigned char *key,    unsigned long keylen,
+symmetric_key       *uskey,
 const unsigned char *nonce,  unsigned long noncelen,
 const unsigned char *header, unsigned long headerlen,
 unsigned char *pt,     unsigned long ptlen,
 unsigned char *ct,
 unsigned char *tag,    unsigned long *taglen,
 int  direction);
 \end{verbatim}
-This performs the ``CCM'' operation on the data.  The ``cipher'' variable indicates which cipher in the descriptor table to use.  It must have a
+This performs the \textit{CCM} operation on the data.  The \textit{cipher} variable indicates which cipher in the descriptor table to use.  It must have a
-16--byte block size for CCM.  The key is ``key'' with a length of ``keylen'' octets.  The nonce or salt is ``nonce'' of
+16--byte block size for CCM.
-length ``noncelen'' octets.  The header is meta--data you want to send with the message but not have encrypted, it is stored in ``header''
-of length ``headerlen'' octets.  The header can be zero octets long (if $headerlen = 0$ then you can pass ``header'' as \textbf{NULL}).
+The key can be specified in one of two fashions.  First, it can be passed as an array of octets in \textit{key} of length \textit{keylen}.  Alternatively,
+it can be passed in as a previously scheduled key in \textit{uskey}.  The latter fashion saves time when the same key is used for multiple packets.  If
-The plaintext is stored in ``pt'' and the ciphertext in ``ct''.  The length of both are expected to be equal and is passed in as ``ptlen''.  It is
+\textit{uskey} is not \textbf{NULL}, then \textit{key} may be \textbf{NULL} (and vice-versa).
-allowable that $pt = ct$.  The ``direction'' variable indicates whether encryption (direction $=$ \textbf{CCM\_ENCRYPT}) or
+The nonce or salt is \textit{nonce} of length \textit{noncelen} octets.  The header is meta--data you want to send with the message but not have
+encrypted, it is stored in \textit{header} of length \textit{headerlen} octets.  The header can be zero octets long (if $headerlen = 0$ then
+you can pass \textit{header} as \textbf{NULL}).
+The plaintext is stored in \textit{pt}, and the ciphertext in \textit{ct}.  The length of both are expected to be equal and is passed in as \textit{ptlen}.  It is
+allowable that $pt = ct$.  The \textit{direction} variable indicates whether encryption (direction $=$ \textbf{CCM\_ENCRYPT}) or
 decryption (direction $=$ \textbf{CCM\_DECRYPT}) is to be performed.
-As implemented this copy of CCM cannot handle a header or plaintext longer than $2^{32} - 1$ octets long.
+As implemented, this version of CCM cannot handle header or plaintext data longer than $2^{32} - 1$ octets long.
 You can test the implementation of CCM with the following function.
 \index{ccm\_test()}
 \begin{verbatim}
 int ccm_test(void);
 \end{verbatim}
-This will return \textbf{CRYPT\_OK} if the CCM routine passes known test vectors.
+This will return \textbf{CRYPT\_OK} if the CCM routine passes known test vectors.  It requires AES or Rijndael to be registered previously, otherwise it will
+return \textbf{CRYPT\_NOP}.
+\subsubsection{CCM Example}
+The following is a sample of how to call CCM.
+\begin{small}
+\begin{verbatim}
+#include <tomcrypt.h>
+int main(void)
+{
+unsigned char key[16], nonce[12], pt[32], ct[32],
+tag[16], tagcp[16];
+unsigned long taglen;
+int           err;
+/* register cipher */
+register_cipher(&aes_desc);
+/* somehow fill key, nonce, pt */
+/* encrypt it */
+taglen = sizeof(tag);
+if ((err =
+ccm_memory(find_cipher("aes"),
+key, 16,    /* 128-bit key */
+NULL,       /* not prescheduled */
+nonce, 12,  /* 96-bit nonce */
+NULL, 0,    /* no header */
+pt, 32,     /* 32-byte plaintext */
+ct,         /* ciphertext */
+tag, &taglen,
+CCM_ENCRYPT)) != CRYPT_OK) {
+printf("ccm_memory error %s\n", error_to_string(err));
+return -1;
+}
+/* ct[0..31] and tag[0..15] now hold the output */
+/* decrypt it */
+taglen = sizeof(tagcp);
+if ((err =
+ccm_memory(find_cipher("aes"),
+key, 16,    /* 128-bit key */
+NULL,       /* not prescheduled */
+nonce, 12,  /* 96-bit nonce */
+NULL, 0,    /* no header */
+ct, 32,     /* 32-byte ciphertext */
+pt,         /* plaintext */
+tagcp, &taglen,
+CCM_DECRYPT)) != CRYPT_OK) {
+printf("ccm_memory error %s\n", error_to_string(err));
+return -1;
+}
+/* now pt[0..31] should hold the original plaintext,
+tagcp[0..15] and tag[0..15] should have the same contents */
+}
+\end{verbatim}
+\end{small}
 \subsection{GCM Mode}
-Galois counter mode is an IEEE proposal for authenticated encryption.  Like EAX and OCB it can be used in a streaming capacity however, unlike EAX it cannot
+Galois counter mode is an IEEE proposal for authenticated encryption (also it is a planned NIST standard).  Like EAX and OCB mode, it can be used in a streaming capacity
-accept ``additional authentication data'' (meta--data) after plaintext has been processed.  This mode also only works with block ciphers with a sixteen
+however, unlike EAX it cannot accept \textit{additional authentication data} (meta--data) after plaintext has been processed.  This mode also only works with
-byte block.
+block ciphers with a 16--byte block.
-A GCM stream is meant to be processed in three modes each one sequential serial.  First the initial vector (per session) data is processed.  This should be
+A GCM stream is meant to be processed in three modes, one after another.  First, the initial vector (per session) data is processed.  This should be
-unique to every session.  Next the the optional additional authentication data is processed and finally the plaintext.
+unique to every session.  Next, the the optional additional authentication data is processed, and finally the plaintext (or ciphertext depending on the direction).
 \subsubsection{Initialization}
 To initialize the GCM context with a secret key call the following function.
 \index{gcm\_init()}
 \begin{verbatim}
-int gcm_init(gcm_state *gcm, int cipher,
+int gcm_init(          gcm_state *gcm,
-const unsigned char *key, int keylen);
+int  cipher,
-\end{verbatim}
+const unsigned char *key,
-This initializes the GCM state ``gcm'' for the given cipher indexed by ``cipher'' with a secret key ``key'' of length ``keylen'' octets.  The cipher chosen
+int  keylen);
-must have a 16--byte block size (e.g. AES).
+\end{verbatim}
+This initializes the GCM state \textit{gcm} for the given cipher indexed by \textit{cipher}, with a secret key \textit{key} of length \textit{keylen} octets.  The cipher
+chosen must have a 16--byte block size (e.g., AES).
 \subsubsection{Initial Vector}
 After the state has been initialized (or reset) the next step is to add the session (or packet) initial vector.  It should be unique per packet encrypted.
 \index{gcm\_add\_iv()}
 \begin{verbatim}
-int gcm_add_iv(gcm_state *gcm,
+int gcm_add_iv(          gcm_state *gcm,
-const unsigned char *IV,     unsigned long IVlen);
+const unsigned char *IV,
-\end{verbatim}
+unsigned long  IVlen);
+\end{verbatim}
-This adds the initial vector octets from ``IV'' of length ``IVlen'' to the GCM state ``gcm''.  You can call this function as many times as required
+This adds the initial vector octets from \textit{IV} of length \textit{IVlen} to the GCM state \textit{gcm}.  You can call this function as many times as required
 to process the entire IV.
-Note that the GCM protocols provides a ``shortcut'' for 12--byte IVs where no preprocessing is to be done.  If you want to minimize per packet latency it's ideal
+Note: the GCM protocols provides a \textit{shortcut} for 12--byte IVs where no pre-processing is to be done.  If you want to minimize per packet latency it is ideal
-to only use 12--byte IVs.  You can just increment it like a counter for each packet and the CTR [privacy] will be ensured.
+to only use 12--byte IVs.  You can just increment it like a counter for each packet.
 \subsubsection{Additional Authentication Data}
-After the entire IV has been processed the additional authentication data can be processed.  Unlike the IV a packet/session does not require additional
+After the entire IV has been processed, the additional authentication data can be processed.  Unlike the IV, a packet/session does not require additional
-authentication data (AAD) for security.  The AAD is meant to be used as side--channel data you want to be authenticated with the packet.  Note that once
+authentication data (AAD) for security.  The AAD is meant to be used as side--channel data you want to be authenticated with the packet.  Note:  once
-you begin adding AAD to the GCM state you cannot return to adding IV data until the state is reset.
+you begin adding AAD to the GCM state you cannot return to adding IV data until the state has been reset.
 \index{gcm\_add\_aad()}
 \begin{verbatim}
-int gcm_add_aad(gcm_state *gcm,
+int gcm_add_aad(          gcm_state *gcm,
-const unsigned char *adata,     unsigned long adatalen);
+const unsigned char *adata,
-\end{verbatim}
+unsigned long  adatalen);
-This adds the additional authentication data ``adata'' of length ``adatalen'' to the GCM state ``gcm''.
+\end{verbatim}
+This adds the additional authentication data \textit{adata} of length \textit{adatalen} to the GCM state \textit{gcm}.
 \subsubsection{Plaintext Processing}
-After the AAD has been processed the plaintext (or ciphertext depending on the direction) can be processed.
+After the AAD has been processed, the plaintext (or ciphertext depending on the direction) can be processed.
 \index{gcm\_process()}
 \begin{verbatim}
-int gcm_process(gcm_state *gcm,
+int gcm_process(    gcm_state *gcm,
-unsigned char *pt,     unsigned long ptlen,
+unsigned char *pt,
-unsigned char *ct,
+unsigned long  ptlen,
-int direction);
+unsigned char *ct,
-\end{verbatim}
+int  direction);
-This processes message data where ``pt'' is the plaintext and ``ct'' is the ciphertext.  The length of both are equal and stored in ``ptlen''.  Depending on the
+\end{verbatim}
-mode ``pt'' is the input and ``ct'' is the output (or vice versa).  When ``direction'' equals \textbf{GCM\_ENCRYPT} the plaintext is read, encrypted and stored
+This processes message data where \textit{pt} is the plaintext and \textit{ct} is the ciphertext.  The length of both are equal and stored in \textit{ptlen}.  Depending on
-in the ciphertext buffer.  When ``direction'' equals \textbf{GCM\_DECRYPT} the opposite occurs.
+the mode \textit{pt} is the input and \textit{ct} is the output (or vice versa).  When \textit{direction} equals \textbf{GCM\_ENCRYPT} the plaintext is read,
+encrypted and stored in the ciphertext buffer.  When \textit{direction} equals \textbf{GCM\_DECRYPT} the opposite occurs.
 \subsubsection{State Termination}
 To terminate a GCM state and retrieve the message authentication tag call the following function.
 \index{gcm\_done()}
 \begin{verbatim}
-int gcm_done(gcm_state *gcm,
+int gcm_done(    gcm_state *gcm,
-unsigned char *tag,    unsigned long *taglen);
+unsigned char *tag,
-\end{verbatim}
+unsigned long *taglen);
-This terminates the GCM state ``gcm'' and stores the tag in ``tag'' of length ``taglen'' octets.
+\end{verbatim}
+This terminates the GCM state \textit{gcm} and stores the tag in \textit{tag} of length \textit{taglen} octets.
 \subsubsection{State Reset}
 The call to gcm\_init() will perform considerable pre--computation (when \textbf{GCM\_TABLES} is defined) and if you're going to be dealing with a lot of packets
-it is very costly to have to call it repeatedly.  To aid in this endeavour the reset function has been provided.
+it is very costly to have to call it repeatedly.  To aid in this endeavour, the reset function has been provided.
 \index{gcm\_reset()}
 \begin{verbatim}
 int gcm_reset(gcm_state *gcm);
 \end{verbatim}
-This will reset the GCM state ``gcm'' to the state that gcm\_init() left it.  The user would then call gcm\_add\_iv(), gcm\_add\_aad(), etc.
+This will reset the GCM state \textit{gcm} to the state that gcm\_init() left it.  The user would then call gcm\_add\_iv(), gcm\_add\_aad(), etc.
 \subsubsection{One--Shot Packet}
 To process a single packet under any given key the following helper function can be used.
 \index{gcm\_memory()}
 \begin{verbatim}
-int gcm_memory(      int           cipher,
+int gcm_memory(
-const unsigned char *key,    unsigned long keylen,
+int  cipher,
-const unsigned char *IV,     unsigned long IVlen,
+const unsigned char *key,
-const unsigned char *adata,  unsigned long adatalen,
+unsigned long keylen,
-unsigned char *pt,     unsigned long ptlen,
+const unsigned char *IV,    unsigned long IVlen,
-unsigned char *ct,
+const unsigned char *adata, unsigned long adatalen,
-unsigned char *tag,    unsigned long *taglen,
+unsigned char *pt,    unsigned long ptlen,
-int direction);
+unsigned char *ct,
+unsigned char *tag,   unsigned long *taglen,
+int  direction);
 \end{verbatim}
 This will initialize the GCM state with the given key, IV and AAD value then proceed to encrypt or decrypt the message text and store the final
 message tag.  The definition of the variables is the same as it is for all the manual functions.
 if ((err = gcm_add_aad(gcm, aad, aadlen)) != CRYPT_OK) {
 return err;
 }
 /* process the plaintext */
-if ((err = gcm_process(gcm, pt, ptlen, pt, GCM_ENCRYPT)) != CRYPT_OK) {
+if ((err =
+gcm_process(gcm, pt, ptlen, pt, GCM_ENCRYPT)) != CRYPT_OK) {
 return err;
 }
 /* Finish up and get the MAC tag */
 taglen = sizeof(tag);
 return err;
 }
 /* ... send a header describing the lengths ... */
-/* depending on the protocol and how IV is generated you may have to send it too... */
+/* depending on the protocol and how IV is
+* generated you may have to send it too... */
 send(socket, iv, ivlen, 0);
 /* send the aad */
 send(socket, aad, aadlen, 0);
 /* register AES */
 register_cipher(&aes_desc);
 /* init the GCM state */
-if ((err = gcm_init(&gcm, find_cipher("aes"), key, 16)) != CRYPT_OK) {
+if ((err =
+gcm_init(&gcm, find_cipher("aes"), key, 16)) != CRYPT_OK) {
 whine_and_pout(err);
 }
 /* handle us some packets */
 for (;;) {
 if (++IV[x]) {
 break;
 }
 }
-if ((err = send_packet(pt, ptlen, iv, 12, NULL, 0, &gcm)) != CRYPT_OK) {
+if ((err = send_packet(pt, ptlen, iv, 12, NULL, 0, &gcm))
+!= CRYPT_OK) {
 whine_and_pout(err);
 }
 }
 return EXIT_SUCCESS;
 }
 \end{verbatim}
 \end{small}
 \chapter{One-Way Cryptographic Hash Functions}
-\section{Core Functions}
+\mysection{Core Functions}
+Like the ciphers, there are hash core functions and a universal data type to hold the hash state called \textit{hash\_state}.  To initialize hash
-Like the ciphers there are hash core functions and a universal data type to hold the hash state called ``hash\_state''.
+XXX (where XXX is the name) call:
-To initialize hash XXX (where XXX is the name) call:
 \index{Hash Functions}
 \begin{verbatim}
 void XXX_init(hash_state *md);
 \end{verbatim}
-This simply sets up the hash to the default state governed by the specifications of the hash.  To add data to the
+This simply sets up the hash to the default state governed by the specifications of the hash.  To add data to the message being hashed call:
-message being hashed call:
+\begin{verbatim}
-\begin{verbatim}
+int XXX_process(         hash_state *md,
-int XXX_process(hash_state *md, const unsigned char *in, unsigned long inlen);
+const unsigned char *in,
-\end{verbatim}
+unsigned long  inlen);
+\end{verbatim}
 Essentially all hash messages are virtually infinitely\footnote{Most hashes are limited to $2^{64}$ bits or 2,305,843,009,213,693,952 bytes.} long message which
-are buffered.  The data can be passed in any sized chunks as long as the order of the bytes are the same the message digest
+are buffered.  The data can be passed in any sized chunks as long as the order of the bytes are the same the message digest (hash output) will be the same.  For example,
-(hash output) will be the same.  For example, this means that:
+this means that:
 \begin{verbatim}
 md5_process(&md, "hello ", 6);
 md5_process(&md, "world", 5);
 \end{verbatim}
 Will produce the same message digest as the single call:
 md5_process(&md, "hello world", 11);
 \end{verbatim}
 To finally get the message digest (the hash) call:
 \begin{verbatim}
-int XXX_done(hash_state *md,
+int XXX_done(   hash_state *md,
 unsigned char *out);
 \end{verbatim}
-This function will finish up the hash and store the result in the ``out'' array.  You must ensure that ``out'' is long
+This function will finish up the hash and store the result in the \textit{out} array.  You must ensure that \textit{out} is long
-enough for the hash in question.  Often hashes are used to get keys for symmetric ciphers so the ``XXX\_done()'' functions
+enough for the hash in question.  Often hashes are used to get keys for symmetric ciphers so the \textit{XXX\_done()} functions
-will wipe the ``md'' variable before returning automatically.
+will wipe the \textit{md} variable before returning automatically.
 To test a hash function call:
 \begin{verbatim}
 int XXX_test(void);
 \end{verbatim}
-This will return {\bf CRYPTO\_OK} if the hash matches the test vectors, otherwise it returns an error code.  An
+This will return {\bf CRYPT\_OK} if the hash matches the test vectors, otherwise it returns an error code.  An
 example snippet that hashes a message with md5 is given below.
 \begin{small}
 \begin{verbatim}
 #include <tomcrypt.h>
 int main(void)
 return 0;
 }
 \end{verbatim}
 \end{small}
-\section{Hash Descriptors}
+\mysection{Hash Descriptors}
-Like the set of ciphers the set of hashes have descriptors too.  They are stored in an array called ``hash\_descriptor'' and
+Like the set of ciphers, the set of hashes have descriptors as well.  They are stored in an array called \textit{hash\_descriptor} and
 are defined by:
 \begin{verbatim}
 struct _hash_descriptor {
 char *name;
 unsigned long hashsize;    /* digest output size in bytes  */
 unsigned long blocksize;   /* the block size the hash uses */
 void (*init)   (hash_state *hash);
-int  (*process)(hash_state *hash,
-const unsigned char *in, unsigned long inlen);
+int  (*process)(         hash_state *hash,
+const unsigned char *in,
+unsigned long  inlen);
 int  (*done)   (hash_state *hash, unsigned char *out);
 int  (*test)   (void);
 };
 \end{verbatim}
-Similarly ``name'' is the name of the hash function in ASCII (all lowercase).  ``hashsize'' is the size of the digest output
+\index{find\_hash()}
-in bytes.  The remaining fields are pointers to the functions that do the respective tasks.  There is a function to
+The \textit{name} member is the name of the hash function (all lowercase).  The \textit{hashsize} member is the size of the digest output
-search the array as well called ``int find\_hash(char *name)''.  It returns -1 if the hash is not found, otherwise the
+in bytes, while \textit{blocksize} is the size of blocks the hash expects to the compression function.  Technically, this detail is not important
+for high level developers but is useful to know for performance reasons.
+The \textit{init} member initializes the hash, \textit{process} passes data through the hash, \textit{done} terminates the hash and retrieves the
+digest.  The \textit{test} member tests the hash against the specified test vectors.
+There is a function to search the array as well called \textit{int find\_hash(char *name)}.  It returns -1 if the hash is not found, otherwise, the
 position in the descriptor table of the hash.
-You can use the table to indirectly call a hash function that is chosen at runtime.  For example:
+In addition, there is also find\_hash\_oid() which finds a hash by the ASN.1 OBJECT IDENTIFIER string.
+\index{find\_hash\_oid()}
+\begin{verbatim}
+int find_hash_oid(const unsigned long *ID, unsigned long IDlen);
+\end{verbatim}
+You can use the table to indirectly call a hash function that is chosen at run-time.  For example:
 \begin{small}
 \begin{verbatim}
 #include <tomcrypt.h>
 int main(void)
 {
 return 0;
 }
 \end{verbatim}
 \end{small}
-Note the usage of ``MAXBLOCKSIZE''.  In Libtomcrypt no symmetric block, key or hash digest is larger than MAXBLOCKSIZE in
+Note the usage of \textbf{MAXBLOCKSIZE}.  In LibTomCrypt, no symmetric block, key or hash digest is larger than \textbf{MAXBLOCKSIZE} in
 length.  This provides a simple size you can set your automatic arrays to that will not get overrun.
-There are three helper functions as well:
+There are three helper functions to make working with hashes easier.  The first is a function to hash a buffer, and produce the digest in a single
-\index{hash\_memory()} \index{hash\_file()}
+function call.
-\begin{verbatim}
-int hash_memory(int hash,
+\index{hash\_memory()}
-const unsigned char *in,   unsigned long inlen,
+\begin{verbatim}
-unsigned char *out,  unsigned long *outlen);
+int hash_memory(                int  hash,
+const unsigned char *in,
-int hash_file(int hash, const char *fname,
+unsigned long  inlen,
-unsigned char *out, unsigned long *outlen);
+unsigned char *out,
+unsigned long *outlen);
-int hash_filehandle(int hash, FILE *in,
+\end{verbatim}
-unsigned char *out, unsigned long *outlen);
-\end{verbatim}
+This will hash the data pointed to by \textit{in} of length \textit{inlen}.  The hash used is indexed by the \textit{hash} parameter.  The message
+digest is stored in \textit{out}, and the \textit{outlen} parameter is updated to hold the message digest size.
-The ``hash'' parameter is the location in the descriptor table of the hash (\textit{e.g. the return of find\_hash()}).
-The ``*outlen'' variable is used to keep track of the output size.  You must set it to the size of your output buffer before
+The next helper function allows for the hashing of a file based on a file name.
-calling the functions.  When they complete succesfully they store the length of the message digest back in it.  The functions
+\index{hash\_file()}
-are otherwise straightforward.  The ``hash\_filehandle'' function assumes that ``in'' is an file handle opened in binary mode.
+\begin{verbatim}
-It will hash to the end of file and not reset the file position when finished.
+int hash_file(          int  hash,
+const char *fname,
+unsigned char *out,
+unsigned long *outlen);
+\end{verbatim}
+This will hash the file named by \textit{fname} using the hash indexed by \textit{hash}.  The file named in this function call must be readable by the
+user owning the process performing the request.  This function can be omitted by the \textbf{LTC\_NO\_FILE} define, which forces it to return \textbf{CRYPT\_NOP}
+when it is called.  The message digest is stored in \textit{out}, and the \textit{outlen} parameter is updated to hold the message digest size.
+\index{hash\_filehandle()}
+\begin{verbatim}
+int hash_filehandle(          int  hash,
+FILE *in,
+unsigned char *out,
+unsigned long *outlen);
+\end{verbatim}
+This will hash the file identified by the handle \textit{in} using the hash indexed by \textit{hash}.  This will begin hashing from the current file pointer position, and
+will not rewind the file pointer when finished.  This function can be omitted by the \textbf{LTC\_NO\_FILE} define, which forces it to return \textbf{CRYPT\_NOP}
+when it is called.  The message digest is stored in \textit{out}, and the \textit{outlen} parameter is updated to hold the message digest size.
 To perform the above hash with md5 the following code could be used:
 \begin{small}
 \begin{verbatim}
 #include <tomcrypt.h>
 /* get the index of the hash  */
 idx = find_hash("md5");
 /* call the hash */
 len = sizeof(out);
-if ((err = hash_memory(idx, "hello world", 11, out, &len)) != CRYPT_OK) {
+if ((err =
+hash_memory(idx, "hello world", 11, out, &len)) != CRYPT_OK) {
 printf("Error hashing data: %s\n", error_to_string(err));
 return -1;
 }
 return 0;
 }
 \end{verbatim}
 \end{small}
-The following hashes are provided as of this release:
+\subsection{Hash Registration}
+Similar to the cipher descriptor table you must register your hash algorithms before you can use them.  These functions
+work exactly like those of the cipher registration code.  The functions are:
+\index{register\_hash()} \index{unregister\_hash()}
+\begin{verbatim}
+int register_hash(const struct _hash_descriptor *hash);
+int unregister_hash(const struct _hash_descriptor *hash);
+\end{verbatim}
+The following hashes are provided as of this release within the LibTomCrypt library:
 \index{Hash descriptor table}
+\begin{figure}[here]
 \begin{center}
 \begin{tabular}{|c|c|c|}
-\hline Name & Descriptor Name & Size of Message Digest (bytes) \\
+\hline \textbf{Name} & \textbf{Descriptor Name} & \textbf{Size of Message Digest (bytes)} \\
 \hline WHIRLPOOL & whirlpool\_desc & 64 \\
 \hline SHA-512 & sha512\_desc & 64 \\
 \hline SHA-384 & sha384\_desc & 48 \\
+\hline RIPEMD-320 & rmd160\_desc & 40 \\
 \hline SHA-256 & sha256\_desc & 32 \\
+\hline RIPEMD-256 & rmd160\_desc & 32 \\
 \hline SHA-224 & sha224\_desc & 28 \\
 \hline TIGER-192 & tiger\_desc & 24 \\
 \hline SHA-1 & sha1\_desc & 20 \\
 \hline RIPEMD-160 & rmd160\_desc & 20 \\
 \hline RIPEMD-128 & rmd128\_desc & 16 \\
 \hline MD4 & md4\_desc & 16 \\
 \hline MD2 & md2\_desc & 16 \\
 \hline
 \end{tabular}
 \end{center}
+\caption{Built--In Software Hashes}
-Similar to the cipher descriptor table you must register your hash algorithms before you can use them.  These functions
+\end{figure}
-work exactly like those of the cipher registration code.  The functions are:
+\vfil
-\index{register\_hash()} \index{unregister\_hash()}
-\begin{verbatim}
+\mysection{Cipher Hash Construction}
-int register_hash(const struct _hash_descriptor *hash);
-int unregister_hash(const struct _hash_descriptor *hash);
-\end{verbatim}
-\section{Cipher Hash Construction}
 \index{Cipher Hash Construction}
-An addition to the suite of hash functions is the ``Cipher Hash Construction'' or ``CHC'' mode.  In this mode
+An addition to the suite of hash functions is the \textit{Cipher Hash Construction} or \textit{CHC} mode.  In this mode
 applicable block ciphers (such as AES) can be turned into hash functions that other LTC functions can use.  In
 particular this allows a cryptosystem to be designed using very few moving parts.
-In order to use the CHC system the developer will have to take a few extra steps.  First the ``chc\_desc'' hash
+In order to use the CHC system the developer will have to take a few extra steps.  First the \textit{chc\_desc} hash
 descriptor must be registered with register\_hash().  At this point the CHC hash cannot be used to hash
 data.  While it is in the hash system you still have to tell the CHC code which cipher to use.  This is accomplished
 via the chc\_register() function.
 \index{chc\_register()}
 return EXIT_FAILURE;
 }
 /* start chc with AES */
 if ((err = chc_register(find_cipher("aes"))) != CRYPT_OK) {
-printf("Error binding AES to CHC: %s\n", error_to_string(err));
+printf("Error binding AES to CHC: %s\n",
+error_to_string(err));
 }
-/* now you can use chc_hash in any LTC function [aside from pkcs...] */
+/* now you can use chc_hash in any LTC function
-/* ... */
+* [aside from pkcs...] */
-\end{verbatim}
+}
+\end{verbatim}
-\section{Notice}
+\mysection{Notice}
 It is highly recommended that you \textbf{not} use the MD4 or MD5 hashes for the purposes of digital signatures or authentication codes.
 These hashes are provided for completeness and they still can be used for the purposes of password hashing or one-way accumulators
 (e.g. Yarrow).
 The other hashes such as the SHA-1, SHA-2 (that includes SHA-512, SHA-384 and SHA-256) and TIGER-192 are still considered secure
 for all purposes you would normally use a hash for.
 \chapter{Message Authentication Codes}
-\section{HMAC Protocol}
+\mysection{HMAC Protocol}
-Thanks to Dobes Vandermeer the library now includes support for hash based message authenication codes or HMAC for short.  An HMAC
+Thanks to Dobes Vandermeer, the library now includes support for hash based message authentication codes, or HMAC for short.  An HMAC
-of a message is a keyed authenication code that only the owner of a private symmetric key will be able to verify.  The purpose is
+of a message is a keyed authentication code that only the owner of a private symmetric key will be able to verify.  The purpose is
 to allow an owner of a private symmetric key to produce an HMAC on a message then later verify if it is correct.  Any impostor or
 eavesdropper will not be able to verify the authenticity of a message.
 The HMAC support works much like the normal hash functions except that the initialization routine requires you to pass a key
 and its length.  The key is much like a key you would pass to a cipher.  That is, it is simply an array of octets stored in
-chars.  The initialization routine is:
+unsigned characters.  The initialization routine is:
 \index{hmac\_init()}
 \begin{verbatim}
-int hmac_init(hmac_state *hmac, int hash,
+int hmac_init(         hmac_state *hmac,
-const unsigned char *key, unsigned long keylen);
+int  hash,
-\end{verbatim}
+const unsigned char *key,
-The ``hmac'' parameter is the state for the HMAC code.  ``hash'' is the index into the descriptor table of the hash you want
+unsigned long  keylen);
-to use to authenticate the message.  ``key'' is the pointer to the array of chars that make up the key.  ``keylen'' is the
+\end{verbatim}
+The \textit{hmac} parameter is the state for the HMAC code.  The \textit{hash} parameter is the index into the descriptor table of the hash you want
+to use to authenticate the message.  The \textit{key} parameter is the pointer to the array of chars that make up the key.  The \textit{keylen} parameter is the
 length (in octets) of the key you want to use to authenticate the message.  To send octets of a message through the HMAC system you must use the following function:
 \index{hmac\_process()}
 \begin{verbatim}
-int hmac_process(hmac_state *hmac,
+int hmac_process(         hmac_state *hmac,
-const unsigned char *in, unsigned long inlen);
+const unsigned char *in,
-\end{verbatim}
+unsigned long  inlen);
-``hmac'' is the HMAC state you are working with. ``buf'' is the array of octets to send into the HMAC process.  ``len'' is the
+\end{verbatim}
-number of octets to process.  Like the hash process routines you can send the data in arbitrarly sized chunks. When you
+\textit{hmac} is the HMAC state you are working with. \textit{buf} is the array of octets to send into the HMAC process.  \textit{len} is the
+number of octets to process.  Like the hash process routines you can send the data in arbitrarily sized chunks. When you
 are finished with the HMAC process you must call the following function to get the HMAC code:
 \index{hmac\_done()}
 \begin{verbatim}
-int hmac_done(hmac_state *hmac,
+int hmac_done(   hmac_state *hmac,
-unsigned char *out, unsigned long *outlen);
+unsigned char *out,
-\end{verbatim}
+unsigned long *outlen);
-``hmac'' is the HMAC state you are working with.  ``out'' is the array of octets where the HMAC code should be stored.  You must
+\end{verbatim}
-set ``outlen'' to the size of the destination buffer before calling this function.  It is updated with the length of the HMAC code
+The \textit{hmac} parameter is the HMAC state you are working with.  The \textit{out} parameter is the array of octets where the HMAC code should be stored.
-produced (depending on which hash was picked).  If ``outlen'' is less than the size of the message digest (and ultimately
+You must set \textit{outlen} to the size of the destination buffer before calling this function.  It is updated with the length of the HMAC code
-the HMAC code) then the HMAC code is truncated as per FIPS-198 specifications (e.g. take the first ``outlen'' bytes).
+produced (depending on which hash was picked).  If \textit{outlen} is less than the size of the message digest (and ultimately
+the HMAC code) then the HMAC code is truncated as per FIPS-198 specifications (e.g. take the first \textit{outlen} bytes).
-There are two  utility functions provided to make using HMACs easier todo.  They accept the key and information about the
-message (file pointer, address in memory) and produce the HMAC result in one shot.  These are useful if you want to avoid
+There are two utility functions provided to make using HMACs easier to do.  They accept the key and information about the
+message (file pointer, address in memory), and produce the HMAC result in one shot.  These are useful if you want to avoid
 calling the three step process yourself.
 \index{hmac\_memory()}
 \begin{verbatim}
-int hmac_memory(int hash,
+int hmac_memory(
-const unsigned char *key, unsigned long  keylen,
+int  hash,
-const unsigned char *in,  unsigned long  inlen,
+const unsigned char *key, unsigned long  keylen,
-unsigned char *out, unsigned long *outlen);
+const unsigned char *in,  unsigned long  inlen,
-\end{verbatim}
+unsigned char *out, unsigned long *outlen);
-This will produce an HMAC code for the array of octets in ``in'' of length ``inlen''.  The index into the hash descriptor
+\end{verbatim}
-table must be provided in ``hash''.  It uses the key from ``key'' with a key length of ``keylen''.
+This will produce an HMAC code for the array of octets in \textit{in} of length \textit{inlen}.  The index into the hash descriptor
-The result is stored in the array of octets ``out'' and the length in ``outlen''.  The value of ``outlen'' must be set
+table must be provided in \textit{hash}.  It uses the key from \textit{key} with a key length of \textit{keylen}.
+The result is stored in the array of octets \textit{out} and the length in \textit{outlen}.  The value of \textit{outlen} must be set
 to the size of the destination buffer before calling this function.  Similarly for files there is the  following function:
 \index{hmac\_file()}
 \begin{verbatim}
-int hmac_file(int hash, const char *fname,
+int hmac_file(
-const unsigned char *key, unsigned long  keylen,
+int  hash,
-unsigned char *out, unsigned long *outlen);
+const char *fname,
-\end{verbatim}
+const unsigned char *key, unsigned long  keylen,
-``hash'' is the index into the hash descriptor table of the hash you want to use.  ``fname'' is the filename to process.
+unsigned char *out, unsigned long *outlen);
-``key'' is the array of octets to use as the key of length ``keylen''.  ``out'' is the array of octets where the
+\end{verbatim}
+\textit{hash} is the index into the hash descriptor table of the hash you want to use.  \textit{fname} is the filename to process.
+\textit{key} is the array of octets to use as the key of length \textit{keylen}.  \textit{out} is the array of octets where the
 result should be stored.
 To test if the HMAC code is working there is the following function:
 \index{hmac\_test()}
 \begin{verbatim}
 return 0;
 }
 \end{verbatim}
 \end{small}
-\section{OMAC Support}
+\mysection{OMAC Support}
+\index{OMAC} \index{CMAC}
 OMAC\footnote{\url{http://crypt.cis.ibaraki.ac.jp/omac/omac.html}}, which stands for \textit{One-Key CBC MAC} is an
-algorithm which produces a Message Authentication Code (MAC) using only a block cipher such as AES.  From an API
+algorithm which produces a Message Authentication Code (MAC) using only a block cipher such as AES.  Note:  OMAC has been standardized as
-standpoint the OMAC routines work much like the HMAC routines do.  Instead in this case a cipher is used instead of a hash.
+CMAC within NIST, for the purposes of this library OMAC and CMAC are synonymous.  From an API standpoint, the OMAC routines work much like the
+HMAC routines.  Instead, in this case a cipher is used instead of a hash.
 To start an OMAC state you call
 \index{omac\_init()}
 \begin{verbatim}
-int omac_init(omac_state *omac, int cipher,
+int omac_init(         omac_state *omac,
-const unsigned char *key, unsigned long keylen);
+int  cipher,
-\end{verbatim}
+const unsigned char *key,
-The ``omac'' variable is the state for the OMAC algorithm.  ``cipher'' is the index into the cipher\_descriptor table
+unsigned long  keylen);
+\end{verbatim}
+The \textit{omac} parameter is the state for the OMAC algorithm.  The \textit{cipher} parameter is the index into the cipher\_descriptor table
 of the cipher\footnote{The cipher must have a 64 or 128 bit block size.  Such as CAST5, Blowfish, DES, AES, Twofish, etc.} you
-wish to use.  ``key'' and ``keylen'' are the keys used to authenticate the data.
+wish to use.  The \textit{key} and \textit{keylen} parameters are the keys used to authenticate the data.
 To send data through the algorithm call
 \index{omac\_process()}
 \begin{verbatim}
-int omac_process(omac_state *state,
+int omac_process(         omac_state *state,
-const unsigned char *in, unsigned long inlen);
+const unsigned char *in,
-\end{verbatim}
+unsigned long  inlen);
-This will send ``inlen'' bytes from ``in'' through the active OMAC state ``state''.  Returns \textbf{CRYPT\_OK} if the
+\end{verbatim}
+This will send \textit{inlen} bytes from \textit{in} through the active OMAC state \textit{state}.  Returns \textbf{CRYPT\_OK} if the
 function succeeds.  The function is not sensitive to the granularity of the data.  For example,
 \begin{verbatim}
 omac_process(&mystate, "hello",  5);
 omac_process(&mystate, " world", 6);
 When you are done processing the message you can call the following to compute the message tag.
 \index{omac\_done()}
 \begin{verbatim}
-int omac_done(omac_state *state,
+int omac_done(   omac_state *state,
-unsigned char *out, unsigned long *outlen);
+unsigned char *out,
-\end{verbatim}
+unsigned long *outlen);
-Which will terminate the OMAC and output the \textit{tag} (MAC) to ``out''.  Note that unlike the HMAC and other code
+\end{verbatim}
-``outlen'' can be smaller than the default MAC size (for instance AES would make a 16-byte tag).  Part of the OMAC
+Which will terminate the OMAC and output the \textit{tag} (MAC) to \textit{out}.  Note that unlike the HMAC and other code
+\textit{outlen} can be smaller than the default MAC size (for instance AES would make a 16-byte tag).  Part of the OMAC
 specification states that the output may be truncated.  So if you pass in $outlen = 5$ and use AES as your cipher than
-the output MAC code will only be five bytes long.  If ``outlen'' is larger than the default size it is set to the default
+the output MAC code will only be five bytes long.  If \textit{outlen} is larger than the default size it is set to the default
 size to show how many bytes were actually used.
 Similar to the HMAC code the file and memory functions are also provided.  To OMAC a buffer of memory in one shot use the
 following function.
 \index{omac\_memory()}
 \begin{verbatim}
-int omac_memory(int cipher,
+int omac_memory(
-const unsigned char *key, unsigned long keylen,
+int  cipher,
-const unsigned char *in,  unsigned long inlen,
+const unsigned char *key, unsigned long keylen,
-unsigned char *out, unsigned long *outlen);
+const unsigned char *in,  unsigned long inlen,
-\end{verbatim}
+unsigned char *out, unsigned long *outlen);
-This will compute the OMAC of ``inlen'' bytes of ``in'' using the key ``key'' of length ``keylen'' bytes and the cipher
+\end{verbatim}
-specified by the ``cipher'''th entry in the cipher\_descriptor table.  It will store the MAC in ``out'' with the same
+This will compute the OMAC of \textit{inlen} bytes of \textit{in} using the key \textit{key} of length \textit{keylen} bytes and the cipher
+specified by the \textit{cipher}'th entry in the cipher\_descriptor table.  It will store the MAC in \textit{out} with the same
 rules as omac\_done.
 To OMAC a file use
 \index{omac\_file()}
 \begin{verbatim}
-int omac_file(int cipher,
+int omac_file(
-const unsigned char *key, unsigned long keylen,
+int  cipher,
-const char *filename,
+const unsigned char *key,      unsigned long keylen,
-unsigned char *out, unsigned long *outlen);
+const char *filename,
-\end{verbatim}
+unsigned char *out,      unsigned long *outlen);
+\end{verbatim}
-Which will OMAC the entire contents of the file specified by ``filename'' using the key ``key'' of length ``keylen'' bytes
-and the cipher specified by the ``cipher'''th entry in the cipher\_descriptor table.  It will store the MAC in ``out'' with
+Which will OMAC the entire contents of the file specified by \textit{filename} using the key \textit{key} of length \textit{keylen} bytes
+and the cipher specified by the \textit{cipher}'th entry in the cipher\_descriptor table.  It will store the MAC in \textit{out} with
 the same rules as omac\_done.
 To test if the OMAC code is working there is the following function:
 \index{omac\_test()}
 \begin{verbatim}
 return 0;
 }
 \end{verbatim}
 \end{small}
-\section{PMAC Support}
+\mysection{PMAC Support}
-The PMAC\footnote{J.Black, P.Rogaway, ``A Block--Cipher Mode of Operation for Parallelizable Message Authentication''}
+The PMAC\footnote{J.Black, P.Rogaway, \textit{A Block--Cipher Mode of Operation for Parallelizable Message Authentication}}
 protocol is another MAC algorithm that relies solely on a symmetric-key block cipher.  It uses essentially the same
 API as the provided OMAC code.
 A PMAC state is initialized with the following.
 \index{pmac\_init()}
 \begin{verbatim}
-int pmac_init(pmac_state *pmac, int cipher,
+int pmac_init(         pmac_state *pmac,
-const unsigned char *key, unsigned long keylen);
+int  cipher,
-\end{verbatim}
+const unsigned char *key,
-Which initializes the ``pmac'' state with the given ``cipher'' and ``key'' of length ``keylen'' bytes.  The chosen cipher
+unsigned long  keylen);
+\end{verbatim}
+Which initializes the \textit{pmac} state with the given \textit{cipher} and \textit{key} of length \textit{keylen} bytes.  The chosen cipher
 must have a 64 or 128 bit block size (e.x. AES).
 To MAC data simply send it through the process function.
 \index{pmac\_process()}
 \begin{verbatim}
-int pmac_process(pmac_state *state,
+int pmac_process(         pmac_state *state,
-const unsigned char *in, unsigned long inlen);
+const unsigned char *in,
-\end{verbatim}
+unsigned long  inlen);
-This will process ``inlen'' bytes of ``in'' in the given ``state''.  The function is not sensitive to the granularity of the
+\end{verbatim}
+This will process \textit{inlen} bytes of \textit{in} in the given \textit{state}.  The function is not sensitive to the granularity of the
 data.  For example,
 \begin{verbatim}
 pmac_process(&mystate, "hello",  5);
 pmac_process(&mystate, " world", 6);
 When a complete message has been processed the following function can be called to compute the message tag.
 \index{pmac\_done()}
 \begin{verbatim}
-int pmac_done(pmac_state *state,
+int pmac_done(   pmac_state *state,
-unsigned char *out, unsigned long *outlen);
+unsigned char *out,
-\end{verbatim}
+unsigned long *outlen);
-This will store upto ``outlen'' bytes of the tag for the given ``state'' into ``out''.  Note that if ``outlen'' is larger
+\end{verbatim}
-than the size of the tag it is set to the amount of bytes stored in ``out''.
+This will store up to \textit{outlen} bytes of the tag for the given \textit{state} into \textit{out}.  Note that if \textit{outlen} is larger
+than the size of the tag it is set to the amount of bytes stored in \textit{out}.
-Similar to the PMAC code the file and memory functions are also provided.  To PMAC a buffer of memory in one shot use the
+Similar to the OMAC code the file and memory functions are also provided.  To PMAC a buffer of memory in one shot use the
 following function.
 \index{pmac\_memory()}
 \begin{verbatim}
-int pmac_memory(int cipher,
+int pmac_memory(
-const unsigned char *key, unsigned long  keylen,
+int  cipher,
-const unsigned char *in,  unsigned long  inlen,
+const unsigned char *key, unsigned long  keylen,
-unsigned char *out, unsigned long *outlen);
+const unsigned char *in,  unsigned long  inlen,
-\end{verbatim}
+unsigned char *out, unsigned long *outlen);
-This will compute the PMAC of ``msglen'' bytes of ``msg'' using the key ``key'' of length ``keylen'' bytes and the cipher
+\end{verbatim}
-specified by the ``cipher'''th entry in the cipher\_descriptor table.  It will store the MAC in ``out'' with the same
+This will compute the PMAC of \textit{msglen} bytes of \textit{msg} using the key \textit{key} of length \textit{keylen} bytes, and the cipher
-rules as omac\_done.
+specified by the \textit{cipher}'th entry in the cipher\_descriptor table.  It will store the MAC in \textit{out} with the same
+rules as pmac\_done().
 To PMAC a file use
 \index{pmac\_file()}
 \begin{verbatim}
-int pmac_file(int cipher,
+int pmac_file(
-const unsigned char *key, unsigned long keylen,
+int  cipher,
-const char *filename,
+const unsigned char *key,      unsigned long keylen,
-unsigned char *out, unsigned long *outlen);
+const char *filename,
-\end{verbatim}
+unsigned char *out,      unsigned long *outlen);
+\end{verbatim}
-Which will PMAC the entire contents of the file specified by ``filename'' using the key ``key'' of length ``keylen'' bytes
-and the cipher specified by the ``cipher'''th entry in the cipher\_descriptor table.  It will store the MAC in ``out'' with
+Which will PMAC the entire contents of the file specified by \textit{filename} using the key \textit{key} of length \textit{keylen} bytes,
-the same rules as omac\_done.
+and the cipher specified by the \textit{cipher}'th entry in the cipher\_descriptor table.  It will store the MAC in \textit{out} with
+the same rules as pmac\_done().
 To test if the PMAC code is working there is the following function:
 \index{pmac\_test()}
 \begin{verbatim}
 int pmac_test(void);
 \end{verbatim}
 Which returns {\bf CRYPT\_OK} if the code passes otherwise it returns an error code.
-\section{Pelican MAC}
+\mysection{Pelican MAC}
-Pelican MAC is a new (experimental) MAC by the AES team that uses four rounds of AES as a ``mixing function''.  It achieves a very high
+Pelican MAC is a new (experimental) MAC by the AES team that uses four rounds of AES as a \textit{mixing function}.  It achieves a very high
 rate of processing and is potentially very secure.  It requires AES to be enabled to function.  You do not have to register\_cipher() AES first though
 as it calls AES directly.
 \index{pelican\_init()}
 \begin{verbatim}
-int pelican_init(pelican_state *pelmac, const unsigned char *key, unsigned long keylen);
+int pelican_init(      pelican_state *pelmac,
+const unsigned char *key,
+unsigned long  keylen);
 \end{verbatim}
 This will initialize the Pelican state with the given AES key.  Once this has been done you can begin processing data.
 \index{pelican\_process()}
 \begin{verbatim}
-int pelican_process(pelican_state *pelmac, const unsigned char *in, unsigned long inlen);
+int pelican_process(      pelican_state *pelmac,
-\end{verbatim}
+const unsigned char *in,
-This will process ``inlen'' bytes of ``in'' through the Pelican MAC.  It's best that you pass in multiples of 16 bytes as it makes the
+unsigned long  inlen);
+\end{verbatim}
+This will process \textit{inlen} bytes of \textit{in} through the Pelican MAC.  It's best that you pass in multiples of 16 bytes as it makes the
 routine more efficient but you may pass in any length of text.  You can call this function as many times as required to process
 an entire message.
 \index{pelican\_done()}
 \begin{verbatim}
 int pelican_done(pelican_state *pelmac, unsigned char *out);
 \end{verbatim}
-This terminates a Pelican MAC and writes the 16--octet tag to ``out''.
+This terminates a Pelican MAC and writes the 16--octet tag to \textit{out}.
 \subsection{Example}
 \begin{verbatim}
 #include <tomcrypt.h>
 int           err;
 /* somehow initialize a key */
 /* initialize pelican mac */
-if ((err = pelican_init(&pelstate,          /* the state */
+if ((err = pelican_init(&pelstate, /* the state */
-key,                /* user key */
+key,       /* user key */
-32                  /* key length in octets */
+32         /* key length in octets */
 )) != CRYPT_OK) {
-printf("Error initializing Pelican: %s", error_to_string(err));
+printf("Error initializing Pelican: %s",
+error_to_string(err));
 return EXIT_FAILURE;
 }
 /* MAC some data */
 if ((err = pelican_process(&pelstate,       /* the state */
 "hello world",   /* data to mac */
 11               /* length of data */
 )) != CRYPT_OK) {
-printf("Error processing Pelican: %s", error_to_string(err));
+printf("Error processing Pelican: %s",
+error_to_string(err));
 return EXIT_FAILURE;
 }
 /* Terminate the MAC */
-if ((err = pelican_done(&pelstate,       /* the state */
+if ((err = pelican_done(&pelstate,/* the state */
-tag              /* where to store the tag */
+tag       /* where to store the tag */
 )) != CRYPT_OK) {
-printf("Error terminating Pelican: %s", error_to_string(err));
+printf("Error terminating Pelican: %s",
+error_to_string(err));
 return EXIT_FAILURE;
 }
 /* tag[0..15] has the MAC output now */
 return EXIT_SUCCESS;
 }
 \end{verbatim}
+\mysection{XCBC-MAC}
+As of LibTomCrypt v1.15, XCBC-MAC (RFC 3566) has been provided to support TLS encryption suites.  Like OMAC, it computes a message authentication code
+by using a cipher in CBC mode.  It also uses a single key which it expands into the requisite three keys for the MAC function.  A XCBC--MAC state is
+initialized with the following function:
+\index{xcbc\_init()}
+\begin{verbatim}
+int xcbc_init(         xcbc_state *xcbc,
+int  cipher,
+const unsigned char *key,
+unsigned long  keylen);
+\end{verbatim}
+This will initialize the XCBC--MAC state \textit{xcbc}, with the key specified in \textit{key} of length \textit{keylen} octets.  The cipher indicated
+by the \textit{cipher} index can be either a 64 or 128--bit block cipher.  This will return \textbf{CRYPT\_OK} on success.
+To process data through XCBC--MAC use the following function:
+\index{xcbc\_process()}
+\begin{verbatim}
+int xcbc_process(         xcbc_state *state,
+const unsigned char *in,
+unsigned long  inlen);
+\end{verbatim}
+This will add the message octets pointed to by \textit{in} of length \textit{inlen} to the XCBC--MAC state pointed to by \textit{state}.  Like the other MAC functions,
+the granularity of the input is not important but the order is.  This will return \textbf{CRYPT\_OK} on success.
+To compute the MAC tag value use the following function:
+\index{xcbc\_done()}
+\begin{verbatim}
+int xcbc_done(   xcbc_state *state,
+unsigned char *out,
+unsigned long *outlen);
+\end{verbatim}
+This will retrieve the XCBC--MAC tag from the state pointed to by \textit{state}, and store it in the array pointed to by \textit{out}.  The \textit{outlen} parameter
+specifies the maximum size of the destination buffer, and is updated to hold the final size of the tag when the function returns.  This will return \textbf{CRYPT\_OK} on success.
+Helper functions are provided to make parsing memory buffers and files easier.  The following functions are provided:
+\index{xcbc\_memory()}
+\begin{verbatim}
+int xcbc_memory(
+int  cipher,
+const unsigned char *key, unsigned long  keylen,
+const unsigned char *in,  unsigned long  inlen,
+unsigned char *out, unsigned long *outlen);
+\end{verbatim}
+This will compute the XCBC--MAC of \textit{msglen} bytes of \textit{msg}, using the key \textit{key} of length \textit{keylen} bytes, and the cipher
+specified by the \textit{cipher}'th entry in the cipher\_descriptor table.  It will store the MAC in \textit{out} with the same rules as xcbc\_done().
+To xcbc a file use
+\index{xcbc\_file()}
+\begin{verbatim}
+int xcbc_file(
+int  cipher,
+const unsigned char *key,      unsigned long keylen,
+const char *filename,
+unsigned char *out,      unsigned long *outlen);
+\end{verbatim}
+Which will XCBC--MAC the entire contents of the file specified by \textit{filename} using the key \textit{key} of length \textit{keylen} bytes, and the cipher
+specified by the \textit{cipher}'th entry in the cipher\_descriptor table.  It will store the MAC in \textit{out} with the same rules as xcbc\_done().
+To test XCBC--MAC for RFC 3566 compliance use the following function:
+\index{xcbc\_test()}
+\begin{verbatim}
+int xcbc_test(void);
+\end{verbatim}
+This will return \textbf{CRYPT\_OK} on success.  This requires the AES or Rijndael descriptor be previously registered, otherwise, it will return
+\textbf{CRYPT\_NOP}.
+\mysection{F9--MAC}
+The F9--MAC is yet another CBC--MAC variant proposed for the 3GPP standard.  Originally specified to be used with the KASUMI block cipher, it can also be used
+with other ciphers.  For LibTomCrypt, the F9--MAC code can use any cipher.
+\subsection{Usage Notice}
+F9--MAC differs slightly from the other MAC functions in that it requires the caller to perform the final message padding.  The padding quite simply is a direction
+bit followed by a 1 bit and enough zeros to make the message a multiple of the cipher block size.  If the message is byte aligned, the padding takes on the form of
+a single 0x40 or 0xC0 byte followed by enough 0x00 bytes to make the message proper multiple.
+If the user simply wants a MAC function (hint: use OMAC) padding with a single 0x40 byte should be sufficient for security purposes and still be reasonably compatible
+with F9--MAC.
+\subsection{F9--MAC Functions}
+A F9--MAC state is initialized with the following function:
+\index{f9\_init()}
+\begin{verbatim}
+int f9_init(           f9_state *f9,
+int  cipher,
+const unsigned char *key,
+unsigned long  keylen);
+\end{verbatim}
+This will initialize the F9--MAC state \textit{f9}, with the key specified in \textit{key} of length \textit{keylen} octets.  The cipher indicated
+by the \textit{cipher} index can be either a 64 or 128--bit block cipher.  This will return \textbf{CRYPT\_OK} on success.
+To process data through F9--MAC use the following function:
+\index{f9\_process()}
+\begin{verbatim}
+int f9_process(           f9_state *state,
+const unsigned char *in,
+unsigned long  inlen);
+\end{verbatim}
+This will add the message octets pointed to by \textit{in} of length \textit{inlen} to the F9--MAC state pointed to by \textit{state}.  Like the other MAC functions,
+the granularity of the input is not important but the order is.  This will return \textbf{CRYPT\_OK} on success.
+To compute the MAC tag value use the following function:
+\index{f9\_done()}
+\begin{verbatim}
+int f9_done(     f9_state *state,
+unsigned char *out,
+unsigned long *outlen);
+\end{verbatim}
+This will retrieve the F9--MAC tag from the state pointed to by \textit{state}, and store it in the array pointed to by \textit{out}.  The \textit{outlen} parameter
+specifies the maximum size of the destination buffer, and is updated to hold the final size of the tag when the function returns.  This will return
+\textbf{CRYPT\_OK} on success.
+Helper functions are provided to make parsing memory buffers and files easier.  The following functions are provided:
+\index{f9\_memory()}
+\begin{verbatim}
+int f9_memory(
+int  cipher,
+const unsigned char *key, unsigned long  keylen,
+const unsigned char *in,  unsigned long  inlen,
+unsigned char *out, unsigned long *outlen);
+\end{verbatim}
+This will compute the F9--MAC of \textit{msglen} bytes of \textit{msg}, using the key \textit{key} of length \textit{keylen} bytes, and the cipher
+specified by the \textit{cipher}'th entry in the cipher\_descriptor table.  It will store the MAC in \textit{out} with the same rules as f9\_done().
+To F9--MAC a file use
+\index{f9\_file()}
+\begin{verbatim}
+int f9_file(
+int  cipher,
+const unsigned char *key,      unsigned long keylen,
+const char *filename,
+unsigned char *out,      unsigned long *outlen);
+\end{verbatim}
+Which will F9--MAC the entire contents of the file specified by \textit{filename} using the key \textit{key} of length \textit{keylen} bytes, and the cipher
+specified by the \textit{cipher}'th entry in the cipher\_descriptor table.  It will store the MAC in \textit{out} with the same rules as f9\_done().
+To test f9--MAC for RFC 3566 compliance use the following function:
+\index{f9\_test()}
+\begin{verbatim}
+int f9_test(void);
+\end{verbatim}
+This will return \textbf{CRYPT\_OK} on success.  This requires the AES or Rijndael descriptor be previously registered, otherwise, it will return
+\textbf{CRYPT\_NOP}.
 \chapter{Pseudo-Random Number Generators}
-\section{Core Functions}
+\mysection{Core Functions}
 The library provides an array of core functions for Pseudo-Random Number Generators (PRNGs) as well.  A cryptographic PRNG is
 used to expand a shorter bit string into a longer bit string.  PRNGs are used wherever random data is required such as Public Key (PK)
-key generation.  There is a universal structure called ``prng\_state''.  To initialize a PRNG call:
+key generation.  There is a universal structure called \textit{prng\_state}.  To initialize a PRNG call:
 \index{PRNG start}
 \begin{verbatim}
 int XXX_start(prng_state *prng);
 \end{verbatim}
 This will setup the PRNG for future use and not seed it.  In order for the PRNG to be cryptographically useful you must give it
 entropy.  Ideally you'd have some OS level source to tap like in UNIX.  To add entropy to the PRNG call:
 \index{PRNG add\_entropy}
 \begin{verbatim}
-int XXX_add_entropy(const unsigned char *in, unsigned long inlen,
+int XXX_add_entropy(const unsigned char *in,
-prng_state *prng);
+unsigned long  inlen,
-\end{verbatim}
+prng_state *prng);
+\end{verbatim}
-Which returns {\bf CRYPTO\_OK} if the entropy was accepted.  Once you think you have enough entropy you call another
+Which returns {\bf CRYPT\_OK} if the entropy was accepted.  Once you think you have enough entropy you call another
 function to put the entropy into action.
 \index{PRNG ready}
 \begin{verbatim}
 int XXX_ready(prng_state *prng);
 \end{verbatim}
-Which returns {\bf CRYPTO\_OK} if it is ready.  Finally to actually read bytes call:
+Which returns {\bf CRYPT\_OK} if it is ready.  Finally to actually read bytes call:
 \index{PRNG read}
 \begin{verbatim}
-unsigned long XXX_read(unsigned char *out, unsigned long outlen,
+unsigned long XXX_read(unsigned char *out,
-prng_state *prng);
+unsigned long  outlen,
+prng_state *prng);
 \end{verbatim}
 Which returns the number of bytes read from the PRNG.  When you are finished with a PRNG state you call
 the following.
 This will terminate a PRNG state and free any memory (if any) allocated.  To export a PRNG state
 so that you can later resume the PRNG call the following.
 \index{PRNG export}
 \begin{verbatim}
-int XXX_export(unsigned char *out, unsigned long *outlen,
+int XXX_export(unsigned char *out,
-prng_state    *prng);
+unsigned long *outlen,
-\end{verbatim}
+prng_state *prng);
+\end{verbatim}
-This will write a ``PRNG state'' to the buffer ``out'' of length ``outlen'' bytes.  The idea of
-the export is meant to be used as a ``seed file''.  That is, when the program starts up there will not likely
+This will write a \textit{PRNG state} to the buffer \textit{out} of length \textit{outlen} bytes.  The idea of
+the export is meant to be used as a \textit{seed file}.  That is, when the program starts up there will not likely
 be that much entropy available.   To import a state to seed a PRNG call the following function.
 \index{PRNG import}
 \begin{verbatim}
-int XXX_import(const unsigned char *in, unsigned long inlen,
+int XXX_import(const unsigned char *in,
-prng_state     *prng);
+unsigned long  inlen,
+prng_state *prng);
 \end{verbatim}
 This will call the start and add\_entropy functions of the given PRNG.  It will use the state in
-``in'' of length ``inlen'' as the initial seed.  You must pass the same seed length as was exported
+\textit{in} of length \textit{inlen} as the initial seed.  You must pass the same seed length as was exported
 by the corresponding export function.
-Note that importing a state will not ``resume'' the PRNG from where it left off.  That is, if you export
+Note that importing a state will not \textit{resume} the PRNG from where it left off.  That is, if you export
 a state, emit (say) 8 bytes and then import the previously exported state the next 8 bytes will not
 specifically equal the 8 bytes you generated previously.
-When a program is first executed the normal course of operation is
+When a program is first executed the normal course of operation is:
 \begin{enumerate}
 \item Gather entropy from your sources for a given period of time or number of events.
 \item Start, use your entropy via add\_entropy and ready the PRNG yourself.
 \end{enumerate}
 When your program is finished you simply call the export function and save the state to a medium (disk,
 flash memory, etc).  The next time your application starts up you can detect the state, feed it to the
-import function and go on your way.  It is ideal that (as soon as possible) after startup you export a
+import function and go on your way.  It is ideal that (as soon as possible) after start up you export a
 fresh state.  This helps in the case that the program aborts or the machine is powered down without
 being given a chance to exit properly.
 Note that even if you have a state to import it is important to add new entropy to the state.  However,
 there is less pressure to do so.
 \subsection{Remarks}
 It is possible to be adding entropy and reading from a PRNG at the same time.  For example, if you first seed the PRNG
 and call ready() you can now read from it.  You can also keep adding new entropy to it.  The new entropy will not be used
 in the PRNG until ready() is called again.  This allows the PRNG to be used and re-seeded at the same time.  No real error
-checking is guaranteed to see if the entropy is sufficient or if the PRNG is even in a ready state before reading.
+checking is guaranteed to see if the entropy is sufficient, or if the PRNG is even in a ready state before reading.
 \subsection{Example}
+Below is a simple snippet to read 10 bytes from Yarrow.  It is important to note that this snippet is {\bf NOT} secure since
-Below is a simple snippet to read 10 bytes from yarrow.  Its important to note that this snippet is
+the entropy added is not random.
-{\bf NOT} secure since the entropy added is not random.
 \begin{verbatim}
 #include <tomcrypt.h>
 int main(void)
 {
 /* start it */
 if ((err = yarrow_start(&prng)) != CRYPT_OK) {
 printf("Start error: %s\n", error_to_string(err));
 }
 /* add entropy */
-if ((err = yarrow_add_entropy("hello world", 11, &prng)) != CRYPT_OK) {
+if ((err = yarrow_add_entropy("hello world", 11, &prng))
+!= CRYPT_OK) {
 printf("Add_entropy error: %s\n", error_to_string(err));
 }
 /* ready and read */
 if ((err = yarrow_ready(&prng)) != CRYPT_OK) {
 printf("Ready error: %s\n", error_to_string(err));
 }
-printf("Read %lu bytes from yarrow\n", yarrow_read(buf, 10, &prng));
+printf("Read %lu bytes from yarrow\n",
+yarrow_read(buf, sizeof(buf), &prng));
 return 0;
 }
 \end{verbatim}
-\section{PRNG Descriptors}
+\mysection{PRNG Descriptors}
 \index{PRNG Descriptor}
-PRNGs have descriptors too (surprised?). Stored in the structure ``prng\_descriptor''.  The format of an element is:
+PRNGs have descriptors that allow plugin driven functions to be created using PRNGs. The plugin descriptors are stored in the structure \textit{prng\_descriptor}.  The
+format of an element is:
 \begin{verbatim}
 struct _prng_descriptor {
 char *name;
 int  export_size;    /* size in bytes of exported state */
 int (*start)      (prng_state *);
-int (*add_entropy)(const unsigned char *, unsigned long, prng_state *);
+int (*add_entropy)(const unsigned char *, unsigned long,
+prng_state *);
 int (*ready)      (prng_state *);
-unsigned long (*read)(unsigned char *, unsigned long len, prng_state *);
+unsigned long (*read)(unsigned char *, unsigned long len,
+prng_state *);
 void (*done)(prng_state *);
 int (*export)(unsigned char *, unsigned long *, prng_state *);
 int (*import)(const unsigned char *, unsigned long, prng_state *);
 int (*test)(void);
 };
 \end{verbatim}
-There is a ``int find\_prng(char *name)'' function as well.  Returns -1 if the PRNG is not found, otherwise it returns
+To find a PRNG in the descriptor table the following function can be used:
-the position in the prng\_descriptor array.
+\index{find\_prng()}
+\begin{verbatim}
-Just like the ciphers and hashes you must register your prng before you can use it.  The two functions provided work
+int find_prng(const char *name);
-exactly as those for the cipher registry functions.  They are:
+\end{verbatim}
+This will search the PRNG descriptor table for the PRNG named \textit{name}.  It will return -1 if the PRNG is not found, otherwise, it returns
+the index into the descriptor table.
+Just like the ciphers and hashes, you must register your prng before you can use it.  The two functions provided work exactly as those for the cipher registry functions.
+They are the following:
+\index{register\_prng()} \index{unregister\_prng()}
 \begin{verbatim}
 int register_prng(const struct _prng_descriptor *prng);
 int unregister_prng(const struct _prng_descriptor *prng);
 \end{verbatim}
+The register function will register the PRNG, and return the index into the table where it was placed (or -1 for error).  It will avoid registering the same
+descriptor twice, and will return the index of the current placement in the table if the caller attempts to register it more than once.  The unregister function
+will return \textbf{CRYPT\_OK} if the PRNG was found and removed.  Otherwise, it returns \textbf{CRYPT\_ERROR}.
 \subsection{PRNGs Provided}
 \begin{figure}[here]
 \begin{center}
 \begin{small}
 \caption{List of Provided PRNGs}
 \end{figure}
 \subsubsection{Yarrow}
 Yarrow is fast PRNG meant to collect an unspecified amount of entropy from sources
-(keyboard, mouse, interrupts, etc) and produce an unbounded string of random bytes.
+(keyboard, mouse, interrupts, etc), and produce an unbounded string of random bytes.
-\textit{Note:} This PRNG is still secure for most taskings but is no longer recommended.  Users
+\textit{Note:} This PRNG is still secure for most tasks but is no longer recommended.  Users
 should use Fortuna instead.
 \subsubsection{Fortuna}
 Fortuna is a fast attack tolerant and more thoroughly designed PRNG suitable for long term
 usage.  It is faster than the default implementation of Yarrow\footnote{Yarrow has been implemented
 to work with most cipher and hash combos based on which you have chosen to build into the library.} while
 providing more security.
 Fortuna is slightly less flexible than Yarrow in the sense that it only works with the AES block cipher
-and SHA--256 hash function.  Technically Fortuna will work with any block cipher that accepts a 256--bit
+and SHA--256 hash function.  Technically, Fortuna will work with any block cipher that accepts a 256--bit
-key and any hash that produces at least a 256--bit output.  However, to make the implementation simpler
+key, and any hash that produces at least a 256--bit output.  However, to make the implementation simpler
 it has been fixed to those choices.
 Fortuna is more secure than Yarrow in the sense that attackers who learn parts of the entropy being
 added to the PRNG learn far less about the state than that of Yarrow.  Without getting into to many
 details Fortuna has the ability to recover from state determination attacks where the attacker starts
-to learn information from the PRNGs output about the internal state.  Yarrow on the other hand cannot
+to learn information from the PRNGs output about the internal state.  Yarrow on the other hand, cannot
 recover from that problem until new entropy is added to the pool and put to use through the ready() function.
 \subsubsection{RC4}
-RC4 is an old stream cipher that can also double duty as a PRNG in a pinch.  You ``key'' it by
+RC4 is an old stream cipher that can also double duty as a PRNG in a pinch.  You key RC4 by
-calling add\_entropy() and setup the key by calling ready().  You can only add upto 256 bytes via
+calling add\_entropy(), and setup the key by calling ready().  You can only add up to 256 bytes via
 add\_entropy().
-When you read from RC4 the output of the RC4 algorithm is XOR'd against your buffer you provide.  In this
+When you read from RC4, the output is XOR'ed against your buffer you provide.  In this manner, you can use rc4\_read()
-manner you can use rc4\_read() as an encrypt (and decrypt) function.
+as an encrypt (and decrypt) function.
-You really shouldn't use RC4 anymore.  This isn't because RC4 is weak (though biases are known to exist) just
+You really should not use RC4.  This is not because RC4 is weak, (though biases are known to exist) but simply due to
-simply that faster alternatives exist.
+the fact that faster alternatives exist.
 \subsubsection{SOBER-128}
-SOBER-128 is a stream cipher designed by the QUALCOMM Australia team.  Like RC4 you ``key'' it by
+SOBER--128 is a stream cipher designed by the QUALCOMM Australia team.  Like RC4, you key it by
 calling add\_entropy().  There is no need to call ready() for this PRNG as it does not do anything.
-Note that this cipher has several oddities about how it operates.  The first time you call
+Note: this cipher has several oddities about how it operates.  The first call to add\_entropy() sets the cipher's key.
-add\_entropy() that sets the cipher's key.  Every other time you call the same function it sets
+Every other time call to the add\_entropy() function sets the cipher's IV variable.  The IV mechanism allows you to
-the cipher's IV variable.  The IV mechanism allows you to encrypt several messages with the same
+encrypt several messages with the same key, and not re--use the same key material.
-key and not re--use the same key material.
+Unlike Yarrow and Fortuna, all of the entropy (and hence security) of this algorithm rests in the data
-Unlike Yarrow and Fortuna all of the entropy (and hence security) of this algorithm rests in the data
+you pass it on the \textbf{first} call to add\_entropy().  All buffers sent to add\_entropy() must have a length
-you pass it on the first call to add\_entropy().  All buffers sent to add\_entropy() must have a length
 that is a multiple of four bytes.
-Like RC4 the output of SOBER--128 is XOR'ed against the buffer you provide it.  In this manner you can use
+Like RC4, the output of SOBER--128 is XOR'ed against the buffer you provide it.  In this manner, you can use
 sober128\_read() as an encrypt (and decrypt) function.
-Since SOBER-128 has a fixed keying scheme and is very fast (faster than RC4) the ideal usage of SOBER-128 is to
+Since SOBER-128 has a fixed keying scheme, and is very fast (faster than RC4) the ideal usage of SOBER-128 is to
-key it from the output of Fortuna (or Yarrow) and use it to encrypt messages.  It is also ideal for
+key it from the output of Fortuna (or Yarrow), and use it to encrypt messages.  It is also ideal for
 simulations which need a high quality (and fast) stream of bytes.
 \subsubsection{Example Usage}
 \begin{small}
 \begin{verbatim}
 if ((err = rc4_start(&prng)) != CRYPT_OK) {
 printf("RC4 init error: %s\n", error_to_string(err));
 exit(-1);
 }
-/* use ``key'' as the key */
+/* use "key" as the key */
 if ((err = rc4_add_entropy("key", 3, &prng)) != CRYPT_OK) {
 printf("RC4 add entropy error: %s\n", error_to_string(err));
 exit(-1);
 }
 }
 \end{verbatim}
 \end{small}
 To decrypt you have to do the exact same steps.
-\section{The Secure RNG}
+\mysection{The Secure RNG}
 \index{Secure RNG}
-An RNG is related to a PRNG except that it doesn't expand a smaller seed to get the data.  They generate their random bits
+An RNG is related to a PRNG in many ways, except that it does not expand a smaller seed to get the data.  They generate their random bits
 by performing some computation on fresh input bits.  Possibly the hardest thing to get correctly in a cryptosystem is the
-PRNG.  Computers are deterministic beasts that try hard not to stray from pre-determined paths.  That makes gathering
+PRNG.  Computers are deterministic that try hard not to stray from pre--determined paths.  This makes gathering entropy needed to seed a PRNG
-entropy needed to seed the PRNG a hard task.
+a hard task.
 There is one small function that may help on certain platforms:
 \index{rng\_get\_bytes()}
 \begin{verbatim}
-unsigned long rng_get_bytes(unsigned char *buf, unsigned long len,
+unsigned long rng_get_bytes(
-void (*callback)(void));
+unsigned char *buf,
-\end{verbatim}
+unsigned long  len,
+void         (*callback)(void));
-Which will try one of three methods of getting random data.  The first is to open the popular ``/dev/random'' device which
+\end{verbatim}
-on most *NIX platforms provides cryptographic random bits\footnote{This device is available in Windows through the Cygwin compiler suite.  It emulates ``/dev/random'' via the Microsoft CSP.}.
-The second method is to try the Microsoft Cryptographic Service Provider and read the RNG.  The third method is an ANSI C
+Which will try one of three methods of getting random data.  The first is to open the popular \textit{/dev/random} device which
-clock drift method that is also somewhat popular but gives bits of lower entropy.  The ``callback'' parameter is a pointer to a function that returns void.  Its used when the slower ANSI C RNG must be
+on most *NIX platforms provides cryptographic random bits\footnote{This device is available in Windows through the Cygwin compiler suite.  It emulates \textit{/dev/random} via the Microsoft CSP.}.
-used so the calling application can still work.  This is useful since the ANSI C RNG has a throughput of three
+The second method is to try the Microsoft Cryptographic Service Provider, and read the RNG.  The third method is an ANSI C
-bytes a second.  The callback pointer may be set to {\bf NULL} to avoid using it if you don't want to.  The function
+clock drift method that is also somewhat popular but gives bits of lower entropy.  The \textit{callback} parameter is a pointer to a function that returns void.  It is
-returns the number of bytes actually read from any RNG source.  There is a function to help setup a PRNG as well:
+used when the slower ANSI C RNG must be used so the calling application can still work.  This is useful since the ANSI C RNG has a throughput of roughly three
+bytes a second.  The callback pointer may be set to {\bf NULL} to avoid using it if you do not want to.  The function returns the number of bytes actually read from
+any RNG source.  There is a function to help setup a PRNG as well:
 \index{rng\_make\_prng()}
 \begin{verbatim}
-int rng_make_prng(int bits, int wprng, prng_state *prng,
+int rng_make_prng(       int  bits,
-void (*callback)(void));
+int  wprng,
-\end{verbatim}
+prng_state *prng,
-This will try to setup the prng with a state of at least ``bits'' of entropy.  The ``callback'' parameter works much like
+void (*callback)(void));
-the callback in ``rng\_get\_bytes()''.  It is highly recommended that you use this function to setup your PRNGs unless you have a
+\end{verbatim}
-platform where the RNG doesn't work well.  Example usage of this function is given below.
+This will try to initialize the prng with a state of at least \textit{bits} of entropy.  The \textit{callback} parameter works much like
+the callback in \textit{rng\_get\_bytes()}.  It is highly recommended that you use this function to setup your PRNGs unless you have a
+platform where the RNG does not work well.  Example usage of this function is given below:
 \begin{small}
 \begin{verbatim}
 #include <tomcrypt.h>
 int main(void)
 printf("Error registering Yarrow\n");
 return -1;
 }
 /* setup the PRNG */
-if ((err = rng_make_prng(128, find_prng("yarrow"), &prng, NULL)) != CRYPT_OK) {
+if ((err = rng_make_prng(128, find_prng("yarrow"), &prng, NULL))
+!= CRYPT_OK) {
 printf("Error setting up PRNG, %s\n", error_to_string(err));
 return -1;
 }
 /* make a 192-bit ECC key */
-if ((err = ecc_make_key(&prng, find_prng("yarrow"), 24, &mykey)) != CRYPT_OK) {
+if ((err = ecc_make_key(&prng, find_prng("yarrow"), 24, &mykey))
+!= CRYPT_OK) {
 printf("Error making key: %s\n", error_to_string(err));
 return -1;
 }
 return 0;
 }
 \end{verbatim}
 \end{small}
 \subsection{The Secure PRNG Interface}
-It is possible to access the secure RNG through the PRNG interface and in turn use it within dependent functions such
+It is possible to access the secure RNG through the PRNG interface, and in turn use it within dependent functions such
 as the PK API.  This simplifies the cryptosystem on platforms where the secure RNG is fast.  The secure PRNG never
-requires to be started, that is you need not call the start, add\_entropy or ready functions.  For example, consider
+requires to be started, that is you need not call the start, add\_entropy, or ready functions.  For example, consider
 the previous example using this PRNG.
 \begin{small}
 \begin{verbatim}
 #include <tomcrypt.h>
 printf("Error registering SPRNG\n");
 return -1;
 }
 /* make a 192-bit ECC key */
-if ((err = ecc_make_key(NULL, find_prng("sprng"), 24, &mykey)) != CRYPT_OK) {
+if ((err = ecc_make_key(NULL, find_prng("sprng"), 24, &mykey))
+!= CRYPT_OK) {
 printf("Error making key: %s\n", error_to_string(err));
 return -1;
 }
 return 0;
 }
 \end{verbatim}
 \end{small}
 \chapter{RSA Public Key Cryptography}
-\section{Introduction}
+\mysection{Introduction}
 RSA wrote the PKCS \#1 specifications which detail RSA Public Key Cryptography.  In the specifications are
-padding algorithms for encryption and signatures.  The standard includes the ``v2.1'' algorithms.
+padding algorithms for encryption and signatures.  The standard includes the \textit{v1.5} and \textit{v2.1} algorithms.
-To simplify matters a little the v2.1 encryption and signature padding algorithms are called OAEP and PSS
+To simplify matters a little the v2.1 encryption and signature padding algorithms are called OAEP and PSS respectively.
-respectively.
+\mysection{PKCS \#1 Padding}
-\section{PKCS \#1 Encryption}
+PKCS \#1 v1.5 padding is so simple that both signature and encryption padding are performed by the same function.  Note: the
+signature padding does \textbf{not} include the ASN.1 padding required.  That is performed by the rsa\_sign\_hash\_ex() function
+documented later on in this chapter.
+\subsection{PKCS \#1 v1.5 Encoding}
+The following function performs PKCS \#1 v1.5 padding:
+\index{pkcs\_1\_v1\_5\_encode()}
+\begin{verbatim}
+int pkcs_1_v1_5_encode(
+const unsigned char *msg,
+unsigned long  msglen,
+int  block_type,
+unsigned long  modulus_bitlen,
+prng_state *prng,
+int  prng_idx,
+unsigned char *out,
+unsigned long *outlen);
+\end{verbatim}
+This will encode the message pointed to by \textit{msg} of length \textit{msglen} octets.  The \textit{block\_type} parameter must be set to
+\textbf{LTC\_PKCS\_1\_EME} to perform encryption padding.  It must be set to \textbf{LTC\_PKCS\_1\_EMSA} to perform signature padding.  The \textit{modulus\_bitlen}
+parameter indicates the length of the modulus in bits.  The padded data is stored in \textit{out} with a length of \textit{outlen} octets.  The output will not be
+longer than the modulus which helps allocate the correct output buffer size.
+Only encryption padding requires a PRNG.  When performing signature padding the \textit{prng\_idx} parameter may be left to zero as it is not checked for validity.
+\subsection{PKCS \#1 v1.5 Decoding}
+The following function performs PKCS \#1 v1.5 de--padding:
+\index{pkcs\_1\_v1\_5\_decode()}
+\begin{verbatim}
+int pkcs_1_v1_5_decode(
+const unsigned char *msg,
+unsigned long  msglen,
+int  block_type,
+unsigned long  modulus_bitlen,
+unsigned char *out,
+unsigned long *outlen,
+int *is_valid);
+\end{verbatim}
+\index{LTC\_PKCS\_1\_EME} \index{LTC\_PKCS\_1\_EMSA}
+This will remove the PKCS padding data pointed to by \textit{msg} of length \textit{msglen}.  The decoded data is stored in \textit{out} of length
+\textit{outlen}.  If the padding is valid, a 1 is stored in \textit{is\_valid}, otherwise, a 0 is stored.  The \textit{block\_type} parameter must be set to either
+\textbf{LTC\_PKCS\_1\_EME} or \textbf{LTC\_PKCS\_1\_EMSA} depending on whether encryption or signature padding is being removed.
+\mysection{PKCS \#1 v2.1 Encryption}
 PKCS \#1 RSA Encryption amounts to OAEP padding of the input message followed by the modular exponentiation.  As far as this portion of
 the library is concerned we are only dealing with th OAEP padding of the message.
 \subsection{OAEP Encoding}
+The following function performs PKCS \#1 v2.1 encryption padding:
 \index{pkcs\_1\_oaep\_encode()}
 \begin{alltt}
-int pkcs_1_oaep_encode(const unsigned char *msg,    unsigned long msglen,
+int pkcs_1_oaep_encode(
-const unsigned char *lparam, unsigned long lparamlen,
+const unsigned char *msg,
-unsigned long modulus_bitlen, prng_state *prng,
+unsigned long  msglen,
-int           prng_idx,         int  hash_idx,
+const unsigned char *lparam,
-unsigned char *out,    unsigned long *outlen);
+unsigned long  lparamlen,
+unsigned long  modulus_bitlen,
+prng_state *prng,
+int  prng_idx,
+int  hash_idx,
+unsigned char *out,
+unsigned long *outlen);
 \end{alltt}
-This accepts ``msg'' as input of length ``msglen'' which will be OAEP padded.  The ``lparam'' variable is an additional system specific
+This accepts \textit{msg} as input of length \textit{msglen} which will be OAEP padded.  The \textit{lparam} variable is an additional system specific
 tag that can be applied to the encoding.  This is useful to identify which system encoded the message.  If no variance is desired then
-``lparam'' can be set to \textbf{NULL}.
+\textit{lparam} can be set to \textbf{NULL}.
 OAEP encoding requires the length of the modulus in bits in order to calculate the size of the output.  This is passed as the parameter
-``modulus\_bitlen''.  ``hash\_idx'' is the index into the hash descriptor table of the hash desired.  PKCS \#1 allows any hash to be
+\textit{modulus\_bitlen}.  \textit{hash\_idx} is the index into the hash descriptor table of the hash desired.  PKCS \#1 allows any hash to be
 used but both the encoder and decoder must use the same hash in order for this to succeed.  The size of hash output affects the maximum
-sized input message.  ``prng\_idx'' and ``prng'' are the random number generator arguments required to randomize the padding process.
+sized input message.  \textit{prng\_idx} and \textit{prng} are the random number generator arguments required to randomize the padding process.
-The padded message is stored in ``out'' along with the length in ``outlen''.
+The padded message is stored in \textit{out} along with the length in \textit{outlen}.
-If $h$ is the length of the hash and $m$ the length of the modulus (both in octets) then the maximum payload for ``msg'' is
+If $h$ is the length of the hash and $m$ the length of the modulus (both in octets) then the maximum payload for \textit{msg} is
 $m - 2h - 2$.  For example, with a $1024$--bit RSA key and SHA--1 as the hash the maximum payload is $86$ bytes.
 Note that when the message is padded it still has not been RSA encrypted.  You must pass the output of this function to
 rsa\_exptmod() to encrypt it.
 \subsection{OAEP Decoding}
 \index{pkcs\_1\_oaep\_decode()}
 \begin{alltt}
-int pkcs_1_oaep_decode(const unsigned char *msg,    unsigned long msglen,
+int pkcs_1_oaep_decode(
-const unsigned char *lparam, unsigned long lparamlen,
+const unsigned char *msg,
-unsigned long modulus_bitlen, int hash_idx,
+unsigned long  msglen,
-unsigned char *out,    unsigned long *outlen,
+const unsigned char *lparam,
-int           *res);
+unsigned long  lparamlen,
+unsigned long  modulus_bitlen,
+int  hash_idx,
+unsigned char *out,
+unsigned long *outlen,
+int *res);
 \end{alltt}
-This function decodes an OAEP encoded message and outputs the original message that was passed to the OAEP encoder.  ``msg'' is the
+This function decodes an OAEP encoded message and outputs the original message that was passed to the OAEP encoder.  \textit{msg} is the
-output of pkcs\_1\_oaep\_encode() of length ``msglen''.  ``lparam'' is the same system variable passed to the OAEP encoder.  If it does not
+output of pkcs\_1\_oaep\_encode() of length \textit{msglen}.  \textit{lparam} is the same system variable passed to the OAEP encoder.  If it does not
-match what was used during encoding this function will not decode the packet.  ``modulus\_bitlen'' is the size of the RSA modulus in bits
+match what was used during encoding this function will not decode the packet.  \textit{modulus\_bitlen} is the size of the RSA modulus in bits
-and must match what was used during encoding.  Similarly the ``hash\_idx'' index into the hash descriptor table must match what was used
+and must match what was used during encoding.  Similarly the \textit{hash\_idx} index into the hash descriptor table must match what was used
 during encoding.
-If the function succeeds it decodes the OAEP encoded message into ``out'' of length ``outlen'' and stores a
+If the function succeeds it decodes the OAEP encoded message into \textit{out} of length \textit{outlen} and stores a
-$1$ in ``res''.  If the packet is invalid it stores $0$ in ``res'' and if the function fails for another reason
+$1$ in \textit{res}.  If the packet is invalid it stores $0$ in \textit{res} and if the function fails for another reason
 it returns an error code.
-\section{PKCS \#1 Digital Signatures}
+\mysection{PKCS \#1 Digital Signatures}
 \subsection{PSS Encoding}
 PSS encoding is the second half of the PKCS \#1 standard which is padding to be applied to messages that are signed.
 \index{pkcs\_1\_pss\_encode()}
 \begin{alltt}
-int pkcs_1_pss_encode(const unsigned char *msghash, unsigned long msghashlen,
+int pkcs_1_pss_encode(
-unsigned long saltlen,  prng_state   *prng,
+const unsigned char *msghash,
-int           prng_idx, int           hash_idx,
+unsigned long  msghashlen,
-unsigned long modulus_bitlen,
+unsigned long  saltlen,
-unsigned char *out,     unsigned long *outlen);
+prng_state *prng,
+int  prng_idx,
+int  hash_idx,
+unsigned long  modulus_bitlen,
+unsigned char *out,
+unsigned long *outlen);
 \end{alltt}
-This function assumes the message to be PSS encoded has previously been hashed.  The input hash ``msghash'' is of length
+This function assumes the message to be PSS encoded has previously been hashed.  The input hash \textit{msghash} is of length
-``msghashlen''.  PSS allows a variable length random salt (it can be zero length) to be introduced in the signature process.
+\textit{msghashlen}.  PSS allows a variable length random salt (it can be zero length) to be introduced in the signature process.
-``hash\_idx'' is the index into the hash descriptor table of the hash to use.  ``prng\_idx'' and ``prng'' are the random
+\textit{hash\_idx} is the index into the hash descriptor table of the hash to use.  \textit{prng\_idx} and \textit{prng} are the random
 number generator information required for the salt.
-Similar to OAEP encoding ``modulus\_bitlen'' is the size of the RSA modulus (in bits).  It limits the size of the salt.  If $m$ is the length
+Similar to OAEP encoding \textit{modulus\_bitlen} is the size of the RSA modulus (in bits).  It limits the size of the salt.  If $m$ is the length
 of the modulus $h$ the length of the hash output (in octets) then there can be $m - h - 2$ bytes of salt.
 This function does not actually sign the data it merely pads the hash of a message so that it can be processed by rsa\_exptmod().
 \subsection{PSS Decoding}
 To decode a PSS encoded signature block you have to use the following.
 \index{pkcs\_1\_pss\_decode()}
 \begin{alltt}
-int pkcs_1_pss_decode(const unsigned char *msghash, unsigned long msghashlen,
+int pkcs_1_pss_decode(
-const unsigned char *sig,     unsigned long siglen,
+const unsigned char *msghash,
-unsigned long saltlen,  int           hash_idx,
+unsigned long  msghashlen,
-unsigned long modulus_bitlen, int    *res);
+const unsigned char *sig,
+unsigned long  siglen,
+unsigned long  saltlen,
+int  hash_idx,
+unsigned long  modulus_bitlen,
+int *res);
 \end{alltt}
-This will decode the PSS encoded message in ``sig'' of length ``siglen'' and compare it to values in ``msghash'' of length
+This will decode the PSS encoded message in \textit{sig} of length \textit{siglen} and compare it to values in \textit{msghash} of length
-``msghashlen''.  If the block is a valid PSS block and the decoded hash equals the hash supplied ``res'' is set to non--zero.  Otherwise,
+\textit{msghashlen}.  If the block is a valid PSS block and the decoded hash equals the hash supplied \textit{res} is set to non--zero.  Otherwise,
 it is set to zero.  The rest of the parameters are as in the PSS encode call.
-It's important to use the same ``saltlen'' and hash for both encoding and decoding as otherwise the procedure will not work.
+It's important to use the same \textit{saltlen} and hash for both encoding and decoding as otherwise the procedure will not work.
-\section{RSA Operations}
+\mysection{RSA Key Operations}
 \subsection{Background}
-RSA is a public key algorithm that is based on the inability to find the ``e-th'' root modulo a composite of unknown
+RSA is a public key algorithm that is based on the inability to find the \textit{e-th} root modulo a composite of unknown
 factorization.  Normally the difficulty of breaking RSA is associated with the integer factoring problem but they are
 not strictly equivalent.
-The system begins with with two primes $p$ and $q$ and their product $N = pq$.  The order or ``Euler totient'' of the
+The system begins with with two primes $p$ and $q$ and their product $N = pq$.  The order or \textit{Euler totient} of the
 multiplicative sub-group formed modulo $N$ is given as $\phi(N) = (p - 1)(q - 1)$ which can be reduced to
 $\mbox{lcm}(p - 1, q - 1)$.  The public key consists of the composite $N$ and some integer $e$ such that
 $\mbox{gcd}(e, \phi(N)) = 1$.  The private key consists of the composite $N$ and the inverse of $e$ modulo $\phi(N)$
 often simply denoted as $de \equiv 1\mbox{ }(\mbox{mod }\phi(N))$.
 A person who wants to encrypt with your public key simply forms an integer (the plaintext) $M$ such that
 $1 < M < N-2$ and computes the ciphertext $C = M^e\mbox{ }(\mbox{mod }N)$.  Since finding the inverse exponent $d$
 given only $N$ and $e$ appears to be intractable only the owner of the private key can decrypt the ciphertext and compute
 $C^d \equiv \left (M^e \right)^d \equiv M^1 \equiv M\mbox{ }(\mbox{mod }N)$.  Similarly the owner of the private key
-can sign a message by ``decrypting'' it.  Others can verify it by ``encrypting'' it.
+can sign a message by \textit{decrypting} it.  Others can verify it by \textit{encrypting} it.
 Currently RSA is a difficult system to cryptanalyze provided that both primes are large and not close to each other.
 Ideally $e$ should be larger than $100$ to prevent direct analysis.  For example, if $e$ is three and you do not pad
 the plaintext to be encrypted than it is possible that $M^3 < N$ in which case finding the cube-root would be trivial.
 The most often suggested value for $e$ is $65537$ since it is large enough to make such attacks impossible and also well
 together.  Similar tricks can be used to deduce plaintexts from ciphertexts.  It is important not only to sign
 the hash of documents only but also to pad the inputs with data to remove such structure.
 \subsection{RSA Key Generation}
-For RSA routines a single ``rsa\_key'' structure is used.  To make a new RSA key call:
+For RSA routines a single \textit{rsa\_key} structure is used.  To make a new RSA key call:
 \index{rsa\_make\_key()}
 \begin{verbatim}
 int rsa_make_key(prng_state *prng,
-int wprng, int size,
+int  wprng,
-long e, rsa_key *key);
+int  size,
-\end{verbatim}
+long  e,
+rsa_key *key);
-Where ``wprng'' is the index into the PRNG descriptor array.  ``size'' is the size in bytes of the RSA modulus desired.
+\end{verbatim}
-``e'' is the encryption exponent desired, typical values are 3, 17, 257 and 65537.  I suggest you stick with 65537 since its big
-enough to prevent trivial math attacks and not super slow.  ``key'' is where the key is placed.  All keys must be at
+Where \textit{wprng} is the index into the PRNG descriptor array.  The \textit{size} parameter is the size in bytes of the RSA modulus desired.
-least 128 bytes and no more than 512 bytes in size (\textit{that is from 1024 to 4096 bits}).
+The \textit{e} parameter is the encryption exponent desired, typical values are 3, 17, 257 and 65537.  Stick with 65537 since it is big enough to prevent
+trivial math attacks, and not super slow.  The \textit{key} parameter is where the constructed key is placed.  All keys must be at
-Note that the ``rsa\_make\_key()'' function allocates memory at runtime when you make the key.  Make sure to call
+least 128 bytes, and no more than 512 bytes in size (\textit{that is from 1024 to 4096 bits}).
-``rsa\_free()'' (see below) when you are finished with the key.  If ``rsa\_make\_key()'' fails it will automatically
-free the ram allocated itself.
+\index{rsa\_free()}
+Note: the \textit{rsa\_make\_key()} function allocates memory at run--time when you make the key.  Make sure to call
+\textit{rsa\_free()} (see below) when you are finished with the key.  If \textit{rsa\_make\_key()} fails it will automatically
+free the memory allocated.
 \index{PK\_PRIVATE} \index{PK\_PUBLIC}
 There are two types of RSA keys.  The types are {\bf PK\_PRIVATE} and {\bf PK\_PUBLIC}.  The first type is a private
-RSA key which includes the CRT parameters\footnote{As of v0.99 the PK\_PRIVATE\_OPTIMIZED type has been deprecated
+RSA key which includes the CRT parameters\footnote{As of v0.99 the PK\_PRIVATE\_OPTIMIZED type has been deprecated, and has been replaced by the
-and has been replaced by the PK\_PRIVATE type.} in the form of a RSAPrivateKey.  The second type is a public RSA key
+PK\_PRIVATE type.} in the form of a RSAPrivateKey (PKCS \#1 compliant).  The second type, is a public RSA key which only includes the modulus and public exponent.
-which only includes the modulus and public exponent.  It takes the form of a RSAPublicKey.
+It takes the form of a RSAPublicKey (PKCS \#1 compliant).
 \subsection{RSA Exponentiation}
+To do raw work with the RSA function, that is without padding, use the following function:
-To do raw work with the RSA function call:
 \index{rsa\_exptmod()}
 \begin{verbatim}
-int rsa_exptmod(const unsigned char *in,   unsigned long inlen,
+int rsa_exptmod(const unsigned char *in,
-unsigned char *out,  unsigned long *outlen,
+unsigned long  inlen,
-int which, prng_state *prng, int prng_idx,
+unsigned char *out,
-rsa_key *key);
+unsigned long *outlen,
-\end{verbatim}
+int  which,
-This loads the bignum from ``in'' as a big endian word in the format PKCS specifies, raises it to either ``e'' or ``d'' and stores the result
+rsa_key *key);
-in ``out'' and the size of the result in ``outlen''. ``which'' is set to {\bf PK\_PUBLIC} to use ``e''
+\end{verbatim}
-(i.e. for encryption/verifying) and set to {\bf PK\_PRIVATE} to use ``d'' as the exponent (i.e. for decrypting/signing).
+This will load the bignum from \textit{in} as a big endian integer in the format PKCS \#1 specifies, raises it to either \textit{e} or \textit{d} and stores the result
+in \textit{out} and the size of the result in \textit{outlen}. \textit{which} is set to {\bf PK\_PUBLIC} to use \textit{e}
-Note that the output of his function is zero-padded as per PKCS \#1 specifications.  This allows this routine to
+(i.e. for encryption/verifying) and set to {\bf PK\_PRIVATE} to use \textit{d} as the exponent (i.e. for decrypting/signing).
-interoprate with PKCS \#1 padding functions properly.
+Note: the output of this function is zero--padded as per PKCS \#1 specification.  This allows this routine to work with PKCS \#1 padding functions properly.
-\subsection{RSA Key Encryption}
+\mysection{RSA Key Encryption}
 Normally RSA is used to encrypt short symmetric keys which are then used in block ciphers to encrypt a message.
 To facilitate encrypting short keys the following functions have been provided.
 \index{rsa\_encrypt\_key()}
 \begin{verbatim}
-int rsa_encrypt_key(const unsigned char *in,  unsigned long inlen,
+int rsa_encrypt_key(
-unsigned char *out, unsigned long *outlen,
+const unsigned char *in,
-const unsigned char *lparam, unsigned long lparamlen,
+unsigned long  inlen,
-prng_state *prng, int prng_idx, int hash_idx, rsa_key *key);
+unsigned char *out,
-\end{verbatim}
+unsigned long *outlen,
-This function will OAEP pad ``in'' of length inlen bytes then RSA encrypt it and store the ciphertext
+const unsigned char *lparam,
-in ``out'' of length ``outlen''.  The ``lparam'' and ``lparamlen'' are the same parameters you would pass
+unsigned long  lparamlen,
-to pkcs\_1\_oaep\_encode().
+prng_state *prng,
+int  prng_idx,
+int  hash_idx,
+rsa_key *key);
+\end{verbatim}
+This function will OAEP pad \textit{in} of length \textit{inlen} bytes, RSA encrypt it, and store the ciphertext
+in \textit{out} of length \textit{outlen} octets.  The \textit{lparam} and \textit{lparamlen} are the same parameters you would pass
+to \index{pkcs\_1\_oaep\_encode()} pkcs\_1\_oaep\_encode().
+\subsection{Extended Encryption}
+As of v1.15, the library supports both v1.5 and v2.1 PKCS \#1 style paddings in these higher level functions.  The following is the extended
+encryption function:
+\index{rsa\_encrypt\_key\_ex()}
+\begin{verbatim}
+int rsa_encrypt_key_ex(
+const unsigned char *in,
+unsigned long  inlen,
+unsigned char *out,
+unsigned long *outlen,
+const unsigned char *lparam,
+unsigned long  lparamlen,
+prng_state *prng,
+int  prng_idx,
+int  hash_idx,
+int  padding,
+rsa_key *key);
+\end{verbatim}
+\index{LTC\_PKCS\_1\_OAEP} \index{LTC\_PKCS\_1\_V1\_5}
+The parameters are all the same as for rsa\_encrypt\_key() except for the addition of the \textit{padding} parameter.  It must be set to
+\textbf{LTC\_PKCS\_1\_V1\_5} to perform v1.5 encryption, or set to \textbf{LTC\_PKCS\_1\_OAEP} to perform v2.1 encryption.
+When performing v1.5 encryption, the hash and lparam parameters are totally ignored and can be set to \textbf{NULL} or zero (respectively).
+\mysection{RSA Key Decryption}
 \index{rsa\_decrypt\_key()}
 \begin{verbatim}
-int rsa_decrypt_key(const unsigned char *in,  unsigned long inlen,
+int rsa_decrypt_key(
-unsigned char *out, unsigned long *outlen,
+const unsigned char *in,
-const unsigned char *lparam, unsigned long lparamlen,
+unsigned long  inlen,
-int            hash_idx, int *stat,
+unsigned char *out,
-rsa_key       *key);
+unsigned long *outlen,
-\end{verbatim}
+const unsigned char *lparam,
-This function will RSA decrypt ``in'' of length ``inlen'' then OAEP depad the resulting data and store it in
+unsigned long  lparamlen,
-``out'' of length ``outlen''.  The ``lparam'' and ``lparamlen'' are the same parameters you would pass
+int  hash_idx,
+int *stat,
+rsa_key *key);
+\end{verbatim}
+This function will RSA decrypt \textit{in} of length \textit{inlen} then OAEP de-pad the resulting data and store it in
+\textit{out} of length \textit{outlen}.  The \textit{lparam} and \textit{lparamlen} are the same parameters you would pass
 to pkcs\_1\_oaep\_decode().
-If the RSA decrypted data isn't a valid OAEP packet then ``stat'' is set to $0$.  Otherwise, it is set to $1$.
+If the RSA decrypted data is not a valid OAEP packet then \textit{stat} is set to $0$.  Otherwise, it is set to $1$.
-\subsection{RSA Hash Signatures}
+\subsection{Extended Decryption}
-Similar to RSA key encryption RSA is also used to ``digitally sign'' message digests (hashes).  To facilitate this
+As of v1.15, the library supports both v1.5 and v2.1 PKCS \#1 style paddings in these higher level functions.  The following is the extended
+decryption function:
+\index{rsa\_decrypt\_key\_ex()}
+\begin{verbatim}
+int rsa_decrypt_key_ex(
+const unsigned char *in,
+unsigned long  inlen,
+unsigned char *out,
+unsigned long *outlen,
+const unsigned char *lparam,
+unsigned long  lparamlen,
+int  hash_idx,
+int  padding,
+int *stat,
+rsa_key *key);
+\end{verbatim}
+Similar to the extended encryption, the new parameter \textit{padding} indicates which version of the PKCS \#1 standard to use.
+It must be set to \textbf{LTC\_PKCS\_1\_V1\_5} to perform v1.5 decryption, or set to \textbf{LTC\_PKCS\_1\_OAEP} to perform v2.1 decryption.
+When performing v1.5 decryption, the hash and lparam parameters are totally ignored and can be set to \textbf{NULL} or zero (respectively).
+\mysection{RSA Signature Generation}
+Similar to RSA key encryption RSA is also used to \textit{digitally sign} message digests (hashes).  To facilitate this
 process the following functions have been provided.
 \index{rsa\_sign\_hash()}
 \begin{verbatim}
-int rsa_sign_hash(const unsigned char *in,   unsigned long  inlen,
+int rsa_sign_hash(const unsigned char *in,
-unsigned char *out,  unsigned long *outlen,
+unsigned long  inlen,
-prng_state    *prng,     int            prng_idx,
+unsigned char *out,
-int            hash_idx, unsigned long  saltlen,
+unsigned long *outlen,
-rsa_key *key);
+prng_state *prng,
-\end{verbatim}
+int  prng_idx,
+int  hash_idx,
-This will PSS encode the message hash ``in'' of length ``inlen''.  Next the PSS encoded message will be RSA ``signed'' and
+unsigned long  saltlen,
-the output is stored in ``out'' of length ``outlen''.
+rsa_key *key);
+\end{verbatim}
+This will PSS encode the message digest pointed to by \textit{in} of length \textit{inlen} octets.  Next, the PSS encoded hash will be RSA
+\textit{signed} and the output stored in the buffer pointed to by \textit{out} of length \textit{outlen} octets.
+The \textit{hash\_idx} parameter indicates which hash will be used to create the PSS encoding.  It should be the same as the hash used to
+hash the message being signed.  The \textit{saltlen} parameter indicates the length of the desired salt, and should typically be small.  A good
+default value is between 8 and 16 octets.  Strictly, it must be small than $modulus\_len - hLen - 2$ where \textit{modulus\_len} is the size of
+the RSA modulus (in octets), and \textit{hLen} is the length of the message digest produced by the chosen hash.
+\subsection{Extended Signatures}
+As of v1.15, the library supports both v1.5 and v2.1 signatures.  The extended signature generation function has the following prototype:
+\index{rsa\_sign\_hash\_ex()}
+\begin{verbatim}
+int rsa_sign_hash_ex(
+const unsigned char *in,
+unsigned long  inlen,
+unsigned char *out,
+unsigned long *outlen,
+int  padding,
+prng_state    *prng,
+int  prng_idx,
+int  hash_idx,
+unsigned long  saltlen,
+rsa_key *key);
+\end{verbatim}
+This will PKCS encode the message digest pointed to by \textit{in} of length \textit{inlen} octets.  Next, the PKCS encoded hash will be RSA
+\textit{signed} and the output stored in the buffer pointed to by \textit{out} of length \textit{outlen} octets.  The \textit{padding} parameter
+must be set to \textbf{LTC\_PKCS\_1\_V1\_5} to produce a v1.5 signature, otherwise, it must be set to \textbf{LTC\_PKCS\_1\_PSS} to produce a
+v2.1 signature.
+When performing a v1.5 signature the \textit{prng}, \textit{prng\_idx}, and \textit{hash\_idx} parameters are not checked and can be left to any
+values such as $\lbrace$\textbf{NULL}, 0, 0$\rbrace$.
+\mysection{RSA Signature Verification}
 \index{rsa\_verify\_hash()}
 \begin{verbatim}
-int rsa_verify_hash(const unsigned char *sig,      unsigned long siglen,
+int rsa_verify_hash(const unsigned char *sig,
-const unsigned char *msghash,  unsigned long msghashlen,
+unsigned long  siglen,
-int            hash_idx, unsigned long saltlen,
+const unsigned char *msghash,
-int           *stat,     rsa_key      *key);
+unsigned long  msghashlen,
-\end{verbatim}
+int  hash_idx,
+unsigned long  saltlen,
-This will RSA ``verify'' the signature in ``sig'' of length ``siglen''.  Next the RSA decoded data is PSS decoded
+int *stat,
-and the extracted hash is compared against the message hash ``msghash'' of length ``msghashlen''.
+rsa_key *key);
+\end{verbatim}
-If the RSA decoded data is not a valid PSS message or if the PSS decoded hash does not match the ``msghash''
-the value ``res'' is set to $0$.  Otherwise, if the function succeeds and signature is valid ``res'' is set
+This will RSA \textit{verify} the signature pointed to by \textit{sig} of length \textit{siglen} octets.  Next, the RSA decoded data is PSS decoded
-to $1$.
+and the extracted hash is compared against the message digest pointed to by \textit{msghash} of length \textit{msghashlen} octets.
+If the RSA decoded data is not a valid PSS message, or if the PSS decoded hash does not match the \textit{msghash}
+value, \textit{res} is set to $0$.  Otherwise, if the function succeeds, and signature is valid \textit{res} is set to $1$.
+\subsection{Extended Verification}
+As of v1.15, the library supports both v1.5 and v2.1 signature verification.  The extended signature verification function has the following prototype:
+\index{rsa\_verify\_hash\_ex()}
+\begin{verbatim}
+int rsa_verify_hash_ex(
+const unsigned char *sig,
+unsigned long  siglen,
+const unsigned char *hash,
+unsigned long  hashlen,
+int  padding,
+int  hash_idx,
+unsigned long  saltlen,
+int *stat,
+rsa_key *key);
+\end{verbatim}
+This will RSA \textit{verify} the signature pointed to by \textit{sig} of length \textit{siglen} octets.  Next, the RSA decoded data is PKCS decoded
+and the extracted hash is compared against the message digest pointed to by \textit{msghash} of length \textit{msghashlen} octets.
+If the RSA decoded data is not a valid PSS message, or if the PKCS decoded hash does not match the \textit{msghash}
+value, \textit{res} is set to $0$.  Otherwise, if the function succeeds, and signature is valid \textit{res} is set to $1$.
+The \textit{padding} parameter must be set to \textbf{LTC\_PKCS\_1\_V1\_5} to perform a v1.5 verification.  Otherwise, it must be set to
+\textbf{LTC\_PKCS\_1\_PSS} to perform a v2.1 verification.  When performing a v1.5 verification the \textit{hash\_idx} parameter is ignored.
+\mysection{RSA Encryption Example}
+\begin{small}
 \begin{verbatim}
 #include <tomcrypt.h>
 int main(void)
 {
 int           err, hash_idx, prng_idx, res;
 /* register prng/hash */
 if (register_prng(&sprng_desc) == -1) {
 printf("Error registering sprng");
 return EXIT_FAILURE;
 }
+/* register a math library (in this case TomsFastMath)
+ltc_mp = tfm_desc;
 if (register_hash(&sha1_desc) == -1) {
 printf("Error registering sha1");
 return EXIT_FAILURE;
 }
 return EXIT_FAILURE;
 }
 /* fill in pt[] with a key we want to send ... */
 l1 = sizeof(out);
-if ((err = rsa_encrypt_key(pt,    /* data we wish to encrypt */
+if ((err = rsa_encrypt_key(pt, /* data we wish to encrypt */
-16,    /* data is 16 bytes long */
+16, /* data is 16 bytes long */
-out,    /* where to store ciphertext */
+out, /* where to store ciphertext */
-&l1,    /* length of ciphertext */
+&l1, /* length of ciphertext */
-"TestApp",    /* our lparam for this program */
+"TestApp", /* our lparam for this program */
-7,    /* lparam is 7 bytes long */
+7, /* lparam is 7 bytes long */
-NULL,    /* PRNG state */
+NULL, /* PRNG state */
-prng_idx,    /* prng idx */
+prng_idx, /* prng idx */
-hash_idx,    /* hash idx */
+hash_idx, /* hash idx */
-&key)    /* our RSA key */
+&key) /* our RSA key */
 ) != CRYPT_OK) {
 printf("rsa_encrypt_key %s", error_to_string(err));
 return EXIT_FAILURE;
 }
 return EXIT_FAILURE;
 }
 /* if all went well pt == pt2, l2 == 16, res == 1 */
 }
 \end{verbatim}
-\chapter{Diffie-Hellman Key Exchange}
-\section{Background}
-Diffie-Hellman was the original public key system proposed.  The system is based upon the group structure
-of finite fields.  For Diffie-Hellman a prime $p$ is chosen and a ``base'' $b$ such that $b^x\mbox{ }(\mbox{mod }p)$
-generates a large sub-group of prime order (for unique values of $x$).
-A secret key is an exponent $x$ and a public key is the value of $y \equiv g^x\mbox{ }(\mbox{mod }p)$.  The term
-``discrete logarithm'' denotes the action of finding $x$ given only $y$, $g$ and $p$.  The key exchange part of
-Diffie-Hellman arises from the fact that two users A and B with keys $(A_x, A_y)$ and $(B_x, B_y)$ can exchange
-a shared key $K \equiv B_y^{A_x} \equiv A_y^{B_x} \equiv g^{A_xB_x}\mbox{ }(\mbox{mod }p)$.
-From this public encryption and signatures can be developed.  The trivial way to encrypt (for example) using a public key
-$y$ is to perform the key exchange offline.  The sender invents a key $k$ and its public copy
-$k' \equiv g^k\mbox{ }(\mbox{mod }p)$ and uses $K \equiv k'^{A_x}\mbox{ }(\mbox{mod }p)$ as a key to encrypt
-the message with.  Typically $K$ would be sent to a one-way hash and the message digested used as a key in a
-symmetric cipher.
-It is important that the order of the sub-group that $g$ generates not only be large but also prime.  There are
-discrete logarithm algorithms that take $\sqrt r$ time given the order $r$.  The discrete logarithm can be computed
-modulo each prime factor of $r$ and the results combined using the Chinese Remainder Theorem.  In the cases where
-$r$ is ``B-Smooth'' (e.g. all small factors or powers of small prime factors) the solution is trivial to find.
-To thwart such attacks the primes and bases in the library have been designed and fixed.  Given a prime $p$ the order of
-the sub-group generated is a large prime namely ${p - 1} \over 2$.  Such primes are known as ``strong primes'' and the
-smaller prime (e.g. the order of the base) are known as Sophie-Germaine primes.
-\section{Core Functions}
-This library also provides core Diffie-Hellman functions so you can negotiate keys over insecure mediums.  The routines
-provided are relatively easy to use and only take two function calls to negotiate a shared key.  There is a structure
-called ``dh\_key'' which stores the Diffie-Hellman key in a format these routines can use.  The first routine is to
-make a Diffie-Hellman private key pair:
-\index{dh\_make\_key()}
-\begin{verbatim}
-int dh_make_key(prng_state *prng, int wprng,
-int keysize, dh_key *key);
-\end{verbatim}
-The ``keysize'' is the size of the modulus you want in bytes.  Currently support sizes are 96 to 512 bytes which correspond
-to key sizes of 768 to 4096 bits. The smaller the key the faster it is to use however it will be less secure.  When
-specifying a size not explicitly supported by the library it will round {\em up} to the next key size.  If the size is
-above 512 it will return an error.  So if you pass ``keysize == 32'' it will use a 768 bit key but if you pass
-``keysize == 20000'' it will return an error.  The primes and generators used are built-into the library and were designed
-to meet very specific goals.  The primes are strong primes which means that if $p$ is the prime then
-$p-1$ is equal to $2r$ where $r$ is a large prime.  The bases are chosen to generate a group of order $r$ to prevent
-leaking a bit of the key.  This means the bases generate a very large prime order group which is good to make cryptanalysis
-hard.
-The next two routines are for exporting/importing Diffie-Hellman keys in a binary format.  This is useful for transport
-over communication mediums.
-\index{dh\_export()} \index{dh\_import()}
-\begin{verbatim}
-int dh_export(unsigned char *out, unsigned long *outlen,
-int type, dh_key *key);
-int dh_import(const unsigned char *in, unsigned long inlen, dh_key *key);
-\end{verbatim}
-These two functions work just like the ``rsa\_export()'' and ``rsa\_import()'' functions except these work with
-Diffie-Hellman keys. Its important to note you do not have to free the ram for a ``dh\_key'' if an import fails.  You can free a
-``dh\_key'' using:
-\begin{verbatim}
-void dh_free(dh_key *key);
-\end{verbatim}
-After you have exported a copy of your public key (using {\bf PK\_PUBLIC} as ``type'') you can now create a shared secret
-with the other user using:
-\index{dh\_shared\_secret()}
-\begin{verbatim}
-int dh_shared_secret(dh_key *private_key,
-dh_key *public_key,
-unsigned char *out, unsigned long *outlen);
-\end{verbatim}
-Where ``private\_key'' is the key you made and ``public\_key'' is the copy of the public key the other user sent you.  The result goes
-into ``out'' and the length into ``outlen''.  If all went correctly the data in ``out'' should be identical for both parties.  It is important to
-note that the two keys have to be the same size in order for this to work.  There is a function to get the size of a
-key:
-\index{dh\_get\_size()}
-\begin{verbatim}
-int dh_get_size(dh_key *key);
-\end{verbatim}
-This returns the size in bytes of the modulus chosen for that key.
-\subsection{Remarks on Usage}
-Its important that you hash the shared key before trying to use it as a key for a symmetric cipher or something.  An
-example program that communicates over sockets, using MD5 and 1024-bit DH keys is\footnote{This function is a small example.  It is suggested that proper packaging be used.  For example, if the public key sent is truncated these routines will not detect that.}:
-\newpage
-\begin{small}
-\begin{verbatim}
-int establish_secure_socket(int sock, int mode, unsigned char *key,
-prng_state *prng, int wprng)
-{
-unsigned char buf[4096], buf2[4096];
-unsigned long x, len;
-int res, err, inlen;
-dh_key mykey, theirkey;
-/* make up our private key */
-if ((err = dh_make_key(prng, wprng, 128, &mykey)) != CRYPT_OK)  {
-return err;
-}
-/* export our key as public */
-x = sizeof(buf);
-if ((err = dh_export(buf, &x, PK_PUBLIC, &mykey)) != CRYPT_OK) {
-res = err;
-goto done2;
-}
-if (mode == 0) {
-/* mode 0 so we send first */
-if (send(sock, buf, x, 0) != x) {
-res = CRYPT_ERROR;
-goto done2;
-}
-/* get their key */
-if ((inlen = recv(sock, buf2, sizeof(buf2), 0)) <= 0) {
-res = CRYPT_ERROR;
-goto done2;
-}
-} else {
-/* mode >0 so we send second */
-if ((inlen = recv(sock, buf2, sizeof(buf2), 0)) <= 0) {
-res = CRYPT_ERROR;
-goto done2;
-}
-if (send(sock, buf, x, 0) != x) {
-res = CRYPT_ERROR;
-goto done2;
-}
-}
-if ((err = dh_import(buf2, inlen, &theirkey)) != CRYPT_OK) {
-res = err;
-goto done2;
-}
-/* make shared secret */
-x = sizeof(buf);
-if ((err = dh_shared_secret(&mykey, &theirkey, buf, &x)) != CRYPT_OK) {
-res = err;
-goto done;
-}
-/* hash it */
-len = 16;        /* default is MD5 so "key" must be at least 16 bytes long */
-if ((err = hash_memory(find_hash("md5"), buf, x, key, &len)) != CRYPT_OK) {
-res = err;
-goto done;
-}
-/* clean up and return */
-res = CRYPT_OK;
-done:
-dh_free(&theirkey);
-done2:
-dh_free(&mykey);
-zeromem(buf,  sizeof(buf));
-zeromem(buf2, sizeof(buf2));
-return res;
-}
-\end{verbatim}
 \end{small}
-\newpage
-\subsection{Remarks on The Snippet}
+\mysection{RSA Key Format}
-When the above code snippet is done (assuming all went well) their will be a shared 128-bit key in the ``key'' array
-passed to ``establish\_secure\_socket()''.
+The RSA key format adopted for exporting and importing keys is the PKCS \#1 format defined by the ASN.1 constructs known as
+RSAPublicKey and RSAPrivateKey.  Additionally, the OpenSSL key format is supported by the import function only.
-\section{Other Diffie-Hellman Functions}
-In order to test the Diffie-Hellman function internal workings (e.g. the primes and bases) their is a test function made
+\subsection{RSA Key Export}
-available:
+To export a RSA key use the following function.
-\index{dh\_test()}
-\begin{verbatim}
+\index{rsa\_export()}
-int dh_test(void);
+\begin{verbatim}
-\end{verbatim}
+int rsa_export(unsigned char *out,
+unsigned long *outlen,
-This function returns {\bf CRYPT\_OK} if the bases and primes in the library are correct.  There is one last helper
+int  type,
-function:
+rsa_key *key);
-\index{dh\_sizes()}
+\end{verbatim}
-\begin{verbatim}
+This will export the RSA key in either a RSAPublicKey or RSAPrivateKey (PKCS \#1 types) depending on the value of \textit{type}.  When it is
-void dh_sizes(int *low, int *high);
+set to \textbf{PK\_PRIVATE} the export format will be RSAPrivateKey and otherwise it will be RSAPublicKey.
-\end{verbatim}
-Which stores the smallest and largest key sizes support into the two variables.
+\subsection{RSA Key Import}
+To import a RSA key use the following function.
-\section{DH Packet}
-Similar to the RSA related functions there are functions to encrypt or decrypt symmetric keys using the DH public key
+\index{rsa\_import()}
-algorithms.
+\begin{verbatim}
-\index{dh\_encrypt\_key()} \index{dh\_decrypt\_key()}
+int rsa_import(const unsigned char *in,
-\begin{verbatim}
+unsigned long  inlen,
-int dh_encrypt_key(const unsigned char *in,   unsigned long  inlen,
+rsa_key *key);
-unsigned char *out,  unsigned long *len,
+\end{verbatim}
-prng_state *prng, int wprng, int hash,
-dh_key *key);
+This will import the key stored in \textit{inlen} and import it to \textit{key}.  If the function fails it will automatically free any allocated memory.  This
+function can import both RSAPublicKey and RSAPrivateKey formats.
-int dh_decrypt_key(const unsigned char *in,  unsigned long  inlen,
-unsigned char *out, unsigned long *outlen,
+As of v1.06 this function can also import OpenSSL DER formatted public RSA keys.  They are essentially encapsulated RSAPublicKeys.  LibTomCrypt will
-dh_key *key);
+import the key, strip off the additional data (it's the preferred hash) and fill in the rsa\_key structure as if it were a native RSAPublicKey.  Note that
-\end{verbatim}
+there is no function provided to export in this format.
-Where ``in'' is an input symmetric key of no more than 32 bytes.  Essentially these routines created a random public key
-and find the hash of the shared secret.  The message digest is than XOR'ed against the symmetric key.  All of the
-required data is placed in ``out'' by ``dh\_encrypt\_key()''.   The hash must produce a message digest at least as large
-as the symmetric key you are trying to share.
-Similar to the RSA system you can sign and verify a hash of a message.
-\index{dh\_sign\_hash()} \index{dh\_verify\_hash()}
-\begin{verbatim}
-int dh_sign_hash(const unsigned char *in,  unsigned long inlen,
-unsigned char *out, unsigned long *outlen,
-prng_state *prng, int wprng, dh_key *key);
-int dh_verify_hash(const unsigned char *sig, unsigned long siglen,
-const unsigned char *hash, unsigned long hashlen,
-int *stat, dh_key *key);
-\end{verbatim}
-The ``dh\_sign\_hash'' function signs the message hash in ``in'' of length ``inlen'' and forms a DH packet in ``out''.
-The ``dh\_verify\_hash'' function verifies the DH signature in ``sig'' against the hash in ``hash''.  It sets ``stat''
-to non-zero if the signature passes or zero if it fails.
 \chapter{Elliptic Curve Cryptography}
-\section{Background}
+\mysection{Background}
 The library provides a set of core ECC functions as well that are designed to be the Elliptic Curve analogy of all of the
 Diffie-Hellman routines in the previous chapter.  Elliptic curves (of certain forms) have the benefit that they are harder
 to attack (no sub-exponential attacks exist unlike normal DH crypto) in fact the fastest attack requires the square root
 of the order of the base point in time.  That means if you use a base point of order $2^{192}$ (which would represent a
 192-bit key) then the work factor is $2^{96}$ in order to find the secret key.
 The curves in this library are taken from the following website:
 \begin{verbatim}
 http://csrc.nist.gov/cryptval/dss.htm
 \end{verbatim}
+As of v1.15 three new curves from the SECG standards are also included they are the secp112r1, secp128r1, and secp160r1 curves.  These curves were added to
+support smaller devices which do not need as large keys for security.
 They are all curves over the integers modulo a prime.  The curves have the basic equation that is:
 \begin{equation}
 y^2 = x^3 - 3x + b\mbox{ }(\mbox{mod }p)
 \end{equation}
 The variable $b$ is chosen such that the number of points is nearly maximal.  In fact the order of the base points $\beta$
 provided are very close to $p$ that is $\vert \vert \phi(\beta) \vert \vert \approx \vert \vert p \vert \vert$.  The curves
-range in order from $\approx 2^{192}$ points to $\approx 2^{521}$.  According to the source document any key size greater
+range in order from $\approx 2^{112}$ points to $\approx 2^{521}$.  According to the source document any key size greater
 than or equal to 256-bits is sufficient for long term security.
-\section{Key Format}
+\mysection{Fixed Point Optimizations}
-LibTomCrypt uses it's own format for ECC public and private keys.  While ANSI X9.62 partially specifies key formats (it covers public keys) it does it in a less
+\index{Fixed Point ECC}
-than ideally simple manner.  In the case of LibTomCrypt it is meant \textbf{solely} for NIST $GF(p)$ curves.  The format of the keys is as follows:
+\index{MECC\_FP}
+As of v1.12 of LibTomCrypt, support for Fixed Point ECC point multiplication has been added.  It is a generic optimization that is
+supported by any conforming math plugin.  It is enabled by defining \textbf{MECC\_FP} during the build, such as
+\begin{verbatim}
+CFLAGS="-DTFM_DESC -DMECC_FP" make
+\end{verbatim}
+which will build LTC using the TFM math library and enabling this new feature.  The feature is not enabled by default as it is \textbf{NOT} thread
+safe (by default).  It supports the LTC locking macros (such as by enabling LTC\_PTHREAD), but by default is not locked.
+\index{FP\_ENTRIES}
+The optimization works by using a Fixed Point multiplier on any base point you use twice or more in a short period of time.  It has a limited size
+cache (of FP\_ENTRIES entries) which it uses to hold recent bases passed to ltc\_ecc\_mulmod().  Any base detected to be used twice is sent through the
+pre--computation phase, and then the fixed point algorithm can be used.  For example, if you use a NIST base point twice in a row, the 2$^{nd}$ and
+all subsequent point multiplications with that point will use the faster algorithm.
+\index{FP\_LUT}
+The optimization uses a window on the multiplicand of FP\_LUT bits (default: 8, min: 2, max: 12), and this controls the memory/time trade-off. The larger the
+value the faster the algorithm will be but the more memory it will take.  The memory usage is $3 \cdot 2^{FP\_LUT}$ integers which by default
+with TFM amounts to about 400kB of memory.  Tuning TFM (by changing FP\_SIZE) can decrease the usage by a fair amount.  Memory is only used by a cache entry
+if it is active.  Both FP\_ENTRIES and FP\_LUT are definable on the command line if you wish to override them. For instance,
+\begin{verbatim}
+CFLAGS="-DTFM_DESC -DMECC_FP -DFP_ENTRIES=8 -DFP_LUT=6" make
+\end{verbatim}
+\begin{flushleft}
+\index{FP\_SIZE} \index{TFM} \index{tfm.h}
+would define a window of 6 bits and limit the cache to 8 entries.  Generally, it is better to first tune TFM by adjusting FP\_SIZE (from tfm.h).  It defaults
+to 4096 bits (512 bytes) which is way more than what is required by ECC.  At most, you need 1152 bits to accommodate ECC--521.  If you're only using (say)
+ECC--256 you will only need 576 bits, which would reduce the memory usage by 700\%.
+\end{flushleft}
+\mysection{Key Format}
+LibTomCrypt uses a unique format for ECC public and private keys.  While ANSI X9.63 partially specifies key formats, it does it in a less than ideally simple manner.  \
+In the case of LibTomCrypt, it is meant \textbf{solely} for NIST and SECG $GF(p)$ curves.  The format of the keys is as follows:
+\index{ECC Key Format}
 \begin{small}
 \begin{verbatim}
 ECCPublicKey ::= SEQUENCE {
-flags       BIT STRING(1), -- public/private flag (always zero),
+flags       BIT STRING(0), -- public/private flag (always zero),
 keySize     INTEGER,       -- Curve size (in bits) divided by eight
 -- and rounded down, e.g. 521 => 65
 pubkey.x    INTEGER,       -- The X co-ordinate of the public key point
 pubkey.y    INTEGER,       -- The Y co-ordinate of the public key point
 }
 \end{verbatim}
 \end{small}
 The first flags bit denotes whether the key is public (zero) or private (one).
-\section{Core Functions}
+\vfil
-Like the DH routines there is a key structure ``ecc\_key'' used by the functions.  There is a function to make a key:
+\mysection{ECC Curve Parameters}
+The library uses the following structure to describe an elliptic curve.  This is used internally, as well as by the new
+extended ECC functions which allow the user to specify their own curves.
+\index{ltc\_ecc\_set\_type}
+\begin{verbatim}
+/** Structure defines a NIST GF(p) curve */
+typedef struct {
+/** The size of the curve in octets */
+int size;
+/** name of curve */
+char *name;
+/** The prime that defines the field (encoded in hex) */
+char *prime;
+/** The fields B param (hex) */
+char *B;
+/** The order of the curve (hex) */
+char *order;
+/** The x co-ordinate of the base point on the curve (hex) */
+char *Gx;
+/** The y co-ordinate of the base point on the curve (hex) */
+char *Gy;
+} ltc_ecc_set_type;
+\end{verbatim}
+The curve must be of the form $y^2 = x^3 - 3x + b$, and all of the integer parameters are encoded in hexadecimal format.
+\mysection{Core Functions}
+\subsection{ECC Key Generation}
+There is a key structure called \textit{ecc\_key} used by the ECC functions.  There is a function to make a key:
 \index{ecc\_make\_key()}
 \begin{verbatim}
-int ecc_make_key(prng_state *prng, int wprng,
+int ecc_make_key(prng_state *prng,
-int keysize, ecc_key *key);
+int  wprng,
-\end{verbatim}
+int  keysize,
+ecc_key *key);
-The ``keysize'' is the size of the modulus in bytes desired.  Currently directly supported values are 24, 28, 32, 48 and 65 bytes which
+\end{verbatim}
-correspond to key sizes of 192, 224, 256, 384 and 521 bits respectively.  If you pass a key size that is between any key size
-it will round the keysize up to the next available one.  The rest of the parameters work like they do in the ``dh\_make\_key()'' function.
+The \textit{keysize} is the size of the modulus in bytes desired.  Currently directly supported values are 12, 16, 20, 24, 28, 32, 48, and 65 bytes which
-To free the ram allocated by a key call:
+correspond to key sizes of 112, 128, 160, 192, 224, 256, 384, and 521 bits respectively.  If you pass a key size that is between any key size it will round
+the keysize up to the next available one.
+The function will free any internally allocated resources if there is an error.
+\subsection{Extended Key Generation}
+As of v1.16, the library supports an extended key generation routine which allows the user to specify their own curve.  It is specified as follows:
+\index{ecc\_make\_key\_ex()}
+\begin{verbatim}
+int  ecc_make_key_ex(
+prng_state *prng,
+int  wprng,
+ecc_key *key,
+const ltc_ecc_set_type *dp);
+\end{verbatim}
+This function generates a random ECC key over the curve specified by the parameters by \textit{dp}.  The rest of the parameters are equivalent to
+those from the original key generation function.
+\subsection{ECC Key Free}
+To free the memory allocated by a ecc\_make\_key(), ecc\_make\_key\_ex(), ecc\_import(), or ecc\_import\_ex() call use the following function:
 \index{ecc\_free()}
 \begin{verbatim}
 void ecc_free(ecc_key *key);
 \end{verbatim}
-To import and export a key there are:
+\subsection{ECC Key Export}
+To export an ECC key using the LibTomCrypt format call the following function:
 \index{ecc\_export()}
+\begin{verbatim}
+int ecc_export(unsigned char *out,
+unsigned long *outlen,
+int  type,
+ecc_key *key);
+\end{verbatim}
+This will export the key with the given \textit{type} (\textbf{PK\_PUBLIC} or \textbf{PK\_PRIVATE}), and store it to \textit{out}.
+\subsection{ECC Key Import}
+The following function imports a LibTomCrypt format ECC key:
 \index{ecc\_import()}
 \begin{verbatim}
-int ecc_export(unsigned char *out, unsigned long *outlen,
+int ecc_import(const unsigned char *in,
-int type, ecc_key *key);
+unsigned long  inlen,
+ecc_key *key);
-int ecc_import(const unsigned char *in, unsigned long inlen, ecc_key *key);
+\end{verbatim}
-\end{verbatim}
+This will import the ECC key from \textit{in}, and store it in the ecc\_key structure pointed to by \textit{key}.  If the operation fails it will free
-These two work exactly like there DH counterparts.  Finally when you share your public key you can make a shared secret
+any allocated memory automatically.
-with:
+\subsection{Extended Key Import}
+The following function imports a LibTomCrypt format ECC key using a specified set of curve parameters:
+\index{ecc\_import\_ex()}
+\begin{verbatim}
+int  ecc_import_ex(const unsigned char *in,
+unsigned long  inlen,
+ecc_key *key,
+const ltc_ecc_set_type *dp);
+\end{verbatim}
+This will import the key from the array pointed to by \textit{in} of length \textit{inlen} octets.  The key is stored in
+the ECC structure pointed to by \textit{key}.  The curve is specified by the parameters pointed to by \textit{dp}.  The function will free
+all internally allocated memory upon error.
+\subsection{ANSI X9.63 Export}
+The following function exports an ECC public key in the ANSI X9.63 format:
+\index{ecc\_ansi\_x963\_export()}
+\begin{verbatim}
+int ecc_ansi_x963_export(      ecc_key *key,
+unsigned char *out,
+unsigned long *outlen);
+\end{verbatim}
+The ECC key pointed to by \textit{key} is exported in public fashion to the array pointed to by \textit{out}.  The ANSI X9.63 format used is from
+section 4.3.6 of the standard.  It does not allow for the export of private keys.
+\subsection{ANSI X9.63 Import}
+The following function imports an ANSI X9.63 section 4.3.6 format public ECC key:
+\index{ecc\_ansi\_x963\_import()}
+\begin{verbatim}
+int ecc_ansi_x963_import(const unsigned char *in,
+unsigned long  inlen,
+ecc_key *key);
+\end{verbatim}
+This will import the key stored in the array pointed to by \textit{in} of length \textit{inlen} octets.  The imported key is stored in the ECC key pointed to by
+\textit{key}.  The function will free any allocated memory upon error.
+\subsection{Extended ANSI X9.63 Import}
+The following function allows the importing of an ANSI x9.63 section 4.3.6 format public ECC key using user specified domain parameters:
+\index{ecc\_ansi\_x963\_import\_ex()}
+\begin{verbatim}
+int ecc_ansi_x963_import_ex(const unsigned char *in,
+unsigned long  inlen,
+ecc_key *key,
+ltc_ecc_set_type *dp);
+\end{verbatim}
+This will import the key stored in the array pointed to by \textit{in} of length \textit{inlen} octets using the domain parameters pointed to by \textit{dp}.
+The imported key is stored in the ECC key pointed to by \textit{key}.  The function will free any allocated memory upon error.
+\subsection{ECC Shared Secret}
+To construct a Diffie-Hellman shared secret with a private and public ECC key, use the following function:
 \index{ecc\_shared\_secret()}
 \begin{verbatim}
-int ecc_shared_secret(ecc_key *private_key,
+int ecc_shared_secret(      ecc_key *private_key,
 ecc_key *public_key,
-unsigned char *out, unsigned long *outlen);
+unsigned char *out,
-\end{verbatim}
+unsigned long *outlen);
-Which works exactly like the DH counterpart, the ``private\_key'' is your own key and ``public\_key'' is the key the other
+\end{verbatim}
-user sent you.   Note that this function stores both $x$ and $y$ co-ordinates of the shared
+The \textit{private\_key} is typically the local private key, and \textit{public\_key} is the key the remote party has shared.
-elliptic point.  You should hash the output to get a shared key in a more compact and useful form (most of the entropy is
+Note: this function stores only the $x$ co-ordinate of the shared elliptic point as described in ANSI X9.63 ECC--DH.
-in $x$ anyways).  Both keys have to be the same size for this to work, to help there is a function to get the size in bytes
-of a key.
+\mysection{ECC Diffie-Hellman Encryption}
-\index{ecc\_get\_size()}
+ECC--DH Encryption is performed by producing a random key, hashing it, and XOR'ing the digest against the plaintext.  It is not strictly ANSI X9.63 compliant
-\begin{verbatim}
+but it is very similar.  It has been extended by using an ASN.1 sequence and hash object identifiers to allow portable usage.  The following function
-int ecc_get_size(ecc_key *key);
+encrypts a short string (no longer than the message digest) using this technique:
-\end{verbatim}
+\subsection{ECC-DH Encryption}
-To test the ECC routines and to get the minimum and maximum key sizes there are these two functions:
+\index{ecc\_encrypt\_key()}
-\index{ecc\_test()}
+\begin{verbatim}
-\begin{verbatim}
+int ecc_encrypt_key(const unsigned char *in,
-int ecc_test(void);
+unsigned long  inlen,
-void ecc_sizes(int *low, int *high);
+unsigned char *out,
-\end{verbatim}
+unsigned long *outlen,
-Which both work like their DH counterparts.
+prng_state *prng,
+int  wprng,
-\section{ECC Packet}
+int  hash,
-Similar to the RSA API there are two functions which encrypt and decrypt symmetric keys using the ECC public key
+ecc_key *key);
-algorithms.
+\end{verbatim}
-\index{ecc\_encrypt\_key()} \index{ecc\_decrypt\_key()}
+As the name implies this function encrypts a (symmetric) key, and is not intended for encrypting long messages directly.  It will encrypt the
-\begin{verbatim}
+plaintext in the array pointed to by \textit{in} of length \textit{inlen} octets.  It uses the public ECC key pointed to by \textit{key}, and
-int ecc_encrypt_key(const unsigned char *in,   unsigned long  inlen,
+hash algorithm indexed by \textit{hash} to construct a shared secret which may be XOR'ed against the plaintext.  The ciphertext is stored in
-unsigned char *out,  unsigned long *outlen,
+the output buffer pointed to by \textit{out} of length \textit{outlen} octets.
-prng_state *prng, int wprng, int hash,
-ecc_key *key);
+The data is encrypted to the public ECC \textit{key} such that only the holder of the private key can decrypt the payload.  To have multiple
+recipients multiple call to this function for each public ECC key is required.
-int ecc_decrypt_key(const unsigned char *in,  unsigned long  inlen,
-unsigned char *out, unsigned long *outlen,
+\subsection{ECC-DH Decryption}
-ecc_key *key);
+\index{ecc\_decrypt\_key()}
-\end{verbatim}
+\begin{verbatim}
+int ecc_decrypt_key(const unsigned char *in,
-Where ``in'' is an input symmetric key of no more than 64 bytes.  Essentially these routines created a random public key
+unsigned long  inlen,
-and find the hash of the shared secret.  The message digest is than XOR'ed against the symmetric key.  All of the required
+unsigned char *out,
-data is placed in ``out'' by ``ecc\_encrypt\_key()''.   The hash chosen must produce a message digest at least as large
+unsigned long *outlen,
-as the symmetric key you are trying to share.
+ecc_key *key);
+\end{verbatim}
-\subsection{Encrypt Packet Format}
+This function will decrypt an encrypted payload.  The \textit{key} provided must be the private key corresponding to the public key
+used during encryption.  If the wrong key is provided the function will not specifically return an error code.  It is important
+to use some form of challenge response in that case (e.g. compute a MAC of a known string).
+\subsection{ECC Encryption Format}
 The packet format for the encrypted keys is the following ASN.1 SEQUENCE:
 \begin{verbatim}
 ECCEncrypt ::= SEQUENCE {
 hashID        OBJECT IDENTIFIER, -- OID of hash used
-pubkey        OCTET STRING     , -- Encapsulated ECCPublicKey (see above)
+pubkey        OCTET STRING     , -- Encapsulated ECCPublicKey
-skey          OCTET STRING       -- xor of plaintext and "hash of shared secret"
+skey          OCTET STRING       -- xor of plaintext and
+--"hash of shared secret"
 }
 \end{verbatim}
-There are also functions to sign and verify the hash of a message.
+\mysection{EC DSA Signatures}
-\index{ecc\_sign\_hash()} \index{ecc\_verify\_hash()}
-\begin{verbatim}
+There are also functions to sign and verify messages.  They use the ANSI X9.62 EC-DSA algorithm to generate and verify signatures in the
-int ecc_sign_hash(const unsigned char *in,  unsigned long inlen,
+ANSI X9.62 format.
-unsigned char *out, unsigned long *outlen,
-prng_state *prng, int wprng, ecc_key *key);
+\subsection{EC-DSA Signature Generation}
+To sign a message digest (hash) use the following function:
-int ecc_verify_hash(const unsigned char *sig, unsigned long siglen,
-const unsigned char *hash, unsigned long hashlen,
+\index{ecc\_sign\_hash()}
-int *stat, ecc_key *key);
+\begin{verbatim}
-\end{verbatim}
+int ecc_sign_hash(const unsigned char *in,
+unsigned long  inlen,
-The ``ecc\_sign\_hash'' function signs the message hash in ``in'' of length ``inlen'' and forms a ECC packet in ``out''.
+unsigned char *out,
-The ``ecc\_verify\_hash'' function verifies the ECC signature in ``sig'' against the hash in ``hash''.  It sets ``stat''
+unsigned long *outlen,
-to non-zero if the signature passes or zero if it fails.
+prng_state *prng,
+int  wprng,
+ecc_key *key);
+\end{verbatim}
+This function will EC--DSA sign the message digest stored in the array pointed to by \textit{in} of length \textit{inlen} octets.  The signature
+will be stored in the array pointed to by \textit{out} of length \textit{outlen} octets.  The function requires a properly seeded PRNG, and
+the ECC \textit{key} provided must be a private key.
+\subsection{EC-DSA Signature Verification}
+\index{ecc\_verify\_hash()}
+\begin{verbatim}
+int ecc_verify_hash(const unsigned char *sig,
+unsigned long  siglen,
+const unsigned char *hash,
+unsigned long  hashlen,
+int *stat,
+ecc_key *key);
+\end{verbatim}
+This function will verify the EC-DSA signature in the array pointed to by \textit{sig} of length \textit{siglen} octets, against the message digest
+pointed to by the array \textit{hash} of length \textit{hashlen}.  It will store a non--zero value in \textit{stat} if the signature is valid.  Note:
+the function will not return an error if the signature is invalid.  It will return an error, if the actual signature payload is an invalid format.
+The ECC \textit{key} must be the public (or private) ECC key corresponding to the key that performed the signature.
 \subsection{Signature Format}
-The signature code is an implementation of X9.62 EC-DSA and the output is comformant for GF(p) curves.
+The signature code is an implementation of X9.62 EC--DSA, and the output is compliant for GF(p) curves.
-\section{ECC Keysizes}
+\mysection{ECC Keysizes}
-With ECC if you try and sign a hash that is bigger than your ECC key you can run into problems.  The math will still work
+With ECC if you try to sign a hash that is bigger than your ECC key you can run into problems.  The math will still work, and in effect the signature will still
-and in effect the signature will still work.  With ECC keys the strength of the signature is limited by the size of
+work.  With ECC keys the strength of the signature is limited by the size of the hash, or the size of they key, whichever is smaller.  For example, if you sign with
-the hash or the size of they key, whichever is smaller.  For example, if you sign with SHA256 and an ECC-192 key in effect
+SHA256 and an ECC-192 key, you in effect have 96--bits of security.
-you have 192-bits of security.
+The library will not warn you if you make this mistake, so it is important to check yourself before using the signatures.
-The library will not warn you if you make this mistake so it is important to check yourself before using the
-signatures.
 \chapter{Digital Signature Algorithm}
-\section{Introduction}
+\mysection{Introduction}
 The Digital Signature Algorithm (or DSA) is a variant of the ElGamal Signature scheme which has been modified to
-reduce the bandwidth of a signature.  For example, to have ``80-bits of security'' with ElGamal you need a group of
+reduce the bandwidth of the signatures.  For example, to have \textit{80-bits of security} with ElGamal, you need a group with an order of at least 1024--bits.
-order at least 1024-bits.  With DSA you need a group of order at least 160-bits.  By comparison the ElGamal signature
+With DSA, you need a group of order at least 160--bits.  By comparison, the ElGamal signature would require at least 256 bytes of storage, whereas the DSA signature
-would require at least 256 bytes where as the DSA signature would require only at least 40 bytes.
+would require only at least 40 bytes.
-The API for the DSA is essentially the same as the other PK algorithms.  Except in the case of DSA no encryption or
+\mysection{Key Format}
-decryption routines are provided.
-\section{Key Format}
 Since no useful public standard for DSA key storage was presented to me during the course of this development I made my own ASN.1 SEQUENCE which I document
 now so that others can interoperate with this library.
 \begin{verbatim}
 DSAPublicKey ::= SEQUENCE {
-publicFlags    BIT STRING(1), -- must be 0
+publicFlags    BIT STRING(0), -- must be 0
-g              INTEGER      , -- base generator, check that g^q mod p == 1
+g              INTEGER      , -- base generator
+-- check that g^q mod p == 1
 -- and that 1 < g < p - 1
 p              INTEGER      , -- prime modulus
-q              INTEGER      , -- order of sub-group (must be prime)
+q              INTEGER      , -- order of sub-group
-y              INTEGER      , -- public key, specifically, g^x mod p,
+-- (must be prime)
+y              INTEGER      , -- public key, specifically,
+-- g^x mod p,
 -- check that y^q mod p == 1
 -- and that 1 < y < p - 1
 }
 DSAPrivateKey ::= SEQUENCE {
 publicFlags    BIT STRING(1), -- must be 1
-g              INTEGER      , -- base generator, check that g^q mod p == 1
+g              INTEGER      , -- base generator
+-- check that g^q mod p == 1
 -- and that 1 < g < p - 1
 p              INTEGER      , -- prime modulus
-q              INTEGER      , -- order of sub-group (must be prime)
+q              INTEGER      , -- order of sub-group
-y              INTEGER      , -- public key, specifically, g^x mod p,
+-- (must be prime)
+y              INTEGER      , -- public key, specifically,
+-- g^x mod p,
 -- check that y^q mod p == 1
 -- and that 1 < y < p - 1
 x              INTEGER        -- private key
 }
 \end{verbatim}
-The leading BIT STRING has a single bit in it which is zero for public keys and one for private keys.  This makes the structure uniquely decodable and easy
+The leading BIT STRING has a single bit in it which is zero for public keys and one for private keys.  This makes the structure uniquely decodable,
-to work with.
+and easy to work with.
-\section{Key Generation}
+\mysection{Key Generation}
 To make a DSA key you must call the following function
 \begin{verbatim}
-int dsa_make_key(prng_state *prng, int wprng,
+int dsa_make_key(prng_state *prng,
-int group_size, int modulus_size,
+int  wprng,
-dsa_key *key);
+int  group_size,
-\end{verbatim}
+int  modulus_size,
-The variable ``prng'' is an active PRNG state and ``wprng'' the index to the descriptor.  ``group\_size'' and
+dsa_key *key);
-``modulus\_size'' control the difficulty of forging a signature.  Both parameters are in bytes.  The larger the
+\end{verbatim}
-``group\_size'' the more difficult a forgery becomes upto a limit.  The value of $group\_size$ is limited by
+The variable \textit{prng} is an active PRNG state and \textit{wprng} the index to the descriptor.  \textit{group\_size} and
+\textit{modulus\_size} control the difficulty of forging a signature.  Both parameters are in bytes.  The larger the
+\textit{group\_size} the more difficult a forgery becomes upto a limit.  The value of $group\_size$ is limited by
 $15 < group\_size < 1024$ and $modulus\_size - group\_size < 512$.  Suggested values for the pairs are as follows.
+\begin{figure}[here]
 \begin{center}
 \begin{tabular}{|c|c|c|}
 \hline \textbf{Bits of Security} & \textbf{group\_size} & \textbf{modulus\_size} \\
 \hline 80  & 20 & 128 \\
 \hline 120 & 30 & 256 \\
 \hline 140 & 35 & 384 \\
 \hline 160 & 40 & 512 \\
 \hline
 \end{tabular}
 \end{center}
+\caption{DSA Key Sizes}
+\end{figure}
 When you are finished with a DSA key you can call the following function to free the memory used.
 \index{dsa\_free()}
 \begin{verbatim}
 void dsa_free(dsa_key *key);
 \end{verbatim}
-\section{Key Verification}
+\mysection{Key Verification}
 Each DSA key is composed of the following variables.
 \begin{enumerate}
 \item $q$ a small prime of magnitude $256^{group\_size}$.
 \item $p = qr + 1$ a large prime of magnitude $256^{modulus\_size}$ where $r$ is a random even integer.
 \index{dsa\_verify\_key()}
 \begin{verbatim}
 int dsa_verify_key(dsa_key *key, int *stat);
 \end{verbatim}
-This will test ``key'' and store the result in ``stat''.  If the result is $stat = 0$ the DSA key failed one of the tests
+This will test \textit{key} and store the result in \textit{stat}.  If the result is $stat = 0$ the DSA key failed one of the tests
 and should not be used at all.  If the result is $stat = 1$ the DSA key is valid (as far as valid mathematics are concerned).
-\section{Signatures}
+\mysection{Signatures}
-To generate a DSA signature call the following function
+\subsection{Signature Generation}
+To generate a DSA signature call the following function:
 \index{dsa\_sign\_hash()}
 \begin{verbatim}
-int dsa_sign_hash(const unsigned char *in,  unsigned long inlen,
+int dsa_sign_hash(const unsigned char *in,
-unsigned char *out, unsigned long *outlen,
+unsigned long  inlen,
-prng_state *prng, int wprng, dsa_key *key);
+unsigned char *out,
-\end{verbatim}
+unsigned long *outlen,
+prng_state *prng,
-Which will sign the data in ``in'' of length ``inlen'' bytes.  The signature is stored in ``out'' and the size
+int  wprng,
-of the signature in ``outlen''.  If the signature is longer than the size you initially specify in ``outlen'' nothing
+dsa_key *key);
-is stored and the function returns an error code.  The DSA ``key'' must be of the \textbf{PK\_PRIVATE} persuasion.
+\end{verbatim}
-To verify a hash created with that function use the following function
+Which will sign the data in \textit{in} of length \textit{inlen} bytes.  The signature is stored in \textit{out} and the size
+of the signature in \textit{outlen}.  If the signature is longer than the size you initially specify in \textit{outlen} nothing
+is stored and the function returns an error code.  The DSA \textit{key} must be of the \textbf{PK\_PRIVATE} persuasion.
+\subsection{Signature Verification}
+To verify a hash created with that function use the following function:
 \index{dsa\_verify\_hash()}
 \begin{verbatim}
-int dsa_verify_hash(const unsigned char *sig, unsigned long siglen,
+int dsa_verify_hash(const unsigned char *sig,
-const unsigned char *hash, unsigned long inlen,
+unsigned long  siglen,
-int *stat, dsa_key *key);
+const unsigned char *hash,
-\end{verbatim}
+unsigned long  inlen,
-Which will verify the data in ``hash'' of length ``inlen'' against the signature stored in ``sig'' of length ``siglen''.
+int *stat,
-It will set ``stat'' to $1$ if the signature is valid, otherwise it sets ``stat'' to $0$.
+dsa_key *key);
+\end{verbatim}
-\section{Import and Export}
+Which will verify the data in \textit{hash} of length \textit{inlen} against the signature stored in \textit{sig} of length \textit{siglen}.
+It will set \textit{stat} to $1$ if the signature is valid, otherwise it sets \textit{stat} to $0$.
-To export a DSA key so that it can be transported use the following function
+\mysection{DSA Encrypt and Decrypt}
+As of version 1.07, the DSA keys can be used to encrypt and decrypt small payloads.  It works similar to the ECC encryption where
+a shared key is computed, and the hash of the shared key XOR'ed against the plaintext forms the ciphertext.  The format used is functional port of
+the ECC encryption format to the DSA algorithm.
+\subsection{DSA Encryption}
+This function will encrypt a small payload with a recipients public DSA key.
+\index{dsa\_encrypt\_key()}
+\begin{verbatim}
+int dsa_encrypt_key(const unsigned char *in,
+unsigned long  inlen,
+unsigned char *out,
+unsigned long *outlen,
+prng_state *prng,
+int  wprng,
+int  hash,
+dsa_key *key);
+\end{verbatim}
+This will encrypt the payload in \textit{in} of length \textit{inlen} and store the ciphertext in the output buffer \textit{out}.  The
+length of the ciphertext \textit{outlen} must be originally set to the length of the output buffer.  The DSA \textit{key} can be
+a public key.
+\subsection{DSA Decryption}
+\index{dsa\_decrypt\_key()}
+\begin{verbatim}
+int dsa_decrypt_key(const unsigned char *in,
+unsigned long  inlen,
+unsigned char *out,
+unsigned long *outlen,
+dsa_key *key);
+\end{verbatim}
+This will decrypt the ciphertext \textit{in} of length \textit{inlen}, and store the original payload in \textit{out} of length \textit{outlen}.
+The DSA \textit{key} must be a private key.
+\mysection{DSA Key Import and Export}
+\subsection{DSA Key Export}
+To export a DSA key so that it can be transported use the following function:
 \index{dsa\_export()}
 \begin{verbatim}
-int dsa_export(unsigned char *out, unsigned long *outlen,
+int dsa_export(unsigned char *out,
-int type,
+unsigned long *outlen,
-dsa_key *key);
+int  type,
-\end{verbatim}
+dsa_key *key);
-This will export the DSA ``key'' to the buffer ``out'' and set the length in ``outlen'' (which must have been previously
+\end{verbatim}
-initialized to the maximum buffer size).  The ``type`` variable may be either \textbf{PK\_PRIVATE} or \textbf{PK\_PUBLIC}
+This will export the DSA \textit{key} to the buffer \textit{out} and set the length in \textit{outlen} (which must have been previously
+initialized to the maximum buffer size).  The \textit{type} variable may be either \textbf{PK\_PRIVATE} or \textbf{PK\_PUBLIC}
 depending on whether you want to export a private or public copy of the DSA key.
+\subsection{DSA Key Import}
 To import an exported DSA key use the following function
+:
 \index{dsa\_import()}
 \begin{verbatim}
-int dsa_import(const unsigned char *in, unsigned long inlen,
+int dsa_import(const unsigned char *in,
-dsa_key *key);
+unsigned long  inlen,
-\end{verbatim}
+dsa_key *key);
+\end{verbatim}
-This will import the DSA key from the buffer ``in'' of length ``inlen'' to the ``key''.  If the process fails the function
+This will import the DSA key from the buffer \textit{in} of length \textit{inlen} to the \textit{key}.  If the process fails the function
 will automatically free all of the heap allocated in the process (you don't have to call dsa\_free()).
 \chapter{Standards Support}
-\section{ASN.1 Formats}
+\mysection{ASN.1 Formats}
 LibTomCrypt supports a variety of ASN.1 data types encoded with the Distinguished Encoding Rules (DER) suitable for various cryptographic protocols.  The data types
 are all provided with three basic functions with \textit{similar} prototypes.  One function has been dedicated to calculate the length in octets of a given
-format and two functions have been dedicated to encoding and decoding the format.
+format, and two functions have been dedicated to encoding and decoding the format.
-On top of the basic data types are the SEQUENCE and\footnote{Planned for LTC 1.06} SET data types which are collections of other ASN.1 types.  They are provided
+On top of the basic data types are the SEQUENCE and SET data types which are collections of other ASN.1 types.  They are provided
-in the same manner as the other data types except they use list of objects known as the \textbf{ltc\_asn1\_list} structure.  It is defined as
+in the same manner as the other data types except they use list of objects known as the \textbf{ltc\_asn1\_list} structure.  It is defined as the following:
 \index{ltc\_asn1\_list structure}
 \begin{verbatim}
 typedef struct {
-int           type;
+int                    type;
-void         *data;
+void                  *data;
-unsigned long size;
+unsigned long          size;
-int           used;
+int                    used;
+struct ltc_asn1_list_ *prev,  *next,
+*child, *parent;
 } ltc_asn1_list;
 \end{verbatim}
-The ``type'' field is one of the following ASN.1 field definitions.  The ``data'' pointer is a void pointer to the data to be encoded (or the destination) and the
+\index{LTC\_SET\_ASN1 macro}
-``size'' field is specific to what you are encoding (e.g. number of bits in the BIT STRING data type).  The ``used'' field is primarily for the CHOICE decoder
+The \textit{type} field is one of the following ASN.1 field definitions.  The \textit{data} pointer is a void pointer to the data to be encoded (or the destination) and the
+\textit{size} field is specific to what you are encoding (e.g. number of bits in the BIT STRING data type).  The \textit{used} field is primarily for the CHOICE decoder
 and reflects if the particular member of a list was the decoded data type.  To help build the lists in an orderly fashion the macro
-``LTC\_SET\_ASN1(list, index, Type, Data, Size)'' has been provided.
+\textit{LTC\_SET\_ASN1(list, index, Type, Data, Size)} has been provided.
-It will assign to the ``index''th position in the ``list'' the tripplet (Type, Data, Size).  An example usage would be:
+It will assign to the \textit{index}th position in the \textit{list} the triplet (Type, Data, Size).  An example usage would be:
 \begin{small}
 \begin{verbatim}
 ...
 ltc_asn1_list   sequence[3];
 \begin{center}
 \begin{small}
 \begin{tabular}{|l|l|}
 \hline \textbf{Definition}           & \textbf{ASN.1 Type} \\
 \hline LTC\_ASN1\_EOL                & End of a ASN.1 list structure. \\
+\hline LTC\_ASN1\_BOOLEAN            & BOOLEAN type \\
 \hline LTC\_ASN1\_INTEGER            & INTEGER (uses mp\_int) \\
 \hline LTC\_ASN1\_SHORT\_INTEGER     & INTEGER (32--bit using unsigned long) \\
 \hline LTC\_ASN1\_BIT\_STRING        & BIT STRING (one bit per char) \\
 \hline LTC\_ASN1\_OCTET\_STRING      & OCTET STRING (one octet per char) \\
 \hline LTC\_ASN1\_NULL               & NULL \\
-\hline LTC\_ASN1\_OBJECT\_IDENTIFIER & OBJECT IDENTIFIER (words are in unsigned long) \\
+\hline LTC\_ASN1\_OBJECT\_IDENTIFIER & OBJECT IDENTIFIER  \\
 \hline LTC\_ASN1\_IA5\_STRING        & IA5 STRING (one octet per char) \\
-\hline LTC\_ASN1\_PRINTABLE\_STRING  & PRINTABLE STIRNG (one octet per char) \\
+\hline LTC\_ASN1\_UTF8\_STRING       & UTF8 STRING (one wchar\_t per char) \\
+\hline LTC\_ASN1\_PRINTABLE\_STRING  & PRINTABLE STRING (one octet per char) \\
 \hline LTC\_ASN1\_UTCTIME            & UTCTIME (see ltc\_utctime structure) \\
-\hline LTC\_ASN1\_SEQUENCE           & SEQUENCE OF \\
+\hline LTC\_ASN1\_SEQUENCE           & SEQUENCE (and SEQUENCE OF) \\
+\hline LTC\_ASN1\_SET                & SET \\
+\hline LTC\_ASN1\_SETOF              & SET OF \\
 \hline LTC\_ASN1\_CHOICE             & CHOICE \\
 \hline
 \end{tabular}
 \caption{List of ASN.1 Supported Types}
 \end{small}
 \end{figure}
 \subsection{SEQUENCE Type}
 The SEQUENCE data type is a collection of other ASN.1 data types encapsulated with a small header which is a useful way of sending multiple data types in one packet.
-\subsubsection{SEUQNECE Encoding}
+\subsubsection{SEQUENCE Encoding}
 To encode a sequence a \textbf{ltc\_asn1\_list} array must be initialized with the members of the sequence and their respective pointers.  The encoding is performed
 with the following function.
 \index{der\_encode\_sequence()}
 \begin{verbatim}
-int der_encode_sequence(ltc_asn1_list *list, unsigned long inlen,
+int der_encode_sequence(ltc_asn1_list *list,
-unsigned char *out,  unsigned long *outlen);
+unsigned long  inlen,
-\end{verbatim}
+unsigned char *out,
-This encodes a sequence of items pointed to by ``list'' where the list has ``inlen'' items in it.  The SEQUENCE will be encoded to ``out'' and of length ``outlen''.  The
+unsigned long *outlen);
-function will terminate when it reads all the items out of the list (upto ``inlen'') or it encounters an item in the list with a type of \textbf{LTC\_ASN1\_EOL}.
+\end{verbatim}
+This encodes a sequence of items pointed to by \textit{list} where the list has \textit{inlen} items in it.  The SEQUENCE will be encoded to \textit{out} and of length \textit{outlen}.  The
-The ``data'' pointer in the list would be the same pointer you would pass to the respective ASN.1 encoder (e.g. der\_encode\_bit\_string()) and it is simply passed on
+function will terminate when it reads all the items out of the list (upto \textit{inlen}) or it encounters an item in the list with a type of \textbf{LTC\_ASN1\_EOL}.
+The \textit{data} pointer in the list would be the same pointer you would pass to the respective ASN.1 encoder (e.g. der\_encode\_bit\_string()) and it is simply passed on
 verbatim to the dependent encoder.  The list can contain other SEQUENCE or SET types which enables you to have nested SEQUENCE and SET definitions.  In these cases
-the ``data'' pointer is simply a pointer to another \textbf{ltc\_asn1\_list}.
+the \textit{data} pointer is simply a pointer to another \textbf{ltc\_asn1\_list}.
 \subsubsection{SEQUENCE Decoding}
 \index{der\_decode\_sequence()}
-Decoding a SEQUENCE is similar to encoding.  You set up an array of \textbf{ltc\_asn1\_list} where in this case the ``size'' member is the maximum size
+Decoding a SEQUENCE is similar to encoding.  You set up an array of \textbf{ltc\_asn1\_list} where in this case the \textit{size} member is the maximum size
-(in certain cases).  For types such as IA5 STRING, BIT STRING, OCTET STRING (etc) the ``size'' field is updated after successful decoding to reflect how many
+(in certain cases).  For types such as IA5 STRING, BIT STRING, OCTET STRING (etc) the \textit{size} field is updated after successful decoding to reflect how many
 units of the respective type has been loaded.
 \begin{verbatim}
-int der_decode_sequence(const unsigned char *in,   unsigned long  inlen,
+int der_decode_sequence(const unsigned char *in,
-ltc_asn1_list *list, unsigned long  outlen);
+unsigned long  inlen,
-\end{verbatim}
+ltc_asn1_list *list,
+unsigned long  outlen);
-This will decode upto ``outlen'' items from the input buffer ``in'' of length ``inlen'' octets.  The function will stop (gracefully) when it runs out of items to decode.
+\end{verbatim}
-It will fail (for among other reasons) when it runs out of input bytes to read, a data type is invalid or a heap failure occured.
+This will decode upto \textit{outlen} items from the input buffer \textit{in} of length \textit{inlen} octets.  The function will stop (gracefully) when it runs out of items to decode.
-For the following types the ``size'' field will be updated to reflect the number of units read of the given type.
+It will fail (for among other reasons) when it runs out of input bytes to read, a data type is invalid or a heap failure occurred.
+For the following types the \textit{size} field will be updated to reflect the number of units read of the given type.
 \begin{enumerate}
 \item BIT STRING
 \item OCTET STRING
 \item OBJECT IDENTIFIER
 \item IA5 STRING
 The length of a SEQUENCE can be determined with the following function.
 \index{der\_length\_sequence()}
 \begin{verbatim}
-int der_length_sequence(ltc_asn1_list *list, unsigned long inlen,
+int der_length_sequence(ltc_asn1_list *list,
+unsigned long  inlen,
 unsigned long *outlen);
 \end{verbatim}
-This will get the encoding size for the given ``list'' of length ``inlen'' and store it in ``outlen''.
+This will get the encoding size for the given \textit{list} of length \textit{inlen} and store it in \textit{outlen}.
 \subsubsection{SEQUENCE Multiple Argument Lists}
 For small or simple sequences an encoding or decoding can be performed with one of the following two functions.
 \index{der\_encode\_sequence\_multi()}
 \index{der\_decode\_sequence\_multi()}
 \begin{verbatim}
-int der_encode_sequence_multi(unsigned char *out, unsigned long *outlen, ...);
+int der_encode_sequence_multi(unsigned char *out,
-int der_decode_sequence_multi(const unsigned char *in, unsigned long inlen, ...);
+unsigned long *outlen, ...);
+int der_decode_sequence_multi(const unsigned char *in,
+unsigned long  inlen, ...);
 \end{verbatim}
 These either encode or decode (respectively) a SEQUENCE data type where the items in the sequence are specified after the length parameter.
-The list of items are specified as a triple of the form ``(type, size, data)''  where ``type'' is an \textbf{int}, ``size'' is a \textbf{unsigned long}
+The list of items are specified as a triple of the form \textit{(type, size, data)}  where \textit{type} is an \textbf{int}, \textit{size} is a \textbf{unsigned long}
-and ``data'' is \textbf{void} pointer.  The list of items must be terminated with an item with the type \textbf{LTC\_ASN1\_EOL}.
+and \textit{data} is \textbf{void} pointer.  The list of items must be terminated with an item with the type \textbf{LTC\_ASN1\_EOL}.
-It's ideal that you cast the ``size'' values to unsigned long to ensure that the proper data type is passed to the function.  Constants such as ``1'' without
+It is ideal that you cast the \textit{size} values to unsigned long to ensure that the proper data type is passed to the function.  Constants such as \textit{1} without
-a cast or prototype are of type \textbf{int} by default.  Appending \textit{UL} or prepending \textit{(unsigned long)} is enough to cast it to the correct type.
+a cast or prototype are of type \textbf{int} by default.  Appending \textit{UL} or pre-pending \textit{(unsigned long)} is enough to cast it to the correct type.
+\begin{small}
+\begin{verbatim}
+unsigned char buf[MAXBUFSIZE];
+unsigned long buflen;
+int           err;
+buflen = sizeof(buf);
+if ((err =
+der_encode_sequence_multi(buf, &buflen,
+LTC_ASN1_IA5_STRING, 5UL, "Hello",
+LTC_ASN1_IA5_STRING, 7UL, " World!",
+LTC_ASN1_EOL,        0UL, NULL)) != CRYPT_OK) {
+// error handling
+}
+\end{verbatim}
+\end{small}
+This example encodes a SEQUENCE with two IA5 STRING types containing ``Hello'' and `` World!'' respectively.  Note the usage of the \textbf{UL} modifier
+on the size parameters.  This forces the compiler to pass the numbers as the required \textbf{unsigned long} type that the function expects.
+\subsection{SET and SET OF}
+\index{SET} \index{SET OF}
+SET and SET OF are related to the SEQUENCE type in that they can be pretty much be decoded with the same code.  However, they are different, and they should
+be carefully noted.  The SET type is an unordered array of ASN.1 types sorted by the TAG (type identifier), whereas the SET OF type is an ordered array of
+a \textbf{single} ASN.1 object sorted in ascending order by the DER their respective encodings.
+\subsubsection{SET Encoding}
+SETs use the same array structure of ltc\_asn1\_list that the SEQUENCE functions use.  They are encoded with the following function:
+\index{der\_encode\_set()}
+\begin{verbatim}
+int der_encode_set(ltc_asn1_list *list,
+unsigned long  inlen,
+unsigned char *out,
+unsigned long *outlen);
+\end{verbatim}
+This will encode the list of ASN.1 objects in \textit{list} of length \textit{inlen} objects, and store the output in \textit{out} of length \textit{outlen} bytes.
+The function will make a copy of the list provided, and sort it by the TAG.  Objects with identical TAGs are additionally sorted on their original placement in the
+array (to make the process deterministic).
+This function will \textbf{NOT} recognize \textit{DEFAULT} objects, and it is the responsibility of the caller to remove them as required.
+\subsubsection{SET Decoding}
+The SET type can be decoded with the following function.
+\index{der\_decode\_set()}
+\begin{verbatim}
+int der_decode_set(const unsigned char *in,
+unsigned long  inlen,
+ltc_asn1_list *list,
+unsigned long  outlen);
+\end{verbatim}
+This will decode the SET specified by \textit{list} of length \textit{outlen} objects from the input buffer \textit{in} of length \textit{inlen} octets.
+It handles the fact that SETs are not strictly ordered and will make multiple passes (as required) through the list to decode all the objects.
+\subsubsection{SET Length}
+The length of a SET can be determined by calling der\_length\_sequence() since they have the same encoding length.
+\subsubsection{SET OF Encoding}
+A \textit{SET OF} object is an array of identical objects (e.g. OCTET STRING) sorted in ascending order by the DER encoding of the object.  They are
+used to store objects deterministically based solely on their encoding.  It uses the same array structure of ltc\_asn1\_list that the SEQUENCE functions
+use.  They are encoded with the following function.
+\index{der\_encode\_setof()}
+\begin{verbatim}
+int der_encode_setof(ltc_asn1_list *list,
+unsigned long  inlen,
+unsigned char *out,
+unsigned long *outlen);
+\end{verbatim}
+This will encode a \textit{SET OF} containing the \textit{list} of \textit{inlen} ASN.1 objects and store the encoding in the output buffer \textit{out} of length \textit{outlen}.
+The routine will first encode the SET OF in an unordered fashion (in a temporary buffer) then sort using the XQSORT macro and copy back to the output buffer.  This
+means you need at least enough memory to keep an additional copy of the output on the heap.
+\subsubsection{SET OF Decoding}
+Since the decoding of a \textit{SET OF} object is unambiguous it can be decoded with der\_decode\_sequence().
+\subsubsection{SET OF Length}
+Like the SET type the der\_length\_sequence() function can be used to determine the length of a \textit{SET OF} object.
 \subsection{ASN.1 INTEGER}
 To encode or decode INTEGER data types use the following functions.
-\index{der\_encode\_integer()}
+\index{der\_encode\_integer()}\index{der\_decode\_integer()}\index{der\_length\_integer()}
-\index{der\_decode\_integer()}
+\begin{verbatim}
-\index{der\_length\_integer()}
+int der_encode_integer(         void *num,
-\begin{verbatim}
+unsigned char *out,
-int der_encode_integer(mp_int *num, unsigned char *out, unsigned long *outlen);
+unsigned long *outlen);
-int der_decode_integer(const unsigned char *in, unsigned long inlen, mp_int *num);
-int der_length_integer(mp_int *num, unsigned long *len);
+int der_decode_integer(const unsigned char *in,
-\end{verbatim}
+unsigned long  inlen,
+void *num);
-These will encode or decode a signed INTEGER data type using the ``mp\_int'' data type to store the large INTEGER.  To encode smaller values without allocating
-an mp\_int to store the value the ``short'' INTEGER functions were made available.
+int der_length_integer(         void *num,
+unsigned long *len);
-\index{der\_encode\_short\_integer()}
+\end{verbatim}
-\index{der\_decode\_short\_integer()}
-\index{der\_length\_short\_integer()}
+These will encode or decode a signed INTEGER data type using the bignum data type to store the large INTEGER.  To encode smaller values without allocating
+a bignum to store the value, the \textit{short} INTEGER functions were made available.
+\index{der\_encode\_short\_integer()}\index{der\_decode\_short\_integer()}\index{der\_length\_short\_integer()}
 \begin{verbatim}
 int der_encode_short_integer(unsigned long  num,
-unsigned char *out, unsigned long *outlen);
+unsigned char *out,
+unsigned long *outlen);
-int der_decode_short_integer(const unsigned char *in,  unsigned long inlen,
+int der_decode_short_integer(const unsigned char *in,
+unsigned long  inlen,
 unsigned long *num);
-int der_length_short_integer(unsigned long num, unsigned long *outlen);
+int der_length_short_integer(unsigned long  num,
+unsigned long *outlen);
 \end{verbatim}
 These will encode or decode an unsigned \textbf{unsigned long} type (only reads upto 32--bits).  For values in the range $0 \dots 2^{32} - 1$ the integer
 and short integer functions can encode and decode each others outputs.
 \subsection{ASN.1 BIT STRING}
-\index{der\_encode\_bit\_string()}
+\index{der\_encode\_bit\_string()}\index{der\_decode\_bit\_string()}\index{der\_length\_bit\_string()}
-\index{der\_decode\_bit\_string()}
+\begin{verbatim}
-\index{der\_length\_bit\_string()}
+int der_encode_bit_string(const unsigned char *in,
-\begin{verbatim}
+unsigned long  inlen,
-int der_encode_bit_string(const unsigned char *in, unsigned long inlen,
+unsigned char *out,
-unsigned char *out, unsigned long *outlen);
+unsigned long *outlen);
-int der_decode_bit_string(const unsigned char *in, unsigned long inlen,
+int der_decode_bit_string(const unsigned char *in,
-unsigned char *out, unsigned long *outlen);
+unsigned long  inlen,
+unsigned char *out,
-int der_length_bit_string(unsigned long nbits, unsigned long *outlen);
+unsigned long *outlen);
-\end{verbatim}
+int der_length_bit_string(unsigned long  nbits,
-These will encode or decode a BIT STRING data type.  The bits are passed in (or read out) using one \textbf{char} per bit.  A non--zero value will be interpretted
+unsigned long *outlen);
-as a one bit and a zero value a zero bit.
+\end{verbatim}
+These will encode or decode a BIT STRING data type.  The bits are passed in (or read out) using one \textbf{char} per bit.  A non--zero value will be interpreted
+as a one bit, and a zero value a zero bit.
 \subsection{ASN.1 OCTET STRING}
-\index{der\_encode\_octet\_string()}
+\index{der\_encode\_octet\_string()}\index{der\_decode\_octet\_string()}\index{der\_length\_octet\_string()}
-\index{der\_decode\_octet\_string()}
+\begin{verbatim}
-\index{der\_length\_octet\_string()}
+int der_encode_octet_string(const unsigned char *in,
-\begin{verbatim}
+unsigned long  inlen,
-int der_encode_octet_string(const unsigned char *in, unsigned long inlen,
+unsigned char *out,
-unsigned char *out, unsigned long *outlen);
+unsigned long *outlen);
-int der_decode_octet_string(const unsigned char *in, unsigned long inlen,
+int der_decode_octet_string(const unsigned char *in,
-unsigned char *out, unsigned long *outlen);
+unsigned long  inlen,
+unsigned char *out,
-int der_length_octet_string(unsigned long noctets, unsigned long *outlen);
+unsigned long *outlen);
-\end{verbatim}
+int der_length_octet_string(unsigned long  noctets,
-These will encode or decode an OCTET STRING data type.  The octets are stored using one \textbf{char} each.
+unsigned long *outlen);
+\end{verbatim}
+These will encode or decode an OCTET STRING data type.  The octets are stored using one \textbf{unsigned char} each.
 \subsection{ASN.1 OBJECT IDENTIFIER}
-\index{der\_encode\_object\_identifier()}
+\index{der\_encode\_object\_identifier()}\index{der\_decode\_object\_identifier()}\index{der\_length\_object\_identifier()}
-\index{der\_decode\_object\_identifier()}
+\begin{verbatim}
-\index{der\_length\_object\_identifier()}
+int der_encode_object_identifier(unsigned long *words,
-\begin{verbatim}
+unsigned long  nwords,
-int der_encode_object_identifier(unsigned long *words, unsigned long  nwords,
+unsigned char *out,
-unsigned char *out,   unsigned long *outlen);
-int der_decode_object_identifier(const unsigned char *in,    unsigned long  inlen,
-unsigned long *words, unsigned long *outlen);
-int der_length_object_identifier(unsigned long *words, unsigned long nwords,
 unsigned long *outlen);
-\end{verbatim}
+int der_decode_object_identifier(const unsigned char *in,
-These will encode or decode an OBJECT IDENTIFIER object.  The words of the OID are stored in individual \textbf{unsigned long} elements and must be in the range
+unsigned long  inlen,
+unsigned long *words,
+unsigned long *outlen);
+int der_length_object_identifier(unsigned long *words,
+unsigned long  nwords,
+unsigned long *outlen);
+\end{verbatim}
+These will encode or decode an OBJECT IDENTIFIER object.  The words of the OID are stored in individual \textbf{unsigned long} elements, and must be in the range
 $0 \ldots 2^{32} - 1$.
 \subsection{ASN.1 IA5 STRING}
-\index{der\_encode\_ia5\_string()}
+\index{der\_encode\_ia5\_string()}\index{der\_decode\_ia5\_string()}\index{der\_length\_ia5\_string()}
-\index{der\_decode\_ia5\_string()}
+\begin{verbatim}
-\index{der\_length\_ia5\_string()}
+int der_encode_ia5_string(const unsigned char *in,
-\begin{verbatim}
+unsigned long  inlen,
-int der_encode_ia5_string(const unsigned char *in, unsigned long inlen,
+unsigned char *out,
-unsigned char *out, unsigned long *outlen);
-int der_decode_ia5_string(const unsigned char *in, unsigned long inlen,
-unsigned char *out, unsigned long *outlen);
-int der_length_ia5_string(const unsigned char *octets, unsigned long noctets,
 unsigned long *outlen);
-\end{verbatim}
+int der_decode_ia5_string(const unsigned char *in,
-These will encode or decode an IA5 STRING.  The characters are read or stored in individual \textbf{char} elements.  This functions performs internal character
+unsigned long  inlen,
+unsigned char *out,
+unsigned long *outlen);
+int der_length_ia5_string(const unsigned char *octets,
+unsigned long  noctets,
+unsigned long *outlen);
+\end{verbatim}
+These will encode or decode an IA5 STRING.  The characters are read or stored in individual \textbf{char} elements.  These functions performs internal character
 to numerical conversions based on the conventions of the compiler being used.  For instance, on an x86\_32 machine 'A' == 65 but the same may not be true on
-say a SPARC machine.  Internally these functions have a table of literal characters and their numerical ASCII values.  This provides a stable conversion provided
+say a SPARC machine.  Internally, these functions have a table of literal characters and their numerical ASCII values.  This provides a stable conversion provided
-that the build platform honours the runtime platforms character conventions.
+that the build platform honours the run--time platforms character conventions.
-If you're worried try building the test suite and running it.  It has hard coded test vectors to ensure it is operating properly.
 \subsection{ASN.1 PRINTABLE STRING}
-\index{der\_encode\_printable\_string()}
+\index{der\_encode\_printable\_string()}\index{der\_decode\_printable\_string()}\index{der\_length\_printable\_string()}
-\index{der\_decode\_printable\_string()}
+\begin{verbatim}
-\index{der\_length\_printable\_string()}
+int der_encode_printable_string(const unsigned char *in,
-\begin{verbatim}
+unsigned long  inlen,
-int der_encode_printable_string(const unsigned char *in, unsigned long inlen,
+unsigned char *out,
-unsigned char *out, unsigned long *outlen);
+unsigned long *outlen);
-int der_decode_printable_string(const unsigned char *in, unsigned long inlen,
+int der_decode_printable_string(const unsigned char *in,
-unsigned char *out, unsigned long *outlen);
+unsigned long  inlen,
+unsigned char *out,
-int der_length_printable_string(const unsigned char *octets, unsigned long noctets,
+unsigned long *outlen);
-unsigned long *outlen);
-\end{verbatim}
+int der_length_printable_string(const unsigned char *octets,
+unsigned long  noctets,
-These will encode or decode an PRINTABLE STRING.  The characters are read or stored in individual \textbf{char} elements.  This functions performs internal character
+unsigned long *outlen);
+\end{verbatim}
+These will encode or decode an PRINTABLE STRING.  The characters are read or stored in individual \textbf{char} elements.  These functions performs internal character
 to numerical conversions based on the conventions of the compiler being used.  For instance, on an x86\_32 machine 'A' == 65 but the same may not be true on
-say a SPARC machine.  Internally these functions have a table of literal characters and their numerical ASCII values.  This provides a stable conversion provided
+say a SPARC machine.  Internally, these functions have a table of literal characters and their numerical ASCII values.  This provides a stable conversion provided
-that the build platform honours the runtime platforms character conventions.
+that the build platform honours the run-time platforms character conventions.
-If you're worried try building the test suite and running it.  It has hard coded test vectors to ensure it is operating properly.
+\subsection{ASN.1 UTF8 STRING}
+\index{der\_encode\_utf8\_string()}\index{der\_decode\_utf8\_string()}\index{der\_length\_utf8\_string()}
+\begin{verbatim}
+int der_encode_utf8_string(const wchar_t *in,
+unsigned long  inlen,
+unsigned char *out,
+unsigned long *outlen);
+int der_decode_utf8_string(const unsigned char *in,
+unsigned long  inlen,
+wchar_t *out,
+unsigned long *outlen);
+int der_length_utf8_string(const wchar_t *octets,
+unsigned long  noctets,
+unsigned long *outlen);
+\end{verbatim}
+These will encode or decode an UTF8 STRING.  The characters are read or stored in individual \textbf{wchar\_t} elements.  These function performs no internal
+mapping and treat the characters as literals.
+These functions use the \textbf{wchar\_t} type which is not universally available.  In those cases, the library will typedef it to \textbf{unsigned long}.  If you
+intend to use the ISO C functions for working with wide--char arrays, you should make sure that wchar\_t has been defined previously.
 \subsection{ASN.1 UTCTIME}
 The UTCTIME type is to store a date and time in ASN.1 format.  It uses the following structure to organize the time.
+\index{ltc\_utctime structure}
 \begin{verbatim}
 typedef struct {
 unsigned YY, /* year    00--99 */
 MM, /* month   01--12 */
 DD, /* day     01--31 */
 off_hh, /* timezone offset hours */
 off_mm; /* timezone offset minutes */
 } ltc_utctime;
 \end{verbatim}
-The time can be offset plus or minus a set amount of hours (off\_hh) and minutes (off\_mm).  When ``off\_dir'' is zero the time will be added otherwise it
+The time can be offset plus or minus a set amount of hours (off\_hh) and minutes (off\_mm).  When \textit{off\_dir} is zero, the time will be added otherwise it
-will be subtracted.
+will be subtracted.  For instance, the array $\lbrace 5, 6, 20, 22, 4, 00, 0, 5, 0 \rbrace$ represents the current time of
+\textit{2005, June 20th, 22:04:00} with a time offset of +05h00.
-For instance, the array $\lbrace 5, 6, 20, 22, 4, 00, 0, 5, 0 \rbrace$ represents the current time of 2005, June 20th, 22:04:00 with a time offset of +05h00.
+\index{der\_encode\_utctime()}\index{der\_decode\_utctime()}\index{der\_length\_utctime()}
-\index{der\_encode\_utctime()}
+\begin{verbatim}
-\index{der\_decode\_utctime()}
+int der_encode_utctime(  ltc_utctime *utctime,
-\index{der\_length\_utctime()}
+unsigned char *out,
-\begin{verbatim}
+unsigned long *outlen);
-int der_encode_utctime(ltc_utctime *utctime,
-unsigned char *out,   unsigned long *outlen);
+int der_decode_utctime(const unsigned char *in,
+unsigned long *inlen,
-int der_decode_utctime(const unsigned char *in, unsigned long *inlen,
+ltc_utctime *out);
-ltc_utctime   *out);
+int der_length_utctime(  ltc_utctime *utctime,
-int der_length_utctime(ltc_utctime *utctime, unsigned long *outlen);
+unsigned long *outlen);
 \end{verbatim}
-The encoder will store time in one of the two ASN.1 formats, either ``YYMMDDhhmmssZ'' or ``YYMMDDhhmmss$\pm$hhmm'' and perform minimal error checking on the
+The encoder will store time in one of the two ASN.1 formats, either \textit{YYMMDDhhmmssZ} or \textit{YYMMDDhhmmss$\pm$hhmm}, and perform minimal error checking on the
 input.  The decoder will read all valid ASN.1 formats and perform range checking on the values (not complete but rational) useful for catching packet errors.
 It is suggested that decoded data be further scrutinized (e.g. days of month in particular).
 \subsection{ASN.1 CHOICE}
-The CHOICE ASN.1 type represents a union of ASN.1 types all of which are stored in a ``ltc\_asn1\_list''.  There is no encoder for the CHOICE type, only a
+The CHOICE ASN.1 type represents a union of ASN.1 types all of which are stored in a \textit{ltc\_asn1\_list}.  There is no encoder for the CHOICE type, only a
 decoder.  The decoder will scan through the provided list attempting to use the appropriate decoder on the input packet.  The list can contain any ASN.1 data
 type\footnote{Except it cannot have LTC\_ASN1\_INTEGER and LTC\_ASN1\_SHORT\_INTEGER simultaneously.} except for other CHOICE types.
 There is no encoder for the CHOICE type as the actual DER encoding is the encoding of the chosen type.
 \index{der\_decode\_choice()}
 \begin{verbatim}
-int der_decode_choice(const unsigned char *in,   unsigned long *inlen,
+int der_decode_choice(const unsigned char *in,
-ltc_asn1_list *list, unsigned long  outlen);
+unsigned long *inlen,
-\end{verbatim}
+ltc_asn1_list *list,
+unsigned long  outlen);
-This will decode the input in the ``in'' field of length ``inlen''.  It uses the provided ASN.1 list specified in the ``list'' field which has ``outlen'' elements.
+\end{verbatim}
-The ``inlen'' field will be updated with the length of the decoded data type as well as the respective entry in the ``list'' field will have the ``used'' flag
-set to non--zero to reflect it was the data type decoded.
+This will decode the input in the \textit{in} field of length \textit{inlen}.  It uses the provided ASN.1 list specified in the \textit{list} field which has
+\textit{outlen} elements.  The \textit{inlen} field will be updated with the length of the decoded data type, as well as the respective entry in the \textit{list} field
-\section{Password Based Cryptography}
+will have the \textit{used} flag set to non--zero to reflect it was the data type decoded.
+\subsection{ASN.1 Flexi Decoder}
+The ASN.1 \textit{flexi} decoder allows the developer to decode arbitrary ASN.1 DER packets (provided they use data types LibTomCrypt supports) without first knowing
+the structure of the data.  Where der\_decode \_sequence() requires the developer to specify the data types to decode in advance the flexi decoder is entirely
+free form.
+The flexi decoder uses the same \textit{ltc\_asn1\_list} but instead of being stored in an array it uses the linked list pointers \textit{prev}, \textit{next}, \textit{parent}
+and \textit{child}.  The list works as a \textit{doubly-linked list} structure where decoded items at the same level are siblings (using next and prev) and items
+encoded in a SEQUENCE are stored as a child element.
+When a SEQUENCE or SET has been encountered a SEQUENCE (or SET resp.) item will be added as a sibling (e.g. list.type == LTC\_ASN1\_SEQUENCE) and the child
+pointer points to a new list of items contained within the object.
+\index{der\_decode\_sequence\_flexi()}
+\begin{verbatim}
+int  der_decode_sequence_flexi(const unsigned char *in,
+unsigned long *inlen,
+ltc_asn1_list **out);
+\end{verbatim}
+This will decode items in the \textit{in} buffer of max input length \textit{inlen} and store the newly created pointer to the list in \textit{out}.  This function allocates
+all required memory for the decoding.  It stores the number of octets read back into \textit{inlen}.
+The function will terminate when either it hits an invalid ASN.1 tag, or it reads \textit{inlen} octets.  An early termination is a soft error, and returns
+normally.  The decoded list \textit{out} will point to the very first element of the list (e.g. both parent and prev pointers will be \textbf{NULL}).
+An invalid decoding will terminate the process, and free the allocated memory automatically.
+\textbf{Note:} the list decoded by this function is \textbf{NOT} in the correct form for der\_encode\_sequence() to use directly.  You will have to first
+have to convert the list by first storing all of the siblings in an array then storing all the children as sub-lists of a sequence using the \textit{.data}
+pointer.  Currently no function in LibTomCrypt provides this ability.
+\subsubsection{Sample Decoding}
+Suppose we decode the following structure:
+\begin{small}
+\begin{verbatim}
+User ::= SEQUENCE {
+Name        IA5 STRING
+LoginToken  SEQUENCE {
+passwdHash   OCTET STRING
+pubkey       ECCPublicKey
+}
+LastOn      UTCTIME
+}
+\end{verbatim}
+\end{small}
+\begin{flushleft}and we decoded it with the following code:\end{flushleft}
+\begin{small}
+\begin{verbatim}
+unsigned char inbuf[MAXSIZE];
+unsigned long inbuflen;
+ltc_asn1_list *list;
+int           err;
+/* somehow fill inbuf/inbuflen */
+if ((err = der_decode_sequence_flexi(inbuf, inbuflen, &list)) != CRYPT_OK) {
+printf("Error decoding: %s\n", error_to_string(err));
+exit(EXIT_FAILURE);
+}
+\end{verbatim}
+\end{small}
+At this point \textit{list} would point to the SEQUENCE identified by \textit{User}.  It would have no sibblings (prev or next), and only a child node.  Walking to the child
+node with the following code will bring us to the \textit{Name} portion of the SEQUENCE:
+\begin{small}
+\begin{verbatim}
+list = list->child;
+\end{verbatim}
+\end{small}
+Now \textit{list} points to the \textit{Name} member (with the tag IA5 STRING).  The \textit{data}, \textit{size}, and \textit{type} members of \textit{list} should reflect
+that of an IA5 STRING.  The sibbling will now be the \textit{LoginToken} SEQUENCE.  The sibbling has a child node which points to the \textit{passwdHash} OCTET STRING.
+We can walk to this node with the following code:
+\begin{small}
+\begin{verbatim}
+/* list already pointing to 'Name' */
+list = list->next->child;
+\end{verbatim}
+\end{small}
+At this point, \textit{list} will point to the \textit{passwdHash} member of the innermost SEQUENCE.  This node has a sibbling, the \textit{pubkey} member of the SEQUENCE.
+The \textit{LastOn} member of the SEQUENCE is a sibbling of the LoginToken node, if we wanted to walk there we would have to go up and over via:
+\begin{small}
+\begin{verbatim}
+list = list->parent->next;
+\end{verbatim}
+\end{small}
+At this point, we are pointing to the last node of the list.  Lists are terminated in all directions by a \textbf{NULL} pointer.  All nodes are doubly linked so that you
+can walk up and down the nodes without keeping pointers lying around.
+\subsubsection{Free'ing a Flexi List}
+To free the list use the following function.
+\index{der\_sequence\_free()}
+\begin{verbatim}
+void der_sequence_free(ltc_asn1_list *in);
+\end{verbatim}
+This will free all of the memory allocated by der\_decode\_sequence\_flexi().
+\mysection{Password Based Cryptography}
 \subsection{PKCS \#5}
 \index{PKCS \#5}
 In order to securely handle user passwords for the purposes of creating session keys and chaining IVs the PKCS \#5 was drafted.   PKCS \#5
 is made up of two algorithms, Algorithm One and Algorithm Two.  Algorithm One is the older fairly limited algorithm which has been implemented
 for completeness.  Algorithm Two is a bit more modern and more flexible to work with.
 \subsection{Algorithm One}
-Algorithm One accepts as input a password, an 8--byte salt and an iteration counter.  The iteration counter is meant to act as delay for
+Algorithm One accepts as input a password, an 8--byte salt, and an iteration counter.  The iteration counter is meant to act as delay for
 people trying to brute force guess the password.  The higher the iteration counter the longer the delay.  This algorithm also requires a hash
 algorithm and produces an output no longer than the output of the hash.
 \index{pkcs\_5\_alg1()}
 \begin{alltt}
-int pkcs_5_alg1(const unsigned char *password, unsigned long password_len,
+int pkcs_5_alg1(const unsigned char *password,
+unsigned long  password_len,
 const unsigned char *salt,
-int iteration_count,  int hash_idx,
+int  iteration_count,
-unsigned char *out,   unsigned long *outlen)
+int  hash_idx,
+unsigned char *out,
+unsigned long *outlen)
 \end{alltt}
-Where ``password'' is the users password.  Since the algorithm allows binary passwords you must also specify the length in ``password\_len''.
+Where \textit{password} is the user's password.  Since the algorithm allows binary passwords you must also specify the length in \textit{password\_len}.
-The ``salt'' is a fixed size 8--byte array which should be random for each user and session.  The ``iteration\_count'' is the delay desired
+The \textit{salt} is a fixed size 8--byte array which should be random for each user and session.  The \textit{iteration\_count} is the delay desired
-on the password.  The ``hash\_idx'' is the index of the hash you wish to use in the descriptor table.
+on the password.  The \textit{hash\_idx} is the index of the hash you wish to use in the descriptor table.
-The output of length upto ``outlen'' is stored in ``out''.  If ``outlen'' is initially larger than the size of the hash functions output
+The output of length up to \textit{outlen} is stored in \textit{out}.  If \textit{outlen} is initially larger than the size of the hash functions output
-it is set to the number of bytes stored.  If it is smaller than not all of the hash output is stored in ``out''.
+it is set to the number of bytes stored.  If it is smaller than not all of the hash output is stored in \textit{out}.
 \subsection{Algorithm Two}
-Algorithm Two is the recommended algorithm for this task.  It allows variable length salts and can produce outputs larger than the
+Algorithm Two is the recommended algorithm for this task.  It allows variable length salts, and can produce outputs larger than the
-hash functions output.  As such it can easily be used to derive session keys for ciphers and MACs as well initial vectors as required
+hash functions output.  As such, it can easily be used to derive session keys for ciphers and MACs as well initial vectors as required
-from a single password and invokation of this algorithm.
+from a single password and invocation of this algorithm.
 \index{pkcs\_5\_alg2()}
 \begin{alltt}
-int pkcs_5_alg2(const unsigned char *password, unsigned long password_len,
+int pkcs_5_alg2(const unsigned char *password,
-const unsigned char *salt,     unsigned long salt_len,
+unsigned long  password_len,
-int iteration_count,           int hash_idx,
+const unsigned char *salt,
-unsigned char *out,            unsigned long *outlen)
+unsigned long  salt_len,
+int  iteration_count,
+int  hash_idx,
+unsigned char *out,
+unsigned long *outlen)
 \end{alltt}
-Where ``password'' is the users password.  Since the algorithm allows binary passwords you must also specify the length in ``password\_len''.
+Where \textit{password} is the users password.  Since the algorithm allows binary passwords you must also specify the length in \textit{password\_len}.
-The ``salt'' is an array of size ``salt\_len''.  It should be random for each user and session.  The ``iteration\_count'' is the delay desired
+The \textit{salt} is an array of size \textit{salt\_len}.  It should be random for each user and session.  The \textit{iteration\_count} is the delay desired
-on the password.  The ``hash\_idx'' is the index of the hash you wish to use in the descriptor table.   The output of length upto
+on the password.  The \textit{hash\_idx} is the index of the hash you wish to use in the descriptor table.   The output of length up to
-``outlen'' is stored in ``out''.
+\textit{outlen} is stored in \textit{out}.
-\begin{alltt}
+\begin{verbatim}
-/* demo to show how to make session state material from a password */
+/* demo to show how to make session state material
+* from a password */
 #include <tomcrypt.h>
 int main(void)
-\{
+{
 unsigned char password[100], salt[100],
 cipher_key[16], cipher_iv[16],
 mac_key[16], outbuf[48];
 int           err, hash_idx;
 unsigned long outlen, password_len, salt_len;
 /* get users password and make up a salt ... */
 /* create the material (100 iterations in algorithm) */
 outlen = sizeof(outbuf);
-if ((err = pkcs_5_alg2(password, password_len, salt, salt_len,
+if ((err = pkcs_5_alg2(password, password_len, salt,
-100, hash_idx, outbuf, &outlen)) != CRYPT_OK) \{
+salt_len, 100, hash_idx, outbuf,
+&outlen))
+!= CRYPT_OK) {
 /* error handle */
-\}
+}
 /* now extract it */
 memcpy(cipher_key, outbuf, 16);
 memcpy(cipher_iv,  outbuf+16, 16);
 memcpy(mac_key,    outbuf+32, 16);
 /* use material (recall to store the salt in the output) */
-\}
+}
-\end{alltt}
+\end{verbatim}
 \chapter{Miscellaneous}
-\section{Base64 Encoding and Decoding}
+\mysection{Base64 Encoding and Decoding}
-The library provides functions to encode and decode a RFC1521 base64 coding scheme.  This means that it can decode what it
+The library provides functions to encode and decode a RFC 1521 base--64 coding scheme.  The characters used in the mappings are:
-encodes but the format used does not comply to any known standard.  The characters used in the mappings are:
 \begin{verbatim}
 ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/
 \end{verbatim}
-Those characters should are supported in virtually any 7-bit ASCII system which means they can be used for transport over
+Those characters are supported in the 7-bit ASCII map, which means they can be used for transport over
 common e-mail, usenet and HTTP mediums.  The format of an encoded stream is just a literal sequence of ASCII characters
 where a group of four represent 24-bits of input.  The first four chars of the encoders output is the length of the
 original input.  After the first four characters is the rest of the message.
-Often it is desirable to line wrap the output to fit nicely in an e-mail or usenet posting.  The decoder allows you to
+Often, it is desirable to line wrap the output to fit nicely in an e-mail or usenet posting.  The decoder allows you to
 put any character (that is not in the above sequence) in between any character of the encoders output.  You may not however,
 break up the first four characters.
 To encode a binary string in base64 call:
 \index{base64\_encode()}  \index{base64\_decode()}
 \begin{verbatim}
-int base64_encode(const unsigned char *in, unsigned long len,
+int base64_encode(const unsigned char *in,
-unsigned char *out, unsigned long *outlen);
+unsigned long  len,
-\end{verbatim}
+unsigned char *out,
-Where ``in'' is the binary string and ``out'' is where the ASCII output is placed.  You must set the value of ``outlen'' prior
+unsigned long *outlen);
-to calling this function and it sets the length of the base64 output in ``outlen'' when it is done.  To decode a base64
+\end{verbatim}
+Where \textit{in} is the binary string and \textit{out} is where the ASCII output is placed.  You must set the value of \textit{outlen} prior
+to calling this function and it sets the length of the base64 output in \textit{outlen} when it is done.  To decode a base64
 string call:
 \begin{verbatim}
-int base64_decode(const unsigned char *in, unsigned long len,
+int base64_decode(const unsigned char *in,
-unsigned char *out, unsigned long *outlen);
+unsigned long  len,
-\end{verbatim}
+unsigned char *out,
+unsigned long *outlen);
-\section{The Multiple Precision Integer Library (MPI)}
+\end{verbatim}
-The library comes with a copy of LibTomMath  which is a multiple precision integer library written by the
-author of LibTomCrypt.  LibTomMath is a trivial to use ANSI C compatible large integer library which is free
+\mysection{Primality Testing}
-for all uses and is distributed freely.
-At the heart of all the functions is the data type ``mp\_int'' (defined in tommath.h).  This data type is what
-will hold all large integers.  In order to use an mp\_int one must initialize it first, for example:
-\begin{verbatim}
-#include <tomcrypt.h> /* tomcrypt.h includes mpi.h automatically */
-int main(void)
-{
-mp_int bignum;
-/* initialize it */
-mp_init(&bignum);
-return 0;
-}
-\end{verbatim}
-If you are unfamiliar with the syntax of C the \& symbol is used to pass the address of ``bignum'' to the function.  All
-LibTomMath functions require the address of the parameters.  To free the memory of a mp\_int use (for example):
-\begin{verbatim}
-mp_clear(&bignum);
-\end{verbatim}
-The functions also have the basic form of one of the following:
-\begin{verbatim}
-mp_XXX(mp_int *a);
-mp_XXX(mp_int *a, mp_int *b, mp_int *c);
-mp_XXX(mp_int *a, mp_int *b, mp_int *c, mp_int *d);
-\end{verbatim}
-Where they perform some operation and store the result in the mp\_int variable passed on the far right.
-For example, to compute $c = a + b \mbox{ }(\mbox{mod }m)$ you would call:
-\begin{verbatim}
-mp_addmod(&a, &b, &m, &c);
-\end{verbatim}
-\subsection{Binary Forms of ``mp\_int'' Variables}
-Often it is required to store a ``mp\_int'' in binary form for transport (e.g. exporting a key, packet
-encryption, etc.).  LibTomMath includes two functions to help when exporting numbers:
-\begin{verbatim}
-int mp_raw_size(mp_int *num);
-mp_toraw(&num, buf);
-\end{verbatim}
-The former function gives the size in bytes of the raw format and the latter function actually stores the raw data.  All
-``mp\_int'' numbers are stored in big endian form (like PKCS demands) with the first byte being the sign of the number.  The
-``rsa\_exptmod()'' function differs slightly since it will take the input in the form exactly as PKCS demands (without the
-leading sign byte).  All other functions include the sign byte (since its much simpler just to include it).  The sign byte
-must be zero for positive numbers and non-zero for negative numbers.  For example,
-the sequence:
-\begin{verbatim}
-00 FF 30 04
-\end{verbatim}
-Represents the integer $255 \cdot 256^2 + 48 \cdot 256^1 + 4 \cdot 256^0$ or 16,723,972.
-To read a binary string back into a ``mp\_int'' call:
-\begin{verbatim}
-mp_read_raw(mp_int *num, unsigned char *str, int len);
-\end{verbatim}
-Where ``num'' is where to store it, ``str'' is the binary string (including the leading sign byte) and ``len'' is the
-length of the binary string.
-\subsection{Primality Testing}
 \index{Primality Testing}
 The library includes primality testing and random prime functions as well.  The primality tester will perform the test in
 two phases.  First it will perform trial division by the first few primes.  Second it will perform eight rounds of the
 Rabin-Miller primality testing algorithm.  If the candidate passes both phases it is declared prime otherwise it is declared
 composite.  No prime number will fail the two phases but composites can.  Each round of the Rabin-Miller algorithm reduces
 the probability of a pseudo-prime by $1 \over 4$ therefore after sixteen rounds the probability is no more than
 $\left ( { 1 \over 4 } \right )^{8} = 2^{-16}$.  In practice the probability of error is in fact much lower than that.
-When making random primes the trial division step is in fact an optimized implementation of ``Implementation of Fast RSA Key Generation on Smart Cards''\footnote{Chenghuai Lu, Andre L. M. dos Santos and Francisco R. Pimentel}.
+When making random primes the trial division step is in fact an optimized implementation of \textit{Implementation of Fast RSA Key Generation on Smart Cards}\footnote{Chenghuai Lu, Andre L. M. dos Santos and Francisco R. Pimentel}.
-In essence a table of machine-word sized residues are kept of a candidate modulo a set of primes.  When the candiate
+In essence a table of machine-word sized residues are kept of a candidate modulo a set of primes.  When the candidate
 is rejected and ultimately incremented to test the next number the residues are updated without using multi-word precision
 math operations.  As a result the routine can scan ahead to the next number required for testing with very little work
 involved.
 In the event that a composite did make it through it would most likely cause the the algorithm trying to use it to fail.  For
 will not be able to sign or decrypt messages at all.  Suppose $p$ was prime and $q$ was composite this is just a variation of
 the multi-prime RSA.  Suppose $q = rs$ for two primes $r$ and $s$ then $\phi(pq) = (p - 1)(r - 1)(s - 1)$ which clearly is
 not equal to $(p - 1)(rs - 1)$.
 These are not technically part of the LibTomMath library but this is the best place to document them.
-To test if a ``mp\_int'' is prime call:
+To test if a \textit{mp\_int} is prime call:
 \begin{verbatim}
 int is_prime(mp_int *N, int *result);
 \end{verbatim}
-This puts a one in ``result'' if the number is probably prime, otherwise it places a zero in it.  It is assumed that if
+This puts a one in \textit{result} if the number is probably prime, otherwise it places a zero in it.  It is assumed that if
-it returns an error that the value in ``result'' is undefined.  To make
+it returns an error that the value in \textit{result} is undefined.  To make
 a random prime call:
 \begin{verbatim}
-int rand_prime(mp_int *N, unsigned long len, prng_state *prng, int wprng);
+int rand_prime(       mp_int *N,
-\end{verbatim}
+unsigned long len,
-Where ``len'' is the size of the prime in bytes ($2 \le len \le 256$).  You can set ``len'' to the negative size you want
+prng_state *prng,
+int  wprng);
+\end{verbatim}
+Where \textit{len} is the size of the prime in bytes ($2 \le len \le 256$).  You can set \textit{len} to the negative size you want
 to get a prime of the form $p \equiv 3\mbox{ }(\mbox{mod } 4)$.  So if you want a 1024-bit prime of this sort pass
-``len = -128'' to the function.  Upon success it will return {\bf CRYPT\_OK} and ``N'' will contain an integer which
+\textit{len = -128} to the function.  Upon success it will return {\bf CRYPT\_OK} and \textit{N} will contain an integer which
 is very likely prime.
 \chapter{Programming Guidelines}
-\section{Secure Pseudo Random Number Generators}
+\mysection{Secure Pseudo Random Number Generators}
-Probably the singal most vulnerable point of any cryptosystem is the PRNG.  Without one generating and protecting secrets
+Probably the single most vulnerable point of any cryptosystem is the PRNG.  Without one, generating and protecting secrets
-would be impossible.  The requirement that one be setup correctly is vitally important and to address this point the library
+would be impossible.  The requirement that one be setup correctly is vitally important, and to address this point the library
-does provide two RNG sources that will address the largest amount of end users as possible.  The ``sprng'' PRNG provided
+does provide two RNG sources that will address the largest amount of end users as possible.  The \textit{sprng} PRNG provides an easy to
-provides and easy to access source of entropy for any application on a *NIX or Windows computer.
+access source of entropy for any application on a UNIX (and the like) or Windows computer.
-However, when the end user is not on one of these platforms the application developer must address the issue of finding
+However, when the end user is not on one of these platforms, the application developer must address the issue of finding
 entropy.  This manual is not designed to be a text on cryptography.  I would just like to highlight that when you design
 a cryptosystem make sure the first problem you solve is getting a fresh source of entropy.
-\section{Preventing Trivial Errors}
+\mysection{Preventing Trivial Errors}
-Two simple ways to prevent trivial errors is to prevent overflows and to check the return values.  All of the functions
+Two simple ways to prevent trivial errors is to prevent overflows, and to check the return values.  All of the functions
 which output variable length strings will require you to pass the length of the destination.  If the size of your output
 buffer is smaller than the output it will report an error.  Therefore, make sure the size you pass is correct!
-Also virtually all of the functions return an error code or {\bf CRYPT\_OK}.  You should detect all errors as simple
+Also, virtually all of the functions return an error code or {\bf CRYPT\_OK}.  You should detect all errors, as simple
-typos or such can cause algorithms to fail to work as desired.
+typos can cause algorithms to fail to work as desired.
-\section{Registering Your Algorithms}
+\mysection{Registering Your Algorithms}
-To avoid linking and other runtime errors it is important to register the ciphers, hashes and PRNGs you intend to use
+To avoid linking and other run--time errors it is important to register the ciphers, hashes and PRNGs you intend to use
 before you try to use them.  This includes any function which would use an algorithm indirectly through a descriptor table.
 A neat bonus to the registry system is that you can add external algorithms that are not part of the library without
 having to hack the library.  For example, suppose you have a hardware specific PRNG on your system.  You could easily
-write the few functions required plus a descriptor.  After registering your PRNG all of the library functions that
+write the few functions required plus a descriptor.  After registering your PRNG, all of the library functions that
-need a PRNG can instantly take advantage of it.
+need a PRNG can instantly take advantage of it.  The same applies for ciphers, hashes, and bignum math routines.
-\section{Key Sizes}
+\mysection{Key Sizes}
 \subsection{Symmetric Ciphers}
-For symmetric ciphers use as large as of a key as possible.  For the most part ``bits are cheap'' so using a 256-bit key
+For symmetric ciphers, use as large as of a key as possible.  For the most part \textit{bits are cheap} so using a 256--bit key
-is not a hard thing todo.
+is not a hard thing to do.  As a good rule of thumb do not use a key smaller than 128 bits.
-\subsection{Assymetric Ciphers}
+\subsection{Asymmetric Ciphers}
 The following chart gives the work factor for solving a DH/RSA public key using the NFS.  The work factor for a key of order
 $n$ is estimated to be
 \begin{equation}
 e^{1.923 \cdot ln(n)^{1 \over 3} \cdot ln(ln(n))^{2 \over 3}}
 \end{equation}
 Note that $n$ is not the bit-length but the magnitude.  For example, for a 1024-bit key $n = 2^{1024}$.  The work required
 is:
+\begin{figure}[here]
 \begin{center}
 \begin{tabular}{|c|c|}
 \hline RSA/DH Key Size (bits) & Work Factor ($log_2$) \\
 \hline 512 & 63.92 \\
 \hline 768 & 76.50 \\
 \hline 3072 & 138.73 \\
 \hline 4096 & 156.49 \\
 \hline
 \end{tabular}
 \end{center}
+\caption{RSA/DH Key Strength}
-The work factor for ECC keys is much higher since the best attack is still fully exponentional.  Given a key of magnitude
+\end{figure}
-$n$ it requires $\sqrt n$ work.  The following table sumarizes the work required:
+The work factor for ECC keys is much higher since the best attack is still fully exponential.  Given a key of magnitude
+$n$ it requires $\sqrt n$ work.  The following table summarizes the work required:
+\begin{figure}[here]
 \begin{center}
 \begin{tabular}{|c|c|}
 \hline ECC Key Size (bits) & Work Factor ($log_2$) \\
+\hline 112 & 56 \\
+\hline 128 & 64 \\
+\hline 160 & 80 \\
 \hline 192 & 96  \\
 \hline 224 & 112 \\
 \hline 256 & 128 \\
 \hline 384 & 192 \\
 \hline 521 & 260.5 \\
 \hline
 \end{tabular}
 \end{center}
+\caption{ECC Key Strength}
+\end{figure}
 Using the above tables the following suggestions for key sizes seems appropriate:
 \begin{center}
 \begin{tabular}{|c|c|c|}
 \hline Security Goal & RSA/DH Key Size (bits) & ECC Key Size (bits) \\
-\hline Short term (less than a year) & 1024 & 160 \\
+\hline Near term   & 1024 & 160 \\
-\hline Short term (less than five years) & 1536 & 192 \\
+\hline Short term  & 1536 & 192 \\
-\hline Long Term (less than ten years) & 2560 & 256 \\
+\hline Long Term   & 2560 & 384 \\
 \hline
 \end{tabular}
 \end{center}
-\section{Thread Safety}
+\mysection{Thread Safety}
-The library is not thread safe but several simple precautions can be taken to avoid any problems.  The registry functions
+The library is not fully thread safe but several simple precautions can be taken to avoid any problems.  The registry functions
-such as register\_cipher() are not thread safe no matter what you do.  Its best to call them from your programs initializtion
+such as register\_cipher() are not thread safe no matter what you do.  It is best to call them from your programs initialization
 code before threads are initiated.
 The rest of the code uses state variables you must pass it such as hash\_state, hmac\_state, etc.  This means that if each
-thread has its own state variables then they will not affect each other.  This is fairly simple with symmetric ciphers
+thread has its own state variables then they will not affect each other, and are fully thread safe.  This is fairly simple with symmetric ciphers
-and hashes.  However, the keyring and PRNG support is something the threads will want to share.  The simplest workaround
+and hashes.
-is create semaphores or mutexes around calls to those functions.
+\index{LTC\_PTHREAD}
-Since C does not have standard semaphores this support is not native to Libtomcrypt.  Even a C based semaphore is not entire
+The only sticky issue is a shared PRNG which can be alleviated with the careful use of mutex devices.  Defining LTC\_PTHREAD for instance, enables
-possible as some compilers may ignore the ``volatile'' keyword or have multiple processors.  Provide your host application
+pthreads based mutex locking in various routines such as the Yarrow and Fortuna PRNGs, the fixed point ECC multiplier, and other routines.
-is modular enough putting the locks in the right place should not bloat the code significantly and will solve all thread
-safety issues within the library.
 \chapter{Configuring and Building the Library}
-\section{Introduction}
+\mysection{Introduction}
-The library is fairly flexible about how it can be built, used and generally distributed.  Additions are being made with
+The library is fairly flexible about how it can be built, used, and generally distributed.  Additions are being made with
 each new release that will make the library even more flexible.  Each of the classes of functions can be disabled during
 the build process to make a smaller library.  This is particularly useful for shared libraries.
-\section{Building a Static Library}
+As of v1.06 of the library, the build process has been moved to two steps for the typical LibTomCrypt application.  This is because
-The library can be built as a static library which is generally the simplest and most portable method of
+LibTomCrypt no longer provides a math API on its own and relies on third party libraries (such as LibTomMath, GnuMP, or TomsFastMath).
-building the library.  With a CC or GCC equipped platform you can issue the following
+The build process now consists of installing a math library first, and then building and installing LibTomCrypt with a math library
-\begin{alltt}
+configured.  Note that LibTomCrypt can be built with no internal math descriptors.  This means that one must be provided at either
-make install_lib
+build, or run time for the application.  LibTomCrypt comes with three math descriptors that provide a standard interface to math
-\end{alltt}
+libraries.
-Which will build the library and install it in /usr/lib (as well as the headers in /usr/include).  The destination
+\mysection{Makefile variables}
-directory of the library and headers can be changed by editing ``makefile''.  The variable LIBNAME controls
-where the library is to be installed and INCNAME controls where the headers are to be installed.  A developer can
+All GNU driven makefiles (including the makefile for ICC) use a set of common variables to control the build and install process.  Most of the
-then use the library by including ``tomcrypt.h'' in their program and linking against ``libtomcrypt.a''.
+settings can be overwritten from the command line which makes custom installation a breeze.
-A static library can also be built with the Intel C Compiler  (ICC) by issuing the following
+\index{MAKE}\index{CC}\index{AR}
+\subsection{MAKE, CC and AR}
-\begin{alltt}
+The MAKE, CC and AR flags can all be overwritten.  They default to \textit{make}, \textit{\$CC} and \textit{\$AR} respectively.
-make -f makefile.icc install
+Changing MAKE allows you to change what program will be invoked to handle sub--directories. For example, this
-\end{alltt}
+\begin{verbatim}
-This will also build ``libtomcrypt.a'' except that it will use ICC.  Additionally Microsoft's Visual C 6.00 can be used
+MAKE=gmake gmake install
-by issuing
+\end{verbatim}
-\begin{alltt}
+\begin{flushleft} will build and install the libraries with the \textit{gmake} tool.  Similarly, \end{flushleft}
-nmake -f makefile.msvc
-\end{alltt}
+\begin{verbatim}
+CC=arm-gcc AR=arm-ar make
-You will have to manually copy ``tomcrypt.lib'' and the headers to your MSVC lib/inc directories.
+\end{verbatim}
-\subsection{MPI Control}
+\begin{flushleft} will build the library using \textit{arm--gcc} as the compiler and \textit{arm--ar} as the archiver. \end{flushleft}
-If you already have LibTomMath installed you can safely remove it from the build.  By commenting the line
-in the appropriate makefile which starts with
+\subsection{IGNORE\_SPEED}
+\index{IGNORE\_SPEED}
-\begin{alltt}
+When \textbf{IGNORE\_SPEED} has been defined the default optimization flags for CFLAGS will be disabled which allows the developer to specify new
-MPIOBJECT=mpi
+CFLAGS on the command line.  E.g. to add debugging
-\end{alltt}
+\begin{verbatim}
-Simply place a \# at the start and re-build the library.  To properly link applications you will have to also
+CFLAGS="-g3" make IGNORE_SPEED=1
-link in LibTomMath.  Removing MPI has the benefit of cutting down the library size as well potentially have access
+\end{verbatim}
-to the latest mpi.
+This will turn off optimizations and add \textit{-g3} to the CFLAGS which enables debugging.
-\section{Building a Shared Library}
-LibTomCrypt can also be built as a shared library (.so, .dll, etc...).  With non-Windows platforms the assumption
+\subsection{LIBNAME and LIBNAME\_S}
-of the presence of gcc and ``libtool'' has been made.  These are fairly common on Unix/Linux/BSD platforms.  To
+\index{LIBNAME} \index{LIBNAME\_S}
-build a .so shared library issue
+\textbf{LIBNAME} is the name of the output library (archive) to create.  It defaults to \textit{libtomcrypt.a} for static builds and \textit{libtomcrypt.la} for
+shared.  The \textbf{LIBNAME\_S} variable is the static name while doing shared builds.  Ideally they should have the same prefix but don't have to.
-\begin{alltt}
-make -f makefile.shared
+\index{LIBTEST} \index{LIBTEST\_S}
-\end{alltt}
+Similarly \textbf{LIBTEST} and \textbf{LIBTEST\_S} are the names for the profiling and testing library.  The default is \textit{libtomcrypt\_prof.a} for
-This will use libtool and gcc to build a shared library ``libtomcrypt.la'' as well as a static library ``libtomcrypt.a''
+static and \textit{libtomcrypt\_prof.la} for shared.
-and install them into /usr/lib (and the headers into /usr/include).  To link your application you should use the
-libtool program in ``--mode=link''.
+\subsection{Installation Directories}
+\index{DESTDIR} \index{LIBPATH} \index{INCPATH} \index{DATADIR}
-\section{tomcrypt\_cfg.h}
+\textbf{DESTDIR} is the prefix for the installation directories.  It defaults to an empty string.  \textbf{LIBPATH} is the prefix for the library
-The file ``tomcrypt\_cfg.h'' is what lets you control various high level macros which control the behaviour
+directory which defaults to \textit{/usr/lib}.  \textbf{INCPATH} is the prefix for the header file directory which defaults to \textit{/usr/include}.
-of the library.
+\textbf{DATADIR} is the prefix for the data (documentation) directory which defaults to \textit{/usr/share/doc/libtomcrypt/pdf}.
+All four can be used to create custom install locations depending on the nature of the OS and file system in use.
+\begin{verbatim}
+make LIBPATH=/home/tom/project/lib INCPATH=/home/tom/project/include \
+DATAPATH=/home/tom/project/docs install
+\end{verbatim}
+This will build the library and install it to the directories under \textit{/home/tom/project/}.  e.g.
+\begin{small}
+\begin{verbatim}
+/home/tom/project/:
+total 1
+drwxr-xr-x  2 tom users  80 Jul 30 16:02 docs
+drwxr-xr-x  2 tom users 528 Jul 30 16:02 include
+drwxr-xr-x  2 tom users  80 Jul 30 16:02 lib
+/home/tom/project/docs:
+total 452
+-rwxr-xr-x  1 tom users 459009 Jul 30 16:02 crypt.pdf
+/home/tom/project/include:
+total 132
+-rwxr-xr-x  1 tom users  2482 Jul 30 16:02 tomcrypt.h
+-rwxr-xr-x  1 tom users   702 Jul 30 16:02 tomcrypt_argchk.h
+-rwxr-xr-x  1 tom users  2945 Jul 30 16:02 tomcrypt_cfg.h
+-rwxr-xr-x  1 tom users 22763 Jul 30 16:02 tomcrypt_cipher.h
+-rwxr-xr-x  1 tom users  5174 Jul 30 16:02 tomcrypt_custom.h
+-rwxr-xr-x  1 tom users 11314 Jul 30 16:02 tomcrypt_hash.h
+-rwxr-xr-x  1 tom users 11571 Jul 30 16:02 tomcrypt_mac.h
+-rwxr-xr-x  1 tom users 13614 Jul 30 16:02 tomcrypt_macros.h
+-rwxr-xr-x  1 tom users 14714 Jul 30 16:02 tomcrypt_math.h
+-rwxr-xr-x  1 tom users   632 Jul 30 16:02 tomcrypt_misc.h
+-rwxr-xr-x  1 tom users 10934 Jul 30 16:02 tomcrypt_pk.h
+-rwxr-xr-x  1 tom users  2634 Jul 30 16:02 tomcrypt_pkcs.h
+-rwxr-xr-x  1 tom users  7067 Jul 30 16:02 tomcrypt_prng.h
+-rwxr-xr-x  1 tom users  1467 Jul 30 16:02 tomcrypt_test.h
+/home/tom/project/lib:
+total 1073
+-rwxr-xr-x  1 tom users 1096284 Jul 30 16:02 libtomcrypt.a
+\end{verbatim}
+\end{small}
+\mysection{Extra libraries}
+\index{EXTRALIBS}
+\textbf{EXTRALIBS} specifies any extra libraries required to link the test programs and shared libraries.  They are specified in the notation
+that GCC expects for global archives.
+\begin{verbatim}
+CFLAGS="-DTFM_DESC -DUSE_TFM" EXTRALIBS=-ltfm make install \
+test timing
+\end{verbatim}
+This will install the library using the TomsFastMath library and link the \textit{libtfm.a} library out of the default library search path.  The two
+defines are explained below.  You can specify multiple archives (say if you want to support two math libraries, or add on additional code) to
+the \textbf{EXTRALIBS} variable by separating them by a space.
+Note that \textbf{EXTRALIBS} is not required if you are only making and installing the static library but none of the test programs.
+\mysection{Building a Static Library}
+Building a static library is fairly trivial as it only requires one invocation of the GNU make command.
+\begin{verbatim}
+CFLAGS="-DTFM_DESC" make install
+\end{verbatim}
+That will build LibTomCrypt (including the TomsFastMath descriptor), and install it in the default locations indicated previously.  You can enable
+the built--in LibTomMath descriptor as well (or in place of the TomsFastMath descriptor).  Similarly, you can build the library with no built--in
+math descriptors.
+\begin{verbatim}
+make install
+\end{verbatim}
+In this case, no math descriptors are present in the library and they will have to be made available at build or run time before you can use any of the
+public key functions.
+Note that even if you include the built--in descriptors you must link against the source library as well.
+\begin{verbatim}
+gcc -DTFM_DESC myprogram.c -ltomcrypt -ltfm -o myprogram
+\end{verbatim}
+This will compile \textit{myprogram} and link it against the LibTomCrypt library as well as TomsFastMath (which must have been previously installed).  Note that
+we define \textbf{TFM\_DESC} for compilation.  This is so that the TFM descriptor symbol will be defined for the client application to make use of without
+giving warnings.
+\mysection{Building a Shared Library}
+LibTomCrypt can also be built as a shared library through the \textit{makefile.shared} make script.  It is similar to use as the static script except
+that you \textbf{must} specify the \textbf{EXTRALIBS} variable at install time.
+\begin{verbatim}
+CFLAGS="-DTFM_DESC" EXTRALIBS=-ltfm make -f makefile.shared install
+\end{verbatim}
+This will build and install the library and link the shared object against the TomsFastMath library (which must be installed as a shared object as well).  The
+shared build process requires libtool to be installed.
+\mysection{Header Configuration}
+The file \textit{tomcrypt\_cfg.h} is what lets you control various high level macros which control the behaviour of the library.  Build options are also
+stored in \textit{tomcrypt\_custom.h} which allow the enabling and disabling of various algorithms.
 \subsubsection{ARGTYPE}
-This lets you control how the \_ARGCHK macro will behave.  The macro is used to check pointers inside the functions against
+This lets you control how the LTC\_ARGCHK macro will behave.  The macro is used to check pointers inside the functions against
-NULL.  There are three settings for ARGTYPE.  When set to 0 it will have the default behaviour of printing a message to
+NULL.  There are four settings for ARGTYPE.  When set to 0, it will have the default behaviour of printing a message to
-stderr and raising a SIGABRT signal.  This is provided so all platforms that use libtomcrypt can have an error that functions
+stderr and raising a SIGABRT signal.  This is provided so all platforms that use LibTomCrypt can have an error that functions
-similarly.  When set to 1 it will simply pass on to the assert() macro.  When set to 2 it will resolve to a empty macro
+similarly.  When set to 1, it will simply pass on to the assert() macro.  When set to 2, the macro will display the error to
-and no error checking will be performed.
+stderr then return execution to the caller.  This could lead to a segmentation fault (e.g. when a pointer is \textbf{NULL}) but is useful
+if you handle signals on your own.  When set to 3, it will resolve to a empty macro and no error checking will be performed.  Finally, when set
+to 4, it will return CRYPT\_INVALID\_ARG to the caller.
 \subsubsection{Endianess}
-There are five macros related to endianess issues.  For little endian platforms define, ENDIAN\_LITTLE.  For big endian
+There are five macros related to endianess issues.  For little endian platforms define, \textbf{ENDIAN\_LITTLE}.  For big endian
-platforms define ENDIAN\_BIG.  Similarly when the default word size of an ``unsigned long'' is 32-bits define ENDIAN\_32BITWORD
+platforms define \textbf{ENDIAN\_BIG}.  Similarly when the default word size of an \textit{unsigned long} is 32-bits define \textbf{ENDIAN\_32BITWORD}
-or define ENDIAN\_64BITWORD when its 64-bits.  If you do not define any of them the library will automatically use ENDIAN\_NEUTRAL
+or define \textbf{ENDIAN\_64BITWORD} when its 64-bits.  If you do not define any of them the library will automatically use \textbf{ENDIAN\_NEUTRAL}
 which will work on all platforms.
-Currently LibTomCrypt will detect x86-32 and x86-64 running GCC as well as x86-32 running MSVC.
+Currently LibTomCrypt will detect x86-32, x86-64, MIPS R5900, SPARC and SPARC64 running GCC as well as x86-32 running MSVC.
-\section{The Configure Script}
+\mysection{The Configure Script}
-There are also options you can specify from the configure script or ``tomcrypt\_custom.h''.
+There are also options you can specify from the \textit{tomcrypt\_custom.h} header file.
 \subsection{X memory routines}
-At the top of tomcrypt\_custom.h are four macros denoted as XMALLOC, XCALLOC, XREALLOC and XFREE which resolve to
+\index{XMALLOC}\index{XCALLOC}\index{XREALLOC}\index{XFREE}
-the name of the respective functions.  This lets you substitute in your own memory routines.  If you substitute in
+At the top of tomcrypt\_custom.h are a series of macros denoted as XMALLOC, XCALLOC, XREALLOC, XFREE, and so on.  They resolve to
-your own functions they must behave like the standard C library functions in terms of what they expect as input and
+the name of the respective functions from the standard C library by default.  This lets you substitute in your own memory routines.
-output.  By default the library uses the standard C routines.
+If you substitute in your own functions they must behave like the standard C library functions in terms of what they expect as input and
+output.
+These macros are handy for working with platforms which do not have a standard C library.  For instance, the OLPC\footnote{See http://dev.laptop.org/git?p=bios-crypto;a=summary}
+bios code uses these macros to redirect to very compact heap and string operations.
 \subsection{X clock routines}
 The rng\_get\_bytes() function can call a function that requires the clock() function.  These macros let you override
 the default clock() used with a replacement.  By default the standard C library clock() function is used.
-\subsection{NO\_FILE}
+\subsection{LTC\_NO\_FILE}
-During the build if NO\_FILE is defined then any function in the library that uses file I/O will not call the file I/O
+During the build if LTC\_NO\_FILE is defined then any function in the library that uses file I/O will not call the file I/O
 functions and instead simply return CRYPT\_NOP.  This should help resolve any linker errors stemming from a lack of
 file I/O on embedded platforms.
-\subsection{CLEAN\_STACK}
+\subsection{LTC\_CLEAN\_STACK}
 When this functions is defined the functions that store key material on the stack will clean up afterwards.
 Assumes that you have no memory paging with the stack.
 \subsection{LTC\_TEST}
-When this has been defined the various self--test functions (for ciphers, hashes, prngs, etc) are included in the build.
+When this has been defined the various self--test functions (for ciphers, hashes, prngs, etc) are included in the build.  This is the default configuration.
-When this has been undefined the tests are removed and if called will return CRYPT\_NOP.
+If LTC\_NO\_TEST has been defined, the testing routines will be compacted and only return CRYPT\_NOP.
+\subsection{LTC\_NO\_FAST}
+When this has been defined the library will not use faster word oriented operations.  By default, they are only enabled for platforms
+which can be auto-detected.  This macro ensures that they are never enabled.
+\subsection{LTC\_FAST}
+This mode (auto-detected with x86\_32,x86\_64 platforms with GCC or MSVC) configures various routines such as ctr\_encrypt() or
+cbc\_encrypt() that it can safely XOR multiple octets in one step by using a larger data type.  This has the benefit of
+cutting down the overhead of the respective functions.
+This mode does have one downside.  It can cause unaligned reads from memory if you are not careful with the functions.  This is why
+it has been enabled by default only for the x86 class of processors where unaligned accesses are allowed.  Technically LTC\_FAST
+is not \textit{portable} since unaligned accesses are not covered by the ISO C specifications.
+In practice however, you can use it on pretty much any platform (even MIPS) with care.
+By design the \textit{fast} mode functions won't get unaligned on their own.  For instance, if you call ctr\_encrypt() right after calling
+ctr\_start() and all the inputs you gave are aligned than ctr\_encrypt() will perform aligned memory operations only.  However, if you
+call ctr\_encrypt() with an odd amount of plaintext then call it again the CTR pad (the IV) will be partially used.  This will
+cause the ctr routine to first use up the remaining pad bytes.  Then if there are enough plaintext bytes left it will use
+whole word XOR operations.  These operations will be unaligned.
+The simplest precaution is to make sure you process all data in power of two blocks and handle \textit{remainder} at the end.  e.g. If you are
+CTR'ing a long stream process it in blocks of (say) four kilobytes and handle any remaining incomplete blocks at the end of the stream.
+\index{LTC\_FAST\_TYPE}
+If you do plan on using the \textit{LTC\_FAST} mode you have to also define a \textit{LTC\_FAST\_TYPE} macro which resolves to an optimal sized
+data type you can perform integer operations with.  Ideally it should be four or eight bytes since it must properly divide the size
+of your block cipher (e.g. 16 bytes for AES).  This means sadly if you're on a platform with 57--bit words (or something) you can't
+use this mode.  So sad.
+\subsection{LTC\_NO\_ASM}
+When this has been defined the library will not use any inline assembler.  Only a few platforms support assembler inlines but various versions of ICC and GCC
+cannot handle all of the assembler functions.
 \subsection{Symmetric Ciphers, One-way Hashes, PRNGS and Public Key Functions}
 There are a plethora of macros for the ciphers, hashes, PRNGs and public key functions which are fairly
 self-explanatory.  When they are defined the functionality is included otherwise it is not.  There are some
 dependency issues which are noted in the file.  For instance, Yarrow requires CTR chaining mode, a block
 cipher and a hash function.
+Also see technical note number five for more details.
+\subsection{LTC\_EASY}
+When defined the library is configured to build fewer algorithms and modes.  Mostly it sticks to NIST and ANSI approved algorithms.  See
+the header file \textit{tomcrypt\_custom.h} for more details.  It is meant to provide literally an easy method of trimming the library
+build to the most minimum of useful functionality.
 \subsection{TWOFISH\_SMALL and TWOFISH\_TABLES}
 Twofish is a 128-bit symmetric block cipher that is provided within the library.  The cipher itself is flexible enough
-to allow some tradeoffs in the implementation.  When TWOFISH\_SMALL is defined the scheduled symmetric key for Twofish
+to allow some trade-offs in the implementation.  When TWOFISH\_SMALL is defined the scheduled symmetric key for Twofish
 requires only 200 bytes of memory.  This is achieved by not pre-computing the substitution boxes.  Having this
 defined will also greatly slow down the cipher.  When this macro is not defined Twofish will pre-compute the
 tables at a cost of 4KB of memory.  The cipher will be much faster as a result.
 When TWOFISH\_TABLES is defined the cipher will use pre-computed (and fixed in code) tables required to work.  This is
 will increase by approximately 500 bytes.  If this is defined but TWOFISH\_SMALL is not the cipher will still work but
 it will not speed up the encryption or decryption functions.
 \subsection{GCM\_TABLES}
 When defined GCM will use a 64KB table (per GCM state) which will greatly speed up the per--packet latency.
-It also increases the initialization time and isn't suitable when you are going to use a key a few times only.
+It also increases the initialization time and is not suitable when you are going to use a key a few times only.
-\subsection{SMALL\_CODE}
+\subsection{GCM\_TABLES\_SSE2}
+\index{SSE2}
+When defined GCM will use the SSE2 instructions to perform the $GF(2^x)$ multiply using 16 128--bit XOR operations.  It shaves a few cycles per byte
+of GCM output on both the AMD64 and Intel Pentium 4 platforms.  Requires GCC and an SSE2 equipped platform.
+\subsection{LTC\_SMALL\_CODE}
 When this is defined some of the code such as the Rijndael and SAFER+ ciphers are replaced with smaller code variants.
 These variants are slower but can save quite a bit of code space.
-\subsection{LTC\_FAST}
-This mode (autodetected with x86\_32,x86\_64 platforms with GCC or MSVC) configures various routines such as ctr\_encrypt() or
-cbc\_encrypt() that it can safely XOR multiple octets in one step by using a larger data type.  This has the benefit of
-cutting down the overhead of the respective functions.
-This mode does have one downside.  It can cause unaligned reads from memory if you are not careful with the functions.  This is why
-it has been enabled by default only for the x86 class of processors where unaligned accesses are allowed.  Technically LTC\_FAST
-is not ``portable'' since unaligned accesses are not covered by the ISO C specifications.
-In practice however, you can use it on pretty much any platform (even MIPS) with care.
-By design the ``fast'' mode functions won't get unaligned on their own.  For instance, if you call ctr\_encrypt() right after calling
-ctr\_start() and all the inputs you gave are aligned than ctr\_encrypt() will perform aligned memory operations only.  However, if you
-call ctr\_encrypt() with an odd amount of plaintext then call it again the CTR pad (the IV) will be partially used.  This will
-cause the ctr routine to first use up the remaining pad bytes.  Then if there are enough plaintext bytes left it will use
-whole word XOR operations.  These operations will be unaligned.
-The simplest precaution is to make sure you process all data in power of two blocks and handle ``remainder'' at the end.  e.g. If you are
-CTR'ing a long stream process it in blocks of (say) four kilobytes and handle any remaining incomplete blocks at the end of the stream.
-If you do plan on using the ``LTC\_FAST'' mode you have to also define a ``LTC\_FAST\_TYPE'' macro which resolves to an optimal sized
-data type you can perform integer operations with.  Ideally it should be four or eight bytes since it must properly divide the size
-of your block cipher (e.g. 16 bytes for AES).  This means sadly if you're on a platform with 57--bit words (or something) you can't
-use this mode.  So sad.
 \subsection{LTC\_PTHREAD}
 When this is activated all of the descriptor table functions will use pthread locking to ensure thread safe updates to the tables.  Note that
 it doesn't prevent a thread that is passively using a table from being messed up by another thread that updates the table.
 Generally the rule of thumb is to setup the tables once at startup and then leave them be.  This added build flag simply makes updating
 the tables safer.
-\section{MPI Tweaks}
+\subsection{LTC\_ECC\_TIMING\_RESISTANT}
-\subsection{RSA Only Tweak}
+When this has been defined the ECC point multiplier (built--in to the library) will use a timing resistant point multiplication
-If you plan on only using RSA with moduli in the range of 1024 to 2560 bits you can enable a series of tweaks
+algorithm which prevents leaking key bits of the private key (scalar).  It is a slower algorithm but useful for situations
-to reduce the library size.  Follow these steps
+where timing side channels pose a significant threat.
-\begin{enumerate}
+\subsection{Math Descriptors}
-\item Undefine MDSA, MECC and MDH from tomcrypt\_custom.h
+The library comes with three math descriptors that allow you to interface the public key cryptography API to freely available math
-\item Undefine LTM\_ALL  from tommath\_superclass.h
+libraries.  When \textbf{GMP\_DESC}, \textbf{LTM\_DESC}, or \textbf{TFM\_DESC} are defined
-\item Define SC\_RSA\_1 from tommath\_superclass.h
+descriptors for the respective library are built and included in the library as \textit{gmp\_desc}, \textit{ltm\_desc}, or \textit{tfm\_desc} respectively.
-\item Rebuild the library.
-\end{enumerate}
+In the test demos that use the libraries the additional flags \textbf{USE\_GMP}, \textbf{USE\_LTM}, and \textbf{USE\_TFM} can be defined
+to tell the program which library to use.  Only one of the USE flags can be defined at once.
+\index{GMP\_DESC} \index{USE\_GMP} \index{LTM\_DESC} \index{TFM\_DESC} \index{USE\_LTM} \index{USE\_TFM}
+\begin{small}
+\begin{verbatim}
+CFLAGS="-DGMP_DESC -DLTM_DESC -DTFM_DESC -DUSE_TFM" \
+EXTRALIBS="-lgmp -ltommath -ltfm" make -f makefile.shared install timing
+\end{verbatim}
+\end{small}
+That will build and install the library with all descriptors (and link against all), but only use TomsFastMath in the timing demo.
 \chapter{Optimizations}
-\section{Introduction}
+\mysection{Introduction}
-The entire API was designed with plug and play in mind at the low level.  That is you can swap out any cipher, hash or PRNG and dependent API will not require
+The entire API was designed with plug and play in mind at the low level.  That is you can swap out any cipher, hash, PRNG or bignum library and the dependent API will not
-updating.  This has the nice benefit that I can add ciphers not have to re--write large portions of the API.  For the most part LibTomCrypt has also been written
+require updating.  This has the nice benefit that one can add ciphers (etc.) not have to re--write portions of the API.  For the most part, LibTomCrypt has also been written
 to be highly portable and easy to build out of the box on pretty much any platform.  As such there are no assembler inlines throughout the code, I make no assumptions
 about the platform, etc...
-That works well for most cases but there are times where time is of the essence.  This API also allows optimized routines to be dropped in--place of the existing
+That works well for most cases but there are times where performance is of the essence.  This API allows optimized routines to be dropped in--place of the existing
-portable routines.  For instance, hand optimized assembler versions of AES could be provided and any existing function that uses the cipher could automatically use
+portable routines.  For instance, hand optimized assembler versions of AES could be provided.  Any existing function that uses the cipher could automatically use
 the optimized code without re--writing.  This also paves the way for hardware drivers that can access hardware accelerated cryptographic devices.
-At the heart of this flexibility is the ``descriptor'' system.  A descriptor is essentially just a C ``struct'' which describes the algorithm and provides pointers
+At the heart of this flexibility is the \textit{descriptor} system.  A descriptor is essentially just a C \textit{struct} which describes the algorithm and provides pointers
-to functions that do the work.  For a given class of operation (e.g. cipher, hash, prng) the functions have identical prototypes which makes development simple.  In most
+to functions that do the required work.  For a given class of operation (e.g. cipher, hash, prng, bignum) the functions of a descriptor have identical prototypes which makes
-dependent routines all a developer has to do is register\_XXX() the descriptor and they're set.
+development simple.  In most dependent routines all an end developer has to do is register\_XXX() the descriptor and they are set.
-\section{Ciphers}
+\mysection{Ciphers}
 The ciphers in LibTomCrypt are accessed through the ltc\_cipher\_descriptor structure.
+\label{sec:cipherdesc}
 \begin{small}
 \begin{verbatim}
 struct ltc_cipher_descriptor {
 /** name of cipher */
 char *name;
 /** internal ID */
 unsigned char ID;
 /** min keysize (octets) */
 int  min_key_length,
 /** max keysize (octets) */
 max_key_length,
 /** block size (octets) */
 block_length,
 /** default number of rounds */
 default_rounds;
 /** Setup the cipher
 @param key         The input symmetric key
 @param keylen      The length of the input key (octets)
 @param num_rounds  The requested number of rounds (0==default)
 @param skey        [out] The destination of the scheduled key
 @return CRYPT_OK if successful
 */
-int  (*setup)(const unsigned char *key, int keylen,
+int  (*setup)(const unsigned char *key,
-int num_rounds, symmetric_key *skey);
+int  keylen,
+int  num_rounds,
+symmetric_key *skey);
 /** Encrypt a block
 @param pt      The plaintext
 @param ct      [out] The ciphertext
 @param skey    The scheduled key
+@return CRYPT_OK if successful
 */
-void (*ecb_encrypt)(const unsigned char *pt,
+int (*ecb_encrypt)(const unsigned char *pt,
-unsigned char *ct, symmetric_key *skey);
+unsigned char *ct,
+symmetric_key *skey);
 /** Decrypt a block
 @param ct      The ciphertext
 @param pt      [out] The plaintext
 @param skey    The scheduled key
+@return CRYPT_OK if successful
 */
-void (*ecb_decrypt)(const unsigned char *ct,
+int (*ecb_decrypt)(const unsigned char *ct,
-unsigned char *pt, symmetric_key *skey);
+unsigned char *pt,
+symmetric_key *skey);
 /** Test the block cipher
-@return CRYPT_OK if successful, CRYPT_NOP if self-testing has been disabled
+@return CRYPT_OK if successful,
+CRYPT_NOP if self-testing has been disabled
 */
 int (*test)(void);
+/** Terminate the context
+@param skey    The scheduled key
+*/
+void (*done)(symmetric_key *skey);
 /** Determine a key size
-@param keysize    [in/out] The size of the key desired and the suggested size
+@param keysize    [in/out] The size of the key desired
+The suggested size
 @return CRYPT_OK if successful
 */
 int  (*keysize)(int *keysize);
 /** Accelerators **/
 /** Accelerated ECB encryption
 @param pt      Plaintext
 @param ct      Ciphertext
 @param blocks  The number of complete blocks to process
 @param skey    The scheduled key context
+@return CRYPT_OK if successful
 */
-void (*accel_ecb_encrypt)(const unsigned char *pt,
+int (*accel_ecb_encrypt)(const unsigned char *pt,
-unsigned char *ct, unsigned long blocks,
+unsigned char *ct,
-symmetric_key *skey);
+unsigned long  blocks,
+symmetric_key *skey);
 /** Accelerated ECB decryption
 @param pt      Plaintext
 @param ct      Ciphertext
 @param blocks  The number of complete blocks to process
 @param skey    The scheduled key context
+@return CRYPT_OK if successful
 */
-void (*accel_ecb_decrypt)(const unsigned char *ct,
+int (*accel_ecb_decrypt)(const unsigned char *ct,
-unsigned char *pt, unsigned long blocks,
+unsigned char *pt,
-symmetric_key *skey);
+unsigned long  blocks,
+symmetric_key *skey);
 /** Accelerated CBC encryption
 @param pt      Plaintext
 @param ct      Ciphertext
 @param blocks  The number of complete blocks to process
 @param IV      The initial value (input/output)
 @param skey    The scheduled key context
+@return CRYPT_OK if successful
 */
-void (*accel_cbc_encrypt)(const unsigned char *pt,
+int (*accel_cbc_encrypt)(const unsigned char *pt,
-unsigned char *ct, unsigned long blocks,
+unsigned char *ct,
-unsigned char *IV, symmetric_key *skey);
+unsigned long  blocks,
+unsigned char *IV,
+symmetric_key *skey);
 /** Accelerated CBC decryption
 @param pt      Plaintext
 @param ct      Ciphertext
 @param blocks  The number of complete blocks to process
 @param IV      The initial value (input/output)
 @param skey    The scheduled key context
+@return CRYPT_OK if successful
 */
-void (*accel_cbc_decrypt)(const unsigned char *ct,
+int (*accel_cbc_decrypt)(const unsigned char *ct,
-unsigned char *pt, unsigned long blocks,
+unsigned char *pt,
-unsigned char *IV, symmetric_key *skey);
+unsigned long  blocks,
+unsigned char *IV,
+symmetric_key *skey);
 /** Accelerated CTR encryption
 @param pt      Plaintext
 @param ct      Ciphertext
 @param blocks  The number of complete blocks to process
 @param IV      The initial value (input/output)
 @param mode    little or big endian counter (mode=0 or mode=1)
 @param skey    The scheduled key context
+@return CRYPT_OK if successful
 */
-void (*accel_ctr_encrypt)(const unsigned char *pt,
+int (*accel_ctr_encrypt)(const unsigned char *pt,
-unsigned char *ct, unsigned long blocks,
+unsigned char *ct,
-unsigned char *IV, int mode, symmetric_key *skey);
+unsigned long  blocks,
+unsigned char *IV,
+int  mode,
+symmetric_key *skey);
+/** Accelerated LRW
+@param pt      Plaintext
+@param ct      Ciphertext
+@param blocks  The number of complete blocks to process
+@param IV      The initial value (input/output)
+@param tweak   The LRW tweak
+@param skey    The scheduled key context
+@return CRYPT_OK if successful
+*/
+int (*accel_lrw_encrypt)(const unsigned char *pt,
+unsigned char *ct,
+unsigned long  blocks,
+unsigned char *IV,
+const unsigned char *tweak,
+symmetric_key *skey);
+/** Accelerated LRW
+@param ct      Ciphertext
+@param pt      Plaintext
+@param blocks  The number of complete blocks to process
+@param IV      The initial value (input/output)
+@param tweak   The LRW tweak
+@param skey    The scheduled key context
+@return CRYPT_OK if successful
+*/
+int (*accel_lrw_decrypt)(const unsigned char *ct,
+unsigned char *pt,
+unsigned long  blocks,
+unsigned char *IV,
+const unsigned char *tweak,
+symmetric_key *skey);
 /** Accelerated CCM packet (one-shot)
 @param key        The secret key to use
 @param keylen     The length of the secret key (octets)
+@param uskey      A previously scheduled key [can be NULL]
 @param nonce      The session nonce [use once]
 @param noncelen   The length of the nonce
 @param header     The header for the session
 @param headerlen  The length of the header (octets)
 @param pt         [out] The plaintext
 @param ptlen      The length of the plaintext (octets)
 @param ct         [out] The ciphertext
 @param tag        [out] The destination tag
-@param taglen     [in/out] The max size and resulting size of the authentication tag
+@param taglen     [in/out] The max size and resulting size
+of the authentication tag
 @param direction  Encrypt or Decrypt direction (0 or 1)
 @return CRYPT_OK if successful
 */
-void (*accel_ccm_memory)(
+int (*accel_ccm_memory)(
 const unsigned char *key,    unsigned long keylen,
+symmetric_key       *uskey,
 const unsigned char *nonce,  unsigned long noncelen,
 const unsigned char *header, unsigned long headerlen,
 unsigned char *pt,     unsigned long ptlen,
 unsigned char *ct,
 unsigned char *tag,    unsigned long *taglen,
 int  direction);
 /** Accelerated GCM packet (one shot)
-@param key               The secret key
+@param key        The secret key
-@param keylen            The length of the secret key
+@param keylen     The length of the secret key
-@param IV                The initial vector
+@param IV         The initial vector
-@param IVlen             The length of the initial vector
+@param IVlen      The length of the initial vector
-@param adata             The additional authentication data (header)
+@param adata      The additional authentication data (header)
-@param adatalen          The length of the adata
+@param adatalen   The length of the adata
-@param pt                The plaintext
+@param pt         The plaintext
-@param ptlen             The length of the plaintext (ciphertext length is the same)
+@param ptlen      The length of the plaintext/ciphertext
-@param ct                The ciphertext
+@param ct         The ciphertext
-@param tag               [out] The MAC tag
+@param tag        [out] The MAC tag
-@param taglen            [in/out] The MAC tag length
+@param taglen     [in/out] The MAC tag length
-@param direction         Encrypt or Decrypt mode (GCM_ENCRYPT or GCM_DECRYPT)
+@param direction  Encrypt or Decrypt mode (GCM_ENCRYPT or GCM_DECRYPT)
+@return CRYPT_OK on success
 */
-void (*accel_gcm_memory)(
+int (*accel_gcm_memory)(
 const unsigned char *key,    unsigned long keylen,
 const unsigned char *IV,     unsigned long IVlen,
 const unsigned char *adata,  unsigned long adatalen,
 unsigned char *pt,     unsigned long ptlen,
 unsigned char *ct,
 unsigned char *tag,    unsigned long *taglen,
 int direction);
+/** Accelerated one shot OMAC
+@param key            The secret key
+@param keylen         The key length (octets)
+@param in             The message
+@param inlen          Length of message (octets)
+@param out            [out] Destination for tag
+@param outlen         [in/out] Initial and final size of out
+@return CRYPT_OK on success
+*/
+int (*omac_memory)(
+const unsigned char *key, unsigned long keylen,
+const unsigned char *in,  unsigned long inlen,
+unsigned char *out, unsigned long *outlen);
+/** Accelerated one shot XCBC
+@param key            The secret key
+@param keylen         The key length (octets)
+@param in             The message
+@param inlen          Length of message (octets)
+@param out            [out] Destination for tag
+@param outlen         [in/out] Initial and final size of out
+@return CRYPT_OK on success
+*/
+int (*xcbc_memory)(
+const unsigned char *key, unsigned long keylen,
+const unsigned char *in,  unsigned long inlen,
+unsigned char *out, unsigned long *outlen);
+/** Accelerated one shot F9
+@param key            The secret key
+@param keylen         The key length (octets)
+@param in             The message
+@param inlen          Length of message (octets)
+@param out            [out] Destination for tag
+@param outlen         [in/out] Initial and final size of out
+@return CRYPT_OK on success
+@remark Requires manual padding
+*/
+int (*f9_memory)(
+const unsigned char *key, unsigned long keylen,
+const unsigned char *in,  unsigned long inlen,
+unsigned char *out, unsigned long *outlen);
 };
 \end{verbatim}
 \end{small}
 \subsection{Name}
-The ``name'' parameter specifies the name of the cipher.  This is what a developer would pass to find\_cipher() to find the cipher in the descriptor
+\index{find\_cipher()}
+The \textit{name} parameter specifies the name of the cipher.  This is what a developer would pass to find\_cipher() to find the cipher in the descriptor
 tables.
 \subsection{Internal ID}
-This is a single byte Internal ID you can use to distingish ciphers from each other.
+This is a single byte Internal ID you can use to distinguish ciphers from each other.
 \subsection{Key Lengths}
-The minimum key length is ``min\_key\_length'' and is measured in octets.  Similarly the maximum key length is ``max\_key\_length''.  They can be equal
+The minimum key length is \textit{min\_key\_length} and is measured in octets.  Similarly the maximum key length is \textit{max\_key\_length}.  They can be equal
 and both must valid key sizes for the cipher.  Values in between are not assumed to be valid though they may be.
 \subsection{Block Length}
-The size of the ciphers plaintext or ciphertext is ``block\_length'' and is measured in octets.
+The size of the ciphers plaintext or ciphertext is \textit{block\_length} and is measured in octets.
 \subsection{Rounds}
-Some ciphers allow different number of rounds to be used.  Usually you just use the default.  The default round count is ``default\_rounds''.
+Some ciphers allow different number of rounds to be used.  Usually you just use the default.  The default round count is \textit{default\_rounds}.
 \subsection{Setup}
-To initialize a cipher (for ECB mode) the function setup() was provided.  It accepts an array of key octets ``key'' of length ``keylen'' octets.  The user
+To initialize a cipher (for ECB mode) the function setup() was provided.  It accepts an array of key octets \textit{key} of length \textit{keylen} octets.  The user
-can specify the number of rounds they want through ``num\_rounds'' where $num\_rounds = 0$ means use the default.  The destination of a scheduled key is stored
+can specify the number of rounds they want through \textit{num\_rounds} where $num\_rounds = 0$ means use the default.  The destination of a scheduled key is stored
-in ``skey''.
+in \textit{skey}.
-Inside the ``symmetric\_key'' union there is a ``void *data'' which you can use to allocate data if you need a data structure that doesn't fit with the existing
+Inside the \textit{symmetric\_key} union there is a \textit{void *data} which you can use to allocate data if you need a data structure that does not fit with the existing
-ones provided.  Just make sure in your ``done()'' function that you free the allocated memory.
+ones provided.  Just make sure in your \textit{done()} function that you free the allocated memory.
 \subsection{Single block ECB}
 To process a single block in ECB mode the ecb\_encrypt() and ecb\_decrypt() functions were provided.  The plaintext and ciphertext buffers are allowed to overlap so you
 must make sure you do not overwrite the output before you are finished with the input.
 \subsection{Testing}
-The test() function is used to self--test the ``device''.  It takes no arguments and returns \textbf{CRYPT\_OK} if all is working properly.
+The test() function is used to self--test the \textit{device}.  It takes no arguments and returns \textbf{CRYPT\_OK} if all is working properly.  You may return
+\textbf{CRYPT\_NOP} to indicate that no testing was performed.
 \subsection{Key Sizing}
-Occasionally a function will want to find a suitable key size to use since the input is oddly sized.  The keysize() function is for this case.  It accepts a
+Occasionally, a function will want to find a suitable key size to use since the input is oddly sized.  The keysize() function is for this case.  It accepts a
 pointer to an integer which represents the desired size.  The function then has to match it to the exact or a lower key size that is valid for the cipher.  For
 example, if the input is $25$ and $24$ is valid then it stores $24$ back in the pointed to integer.  It must not round up and must return an error if the keysize
 cannot be mapped to a valid key size for the cipher.
 \subsection{Acceleration}
 The next set of functions cover the accelerated functionality of the cipher descriptor.  Any combination of these functions may be set to \textbf{NULL} to indicate
-it is not supported.  In those cases the software fallbacks are used (using the single ECB block routines).
+it is not supported.  In those cases the software defaults are used (using the single ECB block routines).
 \subsubsection{Accelerated ECB}
 These two functions are meant for cases where a user wants to encrypt (in ECB mode no less) an array of blocks.  These functions are accessed
-through the accel\_ecb\_encrypt and accel\_ecb\_decrypt pointers.  The ``blocks'' count is the number of complete blocks to process.
+through the accel\_ecb\_encrypt and accel\_ecb\_decrypt pointers.  The \textit{blocks} count is the number of complete blocks to process.
 \subsubsection{Accelerated CBC}
 These two functions are meant for accelerated CBC encryption.  These functions are accessed through the accel\_cbc\_encrypt and accel\_cbc\_decrypt pointers.
-The ``blocks'' value is the number of complete blocks to process.  The ``IV'' is the CBC initial vector.  It is an input upon calling this function and must be
+The \textit{blocks} value is the number of complete blocks to process.  The \textit{IV} is the CBC initial vector.  It is an input upon calling this function and must be
 updated by the function before returning.
 \subsubsection{Accelerated CTR}
 This function is meant for accelerated CTR encryption.  It is accessible through the accel\_ctr\_encrypt pointer.
-The ``blocks'' value is the number of complete blocks to process.  The ``IV'' is the CTR counter vector.  It is an input upon calling this function and must be
+The \textit{blocks} value is the number of complete blocks to process.  The \textit{IV} is the CTR counter vector.  It is an input upon calling this function and must be
-updated by the function before returning.  The ``mode'' value indicates whether the counter is big (mode = CTR\_COUNTER\_BIG\_ENDIAN) or
+updated by the function before returning.  The \textit{mode} value indicates whether the counter is big (mode = CTR\_COUNTER\_BIG\_ENDIAN) or
 little (mode = CTR\_COUNTER\_LITTLE\_ENDIAN) endian.
 This function (and the way it's called) differs from the other two since ctr\_encrypt() allows any size input plaintext.  The accelerator will only be
 called if the following conditions are met.
 \item The accelerator is present
 \item The CTR pad is empty
 \item The remaining length of the input to process is greater than or equal to the block size.
 \end{enumerate}
-The ``CTR pad'' is empty when a multiple (including zero) blocks of text have been processed.  That is, if you pass in seven bytes to AES--CTR mode you would have to
+The \textit{CTR pad} is empty when a multiple (including zero) blocks of text have been processed.  That is, if you pass in seven bytes to AES--CTR mode you would have to
 pass in a minimum of nine extra bytes before the accelerator could be called.  The CTR accelerator must increment the counter (and store it back into the
 buffer provided) before encrypting it to create the pad.
 The accelerator will only be used to encrypt whole blocks.  Partial blocks are always handled in software.
+\subsubsection{Accelerated LRW}
+These functions are meant for accelerated LRW.  They process blocks of input in lengths of multiples of 16 octets.  They must accept the \textit{IV} and \textit{tweak}
+state variables and updated them prior to returning.  Note that you may want to disable \textbf{LRW\_TABLES} in \textit{tomcrypt\_custom.h} if you intend
+to use accelerators for LRW.
+While both encrypt and decrypt accelerators are not required it is suggested as it makes lrw\_setiv() more efficient.
+Note that calling lrw\_done() will only invoke the cipher\_descriptor[].done() function on the \textit{symmetric\_key} parameter of the LRW state.  That means
+if your device requires any (LRW specific) resources you should free them in your ciphers() done function.  The simplest way to think of it is to write
+the plugin solely to do LRW with the cipher.  That way cipher\_descriptor[].setup() means to init LRW resources and cipher\_descriptor[].done() means to
+free them.
 \subsubsection{Accelerated CCM}
-This function is meant for accelerated CCM encryption or decryption.  It processes the entire packet in one call.  Note that the setup() function will not
+This function is meant for accelerated CCM encryption or decryption.  It processes the entire packet in one call.  You can optimize the work flow somewhat
-be called prior to this.  This function must handle scheduling the key provided on its own.
+by allowing the caller to call the setup() function first to schedule the key if your accelerator cannot do the key schedule on the fly (for instance).  This
+function MUST support both key passing methods.
+\begin{center}
+\begin{small}
+\begin{tabular}{|r|r|l|}
+\hline \textbf{key} & \textbf{uskey} & \textbf{Source of key} \\
+\hline NULL         & NULL           & Error, not supported \\
+\hline non-NULL     & NULL           & Use key, do a key schedule \\
+\hline NULL         & non-NULL       & Use uskey, key schedule not required \\
+\hline non-NULL     & non-NULL       & Use uskey, key schedule not required \\
+\hline
+\end{tabular}
+\end{small}
+\end{center}
+\index{ccm\_memory()} This function is called when the user calls ccm\_memory().
 \subsubsection{Accelerated GCM}
+\index{gcm\_memory()}
 This function is meant for accelerated GCM encryption or decryption.  It processes the entire packet in one call.  Note that the setup() function will not
-be called prior to this.  This function must handle scheduling the key provided on its own.
+be called prior to this.  This function must handle scheduling the key provided on its own.  It is called when the user calls gcm\_memory().
-\section{One--Way Hashes}
+\subsubsection{Accelerated OMAC}
+\index{omac\_memory()}
+This function is meant to perform an optimized OMAC1 (CMAC) message authentication code computation when the user calls omac\_memory().
+\subsubsection{Accelerated XCBC-MAC}
+\index{xcbc\_memory()}
+This function is meant to perform an optimized XCBC-MAC message authentication code computation when the user calls xcbc\_memory().
+\subsubsection{Accelerated F9}
+\index{f9\_memory()}
+This function is meant to perform an optimized F9 message authentication code computation when the user calls f9\_memory().  Like f9\_memory(), it requires
+the caller to perform any 3GPP related padding before calling in order to ensure proper compliance with F9.
+\mysection{One--Way Hashes}
 The hash functions are accessed through the ltc\_hash\_descriptor structure.
 \begin{small}
 \begin{verbatim}
 struct ltc_hash_descriptor {
 /** name of hash */
 char *name;
 /** internal ID */
 unsigned char ID;
 /** Size of digest in octets */
 unsigned long hashsize;
 /** Input block size in octets */
 unsigned long blocksize;
 /** ASN.1 OID */
 unsigned long OID[16];
 /** Length of DER encoding */
 unsigned long OIDlen;
 /** Init a hash state
 @param hash   The hash to initialize
 @return CRYPT_OK if successful
 */
 int (*init)(hash_state *hash);
 /** Process a block of data
 @param hash   The hash state
 @param in     The data to hash
 @param inlen  The length of the data (octets)
 @return CRYPT_OK if successful
 */
-int (*process)(hash_state *hash, const unsigned char *in, unsigned long inlen);
+int (*process)(         hash_state *hash,
+const unsigned char *in,
+unsigned long  inlen);
 /** Produce the digest and store it
 @param hash   The hash state
 @param out    [out] The destination of the digest
 @return CRYPT_OK if successful
 */
-int (*done)(hash_state *hash, unsigned char *out);
+int (*done)(   hash_state *hash,
+unsigned char *out);
 /** Self-test
-@return CRYPT_OK if successful, CRYPT_NOP if self-tests have been disabled
+@return CRYPT_OK if successful,
+CRYPT_NOP if self-tests have been disabled
 */
 int (*test)(void);
+/* accelerated hmac callback: if you need to-do
+multiple packets just use the generic hmac_memory
+and provide a hash callback
+*/
+int  (*hmac_block)(const unsigned char *key,
+unsigned long  keylen,
+const unsigned char *in,
+unsigned long  inlen,
+unsigned char *out,
+unsigned long *outlen);
 };
 \end{verbatim}
 \end{small}
 \subsection{Name}
 \subsection{Internal ID}
 This is the internal ID byte used to distinguish the hash from other hashes.
 \subsection{Digest Size}
-The ``hashsize'' variable indicates the length of the output in octets.
+The \textit{hashsize} variable indicates the length of the output in octets.
 \subsection{Block Size}
-The `blocksize'' variable indicates the length of input (in octets) that the hash processes in a given
+The \textit{blocksize} variable indicates the length of input (in octets) that the hash processes in a given
-invokation.
+invocation.
 \subsection{OID Identifier}
 This is the universal ASN.1 Object Identifier for the hash.
 \subsection{Initialization}
 \subsection{Done}
 The done function terminates the hash and returns the message digest.
 \subsection{Acceleration}
 A compatible accelerator must allow processing data in any granularity which may require internal padding on the driver side.
-\section{Pseudo--Random Number Generators}
+\subsection{HMAC Acceleration}
+The hmac\_block() callback is meant for single--shot optimized HMAC implementations.  It is called directly by hmac\_memory() if present.  If you need
+to be able to process multiple blocks per MAC then you will have to simply provide a process() callback and use hmac\_memory() as provided in LibTomCrypt.
+\mysection{Pseudo--Random Number Generators}
 The pseudo--random number generators are accessible through the ltc\_prng\_descriptor structure.
 \begin{small}
 \begin{verbatim}
 struct ltc_prng_descriptor {
 /** Name of the PRNG */
 char *name;
 /** size in bytes of exported state */
 int  export_size;
 /** Start a PRNG state
 @param prng   [out] The state to initialize
 @return CRYPT_OK if successful
 */
 int (*start)(prng_state *prng);
 /** Add entropy to the PRNG
 @param in         The entropy
-@param inlen      Length of the entropy (octets)\
+@param inlen      Length of the entropy (octets)
 @param prng       The PRNG state
 @return CRYPT_OK if successful
 */
-int (*add_entropy)(const unsigned char *in, unsigned long inlen, prng_state *prng);
+int (*add_entropy)(const unsigned char *in,
+unsigned long  inlen,
+prng_state *prng);
 /** Ready a PRNG state to read from
 @param prng       The PRNG state to ready
 @return CRYPT_OK if successful
 */
 int (*ready)(prng_state *prng);
 /** Read from the PRNG
 @param out     [out] Where to store the data
 @param outlen  Length of data desired (octets)
 @param prng    The PRNG state to read from
 @return Number of octets read
 */
-unsigned long (*read)(unsigned char *out, unsigned long outlen, prng_state *prng);
+unsigned long (*read)(unsigned char *out,
+unsigned long  outlen,
+prng_state *prng);
 /** Terminate a PRNG state
 @param prng   The PRNG state to terminate
 @return CRYPT_OK if successful
 */
 int (*done)(prng_state *prng);
 /** Export a PRNG state
 @param out     [out] The destination for the state
-@param outlen  [in/out] The max size and resulting size of the PRNG state
+@param outlen  [in/out] The max size and resulting size
 @param prng    The PRNG to export
 @return CRYPT_OK if successful
 */
-int (*pexport)(unsigned char *out, unsigned long *outlen, prng_state *prng);
+int (*pexport)(unsigned char *out,
+unsigned long *outlen,
+prng_state *prng);
 /** Import a PRNG state
 @param in      The data to import
 @param inlen   The length of the data to import (octets)
 @param prng    The PRNG to initialize/import
 @return CRYPT_OK if successful
 */
-int (*pimport)(const unsigned char *in, unsigned long inlen, prng_state *prng);
+int (*pimport)(const unsigned char *in,
+unsigned long  inlen,
+prng_state *prng);
 /** Self-test the PRNG
-@return CRYPT_OK if successful, CRYPT_NOP if self-testing has been disabled
+@return CRYPT_OK if successful,
+CRYPT_NOP if self-testing has been disabled
 */
 int (*test)(void);
 };
 \end{verbatim}
 \end{small}
 \subsection{Done}
 Terminate a PRNG state.  The behaviour of this function depends on the particular PRNG used.
 \subsection{Exporting and Importing}
-An exported PRNG state is data that the PRNG can later import to resume activity.  They're not meant to resume ``the same session''
+An exported PRNG state is data that the PRNG can later import to resume activity.  They're not meant to resume \textit{the same session}
 but should at least maintain the same level of state entropy.
+\mysection{BigNum Math Descriptors}
+The library also makes use of the math descriptors to access math functions.  While bignum math libraries usually differ in implementation
+it hasn't proven hard to write \textit{glue} to use math libraries so far.  The basic descriptor looks like.
+\begin{small}
+\begin{verbatim}
+/** math descriptor */
+typedef struct {
+/** Name of the math provider */
+char *name;
+/** Bits per digit, amount of bits must fit in an unsigned long */
+int  bits_per_digit;
+/* ---- init/deinit functions ---- */
+/** initialize a bignum
+@param   a     The number to initialize
+@return  CRYPT_OK on success
+*/
+int (*init)(void **a);
+/** init copy
+@param  dst    The number to initialize and write to
+@param  src    The number to copy from
+@return CRYPT_OK on success
+*/
+int (*init_copy)(void **dst, void *src);
+/** deinit
+@param   a    The number to free
+@return CRYPT_OK on success
+*/
+void (*deinit)(void *a);
+/* ---- data movement ---- */
+/** copy
+@param   src   The number to copy from
+@param   dst   The number to write to
+@return CRYPT_OK on success
+*/
+int (*copy)(void *src, void *dst);
+/* ---- trivial low level functions ---- */
+/** set small constant
+@param a    Number to write to
+@param n    Source upto bits_per_digit (meant for small constants)
+@return CRYPT_OK on success
+*/
+int (*set_int)(void *a, unsigned long n);
+/** get small constant
+@param a  Small number to read
+@return   The lower bits_per_digit of the integer (unsigned)
+*/
+unsigned long (*get_int)(void *a);
+/** get digit n
+@param a  The number to read from
+@param n  The number of the digit to fetch
+@return  The bits_per_digit  sized n'th digit of a
+*/
+unsigned long (*get_digit)(void *a, int n);
+/** Get the number of digits that represent the number
+@param a   The number to count
+@return The number of digits used to represent the number
+*/
+int (*get_digit_count)(void *a);
+/** compare two integers
+@param a   The left side integer
+@param b   The right side integer
+@return LTC_MP_LT if a < b,
+LTC_MP_GT if a > b and
+LTC_MP_EQ otherwise.  (signed comparison)
+*/
+int (*compare)(void *a, void *b);
+/** compare against int
+@param a   The left side integer
+@param b   The right side integer (upto bits_per_digit)
+@return LTC_MP_LT if a < b,
+LTC_MP_GT if a > b and
+LTC_MP_EQ otherwise.  (signed comparison)
+*/
+int (*compare_d)(void *a, unsigned long n);
+/** Count the number of bits used to represent the integer
+@param a   The integer to count
+@return The number of bits required to represent the integer
+*/
+int (*count_bits)(void * a);
+/** Count the number of LSB bits which are zero
+@param a   The integer to count
+@return The number of contiguous zero LSB bits
+*/
+int (*count_lsb_bits)(void *a);
+/** Compute a power of two
+@param a  The integer to store the power in
+@param n  The power of two you want to store (a = 2^n)
+@return CRYPT_OK on success
+*/
+int (*twoexpt)(void *a , int n);
+/* ---- radix conversions ---- */
+/** read ascii string
+@param a     The integer to store into
+@param str   The string to read
+@param radix The radix the integer has been represented in (2-64)
+@return CRYPT_OK on success
+*/
+int (*read_radix)(void *a, const char *str, int radix);
+/** write number to string
+@param a     The integer to store
+@param str   The destination for the string
+@param radix The radix the integer is to be represented in (2-64)
+@return CRYPT_OK on success
+*/
+int (*write_radix)(void *a, char *str, int radix);
+/** get size as unsigned char string
+@param a  The integer to get the size
+@return   The length of the integer in octets
+*/
+unsigned long (*unsigned_size)(void *a);
+/** store an integer as an array of octets
+@param src   The integer to store
+@param dst   The buffer to store the integer in
+@return CRYPT_OK on success
+*/
+int (*unsigned_write)(void *src, unsigned char *dst);
+/** read an array of octets and store as integer
+@param dst   The integer to load
+@param src   The array of octets
+@param len   The number of octets
+@return CRYPT_OK on success
+*/
+int (*unsigned_read)(         void *dst,
+unsigned char *src,
+unsigned long  len);
+/* ---- basic math ---- */
+/** add two integers
+@param a   The first source integer
+@param b   The second source integer
+@param c   The destination of "a + b"
+@return CRYPT_OK on success
+*/
+int (*add)(void *a, void *b, void *c);
+/** add two integers
+@param a   The first source integer
+@param b   The second source integer
+(single digit of upto bits_per_digit in length)
+@param c   The destination of "a + b"
+@return CRYPT_OK on success
+*/
+int (*addi)(void *a, unsigned long b, void *c);
+/** subtract two integers
+@param a   The first source integer
+@param b   The second source integer
+@param c   The destination of "a - b"
+@return CRYPT_OK on success
+*/
+int (*sub)(void *a, void *b, void *c);
+/** subtract two integers
+@param a   The first source integer
+@param b   The second source integer
+(single digit of upto bits_per_digit in length)
+@param c   The destination of "a - b"
+@return CRYPT_OK on success
+*/
+int (*subi)(void *a, unsigned long b, void *c);
+/** multiply two integers
+@param a   The first source integer
+@param b   The second source integer
+(single digit of upto bits_per_digit in length)
+@param c   The destination of "a * b"
+@return CRYPT_OK on success
+*/
+int (*mul)(void *a, void *b, void *c);
+/** multiply two integers
+@param a   The first source integer
+@param b   The second source integer
+(single digit of upto bits_per_digit in length)
+@param c   The destination of "a * b"
+@return CRYPT_OK on success
+*/
+int (*muli)(void *a, unsigned long b, void *c);
+/** Square an integer
+@param a    The integer to square
+@param b    The destination
+@return CRYPT_OK on success
+*/
+int (*sqr)(void *a, void *b);
+/** Divide an integer
+@param a    The dividend
+@param b    The divisor
+@param c    The quotient (can be NULL to signify don't care)
+@param d    The remainder (can be NULL to signify don't care)
+@return CRYPT_OK on success
+*/
+int (*div)(void *a, void *b, void *c, void *d);
+/** divide by two
+@param  a   The integer to divide (shift right)
+@param  b   The destination
+@return CRYPT_OK on success
+*/
+int (*div_2)(void *a, void *b);
+/** Get remainder (small value)
+@param  a    The integer to reduce
+@param  b    The modulus (upto bits_per_digit in length)
+@param  c    The destination for the residue
+@return CRYPT_OK on success
+*/
+int (*modi)(void *a, unsigned long b, unsigned long *c);
+/** gcd
+@param  a     The first integer
+@param  b     The second integer
+@param  c     The destination for (a, b)
+@return CRYPT_OK on success
+*/
+int (*gcd)(void *a, void *b, void *c);
+/** lcm
+@param  a     The first integer
+@param  b     The second integer
+@param  c     The destination for [a, b]
+@return CRYPT_OK on success
+*/
+int (*lcm)(void *a, void *b, void *c);
+/** Modular multiplication
+@param  a     The first source
+@param  b     The second source
+@param  c     The modulus
+@param  d     The destination (a*b mod c)
+@return CRYPT_OK on success
+*/
+int (*mulmod)(void *a, void *b, void *c, void *d);
+/** Modular squaring
+@param  a     The first source
+@param  b     The modulus
+@param  c     The destination (a*a mod b)
+@return CRYPT_OK on success
+*/
+int (*sqrmod)(void *a, void *b, void *c);
+/** Modular inversion
+@param  a     The value to invert
+@param  b     The modulus
+@param  c     The destination (1/a mod b)
+@return CRYPT_OK on success
+*/
+int (*invmod)(void *, void *, void *);
+/* ---- reduction ---- */
+/** setup Montgomery
+@param a  The modulus
+@param b  The destination for the reduction digit
+@return CRYPT_OK on success
+*/
+int (*montgomery_setup)(void *a, void **b);
+/** get normalization value
+@param a   The destination for the normalization value
+@param b   The modulus
+@return  CRYPT_OK on success
+*/
+int (*montgomery_normalization)(void *a, void *b);
+/** reduce a number
+@param a   The number [and dest] to reduce
+@param b   The modulus
+@param c   The value "b" from montgomery_setup()
+@return CRYPT_OK on success
+*/
+int (*montgomery_reduce)(void *a, void *b, void *c);
+/** clean up  (frees memory)
+@param a   The value "b" from montgomery_setup()
+@return CRYPT_OK on success
+*/
+void (*montgomery_deinit)(void *a);
+/* ---- exponentiation ---- */
+/** Modular exponentiation
+@param a    The base integer
+@param b    The power (can be negative) integer
+@param c    The modulus integer
+@param d    The destination
+@return CRYPT_OK on success
+*/
+int (*exptmod)(void *a, void *b, void *c, void *d);
+/** Primality testing
+@param a     The integer to test
+@param b     The destination of the result (FP_YES if prime)
+@return CRYPT_OK on success
+*/
+int (*isprime)(void *a, int *b);
+/* ----  (optional) ecc point math ---- */
+/** ECC GF(p) point multiplication (from the NIST curves)
+@param k   The integer to multiply the point by
+@param G   The point to multiply
+@param R   The destination for kG
+@param modulus  The modulus for the field
+@param map Boolean indicated whether to map back to affine or not
+(can be ignored if you work in affine only)
+@return CRYPT_OK on success
+*/
+int (*ecc_ptmul)(     void *k,
+ecc_point *G,
+ecc_point *R,
+void *modulus,
+int  map);
+/** ECC GF(p) point addition
+@param P    The first point
+@param Q    The second point
+@param R    The destination of P + Q
+@param modulus  The modulus
+@param mp   The "b" value from montgomery_setup()
+@return CRYPT_OK on success
+*/
+int (*ecc_ptadd)(ecc_point *P,
+ecc_point *Q,
+ecc_point *R,
+void *modulus,
+void *mp);
+/** ECC GF(p) point double
+@param P    The first point
+@param R    The destination of 2P
+@param modulus  The modulus
+@param mp   The "b" value from montgomery_setup()
+@return CRYPT_OK on success
+*/
+int (*ecc_ptdbl)(ecc_point *P,
+ecc_point *R,
+void *modulus,
+void *mp);
+/** ECC mapping from projective to affine,
+currently uses (x,y,z) => (x/z^2, y/z^3, 1)
+@param P     The point to map
+@param modulus The modulus
+@param mp    The "b" value from montgomery_setup()
+@return CRYPT_OK on success
+@remark The mapping can be different but keep in mind a
+ecc_point only has three integers (x,y,z) so if
+you use a different mapping you have to make it fit.
+*/
+int (*ecc_map)(ecc_point *P, void *modulus, void *mp);
+/** Computes kA*A + kB*B = C using Shamir's Trick
+@param A        First point to multiply
+@param kA       What to multiple A by
+@param B        Second point to multiply
+@param kB       What to multiple B by
+@param C        [out] Destination point (can overlap with A or B)
+@param modulus  Modulus for curve
+@return CRYPT_OK on success
+*/
+int (*ecc_mul2add)(ecc_point *A, void *kA,
+ecc_point *B, void *kB,
+ecc_point *C,
+void *modulus);
+/* ---- (optional) rsa optimized math (for internal CRT) ---- */
+/** RSA Key Generation
+@param prng     An active PRNG state
+@param wprng    The index of the PRNG desired
+@param size     The size of the key in octets
+@param e        The "e" value (public key).
+e==65537 is a good choice
+@param key      [out] Destination of a newly created private key pair
+@return CRYPT_OK if successful, upon error all allocated ram is freed
+*/
+int (*rsa_keygen)(prng_state *prng,
+int  wprng,
+int  size,
+long  e,
+rsa_key *key);
+/** RSA exponentiation
+@param in       The octet array representing the base
+@param inlen    The length of the input
+@param out      The destination (to be stored in an octet array format)
+@param outlen   The length of the output buffer and the resulting size
+(zero padded to the size of the modulus)
+@param which    PK_PUBLIC for public RSA and PK_PRIVATE for private RSA
+@param key      The RSA key to use
+@return CRYPT_OK on success
+*/
+int (*rsa_me)(const unsigned char *in,   unsigned long inlen,
+unsigned char *out,  unsigned long *outlen, int which,
+rsa_key *key);
+} ltc_math_descriptor;
+\end{verbatim}
+\end{small}
+Most of the functions are fairly straightforward and do not need documentation.  We'll cover the basic conventions of the API and then explain the accelerated functions.
+\subsection{Conventions}
+All \textit{bignums} are accessed through an opaque \textit{void *} data type.  You must internally cast the pointer if you need to access members of your bignum structure.  During
+the init calls a \textit{void **} will be passed where you allocate your structure and set the pointer then initialize the number to zero.  During the deinit calls you must
+free the bignum as well as the structure you allocated to place it in.
+All functions except the Montgomery reductions work from left to right with the arguments.  For example, mul(a, b, c) computes $c \leftarrow ab$.
+All functions (except where noted otherwise) return \textbf{CRYPT\_OK} to signify a successful operation.  All error codes must be valid LibTomCrypt error codes.
+The digit routines (including functions with the \textit{i} suffix) use a \textit{unsigned long} to represent the digit.  If your internal digit is larger than this you must
+then partition your digits.  Normally this does not matter as \textit{unsigned long} will be the same size as your register size.  Note that if your digit is smaller
+than an \textit{unsigned long} that is also acceptable as the \textit{bits\_per\_digit} parameter will specify this.
+\subsection{ECC Functions}
+The ECC system in LibTomCrypt is based off of the NIST recommended curves over $GF(p)$ and is used to implement EC-DSA and EC-DH.   The ECC functions work with
+the \textbf{ecc\_point} structure and assume the points are stored in Jacobian projective format.
+\begin{verbatim}
+/** A point on a ECC curve, stored in Jacobian format such
+that (x,y,z) => (x/z^2, y/z^3, 1) when interpreted as affine */
+typedef struct {
+/** The x co-ordinate */
+void *x;
+/** The y co-ordinate */
+void *y;
+/** The z co-ordinate */
+void *z;
+} ecc_point;
+\end{verbatim}
+All ECC functions must use this mapping system.  The only exception is when you remap all ECC callbacks which will allow you to have more control
+over how the ECC math will be implemented.  Out of the box you only have three parameters per point to use $(x, y, z)$ however, these are just void pointers.  They
+could point to anything you want.  The only further exception is the export functions which expects the values to be in affine format.
+\subsubsection{Point Multiply}
+This will multiply the point $G$ by the scalar $k$ and store the result in the point $R$.  The value should be mapped to affine only if $map$ is set to one.
+\subsubsection{Point Addition}
+This will add the point $P$ to the point $Q$ and store it in the point $R$.  The $mp$ parameter is the \textit{b} value from the montgomery\_setup() call.  The input points
+may be in either affine (with $z = 1$) or projective format and the output point is always projective.
+\subsubsection{Point Mapping}
+This will map the point $P$ back from projective to affine.  The output point $P$ must be of the form $(x, y, 1)$.
+\subsubsection{Shamir's Trick}
+\index{Shamir's Trick}
+\index{ltc\_ecc\_mul2add()}
+To accelerate EC--DSA verification the library provides a built--in function called ltc\_ecc\_mul2add().  This performs two point multiplications and an addition in
+roughly the time of one point multiplication.  It is called from ecc\_verify\_hash() if an accelerator is not present.  The acclerator function must allow the points to
+overlap (e.g., $A \leftarrow k_1A + k_2B$) and must return the final point in affine format.
+\subsection{RSA Functions}
+The RSA Modular Exponentiation (ME) function is used by the RSA API to perform exponentiations for private and public key operations.  In particular for
+private key operations it uses the CRT approach to lower the time required.  It is passed an RSA key with the following format.
+\begin{verbatim}
+/** RSA PKCS style key */
+typedef struct Rsa_key {
+/** Type of key, PK_PRIVATE or PK_PUBLIC */
+int type;
+/** The public exponent */
+void *e;
+/** The private exponent */
+void *d;
+/** The modulus */
+void *N;
+/** The p factor of N */
+void *p;
+/** The q factor of N */
+void *q;
+/** The 1/q mod p CRT param */
+void *qP;
+/** The d mod (p - 1) CRT param */
+void *dP;
+/** The d mod (q - 1) CRT param */
+void *dQ;
+} rsa_key;
+\end{verbatim}
+The call reads the \textit{in} buffer as an unsigned char array in big endian format.  Then it performs the exponentiation and stores the output in big endian format
+to the \textit{out} buffer.  The output must be zero padded (leading bytes) so that the length of the output matches the length of the modulus (in bytes).  For example,
+for RSA--1024 the output is always 128 bytes regardless of how small the numerical value of the exponentiation is.
+Since the function is given the entire RSA key (for private keys only) CRT is possible as prescribed in the PKCS \#1 v2.1 specification.
+\newpage
+\markboth{Index}{Index}
 \input{crypt.ind}
 \end{document}
 % $Source: /cvs/libtom/libtomcrypt/crypt.tex,v $
-% $Revision: 1.39 $
+% $Revision: 1.123 $
-% $Date: 2005/06/27 13:08:28 $
+% $Date: 2006/12/16 19:08:17 $

Mercurial > dropbear

comparison crypt.tex @ 381:999a5eb4ed10 libtomcrypt-dropbear