Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Fetching contributors…

Cannot retrieve contributors at this time

6793 lines (5648 sloc) 307.661 kB
<
\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}}
\def\catn{$\|$}
\def\divides{\hspace{0.3em} | \hspace{0.3em}}
\def\nequiv{\not\equiv}
\def\approx{\raisebox{0.2ex}{\mbox{\small $\sim$}}}
\def\lcm{{\rm lcm}}
\def\gcd{{\rm gcd}}
\def\log{{\rm log}}
\def\ord{{\rm ord}}
\def\abs{{\mathit abs}}
\def\rep{{\mathit rep}}
\def\mod{{\mathit\ mod\ }}
\renewcommand{\pmod}[1]{\ ({\rm mod\ }{#1})}
\newcommand{\floor}[1]{\left\lfloor{#1}\right\rfloor}
\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 \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\F{{\mathbb F}}
\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}
\frontmatter
\pagestyle{empty}
~
\vspace{2in}
~
\begin{center}
\begin{Huge}LibTomCrypt\end{Huge}
~
\begin{large}Developer Manual\end{large}
~
\vspace{15mm}
\begin{tabular}{c}
Tom St Denis \\
LibTom Projects
\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}
\mysection{What is the LibTomCrypt?}
LibTomCrypt is a portable ISO C cryptographic library meant to be a tool set for cryptographers who are
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 routines.
The library was designed such that new ciphers/hashes/PRNGs can be added at run-time 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 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.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.
\mysection{Why did I write it?}
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, 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 the library you
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 run-time. That means your
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 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 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 \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,
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. 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
mode routines for every single cipher. That means every time you add or remove a cipher from the library
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.
\mysection{License}
The project is hereby released as public domain.
\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 author's 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 \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.
\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
\item Ajay K. Agrawal
\item Brian Gladman
\item Svante Seleborg
\item Clay Culver
\item Jason Klapste
\item Dobes Vandermeer
\item Daniel Richards
\item Wayne Scott
\item Andrew Tyler
\item Sky Schulz
\item Christopher Imes
\end{enumerate}
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)}
\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
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 occurred, %s\n", error_to_string(err));
/* perform error handling */
}
/* 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 \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 \textit{tomcrypt.h} also includes \textit{stdio.h}, \textit{string.h}, \textit{stdlib.h}, \textit{time.h} and \textit{ctype.h}.
\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 LOAD32L(x, y) & {\bf unsigned long} x, {\bf unsigned char} *y & $y[0 \ldots 3] \to x$ \\
\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 & 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 RORc(x, y) & {\bf unsigned long} x, {\bf const unsigned long} y & $x >> y, 0 \le y \le 31$ \\
\hline && \\
\hline ROL64(x, y) & {\bf unsigned long} x, {\bf unsigned long} y & $x << y, 0 \le y \le 63$ \\
\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}
\end{figure}
\mysection{Functions with Variable Length Output}
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 char buffer[1024];
unsigned long x;
int err;
/* ... Make up the RSA key somehow ... */
/* 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 */
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 back into
\textit{x} so that the calling application will know how many bytes were used.
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 \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 \textit{prng\_state} argument (sprng for example). The \textit{prng\_state} argument
may be passed as \textbf{NULL} in such situations.
\index{register\_prng()} \index{rsa\_make\_key()}
\begin{small}
\begin{verbatim}
#include <tomcrypt.h>
int main(void) {
rsa_key key;
int err;
/* 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}
\mysection{Core Functions}
LibTomCrypt provides several block ciphers with an ECB block mode interface. It is 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,
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 \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 must provide six visible
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,
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 \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 \textit{blowfish\_setup()} do not
pass the scheduled key onto \textit{rc5\_ecb\_encrypt()}. All built--in setup functions do not allocate memory off the heap so
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 functions per cipher:
\index{Cipher Encrypt} \index{Cipher Decrypt}
\begin{verbatim}
int XXX_ecb_encrypt(const unsigned char *pt,
unsigned char *ct,
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.}, 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 \textit{pt}\footnote{pt stands for plaintext.} is the input and
\textit{ct}\footnote{ct stands for ciphertext.} is the output. For the decryption function it's the opposite. They both
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. 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 \textit{keysize} down to the next appropriate key size. This function
will return {\bf CRYPT\_OK} if the key size specified is acceptable. For example:
\begin{small}
\begin{verbatim}
#include <tomcrypt.h>
int main(void)
{
int keysize, err;
/* now given a 20 byte key what keysize does Twofish want to use? */
keysize = 20;
if ((err = twofish_keysize(&keysize)) != CRYPT_OK) {
printf("Error getting key size: %s\n", error_to_string(err));
return -1;
}
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 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, these functions will not do anything. However, user supplied
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.
\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 ... */
/* ... load a block of plaintext in pt ... */
/* schedule the key */
if ((err = blowfish_setup(key, /* the key we will use */
8, /* key is 8 bytes (64-bits) long */
0, /* 0 == use default # of rounds */
&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 */
ct, /* store encrypted data here */
&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 */
pt, /* store decrypted data here */
&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}
\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 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
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.
\mysection{The Cipher Descriptors}
\index{Cipher Descriptor}
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 (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;
...<snip>...
};
\end{verbatim}
\end{small}
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 \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 \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 \textit{name} equals {\bf NULL}.
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 \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 SAFER+ & saferp\_desc &16 & 16, 24, 32 & 8, 12, 16 \\
\hline AES & aes\_desc & 16 & 16, 24, 32 & 10, 12, 14 \\
& aes\_enc\_desc & 16 & 16, 24, 32 & 10, 12, 14 \\
\hline Twofish & twofish\_desc & 16 & 16, 24, 32 & 16 \\
\hline DES & des\_desc & 8 & 8 & 16 \\
\hline 3DES (EDE mode) & des3\_desc & 8 & 24 & 16 \\
\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
rijndael\_desc and rijndael\_enc\_desc provide the cipher named \textit{rijndael}. The descriptors aes\_desc and
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 \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 \textit{encrypt only} descriptors are set to \textbf{NULL} and
should not be called.
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 \textit{encrypt only} functionality has only been implemented for
Rijndael as it makes the most sense for this cipher.
\item
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 \textit{Twofish} has additional configuration options (Figure \ref{fig:twofishopts}) that take place at build time. These options are found in
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 \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 \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 \textit{TWOFISH\_SMALL} is defined since the s-boxes and MDS multiply form the heart of the
Twofish round function.
\begin{figure}[hpbt]
\index{Twofish build options} \index{TWOFISH\_SMALL} \index{TWOFISH\_TABLES}
\begin{small}
\begin{center}
\begin{tabular}{|l|l|l|}
\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 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 $-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];
symmetric_key skey;
int err;
/* you must register a cipher before you use it */
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) */
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 \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}
Which accepts a pointer to a descriptor and returns the index into the global descriptor table. If an error occurs such
as there is no more room (it can have 32 ciphers at most) it will return {\bf{-1}}. If you try to add the same cipher more
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 the cipher, otherwise it returns {\bf CRYPT\_ERROR}.
\begin{small}
\begin{verbatim}
#include <tomcrypt.h>
int main(void)
{
int err;
/* register the cipher */
if (register_cipher(&rijndael_desc) == -1) {
printf("Error registering Rijndael\n");
return -1;
}
/* use Rijndael */
/* remove it */
if ((err = unregister_cipher(&rijndael_desc)) != CRYPT_OK) {
printf("Error removing Rijndael: %s\n", error_to_string(err));
return -1;
}
return 0;
}
\end{verbatim}
\end{small}
This snippet is a small program that registers Rijndael.
\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}$.
\subsubsection{ECB Mode}
\index{ECB mode}
ECB or Electronic Codebook Mode is the simplest method to use. It is given as:
\begin{equation}
C_i = E_k(P_i)
\end{equation}
This mode is very weak since it allows people to swap blocks and perform replay attacks if the same key is used more
than once.
\subsubsection{CBC Mode}
\index{CBC mode}
CBC or Cipher Block Chaining mode is a simple mode designed to prevent trivial forms of replay and swap attacks on ciphers.
It is given as:
\begin{equation}
C_i = E_k(P_i \oplus C_{i - 1})
\end{equation}
It is important that the initial vector be unique and preferably random for each message encrypted under the same key.
\subsubsection{CTR Mode}
\index{CTR mode}
CTR or Counter Mode is a mode which only uses the encryption function of the cipher. Given a initial vector which is
treated as a large binary counter the CTR mode is given as:
\begin{eqnarray}
C_{-1} = C_{-1} + 1\mbox{ }(\mbox{mod }2^W) \nonumber \\
C_i = P_i \oplus E_k(C_{-1})
\end{eqnarray}
Where $W$ is the size of a block in bits (e.g. 64 for Blowfish). As long as the initial vector is random for each message
encrypted under the same key replay and swap attacks are infeasible. CTR mode may look simple but it is as secure
as the block cipher is under a chosen plaintext attack (provided the initial vector is unique).
\subsubsection{CFB Mode}
\index{CFB mode}
CFB or Ciphertext Feedback Mode is a mode akin to CBC. It is given as:
\begin{eqnarray}
C_i = P_i \oplus C_{-1} \nonumber \\
C_{-1} = E_k(C_i)
\end{eqnarray}
Note that in this library the output feedback width is equal to the size of the block cipher. That is this mode is used
to encrypt whole blocks at a time. However, the library will buffer data allowing the user to encrypt or decrypt partial
blocks without a delay. When this mode is first setup it will initially encrypt the initial vector as required.
\subsubsection{OFB Mode}
\index{OFB mode}
OFB or Output Feedback Mode is a mode akin to CBC as well. It is given as:
\begin{eqnarray}
C_{-1} = E_k(C_{-1}) \nonumber \\
C_i = P_i \oplus C_{-1}
\end{eqnarray}
Like the CFB mode the output width in CFB mode is the same as the width of the block cipher. OFB mode will also
buffer the output which will allow you to encrypt or decrypt partial blocks without delay.
\subsection{Choice of Mode}
My personal preference is for the CTR mode since it has several key benefits:
\begin{enumerate}
\item No short cycles which is possible in the OFB and CFB modes.
\item Provably as secure as the block cipher being used under a chosen plaintext attack.
\item Technically does not require the decryption routine of the cipher.
\item Allows random access to the plaintext.
\item Allows the encryption of block sizes that are not equal to the size of the block cipher.
\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
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 \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,
const unsigned char *key,
int keylen,
int num_rounds,
symmetric_XXX *XXX);
int ctr_start( int cipher,
const unsigned char *IV,
const unsigned char *key,
int keylen,
int num_rounds,
int ctr_mode,
symmetric_CTR *ctr);
int ecb_start( int cipher,
const unsigned char *key,
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 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 \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.
The routines return {\bf CRYPT\_OK} if the cipher initialized correctly, otherwise, they return an error code.
\subsubsection{CTR Mode}
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
\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 counter before encrypting it for the first time.
As of V1.17, the library supports variable length counters for CTR mode. The (optional) counter length is specified by OR'ing the octet
length of the counter against the \textit{ctr\_mode} parameter. The default, zero, indicates that a full block length counter will be used. This also
ensures backwards compatibility with software that uses older versions of the library.
\begin{small}
\begin{verbatim}
symmetric_CTR ctr;
int err;
unsigned char IV[16], key[16];
/* use a 32-bit little endian counter */
if ((err = ctr_start(find_cipher("aes"),
IV, key, 16, 0,
CTR_COUNTER_LITTLE_ENDIAN | 4,
&ctr)) != CRYPT_OK) {
handle_error(err);
}
\end{verbatim}
\end{small}
Changing the counter size has little (really no) effect on the performance of the CTR chaining mode. It is provided for compatibility
with other software (and hardware) which have smaller fixed sized counters.
\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,
unsigned long len,
symmetric_YYY *YYY);
int XXX_decrypt(const unsigned char *ct,
unsigned char *pt,
unsigned long len,
symmetric_YYY *YYY);
\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, \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, 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.
\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_setiv(const unsigned char *IV,
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()}
\begin{verbatim}
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}
\begin{small}
\begin{verbatim}
#include <tomcrypt.h>
int main(void)
{
unsigned char key[16], IV[16], buffer[512];
symmetric_CTR ctr;
int x, err;
/* register twofish first */
if (register_cipher(&twofish_desc) == -1) {
printf("Error registering cipher.\n");
return -1;
}
/* somehow fill out key and IV */
/* 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) */
0, /* 0 == default # of rounds */
CTR_COUNTER_LITTLE_ENDIAN, /* Little endian counter */
&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 plaintext pt */
&ctr) /* CTR state */
) != CRYPT_OK) {
printf("ctr_encrypt error: %s\n", error_to_string(err));
return -1;
}
/* make use of ciphertext... */
/* now we want to decrypt so let's use ctr_setiv */
if ((err = ctr_setiv( IV, /* the initial IV we gave to ctr_start */
16, /* the IV is 16 bytes long */
&ctr) /* the ctr state we wish to modify */
) != CRYPT_OK) {
printf("ctr_setiv error: %s\n", error_to_string(err));
return -1;
}
if ((err = ctr_decrypt( buffer, /* ciphertext */
buffer, /* plaintext */
sizeof(buffer), /* length of plaintext */
&ctr) /* CTR state */
) != CRYPT_OK) {
printf("ctr_decrypt error: %s\n", error_to_string(err));
return -1;
}
/* terminate the stream */
if ((err = ctr_done(&ctr)) != CRYPT_OK) {
printf("ctr_done error: %s\n", error_to_string(err));
return -1;
}
/* clear up and return */
zeromem(key, sizeof(key));
zeromem(&ctr, sizeof(ctr));
return 0;
}
\end{verbatim}
\end{small}
\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{XTS Mode}
As of v1.17, LibTomCrypt supports XTS mode with code donated by Elliptic Semiconductor Inc.\footnote{www.ellipticsemi.com}.
XTS is a chaining mode for 128--bit block ciphers, recommended by IEEE (P1619)
for disk encryption. It is meant to be an encryption mode with random access to the message data without compromising privacy. It requires two private keys (of equal
length) to perform the encryption process. Each encryption invocation includes a sector number or unique identifier specified as a 128--bit string.
To initialize XTS mode use the following function call:
\index{xts\_start()}
\begin{verbatim}
int xts_start( int cipher,
const unsigned char *key1,
const unsigned char *key2,
unsigned long keylen,
int num_rounds,
symmetric_xts *xts)
\end{verbatim}
This will start the XTS mode with the two keys pointed to by \textit{key1} and \textit{key2} of length \textit{keylen} octets each.
To encrypt or decrypt a sector use the following calls:
\index{xts\_encrypt()} \index{xts\_decrypt()}
\begin{verbatim}
int xts_encrypt(
const unsigned char *pt, unsigned long ptlen,
unsigned char *ct,
const unsigned char *tweak,
symmetric_xts *xts);
int xts_decrypt(
const unsigned char *ct, unsigned long ptlen,
unsigned char *pt,
const unsigned char *tweak,
symmetric_xts *xts);
\end{verbatim}
The first will encrypt the plaintext pointed to by \textit{pt} of length \textit{ptlen} octets, and store the ciphertext in the array pointed to by
\textit{ct}. It uses the 128--bit tweak pointed to by \textit{tweak} to encrypt the block. The decrypt function performs the opposite operation. Both
functions support ciphertext stealing (blocks that are not multiples of 16 bytes).
The P1619 specification states the tweak for sector number shall be represented as a 128--bit little endian string.
To terminate the XTS state call the following function:
\index{xts\_done()}
\begin{verbatim}
void xts_done(symmetric_xts *xts);
\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 way it was intended to be used
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,
CTR and OMAC support and provides encryption and
authentication\footnote{Note that since EAX only requires OMAC and CTR you may use \textit{encrypt only} cipher descriptors with this mode.}.
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 \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 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 \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,
const unsigned char *key,
unsigned long keylen,
const unsigned char *nonce,
unsigned long noncelen,
const unsigned char *header,
unsigned long headerlen);
\end{verbatim}
Where \textit{eax} is the EAX state. The \textit{cipher} parameter is the index of the desired cipher in the descriptor table.
The \textit{key} parameter is the shared secret symmetric key of length \textit{keylen} octets. The \textit{nonce} parameter is the
random public string of length \textit{noncelen} octets. The \textit{header} parameter is the random (or fixed or \textbf{NULL}) header for the
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,
unsigned char *ct,
unsigned long length);
int eax_decrypt( eax_state *eax,
const unsigned char *ct,
unsigned char *pt,
unsigned long length);
\end{verbatim}
The function \textit{eax\_encrypt} will encrypt the bytes in \textit{pt} of \textit{length} octets, and store the ciphertext in
\textit{ct}. Note: \textit{ct} and \textit{pt} may be the same region in memory. This function will also send the ciphertext
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.
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,
const unsigned char *header,
unsigned long length);
\end{verbatim}
This will add the \textit{length} octet from \textit{header} to the given \textit{eax} header. Once the message is finished, the
\textit{tag} (checksum) may be computed with the following function:
\index{eax\_done()}
\begin{verbatim}
int eax_done( eax_state *eax,
unsigned char *tag,
unsigned long *taglen);
\end{verbatim}
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:
\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.
\begin{verbatim}
#include <tomcrypt.h>
int main(void)
{
int err;
eax_state eax;
unsigned char pt[64], ct[64], nonce[16], key[16], tag[16];
unsigned long taglen;
if (register_cipher(&rijndael_desc) == -1) {
printf("Error registering Rijndael");
return EXIT_FAILURE;
}
/* ... make up random nonce and key ... */
/* initialize context */
if ((err = eax_init( &eax, /* context */
find_cipher("rijndael"), /* cipher id */
nonce, /* the nonce */
16, /* nonce is 16 bytes */
"TestApp", /* example 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 */
pt, /* plaintext (source) */
ct, /* ciphertext (destination) */
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 */
tag, /* where to put tag */
&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 */
}
\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,
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,
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,
unsigned char *tag, unsigned long taglen,
int *res);
\end{verbatim}
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 \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, \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,
const unsigned char *key,
unsigned long keylen,
const unsigned char *nonce);
\end{verbatim}
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 \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 \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_decrypt( ocb_state *ocb,
const unsigned char *ct,
unsigned char *pt);
\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,
const unsigned char *pt,
unsigned long ptlen,
unsigned char *ct,
unsigned char *tag,
unsigned long *taglen);
\end{verbatim}
This will terminate an encrypt stream \textit{ocb}. If you have trailing bytes of plaintext that will not complete a block
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 \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,
const unsigned char *ct,
unsigned long ctlen,
unsigned char *pt,
const unsigned char *tag,
unsigned long taglen,
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 \textit{taglen} bytes of \textit{tag} provided. By default
\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()}
\begin{verbatim}
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 \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,
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. \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,
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,
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 \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 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
\textit{uskey} is not \textbf{NULL}, then \textit{key} may be \textbf{NULL} (and vice-versa).
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 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. 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 (also it is a planned NIST standard). Like EAX and OCB mode, it can be used in a streaming capacity
however, unlike EAX it cannot accept \textit{additional authentication data} (meta--data) after plaintext has been processed. This mode also only works with
block ciphers with a 16--byte block.
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 (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,
const unsigned char *key,
int keylen);
\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,
const unsigned char *IV,
unsigned long IVlen);
\end{verbatim}
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: 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.
\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
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 has been reset.
\index{gcm\_add\_aad()}
\begin{verbatim}
int gcm_add_aad( gcm_state *gcm,
const unsigned char *adata,
unsigned long adatalen);
\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.
\index{gcm\_process()}
\begin{verbatim}
int gcm_process( gcm_state *gcm,
unsigned char *pt,
unsigned long ptlen,
unsigned char *ct,
int direction);
\end{verbatim}
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
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,
unsigned char *tag,
unsigned long *taglen);
\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.
\index{gcm\_reset()}
\begin{verbatim}
int gcm_reset(gcm_state *gcm);
\end{verbatim}
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,
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);
\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 you are processing many packets under the same key you shouldn't use this function as it invokes the pre--computation with each call.
\subsubsection{Example Usage}
The following is an example usage of how to use GCM over multiple packets with a shared secret key.
\begin{small}
\begin{verbatim}
#include <tomcrypt.h>
int send_packet(const unsigned char *pt, unsigned long ptlen,
const unsigned char *iv, unsigned long ivlen,
const unsigned char *aad, unsigned long aadlen,
gcm_state *gcm)
{
int err;
unsigned long taglen;
unsigned char tag[16];
/* reset the state */
if ((err = gcm_reset(gcm)) != CRYPT_OK) {
return err;
}
/* Add the IV */
if ((err = gcm_add_iv(gcm, iv, ivlen)) != CRYPT_OK) {
return err;
}
/* Add the AAD (note: aad can be NULL if aadlen == 0) */
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) {
return err;
}
/* Finish up and get the MAC tag */
taglen = sizeof(tag);
if ((err = gcm_done(gcm, tag, &taglen)) != CRYPT_OK) {
return err;
}
/* ... send a header describing the lengths ... */
/* 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);
/* send the ciphertext */
send(socket, pt, ptlen, 0);
/* send the tag */
send(socket, tag, taglen, 0);
return CRYPT_OK;
}
int main(void)
{
gcm_state gcm;
unsigned char key[16], IV[12], pt[PACKET_SIZE];
int err, x;
unsigned long ptlen;
/* somehow fill key/IV with random values */
/* register AES */
register_cipher(&aes_desc);
/* init the GCM state */
if ((err =
gcm_init(&gcm, find_cipher("aes"), key, 16)) != CRYPT_OK) {
whine_and_pout(err);
}
/* handle us some packets */
for (;;) {
ptlen = make_packet_we_want_to_send(pt);
/* use IV as counter (12 byte counter) */
for (x = 11; x >= 0; x--) {
if (++IV[x]) {
break;
}
}
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}
\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
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 message being hashed call:
\begin{verbatim}
int XXX_process( hash_state *md,
const unsigned char *in,
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 (hash output) will be the same. For example,
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:
\index{Message Digest}
\begin{verbatim}
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,
unsigned char *out);
\end{verbatim}
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 \textit{XXX\_done()} functions
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 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)
{
hash_state md;
unsigned char *in = "hello world", out[16];
/* setup the hash */
md5_init(&md);
/* add the message */
md5_process(&md, in, strlen(in));
/* get the hash in out[0..15] */
md5_done(&md, out);
return 0;
}
\end{verbatim}
\end{small}
\mysection{Hash Descriptors}
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 (*done) (hash_state *hash, unsigned char *out);
int (*test) (void);
};
\end{verbatim}
\index{find\_hash()}
The \textit{name} member is the name of the hash function (all lowercase). The \textit{hashsize} member is the size of the digest output
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.
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)
{
unsigned char buffer[100], hash[MAXBLOCKSIZE];
int idx, x;
hash_state md;
/* register hashes .... */
if (register_hash(&md5_desc) == -1) {
printf("Error registering MD5.\n");
return -1;
}
/* register other hashes ... */
/* prompt for name and strip newline */
printf("Enter hash name: \n");
fgets(buffer, sizeof(buffer), stdin);
buffer[strlen(buffer) - 1] = 0;
/* get hash index */
idx = find_hash(buffer);
if (idx == -1) {
printf("Invalid hash name!\n");
return -1;
}
/* hash input until blank line */
hash_descriptor[idx].init(&md);
while (fgets(buffer, sizeof(buffer), stdin) != NULL)
hash_descriptor[idx].process(&md, buffer, strlen(buffer));
hash_descriptor[idx].done(&md, hash);
/* dump to screen */
for (x = 0; x < hash_descriptor[idx].hashsize; x++)
printf("%02x ", hash[x]);
printf("\n");
return 0;
}
\end{verbatim}
\end{small}
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 to make working with hashes easier. The first is a function to hash a buffer, and produce the digest in a single
function call.
\index{hash\_memory()}
\begin{verbatim}
int hash_memory( int hash,
const unsigned char *in,
unsigned long inlen,
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 next helper function allows for the hashing of a file based on a file name.
\index{hash\_file()}
\begin{verbatim}
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>
int main(void)
{
int idx, err;
unsigned long len;
unsigned char out[MAXBLOCKSIZE];
/* register the hash */
if (register_hash(&md5_desc) == -1) {
printf("Error registering MD5.\n");
return -1;
}
/* 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) {
printf("Error hashing data: %s\n", error_to_string(err));
return -1;
}
return 0;
}
\end{verbatim}
\end{small}
\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 \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 MD5 & md5\_desc & 16 \\
\hline MD4 & md4\_desc & 16 \\
\hline MD2 & md2\_desc & 16 \\
\hline
\end{tabular}
\end{center}
\caption{Built--In Software Hashes}
\end{figure}
\vfil
\mysection{Cipher Hash Construction}
\index{Cipher Hash Construction}
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 \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()}
\begin{verbatim}
int chc_register(int cipher);
\end{verbatim}
A cipher has to be registered with CHC (and also in the cipher descriptor tables with
register\_cipher()). The chc\_register() function will bind a cipher to the CHC system. Only one cipher can
be bound to the CHC hash at a time. There are additional requirements for the system to work.
\begin{enumerate}
\item The cipher must have a block size greater than 64--bits.
\item The cipher must allow an input key the size of the block size.
\end{enumerate}
Example of using CHC with the AES block cipher.
\begin{verbatim}
#include <tomcrypt.h>
int main(void)
{
int err;
/* register cipher and hash */
if (register_cipher(&aes_enc_desc) == -1) {
printf("Could not register cipher\n");
return EXIT_FAILURE;
}
if (register_hash(&chc_desc) == -1) {
printf("Could not register hash\n");
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));
}
/* now you can use chc_hash in any LTC function
* [aside from pkcs...] */
}
\end{verbatim}
\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}
\mysection{HMAC Protocol}
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 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
unsigned characters. The initialization routine is:
\index{hmac\_init()}
\begin{verbatim}
int hmac_init( hmac_state *hmac,
int hash,
const unsigned char *key,
unsigned long keylen);
\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,
const unsigned char *in,
unsigned long inlen);
\end{verbatim}
\textit{hmac} is the HMAC state you are working with. \textit{in} is the array of octets to send into the HMAC process. \textit{inlen} 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,
unsigned char *out,
unsigned long *outlen);
\end{verbatim}
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.
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
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 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,
const unsigned char *key, unsigned long keylen,
const unsigned char *in, unsigned long inlen,
unsigned char *out, unsigned long *outlen);
\end{verbatim}
This will produce an HMAC code for the array of octets in \textit{in} of length \textit{inlen}. The index into the hash descriptor
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,
const unsigned char *key, unsigned long keylen,
unsigned char *out, unsigned long *outlen);
\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}
int hmac_test(void);
\end{verbatim}
Which returns {\bf CRYPT\_OK} if the code passes otherwise it returns an error code. Some example code for using the
HMAC system is given below.
\begin{small}
\begin{verbatim}
#include <tomcrypt.h>
int main(void)
{
int idx, err;
hmac_state hmac;
unsigned char key[16], dst[MAXBLOCKSIZE];
unsigned long dstlen;
/* register SHA-1 */
if (register_hash(&sha1_desc) == -1) {
printf("Error registering SHA1\n");
return -1;
}
/* get index of SHA1 in hash descriptor table */
idx = find_hash("sha1");
/* we would make up our symmetric key in "key[]" here */
/* start the HMAC */
if ((err = hmac_init(&hmac, idx, key, 16)) != CRYPT_OK) {
printf("Error setting up hmac: %s\n", error_to_string(err));
return -1;
}
/* process a few octets */
if((err = hmac_process(&hmac, "hello", 5) != CRYPT_OK) {
printf("Error processing hmac: %s\n", error_to_string(err));
return -1;
}
/* get result (presumably to use it somehow...) */
dstlen = sizeof(dst);
if ((err = hmac_done(&hmac, dst, &dstlen)) != CRYPT_OK) {
printf("Error finishing hmac: %s\n", error_to_string(err));
return -1;
}
printf("The hmac is %lu bytes long\n", dstlen);
/* return */
return 0;
}
\end{verbatim}
\end{small}
\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. Note: OMAC has been standardized as
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,
const unsigned char *key,
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. 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,
const unsigned char *in,
unsigned long inlen);
\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);
\end{verbatim}
Would produce the same result as,
\begin{verbatim}
omac_process(&mystate, "hello world", 11);
\end{verbatim}
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,
unsigned char *out,
unsigned long *outlen);
\end{verbatim}
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 \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,
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 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,
const unsigned char *key, unsigned long keylen,
const char *filename,
unsigned char *out, unsigned long *outlen);
\end{verbatim}
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}
int omac_test(void);
\end{verbatim}
Which returns {\bf CRYPT\_OK} if the code passes otherwise it returns an error code. Some example code for using the
OMAC system is given below.
\begin{small}
\begin{verbatim}
#include <tomcrypt.h>
int main(void)
{
int idx, err;
omac_state omac;
unsigned char key[16], dst[MAXBLOCKSIZE];
unsigned long dstlen;
/* register Rijndael */
if (register_cipher(&rijndael_desc) == -1) {
printf("Error registering Rijndael\n");
return -1;
}
/* get index of Rijndael in cipher descriptor table */
idx = find_cipher("rijndael");
/* we would make up our symmetric key in "key[]" here */
/* start the OMAC */
if ((err = omac_init(&omac, idx, key, 16)) != CRYPT_OK) {
printf("Error setting up omac: %s\n", error_to_string(err));
return -1;
}
/* process a few octets */
if((err = omac_process(&omac, "hello", 5) != CRYPT_OK) {
printf("Error processing omac: %s\n", error_to_string(err));
return -1;
}
/* get result (presumably to use it somehow...) */
dstlen = sizeof(dst);
if ((err = omac_done(&omac, dst, &dstlen)) != CRYPT_OK) {
printf("Error finishing omac: %s\n", error_to_string(err));
return -1;
}
printf("The omac is %lu bytes long\n", dstlen);
/* return */
return 0;
}
\end{verbatim}
\end{small}
\mysection{PMAC Support}
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,
const unsigned char *key,
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,
const unsigned char *in,
unsigned long inlen);
\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);
\end{verbatim}
Would produce the same result as,
\begin{verbatim}
pmac_process(&mystate, "hello world", 11);
\end{verbatim}
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,
unsigned char *out,
unsigned long *outlen);
\end{verbatim}
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 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,
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 PMAC 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 pmac\_done().
To PMAC a file use
\index{pmac\_file()}
\begin{verbatim}
int pmac_file(
int cipher,
const unsigned char *key, unsigned long keylen,
const char *filename,
unsigned char *out, unsigned long *outlen);
\end{verbatim}
Which will PMAC 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 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.
\mysection{Pelican MAC}
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);
\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);
\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 \textit{out}.
\subsection{Example}
\begin{verbatim}
#include <tomcrypt.h>
int main(void)
{
pelican_state pelstate;
unsigned char key[32], tag[16];
int err;
/* somehow initialize a key */
/* initialize pelican mac */
if ((err = pelican_init(&pelstate, /* the state */
key, /* user key */
32 /* key length in octets */
)) != CRYPT_OK) {
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));
return EXIT_FAILURE;
}
/* Terminate the MAC */
if ((err = pelican_done(&pelstate,/* the state */
tag /* where to store the tag */
)) != CRYPT_OK) {
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.
\index{LTC\_XCBC\_PURE}
It is possible to use XCBC in a three key mode by OR'ing the value \textbf{LTC\_XCBC\_PURE} against the \textit{keylen} parameter. In this mode, the key is
interpretted as three keys. If the cipher has a block size of $n$ octets, the first key is then $keylen - 2n$ octets and is the encryption key. The next
$2n$ octets are the $K_1$ and $K_2$ padding keys (used on the last block). For example, to use AES--192 \textit{keylen} should be $24 + 2 \cdot 16 = 56$ octets.
The three keys are interpretted as if they were concatenated in the \textit{key} buffer.
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}
\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 \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,
prng_state *prng);
\end{verbatim}
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 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,
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.
\index{PRNG done}
\begin{verbatim}
void XXX_done(prng_state *prng);
\end{verbatim}
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,
prng_state *prng);
\end{verbatim}
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,
prng_state *prng);
\end{verbatim}
This will call the start and add\_entropy functions of the given PRNG. It will use the state in
\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 \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:
\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 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.
To test a PRNG for operational conformity call the following functions.
\index{PRNG test}
\begin{verbatim}
int XXX_test(void);
\end{verbatim}
This will return \textbf{CRYPT\_OK} if PRNG is operating properly.
\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.
\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
the entropy added is not random.
\begin{verbatim}
#include <tomcrypt.h>
int main(void)
{
prng_state prng;
unsigned char buf[10];
int err;
/* 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) {
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, sizeof(buf), &prng));
return 0;
}
\end{verbatim}
\mysection{PRNG Descriptors}
\index{PRNG Descriptor}
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 (*ready) (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}
To find a PRNG in the descriptor table the following function can be used:
\index{find\_prng()}
\begin{verbatim}
int find_prng(const char *name);
\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}
\begin{tabular}{|c|c|l|}
\hline \textbf{Name} & \textbf{Descriptor} & \textbf{Usage} \\
\hline Yarrow & yarrow\_desc & Fast short-term PRNG \\
\hline Fortuna & fortuna\_desc & Fast long-term PRNG (recommended) \\
\hline RC4 & rc4\_desc & Stream Cipher \\
\hline SOBER-128 & sober128\_desc & Stream Cipher (also very fast PRNG) \\
\hline
\end{tabular}
\end{small}
\end{center}
\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.
\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
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
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 RC4 by
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 is XOR'ed against your buffer you provide. In this manner, you can use rc4\_read()
as an encrypt (and decrypt) function.
You really should not use RC4. This is not because RC4 is weak, (though biases are known to exist) but simply due to
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
calling add\_entropy(). There is no need to call ready() for this PRNG as it does not do anything.
Note: this cipher has several oddities about how it operates. The first call to add\_entropy() sets the cipher's key.
Every other time call to the add\_entropy() function sets the cipher's IV variable. The IV mechanism allows you to
encrypt several messages with the same 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
you pass it on the \textbf{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
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
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}
#include <tomcrypt.h>
int main(void)
{
prng_state prng;
unsigned char buf[32];
int err;
if ((err = rc4_start(&prng)) != CRYPT_OK) {
printf("RC4 init error: %s\n", error_to_string(err));
exit(-1);
}
/* 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);
}
/* setup RC4 for use */
if ((err = rc4_ready(&prng)) != CRYPT_OK) {
printf("RC4 ready error: %s\n", error_to_string(err));
exit(-1);
}
/* encrypt buffer */
strcpy(buf,"hello world");
if (rc4_read(buf, 11, &prng) != 11) {
printf("RC4 read error\n");
exit(-1);
}
return 0;
}
\end{verbatim}
\end{small}
To decrypt you have to do the exact same steps.
\mysection{The Secure RNG}
\index{Secure RNG}
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 that try hard not to stray from pre--determined paths. This makes gathering entropy needed to seed a PRNG
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,
void (*callback)(void));
\end{verbatim}
Which will try one of three methods of getting random data. The first is to open the popular \textit{/dev/random} device which
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.}.
The second method is to try the Microsoft Cryptographic Service Provider, and read the RNG. The third method is an ANSI C
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
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,
void (*callback)(void));
\end{verbatim}
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)
{
ecc_key mykey;
prng_state prng;
int err;
/* register yarrow */
if (register_prng(&yarrow_desc) == -1) {
printf("Error registering Yarrow\n");
return -1;
}
/* setup the PRNG */
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) {
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
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
the previous example using this PRNG.
\begin{small}
\begin{verbatim}
#include <tomcrypt.h>
int main(void)
{
ecc_key mykey;
int err;
/* register SPRNG */
if (register_prng(&sprng_desc) == -1) {
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) {
printf("Error making key: %s\n", error_to_string(err));
return -1;
}
return 0;
}
\end{verbatim}
\end{small}
\chapter{RSA Public Key Cryptography}
\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 \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 respectively.
\mysection{PKCS \#1 Padding}
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,
const unsigned char *lparam,
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 \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
\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
\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. \textit{prng\_idx} and \textit{prng} are the random number generator arguments required to randomize the padding process.
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 \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,
const unsigned char *lparam,
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. \textit{msg} is the
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. \textit{modulus\_bitlen} is the size of the RSA modulus in bits
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 \textit{out} of length \textit{outlen} and stores a
$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.
\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,
unsigned long saltlen,
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 \textit{msghash} is of length
\textit{msghashlen}. PSS allows a variable length random salt (it can be zero length) to be introduced in the signature process.
\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 \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,
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 \textit{sig} of length \textit{siglen} and compare it to values in \textit{msghash} of length
\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 \textit{saltlen} and hash for both encoding and decoding as otherwise the procedure will not work.
\mysection{RSA Key Operations}
\subsection{Background}
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 \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 \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
designed for fast exponentiation (requires 16 squarings and one multiplication).
It is important to pad the input to RSA since it has particular mathematical structure. For instance
$M_1^dM_2^d = (M_1M_2)^d$ which can be used to forge a signature. Suppose $M_3 = M_1M_2$ is a message you want
to have a forged signature for. Simply get the signatures for $M_1$ and $M_2$ on their own and multiply the result
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 \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,
long e,
rsa_key *key);
\end{verbatim}
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.
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
least 128 bytes, and no more than 512 bytes in size (\textit{that is from 1024 to 4096 bits}).
\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, and has been replaced by the
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.
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:
\index{rsa\_exptmod()}
\begin{verbatim}
int rsa_exptmod(const unsigned char *in,
unsigned long inlen,
unsigned char *out,
unsigned long *outlen,
int which,
rsa_key *key);
\end{verbatim}
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}
(i.e. for encryption/verifying) and set to {\bf PK\_PRIVATE} to use \textit{d} as the exponent (i.e. for decrypting/signing).
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.
\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,
unsigned char *out,
unsigned long *outlen,
const unsigned char *lparam,
unsigned long lparamlen,
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,
unsigned char *out,
unsigned long *outlen,
const unsigned char *lparam,
unsigned long lparamlen,
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 is not a valid OAEP packet then \textit{stat} is set to $0$. Otherwise, it is set to $1$.
\subsection{Extended Decryption}
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,
unsigned char *out,
unsigned long *outlen,
prng_state *prng,
int prng_idx,
int hash_idx,
unsigned long saltlen,
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,
const unsigned char *msghash,
unsigned long msghashlen,
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 PSS 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 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;
unsigned long l1, l2;
unsigned char pt[16], pt2[16], out[1024];
rsa_key key;
/* 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;
}
hash_idx = find_hash("sha1");
prng_idx = find_prng("sprng");
/* make an RSA-1024 key */
if ((err = rsa_make_key(NULL, /* PRNG state */
prng_idx, /* PRNG idx */
1024/8, /* 1024-bit key */
65537, /* we like e=65537 */
&key) /* where to store the key */
) != CRYPT_OK) {
printf("rsa_make_key %s", error_to_string(err));
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 */
16, /* data is 16 bytes long */
out, /* where to store ciphertext */
&l1, /* length of ciphertext */
"TestApp", /* our lparam for this program */
7, /* lparam is 7 bytes long */
NULL, /* PRNG state */
prng_idx, /* prng idx */
hash_idx, /* hash idx */
&key) /* our RSA key */
) != CRYPT_OK) {
printf("rsa_encrypt_key %s", error_to_string(err));
return EXIT_FAILURE;
}
/* now let's decrypt the encrypted key */
l2 = sizeof(pt2);
if ((err = rsa_decrypt_key(out, /* encrypted data */
l1, /* length of ciphertext */
pt2, /* where to put plaintext */
&l2, /* plaintext length */
"TestApp", /* lparam for this program */
7, /* lparam is 7 bytes long */
hash_idx, /* hash idx */
&res, /* validity of data */
&key) /* our RSA key */
) != CRYPT_OK) {
printf("rsa_decrypt_key %s", error_to_string(err));
return EXIT_FAILURE;
}
/* if all went well pt == pt2, l2 == 16, res == 1 */
}
\end{verbatim}
\end{small}
\mysection{RSA Key Format}
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.
\subsection{RSA Key Export}
To export a RSA key use the following function.
\index{rsa\_export()}
\begin{verbatim}
int rsa_export(unsigned char *out,
unsigned long *outlen,
int type,
rsa_key *key);
\end{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
set to \textbf{PK\_PRIVATE} the export format will be RSAPrivateKey and otherwise it will be RSAPublicKey.
\subsection{RSA Key Import}
To import a RSA key use the following function.
\index{rsa\_import()}
\begin{verbatim}
int rsa_import(const unsigned char *in,
unsigned long inlen,
rsa_key *key);
\end{verbatim}
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.
As of v1.06 this function can also import OpenSSL DER formatted public RSA keys. They are essentially encapsulated RSAPublicKeys. LibTomCrypt will
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
there is no function provided to export in this format.
\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}
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()''.
\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
available:
\index{dh\_test()}
\begin{verbatim}
int dh_test(void);
\end{verbatim}
This function returns {\bf CRYPT\_OK} if the bases and primes in the library are correct. There is one last helper
function:
\index{dh\_sizes()}
\begin{verbatim}
void dh_sizes(int *low, int *high);
\end{verbatim}
Which stores the smallest and largest key sizes support into the two variables.
\section{DH Packet}
Similar to the RSA related functions there are functions to encrypt or decrypt symmetric keys using the DH public key
algorithms.
\index{dh\_encrypt\_key()} \index{dh\_decrypt\_key()}
\begin{verbatim}
int dh_encrypt_key(const unsigned char *in, unsigned long inlen,
unsigned char *out, unsigned long *len,
prng_state *prng, int wprng, int hash,
dh_key *key);
int dh_decrypt_key(const unsigned char *in, unsigned long inlen,
unsigned char *out, unsigned long *outlen,
dh_key *key);
\end{verbatim}
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}
\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^{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.
\mysection{Fixed Point Optimizations}
\index{Fixed Point ECC}
\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(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
}
ECCPrivateKey ::= SEQUENCE {
flags BIT STRING(1), -- public/private flag (always one),
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
secret.k INTEGER, -- The secret key scalar
}
\end{verbatim}
\end{small}
The first flags bit denotes whether the key is public (zero) or private (one).
\vfil
\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;