\section{Evaluation}
\label{SEC:evaluation}

To evaluate \PPH, we evaluated the feasibility of its use
in different scenarios.  This includes issues ranging from the efficiency
of the algorithm, to the expected security benefits from different
configurations and deployment scenarios.  We frame our evaluation around
the following questions:

\begin{itemize}
    \item How long does \PPH take for different operations?
    \item What is the storage cost of \PPH?
    \item How much memory is needed for \PPH?
    \item What are the security properties of \PPH?
        \begin{itemize}
            \item What happens if users pick weak passwords?
            \item What \partialbytes settings should be used?
            \item How does the threshold affect the cracking time?
            \item What if a poor value is chosen for the threshold?
%            \item What is the feasibility of an attacker cracking a \PPH
%                protected store, with strong \thresholdaccount passwords
        \end{itemize}
\end{itemize}

%We will evaluate the time, memory and storage aspects of the algorithm and our
%python reference implementation. After this, we will analyze what are the
%optimal configuration values for \PPH by studying the behavior of the algorithm
%when we vary any of its parameters. Finally, we will summarize our findings and provide a
%case study to compare \PPH with regular salted hashes.

\subsection{What is the time cost of \PPH?}
\label{SUBSEC:time-costs}

To evaluate time costs, we examined how long it took PolyPasswordHasher to
process account verifications, new accounts, password changes, initializations
of a password store, and transitioning from bootstrapping to normal operation.
We measured the processing speed and performance of \PPH using an early-2011
MacBook Pro with 4GB of RAM and a 2.3 GHz Intel Core i5 processor.  All
operations reflect the mean verification time across 100 runs and were
performed with the password file already present in memory. For benchmarking
purposes, each action was performed sequentially despite being embarrassingly
parallelizable.

Figure~\ref{FIGURE:running-times} shows the time taken by different
operations (discussed below). Unless noted, the time cost of an operation did
not depend on other factors, such as the number of accounts in the password
database.

\paragraph{Time to verify an account} The mean time to verify a
\thresholdaccount was around 60$\mu$s independent of the threshold value.
For example, a threshold of eight allowed a server to verify more than 16K user
accounts per second.  Verifying a \thresholdlessaccount took approximately 29$\mu$s
and the server processed about 35K such actions per second. Bootstrap accounts,
which use salted hashing, took just over 3$\mu$s on the same platform.

The values presented do not include key stretching.  (Except for
the case of \partialverification, key stretching is unlikely to be used
for individual account verification with \PPH.)
%At a minimum, we need to say we assume 1 billion hashes a second, if we
%assume that~\cite{ElcomSoftGPUCracking,zonenberg2009distributed}...

\begin{figure}
    \centering
    \includegraphics[width=.5\linewidth, trim=205 65 280 105]{./images/pph-running-times.pdf}
    \caption{Time needed per operations in \PPH.
    \Partialbytes verification and transition to
normal operation times are listed without key stretching.   }
    \label{FIGURE:running-times}
\end{figure}

\paragraph{Time to create accounts or process password changes}
Account creation time was similar to the time needed to verify accounts.
Depending on the threshold value, the average creation time varied from
77$\mu$s to 85$\mu$s. A \PPH store with a threshold value of eight created more
than 12K accounts per second. Given that there are a maximum of 255
\thresholdaccounts that can be created (at least with a \PPH implementation
that uses GF256), \thresholdaccount  creation time is not a performance
concern.  \Thresholdlessaccounts were created independent of the threshold, in
about 25$\mu$s. Based on this, we calculated that approximately 40K
thresholdless accounts can be created each second. This is similar to the time
it takes to generate a salted SHA256 hash for a password (16$\mu$s).  Changing
a password only requires \PPH to perform the same operation it uses to
create an account (and potentially also authenticate the old password).

\paragraph{Time needed to initialize a password database} The time to create a
database varied and was dependent on the threshold value used.  However,
varying the threshold from 2 to 16, varied the creation time from 380$\mu$s to
460$\mu$s. This time cost is largely due to the need to generate
cryptographically-suitable random numbers; but this operation is only
performed once, when a new password file is created.

\paragraph{Time needed to transition to normal operation} When the
server restarts, random coefficients are computed from the set of provided
shares, with full interpolation. The time needed to complete this operation
varied between 202$\mu$s and 1.6ms, because the threshold changes in relation to
changes in the number of polynomials, as the store size increases.  Note that
small thresholds were processed quickly --- a store with a threshold of 8 was
unlocked in 617$\mu$s.  There is also the time needed to do the integrity
check on the recovered secret.

Computing the random coefficients and computing the integrity
of the recovered secret (via a cryptographic hash) needs to be done once per
restart for a normal server.  However, an attacker attempting to crack the
database will recompute the random coefficients and compute the hash once
per guess of \thresholdaccount values.  We therefore recommend that the
integrity check use enough iterations of the hash function to increase the
computational time needed to at least 100ms.   This slows the attacker
down per guess (a frequent operation), while only delaying the server slightly
one time per reboot.

{\bf Recommendation 1: The integrity check on the secret that is performed
when transitioning to normal operation should take at
least 100ms to complete.}

\subsection{What is the Storage Cost of \PPH?}

\begin{table}[t]
    \centering
    \renewcommand{\arraystretch}{1.3}

    \begin{tabular}{| c | c | c | c | c | c |}
    \hline
    {\bf Password } & {\bf Original} & {\bf Salted Hashes} & {\bf PPH }& {\bf PPH } & {\bf PPH }\\
    {\bf source} & {\bf space} & {\bf space} & {\bf No IV} & {\bf (16 ICB)} & {\bf (24 ICB)}\\
    \hline
    RockYou & 134MB & 260MB & 265MB & 275MB & 280MB\\
    \hline
    eHarmony* & 51.6MB & 100MB & 102MB & 106MB & 108MB\\
    \hline
    Formspring* & 27.3MB & 34.8MB & 35.2MB & 36.0 MB & 36.4MB\\
    \hline
    Gawker & 75.2MB & 119MB & 120MB & 122MB & 123MB \\
    \hline
    LinkedIn* & 252MB & 424MB & 430MB & 442MB & 448MB\\
    \hline
    Sony & 2.98MB & 4.95MB & 5.00MB & 5.10MB & 5.15MB\\
    \hline
    Yahoo & 17.8MB & 35.0MB & 35.4MB & 36.2MB & 36.6MB\\
    \hline
    \end{tabular}
    \caption{Disk space needed to store leaked password databases in
    different formats. * Denotes breaches in which only the salted hash portion
    of the database was released}
    \label{TABLE:disk-space}
\end{table}

%   ['eHarmony', 51.6, 100.0, 102.0, 104.0, 106.0, 110.0]
%   ['Formspring', 27.3, 34.8, 35.2, 35.60000000000001, 36.000000000000014, 36.80000000000002]
%   ['Gawker', 75.2, 119.0, 120.0, 121.0, 122.0, 124.0]
%   ['LinkedIn', 252.0, 424.0, 430.0, 436.0, 442.0, 454.0]
%   ['Sony', 2.98, 4.95, 5.0, 5.05, 5.1, 5.1899999999999995]
%   ['Yahoo', 17.8, 35.0, 35.4, 35.8, 36.199999999999996, 36.999999999999994]

Storing passwords with \PPH requires that additional information
-- a one byte share number -- be stored for each account.  This adds one byte
of storage space for each account, beyond the cost of current hash techniques.
The one byte has minimal impact on the disk space needed to store production
password databases (Table~\ref{TABLE:disk-space}).
% If \thresholdlessaccounts are stored in a
%separate file or are somehow distinguished stored independently, then only
%\thresholdaccounts require the extra byte of storage. This results in a cost
%for those accounts that is identical to the salted, hashed scheme.

If the \partialbytes
field is used, the amount of information increases by the size of the field.
For example, with a value of $24$ \partialbytes, the total cost increases by
four bytes (one for the share number and three for the \partialbytes field).

\subsection{How much memory is needed for \PPH?}

\PPH uses more memory than does a salted hash solution in normal operation.
The server must store the polynomial coefficients for the
Shamir Secret Share (which includes the secret).  However, the total size
of this data is relatively small --- the threshold value (2-5) multiplied by
the length of the \sxh field (32 bytes).  As this value is likely to be
a few hundred bytes in practical deployments, (which is smaller than the \PPH
code will be in memory), this should not pose a problem in practice.

During bootstrapping, additional memory is also used.  While shares are being
acquired, they are kept in memory.  This has a similar cost to storing
the polynomial coefficients for the Shamir Secret Share.
However, if \partialverification is used, the more
substantial cost is storing authentication information so that it can be
verified against the complete entry to ensure that the previous login was
correct. The memory cost of caching this information will correspond to the
number of logins before bootstrapping is finished (i.e., \sxh * Log-ins).
The total memory cost is still rather small, even for a server that processes
many authentications.  For example, a server that processes ten thousand logins
while bootstrapping needs only 320KB of memory to store that information.  Thus
the memory costs remain small, even for heavily used systems.

\subsection{What happens if users choose extremely weak passwords?}
\label{SUBSEC:bad-passwords}

If extremely weak passwords are
used for a threshold of \thresholdaccounts (like administrators), \PPH will not
provide strong protection.   If there are only a few bits of entropy in the
password, the search space will still be small, but exponentially larger.
For example, if the attacker knows that three \thresholdaccounts each chose one
of 10 weak passwords, the attacker could sweep the search space in 1000
guesses (100 seconds, given a 100ms time to verify the secret).  While this
is much better than the 30 guesses an attacker would need with salted hashing,
this protection is obviously still very weak.  It
is thus critical that \thresholdaccounts are secured with strong passwords.
\PPH performs very poorly when weak passwords are used for \thresholdaccounts.  Even
with extremely weak passwords, \thresholdlessaccounts will have some
protection, so long as the \thresholdaccounts use strong passwords.

However, independent of any storage technology, extremely weak passwords
are susceptible to guessing by an external party without having to steal
the password database.  Therefore, this is not an area that password database
storage technologies can address.

Fortunately, research has shown that users can be helped to choose passwords
that have a significant degree of randomness.  This can be done by requiring a combination of
passwords that are a certain length (8 characters), combinations
of character types (letters, numbers, symbols), and by blacklisting common
passwords~\cite{weir2010passwordpolicies}.  Extremely weak passwords are
susceptible to guessing by an external party (without database access); as
best practice, sites should block them from use~\cite{bancommonpasswords,
weir2010passwordpolicies, cormac2014telepathwords,
kelley2012guessingpasswords}.  The combination of length, diverse character
types, and blacklisting common passwords has been shown to substantially
increase the time needed to crack passwords.

%We applied these techniques to passwords from the RockYou password dump
%and then evaluated the entropy of the resulting password entries.  We
%found ...\cappos{Continue in this vein with results...}
%Thus we expect the \thresholdaccounts can
%pick passwords with ?? bits of entropy; equivalent entropy to
%a ????-character-long, random password.

{\bf Recommendation 2: \Thresholdaccounts should have
as much entropy as a 6-character-long random password.}

%However, \PPH provides the ability to protect \thresholdlessaccounts even if they do not
%pick good passwords, for they are protected by the \thresholdaccounts. When an
%attacker attempts offline cracking on a \PPH-enabled database, his only
%alternative is to crack different \thresholdaccounts simultaneously first, and then
%crack the whole database as he would do against regular salted hashing.

\subsection{{\bf What \partialbytes setting should be used?}}
\label{SUBSEC:security-properties}

%\cappos{Throughout the paper, we need to be sure we don't say
%\partialbytes = 0, when we mean disabling \partialverification.
%We never mean \partialbytes = 0.  We should always say disabling instead.}

\Partialverification changes the properties of \PPH, depending on the
size of the \partialbytes field.
\begin{itemize}

\item When \partialverification is disabled, a user may not log in until a
threshold of \thresholdaccount passwords have been provided.  This makes \PPH
unavailable during the bootstrap phase.

\item When the size of the \partialbytes field is very small,
it is possible that authentication errors will be made during bootstrapping.
For example, if the size of the \partialbytes field is set to 1 bit (an
implausible and extreme example), then an attacker typing a random password
has a 50\% chance of the \partialbytes matching and being allowed in.

\item  As the size of the \partialbytes field grows, the probability that an
attacker will succeed with online cracking decreases. However, when the size of the
\partialbytes field is very large, if an attacker steals the database, the
confidentiality benefits of \PPH are weakened.  For example, in the extreme
case that the \partialbytes field is the size of the entire salted password
hash (an implausible example), then an attacker can use the slow,
\partialverification hash to individually crack passwords.  In this case, from
a security standpoint, \PPH is effectively equivalent to key stretching.  The
primary benefit of \PPH in this case is that it does authenticate accounts much
more quickly in normal operation than does key stretching.

\end{itemize}

Given that the size of the \partialbytes field and the threshold is
configurable, the security properties of \PPH vary. When integrating \PPH into
a system, an administrator can leverage this adaptability to better meet his
expectations.  In the next subsection we explain how different configurations
of \PPH apply to different use cases.

\begin{figure}
    \centering
    \includegraphics[width=.5\linewidth, trim=195 55 165 55]{./images/plotcrack_icb}
    \caption{{\small Time it takes to crack a \PPH store with different values
    for \partialbytes and a threshold of 3.  The line for \partialbytes=8
does not fit within the axes of the graph. }}
    \label{FIGURE:cracking-icb}
\end{figure}

\subsubsection{Immediate Availability For Many Unknown Clients}
In some situations, after
reboot a server needs to be immediately available to a potentially huge
number of untrusted clients.  For example, a
web forum or a social media site is likely to have this property.
Availability is paramount, for a large, diverse, and constantly changing
user base.

If an attacker has his attack detected and his IP address blocked, this
may not be a major concern or deterrent. Therefore, attackers may try to do things such as
brute force passwords, even if this is likely to lead to detection.

There is also a risk of users trying incorrect passwords during the bootstrap
phase to try to break into an account.  Most existing web frameworks deal with
this by restricting the number of password attempts from an IP address over a
period of time (10 authentications per second is common).  However, a motivated
attacker with the ability to connect from many IP addresses (e.g., a botnet
operator), could still be able try a substantial number of passwords.
However, using a \partialbytes value of 24 bits will cause the attacker's
password search space to be as large as the usual number of attempts for
successful online cracking scenarios.

% \cappos{probably discuss somewhere here how bootstrapping is only used
% for a short time..}

The downside is that a large \partialbytes field will make it easier for an
attacker to crack the \thresholdaccounts.  As shown in
Figure~\ref{FIGURE:cracking-threshold}, as the size of the \partialbytes field
grows, the cracking time for a threshold of three starts to resemble the time
for salted hashes. For 24 \partialbytes, the time to crack a six-character
equivalent random password is around $270420$ years. In summary, the
\partialbytes setting reduces the password entropy.  To provide adequate
protection, either passwords with the entropy of 8 character random passwords
should be used, or, as will be discussed later, the threshold should be
increased.

{\bf Recommendation 3: In situations where a large number of unknown clients
will authenticate, use a setting of 24 \partialbytes.}

\subsubsection{Immediate Availability For Known Clients}
In many cases, the set of expected clients is limited and known.
This includes situations like a institutional file server or mail server.
In this case, the total set of possible clients is limited and it is
assumed that an attacker cannot control a large number of IP addresses /
clients.

\begin{table}[t]
    \centering
    \renewcommand{\arraystretch}{1.3}

    \begin{tabular}{| c | c | c | c |}
    \hline
    {\bf guessing} & \multicolumn{3}{ c|}{{\bf Attempts}} \\
    {\bf probability} & {\bf ICB=8} & {\bf ICB=16} & {\bf ICB=24} \\
    \hline
    25\% & 76 (25.4\%) & 18,767 (24.9\%) & 4,804,150 (24.9\%) \\
    \hline
    50\% & 177 (49.9\%) & 45,295 (49.9\%) & 11,595,559 (49.9\%) \\
    \hline
    75\% & 354 (74.9\%) & 90,590 (74.9\%) & 23,191,185 (74.9\%) \\
    \hline
    \end{tabular}
    \caption{Number of attempts required to find a \partialbytes collision}
    \label{TABLE:collisions}
\end{table}

%   []    [8.0, 16.0, 24.0, 32.0]
%   ['25.0%', '100(0.32388353489%)', '18767(0.249010703106%)', '4804150(0.249000026671%)', '99999999(0.0230141050386%)']
%   ['50.0%', '177(0.499806462193%)', '45295(0.499001475831%)', '11595559(0.499000008952%)', '99999999(0.0230141050386%)']
%   ['75.0%', '354(0.749806424736%)', '90590(0.74900047878%)', '23191185(0.749000011343%)', '99999999(0.0230141050386%)']

In this case, an attacker who brute forces accounts is much less of a concern
because he cannot obtain the IP addresses needed and failed attempts should
be flagged and investigated by the security team regardless.  Thus, setting
\partialbytes to be 16 requires that an attacker attempt to crack $45295$ passwords to
have a probability of finding a collision of about 50\%, as shown in
Table~\ref{TABLE:collisions}. This configuration is ideal for cases in which a
lock-out policy can be enforced. However, even if an attacker was able to find
a collision during bootstrapping, \PPH would be able to detect it upon
recombination. If an attacker were to find a collision when \PPH is performing
on normal operation, then the break-in attempt would also notify the
administrators.

The bigger concern is an attacker (possibly an insider) stealing the database
and brute forcing account passwords.   By using a small number of
\partialbytes, such as 16, the resilience to cracking is very high.  Even
if there are three \thresholdaccounts with the entropy of a 6 character
password, it would require $447.8 * 10 ^ 6$ thousand years of CPU effort to crack these
accounts.

{\bf Recommendation 4: In situations where a restricted set of clients will
try to authenticate, use a setting of 16 \partialbytes.}

\subsubsection{When Short Periods of Unavailability are Acceptable}

In some situations, temporary unavailability of a server (while bootstrapping)
is not a major concern.  For example, many services load balance
requests across multiple systems for redundancy and performance.
Administrators will stop and start instances as needed.  When starting
an instance, the first thing the administrators will typically do is log into
the system to validate that it is working, before moving it into production.
For such a system, the time spent in the bootstrapping phase is small
and there is no user-perceived unavailability while the system is
bootstrapping.

In this case, \partialverification can be completely disabled, maximizing
the security benefit of \PPH.  The CPU time it would take an attacker to crack
the database is infeasibly high for practical situations.
Even with a threshold of 3 and 5 character random accounts, the cracking time
when \partialverification is disabled ($1.46*10^{21}$ CPU years) extends past the
top of the y-axis
in Figure~\ref{FIGURE:cracking-icb}.  (This is more CPU time than would be
provided by every computer working nonstop for the estimated
age of the universe.)   Thus, given our understanding of the security of
SHA256 and AES, it is infeasible for any adversary to use the password
database to crack passwords with the entropy of 5 character random
passwords that are stored in this manner.

%\cappos{Low priority: Add a table or similar...}
\begin{table}[t]
    \centering
    \begin{tabular}{ | c | c | c | c | c |}
        \hline
        {\bf Equivalent} & \multirow{2}{*}{{\bf ICB}} & \multirow{2}{*}{{\bf Threshold}} &
        \multirow{2}{*}{{\bf Keyspace}} & \multirow{2}{*}{{\bf Recombinations}} \\
        {\bf Entropy} & & & & \\
        \hline
        \multirow{6}{*}{\parbox[h]{1.8cm}{\centering 32.45 \\(5 character-long,\\ random password)}}
        & \multirow{2}{*}{Disabled} & 3 & $4.632*10^{29}$ & $5.559*10^{31}$ \\
                                \cline{3-5}
                                &    & 4 & $3.584*10^{39}$ & $7.528*10^{41}$ \\
                                \cline{2-5}
                               & \multirow{2}{*}{16} & 3 & $1.645*10^{13}$ & $1.975*10^{17}$ \\
                                \cline{3-5}
                               &    & 4 & $1.943*10^{18}$ & $4.080*10^{22}$\\
                                \cline{2-5}
                               & \multirow{2}{*}{24} & 3 & $2.331*10^{10}$ & $1.175*10^{10}$\\
                                \cline{3-5}
                               &    & 4 & $7.619*10^{10}$ & $9.484*10^{12}$\\
        \hline
        \multirow{6}{*}{\parbox[h]{1.8cm}{\centering 38.85\\(6 charater-long,\\ random password)}}
        & \multirow{2}{*}{Disabled} & 3 & $4.972*10^{35}$& $6.554*10^{37}$ \\
                                \cline{3-5}
                                &    & 4 & $2.919*10^{47}$ & $9.635*10^{49}$ \\
                                \cline{2-5}
                                & \multirow{2}{*}{16} & 3 & $1.411*10^{21}$ & $1.693*10^{23}$ \\
                                \cline{3-5}
                                &    & 4 & $1.582*10^{28}$ & $3.24*10^{30}$ \\
                                \cline{2-5}
                                & \multirow{2}{*}{24} & 3 & $8.631*10^{13}$ & $1.009*10^{16}$ \\
                                \cline{3-5}
                                &    & 4 & $3.684*10^{18}$ & $7.738*10^{20}$ \\
                                \cline{2-5}

        \hline
        \multirow{6}{*}{\parbox[h]{1.8cm}{\centering 45.21\\(7 character-long,\\ random password)}}
        & \multirow{2}{*}{Disabled} & 3 & $3.405*10^{41}$ & $5.619*10^{43}$ \\
                                \cline{3-5}
                                &    & 4 & $2.378*10^{55}$ & $7.848*10^{57}$ \\
                                \cline{2-5}
                                & \multirow{2}{*}{16} & 3 & $1.209*10^{27}$ & $1.558*10^{28}$ \\
                                \cline{3-5}
                                &    & 4 & $1.289*10^{36}$ & $2.976*10^{50}$ \\
                                \cline{2-5}
                                & \multirow{2}{*}{24} & 3 & $7.211*10^{19}$ & $8.654*10^{21}$\\
                                \cline{3-5}
                               &    & 4 & $3.685*10^{26}$ & $6.303*10^{28}$ \\
                                \cline{2-5}

        \hline

    \end{tabular}
    \caption{{\small Equivalent keyspaces and number of recombinations for
    different \PPH configurations. Assuming 10 \thresholdaccounts}}
    \label{TABLE:pph-configurations}
\end{table}

%It is important to consider that disabling \partialverification affects the
%availability of the system, since it cannot provide account verification
%until the server has finished bootstrapping.

{\bf Recommendation 5: In situations where availability immediately
after a reboot is not essential, \partialverification should be disabled.}

\subsection{How does the threshold affect the cracking time?}
\label{SUBSEC:threshold-value}

The threshold value is directly related to the cracking time by
increasing the number of secret recombinations that an attacker needs
to attempt before he can recover the secret. Also, on the usability side,
it is also related to the time it takes for a system to transition
from the bootstrap phase to normal operation.

We can see in Figure~\ref{FIGURE:cracking-threshold} that, when we fix the
\partialbytes number to 24, the threshold value exponentially increases the cracking time.
(We choose a high number of \partialbytes because the
security is lower and thus, differences are easier to see on the graph.)
If the \thresholdaccounts pick strong enough passwords, and the
threshold is three, the cracking time increases by many orders of magnitude.
The regular salted hashes are expected to be cracked in about 40 minutes,
whereas, if using \PPH, these hashes would be cracked in $27,042$ years.

The reason why \PPH provides strong protection is that
even when an attacker has to guess only a few passwords, in most cases \PPH's
exponential increase in guessing time ($O(Vp)$ instead of $O(pV)$, will make
guessing a password computationally infeasible
(Figure~\ref{FIGURE:cracking-threshold}).
Furthermore, it is possible to much more aggressively apply a technique like
key stretching for the integrity check of the reconstructed secret.  This is
because this operation is only done once (by the server), but is done for
each guessed combination of passwords (by the attacker).  This increases
the attacker's time cost while extending the time the server spends, by a second or less, in
bootstrapping .

%For example, suppose an attacker wants to
%guess three passwords that he knows are each comprised of six randomly chosen
%characters. Recent studies have shown that a GPU can compute on the order of a
%billion password hashes per second
%~\cite{ElcomSoftGPUCracking,zonenberg2009distributed}, thus allowing an
%attacker to search the key space for all three passwords in under an hour,
%which indicates that the current state of the art provides little protection
%against password guessing.
%
%Even a threshold of two provides substantially stronger protection than do
%existing best practices. Searching the key space would require over 17 million
%CPU years of effort.

{\bf Recommendation 6: Choose a threshold of 3 plus the number of
\thresholdaccount passwords an attacker could reasonably know, for strong
protection.}

\begin{figure}
    \centering
    \includegraphics[width=.5\linewidth, trim=195 55 165 55]{./images/plotcrack_threshold}
    \caption{{\small Time it takes to crack a \PPH store with different values of
    threshold and 24 \partialbytes}}
    \label{FIGURE:cracking-threshold}
\end{figure}

\subsection{What if a poor value is chosen for the threshold?}

Choosing a poor threshold setting can minimize the protections of \PPH.
If the threshold is too high, the system will primarily be in the
bootstrapping phase while waiting for \thresholdaccounts to log in.
Thus most of the accounts will be bootstrap accounts and only be protected
by salted hashes.  If an attacker steals this database, they can individually
crack these passwords.

An organization might find that there are not enough \thresholdaccount logins to get
the system into normal operation.   One way to mitigate this is to promote
some \thresholdlessaccounts that log in frequently to be \thresholdaccounts.
This would allow an attacker who controls one or more of those accounts to
have an easier time cracking the \thresholdaccounts, but causes bootstrapping
accounts to be protected.

{\bf Recommendation 7: It is often better to have \thresholdaccounts that
frequently log in (but who are untrusted), than those of trusted users
who rarely log in.}

If the threshold setting is too low, then an attacker can feasibly crack
the \thresholdaccounts and gain the ability to individually crack accounts.
This is particularly problematic when combined with a large \partialbytes
settion.  The minimum threshold setting described in the previous
settings should be used wherever possible. This relationship can be verified
by consulting Table~\ref{TABLE:pph-configurations}

%\cappos{I'm of the opinion we should cut the Sony Breach.  Given time, we
%could do an analysis of the RockYou database with the passwords that pass our
%filters.   (Entropy eval then look at this.)
%
%I don't think this helps our case and the argument about why we don't toss
%things is muddied by our other arguments...
%}

\eat{
\subsection{Case study: the Sony Breach}
\label{SUBSEC:sony-database}

To explore how these results carry over to real passwords, we performed an
experiment using the password data dumped from the Sony account
breaches~\cite{sonyhack}.  Of the leaked password databases known to the
authors (Table~\ref{TABLE:disk-space}), this is the only data set which
explicitly lists which accounts are administrator accounts versus normal users.

\santiago{this should be revised, what if we throw away the weak passwords}
In the database dump, there is password data for both outside user accounts as
well as accounts have administrator access. The four administrator accounts
have passwords with the estimated entropy in bits~\cite{passwordstrength}:
password@1 (5.322 bits), welkom@1 (26.553 bits), waderobsen (30.618 bits), and
itsafullcyrcle (44.011 bits). Given a rate of a billion password hashes checked
per second, the first three passwords can all be cracked in two seconds. The
remaining password (and thus every administrator password) could be cracked in
under 5 hours.

If \PPH were protecting these passwords, the ability to crack the
passwords would depend on the threshold. The effective password strength is
that of the weakest passwords combined, times the probability of selecting
those accounts in that order. A threshold of 3 will have an effective entropy
of 67.078 bits, which will take nearly 5000 years to crack, based on 1 billion
guesses per second.

With a threshold of 2, the effective entropy is 35.459 bits, which can be
cracked in under a minute. However, if all administrators chose a password as
strong as the password waderobsen (which is considered a weak password by
current standards~\cite{passwordstrength}), then the password would have had an
effective entropy of 64.820 bits, and take more than a thousand CPU years to
crack at 1 billion guesses per second. This underscores the fact that
administrators still should not choose immensely poor passwords (e.g.,
‘password@1’).  Independent of password storage concerns, avoiding trivially
guessable passwords is essential in preventing remote brute-force password
cracking.

\Thresholdlessaccount passwords (many of which tend to be extremely weak) cannot
be cracked until a threshold of administrator passwords are compromised. This
means that even it is only administrators who can be convinced to use strong
passwords, \PPH still provides substantial security benefits.

\eat{
\santiago{This is part of the old eval, we can take information from here}
\Partialverification allows an attacker to first reduce the search space for a
specific account by eliminating accounts that do not match the leaked bits. If
the attacker knows the password pattern, he can first precompute all passwords
that match that pattern and hash. This requires the same amount of effort
(k*2n) as for cracking passwords that are stored using traditional best
practices. If the attacker has sufficient space to store these passwords, he or
she may then use combinations of these precomputed passwords to try to unlock
the database. The attacker will be able to search the space for the Shamir
Secret Store in 2k*n-l guesses.  Each byte used for \partialverification
effectively reduces the strength of a random password by approximately 1.22
characters. However, the time needed to unlock the Shamir Secret Share still
represents an exponential increase and dominates the overall cost.

With one billion operations per second, sweeping the search space would still
require 45 thousand CPU years (8 orders of magnitude more time than salting and
hashing).  For example, if 2 bytes are leaked for 6 random character passwords
(Figure~\ref{FIGURE:cracking-times}), the attacker will need to do 735 trillion
operations for each of the three passwords and then 1.41×1021 operations to
crack the password database.
}
\subsection{Summary}
\label{SUBSEC:summary}
}


\documentclass[12pt,twoside]{article}

\usepackage{algorithmic}

\begin{document}
\part{Framework for A Fully Automatic Binding Time Analysis}

\section{Offline Partial Evaluation}
Most offline approaches perform what is called a {\em binding-time analysis
  ({\em BTA})} prior to the specialization phase.
The partial evaluator uses the generated annotated program to guide the specialization process.  There are two types of annotations:
\begin{itemize}
  \item {\bf filter declarations},
  indicating whether arguments to predicates are {\bf static},  {\bf dynamic},
or possibly some other binding type.  These annotations
influence the generalization of goals and thus the global control.
  \item {\bf clause annotations},
   indicating how every call in the body should be treated during unfolding.
   These influence the local control.
 \end{itemize}

In this paper we outline a procedure for generating these annotations
automatically.  There are several independent components of the procedure.
Hence, if one of these components is missing it could be replaced by
a manual procedure or oracle, making the whole process semi-automatic.

The input to the procedure is (i) a program to be specialized, (ii) a set of types, and (iii)
a goal whose arguments are typed with respect to the given types.
Note that the program need not be a typed program in the usual sense.
The types simply define sets of terms which form the basis for the binding
type annotations.

The components of the automatic BTA are (i) a type determinization algorithm, (ii)
an abstract interpreter over a domain of determinized (disjoint) types, and (iii)
a termination analyser, incorporating for example an abstract interpreter over
a domain of convex hulls.

\subsection{Binding Types}
The basis of the BTA is a classification of arguments
using abstract values.  Abstract values can be chosen in different ways.
The BTA procedure described here is independent of the particular
choice of abstraction; the only essential aspect of the abstraction is that
it must be possible to determine whether an argument is possibly unbound (that
is, it is could be a variable).  In this case, the argument is called {\em dynamic}.

The simplest approach is to classify arguments within the program
 to be specialized as either {\em static} or {\em dynamic}.
%  (see Figure~\ref{figure:fe-pe}).
The value of a static
 argument will be {\em definitely ground}.  A dynamic argument
can be either ground or not ground, that is, it can be any term.
The use of static-dynamic binding types was introduced
for r functional programs,
and has been used in logic program BTAs  \cite{MogensenBondorf:LOPSTR92}.
While often sufficient for functional programs,
it sometimes
proves to be too weak for logic programs: in logic programming
partially instantiated data structures appear naturally even at
runtime. A simple classification of arguments into ``fully
known'' or ``totally unknown'' is therefore unsatisfactory and
would prevent specialising a lot of ``natural'' logic programs such
as the vanilla metainterpreter
\cite{HillGallagher:metachapter,MartensDeSchreye:metachapter}
 or most of the benchmarks from the {\sc dppd} library
 \cite{Leuschel96:ecce-dppd}.

Other more expressive binding types can be based on lists or other data-types. Using typical
notation for defining types, one can define lists (or trees etc.)
whose elements are
ground, dynamic, numbers, nested structures and so on.
These types must be representable as a set of regular types rules.
The sets of ground and non-ground terms can also be
defined as regular types.   Examples are given in \cite{disjoint-types}.

\subsubsection{Derivation of Filter Declarations}

The given set of types is first transformed into a set of disjoint regular types.
This process is called {\em determinization} and
is described in detail in another report \cite{disjoint-types}.  The
disjoint types define an abstract domain, which is input,
along with the typed goal, to an abstract interpreter over that domain.
The details of the abstract interpretation algorithm are given
in  \cite{disjoint-types}.

For example, the simple binding types {\em static} and {\em dynamic}
are determinized to the disjoint types {\em static} and {\em non-static}.
Note that {\em dynamic} is the union of {\em static} and {\em non-static}.

The output of the abstract interpreter is an assignment of a set of disjoint types
to each argument.  Let $p/n$ be a predicate in the program.
Then the analyser assigns a binding type $p(S_1,\ldots,S_n)$
to $p$, where $S_j$ ($1 \le j \le n$) is a set of disjoint types
$\{t_{j_1},\ldots,t_{j_k}\}$.  The meaning of the assignment is that,
whenever $p/n$ is called during specialization, its $j^{th}$
argument has a value given by one of the types $\{t_{j_1},\ldots,t_{j_k}\}$.

The assignment of types to arguments for a predicate $p$ is called a {\em filter}
for $p$.  The filter is used in the generalization operation dueing partial
evalaution. We assume that there is a generalization operation,
which takes as input an atom for predicate $p$ and a filter for $p$,
and returns another, more general atom for $p$.

\subsection{Clause Annotations}
Each clause is annotated indicating how every call in the body should be treated during specialization.  This is needed to ensure local termination (that is, the termination of
the unfolding for each atom).
Some of the basic annotations are:
\begin{itemize}
\item {\bf unfold} for reducible predicates: they will be unfolded during specialization.
\item {\bf memo} for non-reducible predicates: they will be added to the memoisation table and replaced with a generalized residual predicate (using the filter for that predicate).
\item {\bf call} fully static call will be completely evaluated during specialization.
\item {\bf rescall} the call will be kept and will appear in the final specialised code.
\end{itemize}

\subsection{Example Annotation}
The simple annotations are demonstrated using the {\bf Logen} annotation syntax:
\begin{verbatim}
:- filter append(static, dynamic, dynamic).
append([],L,L).
append([H|T],L,[H|T1]) :- logen(unfold, append(T,L,T1).
\end{verbatim}
The first argument to append has been marked as {\bf static}, it will be known at specialization time, and the other arguments have been marked {\bf dynamic}.
Note that the filter declaration above could be derived automatically from the append program, the types {\em static} and {\em dynamic}, and the typed goal {\em append(static, dynamic, dynamic)}.

After determinizing the types, the filter
would be represented in the following equivalent form.
\begin{verbatim}
:-filter append([static],[static,nonstatic],[static,nonstatic]).
\end{verbatim}
In other words, the second and third argument can be either static or non-static,
which is the same as dynamic.  Note that the analysis guarantees correct
filters.  In a manually written filter, it is not guaranteed that calls to $append$ would
actually satisfy the given binding types (e.g. that $append$ would always be
called with a ground first argument).

Examining the clause annotation in the example,
%The recursive call to append is annotated for unfolding, as we know the first argument we can guarantee termination at specialization time.
the recursive call to append is annotated for unfolding. The first argument is static and
this is sufficient to guarantee termination at specialization time.  If we could not guarantee the termination of the recursive call then it would have to be marked as {\bf memo}.

\subsubsection{Derivation of Filter Declarations in the Presence of Clause Annotations}

In the derivation of filter declarations mentioned above it was stated
that whenever $p/n$ is called during specialization, its $j^{th}$
argument has a value given by one of the types $\{t_{j_1},\ldots,t_{j_k}\}$.
It was not explained what is meant by ``whenever $p/n$ is called during specialization".
In fact, this depends on the clause annotations, since the decision of whether
to memo or call an atom affects the propagation of binding types.

Standard abstract interpretation, which assumes a complete computation,
 is modified to allow for memo-ing of calls.  Memo-ed called are simply
ignored when propagating binding types.  The same holds for {\em rescall}
annotations.  Note that we still derive filters for memo-ed calls:  it is
only for propagation of binding types that they are ignored.

\section{Outline of Algorithm}
We now outline the main operations and steps in the algorithm.
The core of the algorithm is a loop which propagates the binding types
with respect to the current clause annotations, checks the resulting filters
for termination conditions, and modifies the clause annotations accordingly.
Initiially, all body atoms are annotated as {\em unfold} or {\em call}.
These can be changed to {\em memo} or {\em rescall}, until termination
is established.

\begin{enumerate}
\item {\bf Initialisation:}
  \begin{enumerate}
  \item {\bf getProgramTypes()} Standard (static, dynamic, list(dynamic), var) together
with user types from type inference and user declaration.
  \item {\bf determinizeTypes()} Transform types into disjoint intersection types (DIT).
  \item {\bf initialiseAnnotations()} Mark everything as unfolded and add a type declaration
for the initial query.
  \end{enumerate}

\item {\bf Type/Filter inference}
  \begin{enumerate}
  \item {\bf removeMemoedCalls()} Remove all memoed calls for the analysis
  \item {\bf bottomUpAnalysis()} With Respect to DIT types.  We get a precise type inferred for every predicate
    \item \begin{algorithmic}
      \FOR{all filtered calls}

      \STATE {\bf propagateTypes()} - using the result of bottom up analysis.  We get call types for every program point
      \ENDFOR
      \end{algorithmic}
  \end{enumerate}

\item {\bf Local Unfolding Problem}
  \begin{enumerate}
  \item {\bf createUnfoldBinaryClauseSemantics()} Partially Evaluate bin\_solve, specialise with respect to filter goals and the annotated program.  Producing a program whose semantics is the binary clause semantics for local unfoldings
  \item {\bf abstractProgram()} Abstract binaryClause program wrt some norm(s) using the types inferred earlier
  \item {\bf convexHullAnalysis()} Run (Andy King's) Convex Hull Analyser on abstract program
    \item {\bf for} each binary clause C of the form {\it bin\_solve(p(--),p(--), pp)} {\bf do }
      \begin{enumerate}
        \item[]{\bf if} (a rigid argument of C decreases) {\bf then} local termination is ensured
        \item[]{\bf else} mark offending call point(s) as memo and restart at 2
        \item[]{\bf endif}
      \end{enumerate}
      {\bf endfor}

  \end{enumerate}
  \item {\bf Global Termination Problem}
    \begin{enumerate}
      \item {\bf createMemoBinaryClauseSemantics()} Partially Evaluate bin\_solve to produce binary clause semantics for the memoed calls
        \item {\bf na{\"i}ve approach:} Use standard termination analysis with two changes:
          \begin{enumerate}
          \item ensure that every static part of the argument is measured (finitely partitioning condition)
          \item only need to use $=<$ instead of $<$ on all binary recursive calls
          \end{enumerate}

    \end{enumerate}

\end{enumerate}

\section{Binary Clause Semantics}
{\tt Bin\_solve} is a binary clause interpreter based on the simple vanilla interpreter solve. Specialising {\ bin\_solve} with respect to the filter goals and annotated programs we wish to analyse produces a program whose semantics is the binary clause semantics for either local unfolding or memoed calls.

\begin{verbatim}
:- filter solve(type(list(nonvar))):solve.
bin_solve([unfold(H)|_T],H).
bin_solve([memo(H)|_T],memo(H)).
bin_solve([unfold(H)|_T],RecCall) :-
        bin_solve_atom(H,RecCall).
bin_solve([unfold(H)|T],RecCall) :-
        solve_atom(H),
        bin_solve(T,RecCall).
bin_solve([memo(_)|T],RecCall) :-
        bin_solve(T,RecCall).

:- filter bin_solve_atom(nonvar_nf,dynamic).
bin_solve_atom(H,Rec) :-
            rule(H,Bdy),
                bin_solve(Bdy,Rec).

:- filter test(dynamic,dynamic).
test(H,Rec) :-
                filtered(H),
                bin_solve([unfold(H)],Rec).

filtered(ann_dapp(_,_,_,_)).
filtered(ann_app(_,_,_)).
\end{verbatim}

\begin{verbatim}
:- module('/home/sjc02r/cvs_root/cogen2/logen_examples/bta_test/bin_solve.pl.memo',[test__0/2,bin_solve_atom__1/2,solve_atom__2/4,bin_solve_atom__3/2,solve_atom__4/3]).
gensym(num__num,5).
memo_table(0,test(A,B),test__0(A,B),done(user),[]).
memo_table(1,bin_solve_atom(ann_dapp(A,B,C,D),E),bin_solve_atom__1(ann_dapp(A,B,C,D),E),done(internal),[]).
memo_table(2,solve_atom(ann_dapp(A,B,C,D)),solve_atom__2(A,B,C,D),done(internal),[]).
memo_table(3,bin_solve_atom(ann_app(A,B,C),D),bin_solve_atom__3(ann_app(A,B,C),D),done(internal),[]).
memo_table(4,solve_atom(ann_app(A,B,C)),solve_atom__4(A,B,C),done(internal),[]).

test__0(ann_dapp(B,C,D,E),ann_dapp(B,C,D,E)).
test__0(ann_dapp(B,C,D,E),F) :-
  bin_solve_atom__1(ann_dapp(B,C,D,E),F).
test__0(ann_app(B,C,D),ann_app(B,C,D)).
test__0(ann_app(B,C,D),E) :-
  bin_solve_atom__3(ann_app(B,C,D),E).
bin_solve_atom__1(ann_dapp(B,C,D,E),ann_app(C,D,F)).
bin_solve_atom__1(ann_dapp(B,C,D,E),F) :-
  bin_solve_atom__3(ann_app(C,D,G),F).
bin_solve_atom__1(ann_dapp(B,C,D,E),memo(app(B,F,E))) :-
  solve_atom__4(C,D,F).
solve_atom__2(B,C,D,E) :-
  solve_atom__4(C,D,F).
bin_solve_atom__3(ann_app([B|C],D,[B|E]),memo(ann_app(C,D,E))).
solve_atom__4([],B,B).
solve_atom__4([B|C],D,[B|E]).
\end{verbatim}

\section{Worked Example}
We demonstrate the alogrithm using a worked example of a pattern matching program.

The {\tt match} predicate identifies a pattern {\tt Pat} in a string {\tt T}.
\begin{verbatim}
match(Pat,T) :-
        match1(Pat,T,Pat,T).
match1([],Ts,P,T).
match1([A|Ps],[B|Ts],P,[X|T]) :-
        A\==B,
        match1(P,T,P,T).
match1([A|Ps],[A|Ts],P,T) :-
        match1(Ps,Ts,P,T).
\end{verbatim}

Initialise the annotations to all unfold and call?
\begin{verbatim}
:- filter match(list, dynamic).
match(Pat,T) :-
        unfold(match1(Pat,T,Pat,T)).
match1([],Ts,P,T).
match1([A|Ps],[B|Ts],P,[X|T]) :-
        call(A\==B),
        unfold(match1(P,T,P,T)).
match1([A|Ps],[A|Ts],P,T) :-
        unfold(match1(Ps,Ts,P,T)).
\end{verbatim}

Specialising through bin\_solve to obtain the abstract clause semantics:
\begin{verbatim}
bin_solve_atom__0(match(B,C),unfold(match1(B,C,B,C))).
bin_solve_atom__1(match1([B|C],[D|E],F,[G|H]),unfold(match1(F,H,F,H))).
bin_solve_atom__1(match1([B|C],[B|D],E,F),unfold(match1(C,D,E,F))).
\end{verbatim}

Abstracting the programming with respect to list length norm
\begin{verbatim}
:- filter match(list,dynamic).
:- filter match1(list,dynamic,list,dynamic).
bin_solve_atom__0(match(B,_),unfold(match1(B,_,B,_))).
bin_solve_atom__1(match1(1+C,_,F,_),unfold(match1(F,_,F,_))).
bin_solve_atom__1(match1(1+C,_,E,_),unfold(match1(C,_,E,_))).
\end{verbatim}

For each binary clause of the form: {\tt bin\_solve\_atom(p(--),unfold(p(--))}:
\begin{verbatim}
bin_solve_atom__1(match1(1+C,_,F,_),unfold(match1(F,_,F,_))).
\end{verbatim}
Argument 1 does not show decrease 1+C $\to$ F \\
Argument 3 does not show decrease F $\to$ F \\
Offending call must be marked as memo.

\begin{verbatim}
:- filter match(list, dynamic).
match(Pat,T) :-
        unfold(match1(Pat,T,Pat,T)).
match1([],Ts,P,T).
match1([A|Ps],[B|Ts],P,[X|T]) :-
        call(A\==B),
        memo(match1(P,T,P,T)).
match1([A|Ps],[A|Ts],P,T) :-
        unfold(match1(Ps,Ts,P,T)).
\end{verbatim}

\begin{verbatim}
bin_solve_atom__0(match(B,C),unfold(match1(B,C,B,C))).
bin_solve_atom__1(match1([B|C],[B|D],E,F),unfold(match1(C,D,E,F))).
\end{verbatim}

Abstract program again \ldots
\begin{verbatim}
bin_solve_atom__0(match(B,C),unfold(match1(B,C,B,C))).
bin_solve_atom__1(match1(1 +C,_,E,_),unfold(match1(C,_,E,_))).
\end{verbatim}

For each binary clause of the form: {\tt bin\_solve\_atom(p(--),unfold(p(--))}:
\begin{verbatim}
bin_solve_atom__1(match1(1 +C,_,E,_),unfold(match1(C,_,E,_))).
\end{verbatim}
Argument 1 does show decrease 1+C $\to$ C \\
Local termination is ensured.

%solve_atom__2([],B,C,D).
%solve_atom__2([B|C],[D|E],F,[G|H]) :-
%  solve_atom__2(F,H,F,H).
%solve_atom__2([B|C],[B|D],E,F) :-
%  solve_atom__2(C,D,E,F).
%
%bin_solve_atom__1(match1([B|C],[D|E],F,[G|H]),I) :-
%  bin_solve_atom__1(match1(F,H,F,H),I).
%bin_solve_atom__1(match1([B|C],[B|D],E,F),G) :-
%  bin_solve_atom__1(match1(C,D,E,F),G).
%bin_solve_atom__0(match(B,C),D) :-
%  bin_solve_atom__1(match1(B,C,B,C),D).

\end{document}


\chapter{Genomic sequence tools}
\label{gst}
The Genomic Sequence subset works directly with the DNA sequences, without any standard format. These tools allow data extraction, summarising and some mathematical operations over the files. Usually, these are used in the pipeline as complementary tools. Currently, genomic sequence tools, for analysis and manipulation, available are:
\begin{enumerate}

\item \texttt{gto\char`_genomic\char`_gen\char`_random\char`_dna}: to generate a synthetic DNA.

\item \texttt{gto\char`_genomic\char`_rand\char`_seq\char`_extra\char`_chars}: to substitute in a DNA sequence the outside ACGT chars by random ACGT symbols.

\item \texttt{gto\char`_genomic\char`_dna\char`_mutate}: to create a synthetic mutation of a sequence file given specific rates of mutations, deletions and additions.

\item \texttt{gto\char`_genomic\char`_extract}: to extract sequences from a sequence file, whose range is defined by the user in the parameters.

\item \texttt{gto\char`_genomic\char`_period}: to calculate the best order depth of a sequence, using FCMs.

\item \texttt{gto\char`_genomic\char`_count\char`_bases}: to count the number of bases in a sequence, FASTA or FASTQ files.

\item \texttt{gto\char`_genomic\char`_compressor}: to compress and decompress genomic sequences for storage purposes (also under the alias gto\char`_geco).

\item \texttt{gto\char`_genomic\char`_complement}: to replace the ACGT bases with their complements in a DNA sequence.

\item \texttt{gto\char`_genomic\char`_reverse}: to reverse the ACGT bases order for each read in a sequence file (also under the alias gto\char`_reverse).

\item \texttt{gto\char`_genomic\char`_variation\char`_map}: this tool is an alias to gto\char`_fastq\char`_variation\char`_map tool. Please check the documentation of this tool in the FASTQ tools section.

\item \texttt{gto\char`_genomic\char`_variation\char`_filter}: this tool is an alias to gto\char`_fastq\char`_variation\char`_filter tool. Please check the documentation of this tool in the FASTQ tools section.

\item \texttt{gto\char`_genomic\char`_variation\char`_visual}: this tool is an alias to gto\char`_fastq\char`_variation\char`_visual tool. Please check the documentation of this tool in the FASTQ tools section.

\end{enumerate}

\input{\GenomicSequenceToolsPath/GenomicGenRandomDNA.tex}
\input{\GenomicSequenceToolsPath/GenomicRandSeqExtraChars.tex}
\input{\GenomicSequenceToolsPath/GenomicDNAMutate.tex}
\input{\GenomicSequenceToolsPath/GenomicExtract.tex}
\input{\GenomicSequenceToolsPath/GenomicPeriod.tex}
\input{\GenomicSequenceToolsPath/GenomicCountBases.tex}
\input{\GenomicSequenceToolsPath/Geco.tex}
\input{\GenomicSequenceToolsPath/GenomicComplement.tex}
\input{\GenomicSequenceToolsPath/GenomicReverse.tex}


\chapter{Access Graphs and Potential Access}
\label{ch:access}

This chapter presents \TMaccessGraphs{} as the abstract structure for describing authority about multiple \TMsystemStates{}
There are many different types of \TMaccessGraphs{} used by \TMmodelName{}.
The \TMdirAcc{} relation translates a \TMsystemState{} to an \TMaccessGraph{} with the same authority.
The \TMcompleteAG{} for a set of \TMobjs{} defines an \TMaccessGraph{} where each \TMobj{} has total authority to every other \TMobj{}.
\Term{\TMpotAcc} is the judgment defining the worst-case access that a system may ever come to have.

\Term{\TMpotAcc{}} is used extensively throughout \TMmodelName{}.
It is built from the \COQtransfer{} relation: the smallest possible \TMaccessRight{} \TMtransfer{} in an \TMaccessGraph{}.
It defines a \TMpotTransfer{} as a sequence of \COQtransfer{}s.
It then presents the definition of a \TMmaximal{} \TMaccessGraph{} along with the proof that for each initial \TMaccessGraph{} there is only one \TMaccessGraph{} that is both \TMmaximal{} and reachable by \TMpotTransfer{}, called the \TMpotAccAG{}.
The \TMpotAcc{} of a \TMsystemState{} is the \TMpotAccAG{} of that system's \TMdirAccAG{}.
Finally, this chapter demonstrates this by verifying that \TMpotTransfer{} forms a complete partial order when rooted at some initial \TMaccessGraph{} and computing \TMpotAcc{} as a function in \COQSet{}.

\section{Access Graph Structure}

\Term{\TMaccessGraphs} are the structure used by \TMmodelName{}  to perform nearly all permission and information flow reasoning.
\xmakefirstuc{\TMaccessGraphs{}} express \TMsystemStates{} abstractly, representing many \TMsystemStates{} simultaneously.
They condense permission information encoded in \TMsystemState{} to precisely the permissions held between \TMobjs{}, rather than their \TMcaps{}.
An \TMaccessGraph{} is a finite set of \term{\TMaccessEdges}, each a triple in \( \COQReferenceType{} * \COQReferenceType{} * \COQAccessRight{} \).
The edge \mkEdge{src}{tgt}{ar} indicates that \coqvar{src} holds an \coqvar{ar} access right to \coqvar{tgt}.
As a collection of edges, the \TMaccessGraph{} makes no assertions about the nature of \TMobjs{} within it.
If any additional constraints are required, they must be carried alongside the \TMaccessGraph{}.

\begin{figure}
  \COQDOCAccessEdge{}

  \COQDOCAccessGraph{}
  \caption{\xmakefirstuc{\TMaccessGraph{}} interface definition. \label{fig:access:accessGraphs}}
\end{figure}

As a Coq module, the \TMaccessGraph{} is constructed as an \COQFSetList{} with an \COQAccessEdge{} element type.
To satisfy the \COQusualOrderedType{} interface, the \COQAccessEdge{} module is constructed as two \COQProductType{}s.
The entire functor is parameterized over the \COQReferenceType{} module interface.
The concrete implementation uses the \COQFSetList{} functor as it provides an equivalence relation based on identical data structures.

\section{Direct Access}

\begin{figure}
  \COQDOCdirAccSpec{}
  \caption{Inductive definition of \TMdirAccAG{}. \label{fig:access:dirAccSpec}}
\end{figure}

\begin{figure}
  \COQDOCdirAccSimpl{}
  \caption{Simplified, but not complete definition of \TMdirAccAG{}. \label{fig:access:dirAccSimpl}}
\end{figure}

The \Term{\TMdirAccAG{}} of a \TMsystemState{} is the \TMaccessGraph{} containing edges for every \TMcap{} held by \TMalive{} \TMobjs{} whose target is also \TMalive{}.
This forms a reduction of the \TMsystemState{}, as many \TMcaps{} may justify the existence of a single edge.
\xmakefirstuc{\TMcaps} held by \TMdead{} or \TMunborn{} \TMobjs{} are ignored as they may not be invoked and cannot be transferred.
\xmakefirstuc{\TMcaps} targeting \TMunborn{} \TMobjs{} are elided as they are removed before allocation.
\xmakefirstuc{\TMaccessRights} that appear within multiple \TMcaps{} naming the same \TMobj{} are represented by a single edge, further abstracting the \TMsystemState{}.
Therefore, any analysis of \TMaccessGraphs{} necessarily considers how \TMaccessRights{} within a \TMcap{} could operate were they independent.

The libraries \COQDirectAccess{} and \COQDirectAccessImpl{} contain the interface and implementation of \TMdirAcc{}, respectively.
The \COQdirAccSpec{} predicate definition shown in \Cref{fig:access:dirAccSpec} defines \TMdirAcc{} using set comprehension.
It captures the equivalences needed to reason about different \TMsystemStates{} and \TMaccessGraphs{}.
As such, it is a bit cumbersome, and the verification usually relies upon \COQdirAccSimpl{} for most requirements.

\begin{figure}
  \COQDOCdirAccInner{}
  \COQDOCdirAccOuter{}
  \COQDOCdirAcc{}
  \COQDOCdirAccSpecDirAcc{}
  \caption{\COQdirAcc{} function and lemmas. \label{fig:access:dirAcc}}
\end{figure}

The remainder of the \COQDirectAccessImpl{} module defines the \COQdirAcc{} function in \COQSet{} and demonstrates that it is equivalent to the \COQdirAccSpec{} proposition.
Various map fold functions are used to construct the appropriate \TMaccessGraph{} from an \COQAGempty{} accumulator.
The definition of \COQdirAcc{} in \COQSet{} and proof of equivalence together produce both decidability and existence proofs for \COQdirAccSpec{}.

\begin{figure}
  \COQDOCagAddCap{}
  \COQDOCagAddCapEquiv{}
  \COQDOCagAddCapNondecr{}
  \COQDOCagAddCapAddCommute{}
  \COQDOCagAddCommute{}
  \caption{Definition of \COQagAddCap{} and supplemental lemmas. \label{fig:access:agAddCap} \label{fig:access:agAddCommute}}
\end{figure}

\TMmodelName{} defines a number of reusable functions and lemmas as part of the \COQdirAcc{} definition.
Each of the functions named \COQagAddCap{}* adds \TMcaps{} to an \TMaccessGraph{} using the base \COQagAddCap{} function.
The \COQagAddCap{} function adds all edges represented by a single \TMcap{} into an \TMaccessGraph{}.
The \COQagAddCap{} function, and similar functions based thereon, all preserve equivalence, are non-decreasing, and are commutative with set addition.
\Cref{fig:access:agAddCap} contains the definition of \COQagAddCap{} and supplemental lemmas.
The other definitions will be presented as needed, but theorem definitions will not accompany them.
For the full implementation, please review the proof.

\section{Potential Access}

\begin{figure}
  \COQDOCtransfer{}
  \caption{Definition of \COQtransfer{}. \label{fig:access:transfer}}
\end{figure}

The \term{\TMpotAccAG} is the \TMaccessGraph{} representing the greatest potential permission state of a initial \TMaccessGraph{}.
The definition of a \TMpotAccAG{} is the closure of the \COQtransfer{} relation, a micro-operation of permission transfer.
The constructors for a \TMtransfer{} describe the seven methods by which new edges may appear in an \TMaccessGraph{}.

Each \COQtransfer{} constructor relates two \TMaccessGraphs{} by the inclusion of a single edge justified by an \TMaccessRight{}.
The \COQtransferRead{} constructor describes how an edges with the \NMrd{} permission may add a new edge and is similar to the \NMfetch{} \TMop{}.
A \NMwr{} permission authorizes any permission to be transferred in the other direction as performed by the \COQtransferWrite{} constructor.
The constructor for the \NMwk{} case, \COQtransferWeak{}, handles how \NMwk{} permissions are transferred.
\COQtransferReply{} and \COQtransferSend{} cover the \NMtx{} permission authorizing a reply or authorizing a transfer through inter-process communication.
There are also two constructors admitting self-targeting edges.
To keep the number of edges finite, some other edge in the \TMaccessGraph{} is required to identify an object before adding its self-targeting edges.
The cases \COQtransferSelfSrc{} and \COQtransferSelfTgt{} admit self-targeting edges for objects named by the source or target of an existing edge, respectively.

\begin{figure}
  \COQDOCtransferMonotonic{}
  \COQDOCtransferLUB{}
  \caption{\COQtransfer is monotonic and has a least upper bound. \label{fig:access:transferMonotonic}\label{fig:access:transferLUB}}
\end{figure}

A \TMtransfer{} forms a restriction of the subset partial order which continues to be a partial order.
As \TMtransfer{} always relates two \TMaccessGraphs{} by a single \TMaccessEdge{}, it must be monotonic.
Because a \TMtransfer{} performs judgments based solely upon the existence of edges and not their absence, any edge added by a \TMtransfer{} will continue to be valid regardless of what new edges exist, including other \TMtransfers{}.
Therefore, there is always a least upper bound for any two \TMtransfers{} on the same initial graph.
The definition of \COQtransferLUB{} captures the specific case for \TMtransfer{}.

\begin{figure}
  \COQDOCpotTransfer{}
  \caption{Definition of \COQpotTransfer{}. \label{fig:access:potTransfer}}
\end{figure}

\begin{figure}
  \COQDOCpotTransferLUB{}
  \caption{Theorems about \COQpotTransfer{}. \label{fig:access:potTransferLUB}}
\end{figure}

A \TMpotTransfer{} is any sequence of \TMtransfers{}, even empty ones, and is defined by \COQpotTransfer{}.
The \COQtransfer{} least upper bound can be extended to \COQpotTransfer{} such that any two \TMpotTransfers{} rooted sharing the same base have a least upper bound.
\xmakefirstuc{\TMpotTransfer{}} forms a partial order over all possible \TMtransfers{} starting with a base \TMaccessGraph{}.
\xmakefirstuc{\TMpotTransfer{}} is reflexive by inspection and transitive by simple induction.
It must also be anti-symmetric since, as a sequence of \TMtransfers{}, it is non-decreasing.
This least upper bound on \TMpotTransfer{} is used heavily in this verification as it permits \TMtransfers{} sharing an initial \TMaccessGraph{} to be reordered.

\begin{figure}
  \COQDOCmaxTrans{}
  \COQDOCmaxPotTrans{}
  \COQDOCmaxTransferMaxPotTransfer{}
  \COQDOCpotAcc{}
  \caption{Both definitions of \TMmaximal{} and \COQpotAcc{}.\label{fig:access:potAcc}}
\end{figure}

The supremum of \TMpotTransfer{} is \term{\TMpotAcc{}} as it represents the most permissive state after a sequence of \TMtransfers{}.
It is defined as the \TMaccessGraph{} that is both \TMmaximal{} and reachable by \TMpotTransfer{}.
The usual definition of \term{\TMmaximal{}} applies: an \TMaccessGraph{} is \TMmaximal{} precisely when all \TMpotTransfers{} are to equivalent graphs.
To reduce case analysis, we often use the equivalent definition of \TMmaximal{} claiming that all \TMtransfers{} are to equivalent graphs.
Because \TMpotTransfer{} always has a least upper bound, every \TMmaximal{} \TMaccessGraph{} is also a \TMpotAccAG{}.

\section{Computing Potential Access}

\begin{figure}
  \COQDOCagObjsSpec{}
  \COQDOCcompleteAgSpec{}
  \caption{Definition for \COQagObjsSpec{} and \COQcompleteAgSpec{}. \label{fig:access:agObjs}}
\end{figure}

\begin{figure}
  \COQDOCAGallObjs{}
  \COQDOCagObjsSpecAGallObjs{}
  \COQDOCagAllObjsTransfer{}
  \caption{Theorem demonstrating constancy of \TMagObjs{} through \TMtransfer{}. \label{fig:access:agObjsTransfer}}
\end{figure}

\begin{figure}
  \COQDOCtransferDec{}
  \caption{\COQtransfer{} as a Boolean decision.}
\end{figure}

The remainder of \COQSequentialAccess{} contains proofs that \COQtransfer{} is decidable and \COQpotAcc{} is computable in its first input.
To accomplish this, both properties are computed as functions in \COQSet{}.
Verifying the \COQtransfer{} judgment is a Boolean is substantial case analysis, but is obvious by inspection.
The definition of \TMpotTransfer{} cannot be used to compute the \TMpotAccAG{} as it is far too general and does not guarantee progress.

The function \COQcomputePotAcc{} computes \TMpotAcc{} by finding a single sequence of \TMtransfers{} that always adds a novel edge at each step.
For novelty to produce a sound measure, there must be a theoretical limit to the number of new edges.
By inspection, \TMtransfer{} does not alter which \TMrefs{} are in an \TMaccessGraph{}, it only adds edges between existing \TMrefs{}.
The \COQagObjsSpec{} judgment extracts the \TMrefs{} from an \TMaccessGraph{} and this value remains unchanged by the \TMtransfer{} and \TMpotTransfer{} relations.
The \TMcompleteAG{} for these \TMrefs{}, the \TMaccessGraph{} containing an edge with every \TMaccessRight{} and pair of \TMrefs{} available, is used as this upper limit.
The measure conjecture \COQdistFromComplete{} computes the cardinality of the set difference of the \TMcompleteAG{} and the current \TMaccessGraph{}.

\begin{figure}
  \COQDOCcomputePotAcc{}
  \COQDOCpotAccPotAccFun{}
  \caption{Definition of \COQcomputePotAcc{} and proof satisfying \COQpotAcc{}.\label{fig:access:computePotAcc}}
\end{figure}

The method used to \TMpotAcc{} is not efficient, but demonstrably yields a correct result by exhaustion.
\COQpotAccFun{} iterates over the \TMcompleteAG{} until it finds an edge satisfying the \COQtransfer{} relation when added to the initial \TMaccessGraph{}.
If it finds such an edge, it adds the edge to the initial \TMaccessGraph{} and recurses.
If no such edge exists in the \TMcompleteAG{} the current \TMaccessGraph{} must be \TMmaximal{}.
Consequently it must also be the \TMpotAccAG{}.

The majority of \TMmodelName{} is concerned with the relationships surrounding \TMpotAcc{}.
\Term{\TMpotAcc} is central to both the safety property and statically bounding data motion.
Although there are other \TMaccessGraphs{} used by \TMmodelName{}, they will be defined in \Cref{ch:confinement} when used.