\documentclass[12pt,letterpaper,oneside,reqno]{amsart}
\usepackage{amsfonts}
\usepackage{amsmath}
\usepackage{amssymb}
\usepackage{amsthm}
\usepackage{float}
\usepackage{mathrsfs}
\usepackage{colonequals}
\usepackage[font=small,labelfont=bf]{caption}
\usepackage[left=1in,right=1in,bottom=1in,top=1in]{geometry}
\usepackage[pdfpagelabels,hyperindex,colorlinks=true,linkcolor=blue,urlcolor=magenta,citecolor=green]{hyperref}
\usepackage{setspace}
\usepackage{graphicx}
\usepackage{spverbatim}
\onehalfspacing
\emergencystretch=1em

\linespread{1.25}

\newcommand \anglePower [2]{\langle #1 \rangle \sp{#2}}
\newcommand \bernoulli [2][B] {{#1}\sb{#2}}
\newcommand \curvePower [2]{\{#1\}\sp{#2}}
\newcommand \coeffA [3][A] {{\mathbf{#1}} \sb{#2,#3}}
\newcommand \polynomialP [4][P]{{\mathbf{#1}}\sp{#2} \sb{#3}(#4)}

% ordinary derivatives
\newcommand \derivative [2] {\frac{d}{d #2} #1}                              % 1 - function; 2 - variable;
\newcommand \pderivative [2] {\frac{\partial #1}{\partial #2}}               % 1 - function; 2 - variable;
\newcommand \qderivative [1] {D_{q} #1}                                      % 1 - function
\newcommand \nqderivative [1] {D_{n,q} #1}                                   % 1 - function
\newcommand \qpowerDerivative [1] {\mathcal{D}_q #1}                         % 1 - function;
\newcommand \finiteDifference [1] {\Delta #1}                                % 1 - function;
\newcommand \pTsDerivative [2] {\frac{\partial #1}{\Delta #2}}               % 1 - function; 2 - variable;

% high order derivatives
\newcommand \derivativeHO [3] {\frac{d^{#3}}{d {#2}^{#3}} #1}                % 1 - function; 2 - variable; 3 - order
\newcommand \pderivativeHO [3]{\frac{\partial^{#3}}{\partial {#2}^{#3}} #1}
\newcommand \qderivativeHO [2] {D_{q}^{#2} #1}                               % 1 - function; 2 - order
\newcommand \qpowerDerivativeHO [2] {\mathcal{D}_{q}^{#2} #1}                % 1 - function; 2 - order
\newcommand \finiteDifferenceHO [2] {\Delta^{#2} #1}                         % 1 - function; 2 - order
\newcommand \pTsDerivativeHO [3] {\frac{\partial^{#3}}{\Delta {#2}^{#3}} #1} % 1 - function; 2 - variable;

\newtheorem{thm}{Theorem}[section]
\newtheorem{cor}[thm]{Corollary}
\newtheorem{lem}[thm]{Lemma}
\newtheorem{examp}[thm]{Example}

\numberwithin{equation}{section}

\title[Diffie-Hellman Key Exchange via REST]
{Diffie-Hellman Key Exchange via REST}
\author[Petro Kolosov]{Petro Kolosov}
\email{kolosovp94@gmail.com}
\keywords{
    Diffie-Hellman Key Exchange, DH key exchange, REST
}
\urladdr{https://razumovsky.me}
\subjclass[2010]{26E70, 05A30}
\date{\today}
\hypersetup{
    pdftitle={Diffie-Hellman Key Exchange via REST},
    pdfsubject={
        Diffie-Hellman Key Exchange, DH key exchange, REST
    },
    pdfauthor={Petro Kolosov},
    pdfkeywords={
        Diffie-Hellman Key Exchange, DH key exchange, REST
    }
}
\begin{document}
    \begin{abstract}
        Discussion on Diffie-Hellman Key Exchange and its implementation via REST.
    \end{abstract}

    \maketitle

    \tableofcontents

    \section{Introduction} \label{sec:introduction}
    Diffie--Hellman (DH) protocol is a method of asymmetric exchange
    of the cryptographic keys for a group of two or more participants,
    developed in 1976 by cryptographers Ralph Merkle, Whitfield Diffie and Martin Hellman.
    In contrast to the symmetric key exchange,
    the Diffie\textendash Hellman protocol eliminates the direct transfer of the shared secret
    between the participants so that each participant computes a shared secret with his own private-public key pair.
    The Diffie\textendash Hellman protocol is based on a one-way function of the form

    \begin{equation}
        A = G ^ a \bmod P \label{eq:equation}
    \end{equation}

    where $A$ is the user's public key,
    $a$ is the user's private key,
    $P=2Q+1$ is modulus, such that 2048 bits safe-prime because $Q$ is also prime,
    $G$ is generator such that $G$ is primitive root modulo $P$.
    We say that $G$ is primitive root modulo $P$ if for each $1 \leq a \leq P - 1$ the $A = G ^ a \bmod P$
    is unique and belong to the set $\{1, 2, \dots, P-1\}$.
    The period of such cyclic group $\mathbb{Z}_{P}$ is $P-1$ then.

    Thus, the safety of the Diffie--Hellman protocol is based on the discrete logarithm problem which is unsolvable
    in polynomial time if the constants $G$ and $P$ are chosen correctly.
    Graphically the flow of the Diffie--Hellman protocol can be expressed through the
    analogy with mixing paints as the picture below shows
    \begin{figure}[H]
        \centering
        \includegraphics[width=1\textwidth]{Pictures/Diffie_Hellman_keyexchange_concept_diagram}
        ~\caption{Diffie\textendash Hellman key exchange concept diagram.}\label{fig:figure4}
    \end{figure}
    In contrast to the Diffie\textendash Hellman based on discrete logarithm problem, there is an Elliptic Curve Diffie\textendash Hellman
    key exchange, which based on the elliptic curve discrete logarithm problem.
    Although, the idea is quite same, the difference only in that Elliptic Curve Diffie\textendash Hellman ensures the same safety
    as discrete logarithm Diffie\textendash Hellman with lower value of the prime modulus $P$.
    For instance, 521 bit modulus used in Elliptic Curve Diffie\textendash Hellman is equally safe as 2048 bit modulus in
    discrete logarithm Diffie\textendash Hellman.
    To summarize, the flow of Diffie\textendash Hellman key exchange is as follows.
    Given 2048 bits public prime modulus $P$ and generator $G$ such that $G$ is primitive root modulo $P$ then
    \begin{enumerate}
        \item Alice chooses her secret $a$.
        \item Alice sends to Bob her public key $A = G^a \bmod P$.
        \item Bob chooses his secret $b$.
        \item Bob sends to Alice his public key $B = G^b \bmod P$.
        \item Alice computes common secret $s = B^a \bmod P$.
        \item Bob computes common secret $s = A^b \bmod P$.
        \item Alice and Bob have arrived to the same value
        \begin{eqnarray}
            s = A^b \bmod P = G^{ab} \bmod P \\
            s = B^a \bmod P = G^{ba} \bmod P
        \end{eqnarray}
    \end{enumerate}

    \begin{figure}[H]
        \centering
        \includegraphics[width=1\textwidth]{Pictures/DH_Key_Exchange}
        ~\caption{Diffie\textendash Hellman key exchange concept diagram.}\label{fig:figure}
    \end{figure}

    \section{Diffie\textendash Hellman key exchange implementation via REST}
    \label{sec:diffie–-hellman-key-exchange-implementation-via-rest}
    Although, the idea of Diffie\textendash Hellman key exchange looks quite simple,
    some remarks on the concrete implementation should be added.
    Firstly, it is necessary to implement the mechanism of key exchange request between two or more parties.
    As it discussed above, each user has his own private-public keys pair, so in order to perform request between parties,
    it should be implemented dedicate REST~\cite{ong2015materials} web--service endpoint,
    for instance the \texttt{POST: api/key-exchange-requests} which takes the request body of the form

    \input{Files/post-keyexchange-body}

    So, request sender generates on the client side a key pair, keeps private on in the file system and shares the public
    in request to receiver.
    Therefore, the second party has received the key exchange request.
    In order to display all the key exchange requests awaiting the confirmation of decline decisions, it is worth to implement
    another REST endpoint such that \texttt{GET: api/key-exchange-requests}, so that requested party will have the list of
    requests to proceed.
    This endpoint may return the data structure like follows

    \input{Files/get-keyexchangerequests-response}

    Finally, requested party should be able to confirm or decline the key exchange request, the
    \texttt{DELETE: api/key-exchange-requests} endpoint should be implemented then.
    The server is able to fetch the request thanks to the body endpoint takes

    \input{Files/delete-keyexchangerequest-body}

    Therefore, an identifier of awaiting request is passed to the server among with boolean value
    indicating the confirmation.
    Under the roof of this operation are also generation of private-public keys pair for the requested party and
    generation of common secret stored in client's file system.
    As result, the initial request sender receives a public key as confirmation from requested party.
    Requested side may get all his public keys via the REST web--service using the resource \texttt{GET: api/public-keys}

    \input{Files/get-publickeys-response}

    Now requested participant is able to derive the common secret.
    In order to provide an example, a simple command line interface is implemented.
    We have used an Elliptic Curve Diffie\textendash Hellman implementation \texttt{ECDiffieHellmanCng Class} from the namespace
    \texttt{System.Security.Cryptography} of the .NET base class library.
    The \texttt{P-256} curve is used.

    More precisely, the following CLI commands are implemented
    \begin{itemize}
        \item \texttt{MangoAPI.DiffieHellmanConsole login SENDER\_EMAIL SENDER\_PASSWORD}
        \item \texttt{MangoAPI.DiffieHellmanConsole key-exchange RECEIVER\_ID}
        \item \texttt{MangoAPI.DiffieHellmanConsole key-exchange-requests}
        \item \texttt{MangoAPI.DiffieHellmanConsole confirm-key-exchange REQUEST\_ID}
        \item \texttt{MangoAPI.DiffieHellmanConsole print-public-keys}
        \item \texttt{MangoAPI.DiffieHellmanConsole create-common-secret RECEIVER\_ID}
    \end{itemize}
    Commands are self-explanatory, therefore we skip the detailed documentation on them.
    An example of console output straightforward
    \begin{figure}[H]
        \centering
        \includegraphics[width=1\textwidth]{Pictures/Diffie_Hellman_console_output}
        ~\caption{Diffie–-Hellman key exchange console output.}\label{fig:figure7}
    \end{figure}
    In order to repeat the outputs on the screenshot the user may reference to the resources
    \begin{itemize}
        \item API: \href{https://back.mangomessenger.company/swagger}{\texttt{https://back.mangomessenger.company/swagger}}
        \item Source: \href{https://github.com/MangoInstantMessenger/MangoMessengerAPI}{\texttt{https://github.com/MangoInstantMessenger/MangoMessengerAPI}}
    \end{itemize}
    Finally, both test accounts reached the same base 64 common secret.
    \begin{figure}[H]
        \centering
        \includegraphics[width=1\textwidth]{Pictures/Same_common_secret}
        ~\caption{Common secrets.}\label{fig:figure2}
    \end{figure}

    \bibliographystyle{alpha}
    \bibliography{DiffieHellmanKeyExchangeReferences}

\end{document}


%% \section{Discussion and Related Work}
\section{Discussion}
\label{sec:Discussion}

We conclude with a broader discussion of the design space, as well as related
and future work.

\subsection{Design Tradeoffs of Difficult Destruction}
\label{sec:Discussion:Tradeoffs}

Is it possible to have a data structure that possesses all four properties?
%
Probably not.

\SemInj{} requires canonical ordering and deduplication, and \SemTot{} means that the canonical order and deduplication have to come from how the data is interpreted rather than how it is organized.
%
%The following section shows that this non-literal interpretation causes issues with ease of destruction.
%As a result $\hdots$
%% \parahead{The Difficulty of Destruction}
%\parahead{Not-So-Easy Destruction}
%
The non-literal way in which key data is interpreted for delta dictionaries means that it is not safe for client code to work with the raw data directly---rather, all interaction with the data must be encapsulated in library functions.

Unfortunately, this includes \emph{destruction}; an interaction which
normally goes through the very natural, elegant, and well-supported mechanism of pattern matching is now
only available through the library function \verb+destruct+. \autoref{thm:EzDstr} proves that this function
destructs the \dd{} in essentially the same way that a case expression destructs a list of pairs (although
the order in which bindings are plucked away is arbitrary from the client's perspective).

\verb+destruct+ achieves the same purpose as typical pattern matching (albeit more awkwardly), but because it
does not harness the primitive notions of pattern matching and structure, it does not establish structural
decrease on the dictionary object, which may break out-of-the-box structural recursion in the likely case
of recursion on the subdictionary \verb+dd'+. To enable manual establishment of structural recursion, via an extra parameter that
explicitly tracks the dictionary length, we provide another theorem:

\begin{alltt}
  extend-size :
    \altFAll\{V\} \{dd : DD V\} \{k : K\} \{v : V\} \altRArr
      k \altNIn dd \altRArr
      || dd ,, (k , v) || = 1 + || dd ||
\end{alltt}

Although possible, manually establishing termination is painful, especially given that it is not necessary
for {\sal}s or {\cal}s. Thus \dds~ fail at \EzDstr, although they are still better than {\fpf}s in this
regard, seeing as it is not only hard but impossible to destruct {\fpf}s.

%% Is it possible to have a data structure that possesses all four properties?
%% Not likely. As mentioned above, the combination of \SemInj{} and \SemTot{} essentially
%% necessitates that the data in the data structure be interpreted in a non-literal way, which in turn
%% makes it dangerous for client code to manipulate the raw data.

%% As such,

Because satisfying all four properties seems unattainable,
we believe we have uncovered an
inherent trade-off between desirable properties. In cases where \SemTot{} and \EqDec{} are critical,
and there is little to no need to destruct dictionaries, \dds{} seem to be a clear winner over
the conventional solutions. But in cases where \SemTot{} is not so important,
but inspection or destruction are, {\cal}s may be a preferable.

\subsection{Potential Practical Applications}
\label{sec:Discussion:Generality}

Next, we provide additional discussion about the use of dictionaries in our case study, as well as programming language metatheory in general.

%% \parahead{Generality}

\parahead{Generality of Case Study}

The scenario in \autoref{sec:CaseStudy} may seem contrived, but it is actually a simplification of a real task faced by the authors:
%
to mechanize the formalization of AnonymousSystem~\citep{AnonymousSystem}, a program synthesis technique which uses
natural semantics (\ie{} big-step, environment-based evaluation) and which requires assertions.
%
The development in \autoref{sec:CaseStudy} captures the essence of our much larger mechanization~\citep{AnonymousURL} for AnonymousSystem.
%
Although that mechanization has not been completed, the challenges faced during its development---described in \autoref{sec:CaseStudy}---necessitated the invention of \dds.

Perhaps, instead of using \dds, these issues could be worked around, by changing or dropping some of our criteria?
In many cases, substitution can be used to avoid environments. However, environments are often preferred---usually in combination with big-step operational semantics---because
they allow the formalization to more closely resemble the implementation of a simple recursive interpreter. Furthermore,
AnonymousSystem has hole closures in addition to lambda closures, so closing over environments would be necessary regardless.

Contraction and exchange are not always necessary properties for program foundation judgments---%
rather, substructural type systems, by definition, deliberately violate one or both of these properties.%
\footnote{\hspace{0.01in}Technically, some substructural type systems (\eg{} \emph{relevant} type systems) uphold contraction and exchange but violate \emph{weakening}.}
That said, a judgment should generally uphold the structural properties unless there is a strong and explicit
reason not to. Proving the right properties
is both a matter of good housekeeping and necessity: they are standard
considerations because they arise very naturally in any other
interesting metatheory, and the inability to prove them is often a large red flag indicating a bug in the judgment's definition.
Because contraction and exchange are properties of \dds{} themselves,
the proofs of these properties for one or many judgments come ``for free.''
Additionally, the useful properties of \dds{} may greatly reduce the difficulty of the usually
more judgement-specific proof of \emph{weakening}.

It may not seem useful to assert that two functions are intensionally identical, but if assertion is relaxed,
so as to test consistency or partially extensional equality instead of purely intensional equality,
it would require environments that are destructible.
Scenarios which require destructibility but not \EqDec{} lead to the same conclusions,
seeing as these columns are identical in \autoref{fig:prop-summary}.

In addition to breaking strict positivity, refinement proofs can be the source of less severe pain points in
a broader range of circumstances.
The ability to refine ordinary types with proofs of validity is one of the most interesting and useful benefits of
dependently-typed languages, and this power should be appreciated. However, refining with proof terms can
come at a practical cost, so even in dependently-typed languages, there is high value in avoiding refinements
whenever possible (or at least whenever profitable). The practical cost of refinements is that proof terms
do not possess the properties \SemInj~ or \EqDec: due to \emph{proof relevance}, two proofs of
the same property may be unequal, and due to the fact that proof terms may contain functions, proof terms do not
possess \EqDec~ in the general case. Thus, \SemTot---which obviates the need for refinement---has
a lot of practical value in many general cases beyond those where it is absolutely necessary to appease the
positivity checker.

\parahead{Dictionaries vs. Custom Datatypes}

Dictionaries are not always used to represent environments in mechanizations of programming language theory.

When the order of bindings does not matter, dictionaries are a natural choice for type contexts.
%
But if types defined ``later'' in inner scopes, can refer to types defined ``earlier'' in outer scopes, then order-insensitive dictionaries are inherently inappropriate.
%
This is the case for languages that support subtyping---notably, the subject of the POPLmark Challenge~\citep{POPLmark}.
%
Linear type systems, on the other hand, require sensitivity to duplicate insertions, so duplication-insensitive dictionaries are inappropriate for them as well \citep{StructProp}.
%
Though {\sal}s remain the most natural choice in these cases, future work could explore data structures that are sensitive to ordering but not duplication, or vice versa.

The use of dictionaries is furthermore avoided in many systems that use substitution rather than environments
%
in defining the dynamic semantics of a language, as well as the many systems that avoid named variables altogether by using De Bruijn indices or comparable techniques---see \emph{Certified Programming with Dependent Types}~\cite[Library Firstorder]{cpdt} for an introduction.

For these reasons, many existing mechanizations make little use of order-and-duplication-insensitive dictionaries.
%
However, as mechanization becomes increasingly popular, for an ever-broadening scope of applications,
%
it seems inevitable that a programming utility as fundamental as dictionaries will eventually become ubiquitous, at which point it will be important to have the
%
best implementations at our disposal.

\subsection{Related Work}
\label{sec:Discussion:Related}

How often are different dictionary representations used?

\parahead{Conventional Representations}
%
Due to their simplicity, {\sal}s are perhaps the most typical implementation for dictionaries.
%
But because \SemInj{} is so important in simplifying proofs, {\fpf}s also see significant use---in key works such as \emph{Software Foundations}~\cite[Maps]{Pierce:SF1}---despite requiring a bit of extra overhead.

%% TODO macro?

\Cals{} seem to get little use, perhaps because working with refinement proofs might add more hassle than \SemInj{} alleviates.
%
\Cals{} are defined in the Coq standard library as \texttt{FMapList} \citep{FMapList}; a GitHub search for \texttt{FMapList} shows $304$ results,
%
whereas a search for \texttt{FMapAVL} shows $474$ results, suggesting that {\cal}s have been found to be less useful than high-performance implementations.
%
A search for \texttt{FunctionalExtensionality} \citep{FunExt}, on the other hand, turns up $4916$ results, though most of these are probably unrelated to dictionaries.%
\footnote{\hspace{0.01in}%
%
These searches and can be reproduced by URLs of the form:
\url{https://github.com/search?l=\&p=3\&q=FMapList+language\%3ACoq\&ref=advsearch\&type=Code },
replacing \texttt{FMapList} with \texttt{FMapAVL} and \texttt{FunctionalExtensionality}.
%
Accessed August 23, 2020.
%
}
%
\citet{Amorim:fmap} provides a more comprehensive treatment of {\cal}s, augmenting them with a functional interface so that the client can
%
use them as though they were {\fpf}s (note that this is different from having a \fpf{} augmented with keys).

% github searches
% funext        : 4916
% FMapInterface : 504
% FMapAVL       : 474
% FMapList      : 304

\parahead{Performance Concerns}
%
It was noted above that AVL implementations are apparently more popular than {\cal}s, and as more software is mechanized, performance is likely to become an
%
even greater concern than it is today. In cases where there is no extraction step, and the proof language is also the language that will be executed,
%
there may be no choice but to use implementations that are high-performance but theoretically unwieldy.

However, it seems more appropriate, especially with
%
fundamental utilities such as dictionaries, to either extract or translate the mechanization into an implementation language that defines these utilities natively
%
by way of highly efficient implementations such as hashtables or red-black trees. This extraction may not be completely fidelitous, since it will be using a
%
different data structure in the implementation than was used in the proofs, but presumably the implementation's version of dictionaries is well-tested and bug-free,
%
and its definition of equality is, at least for fundamental utilities such as dictionaries, extensional and decidable.

Regardless, even if unperformant implementations
%
cannot be used for code that will be run, they may be useful for parts of the code which are only used for proofs and will not be executed.

\subsection{Conclusion and Future Work}
\label{sec:Discussion:Conclusion}
%
This paper discusses the important properties \SemTot, \SemInj, \EqDec, and \EzDstr, and offers an implementation for dictionaries that (mostly) fulfills these properties.

Future work could consider implementations for other key utilities, such as trees or graphs, that satisfy these properties.
%
Doing so could be far more challenging.
%
It is relatively easy to simultaneously satisfy \SemTot{} and \SemInj{} for list-like structures such as dictionaries,
%
but much more awkward to do so for highly structural data such as graphs. For unlabeled graphs in particular, establishing a one-to-one correspondence between terms and
%
semantic meanings requires understanding of the graph isomorphism problem, which involves complex algebra.

% Other things to consider mentioning, but probably not
% - try to make sense of https://github.com/arthuraa/coq-utils/blob/master/theories/nominal.v
% - Coq also has FMapPositive, which is a tree based on the binary representation
% - something something explicit substitutions, Abadi et al. POPL 1990.
% - Look deeper into TDD with Idris


\documentclass[english]{../thermomemo/thermomemo}
\usepackage[utf8]{inputenc}

\title{Volume shift for generic EOS}
\author{Morten Hammer}

\usepackage[normalem]{ulem}

\usepackage{hyperref}
\usepackage{color}

\definecolor{midnightblue}{RGB}{35,35,132}
\definecolor{urlblue}{RGB}{70,130,180}

\definecolor{shadecolor}{gray}{0.9}

\hypersetup{
    colorlinks=true,
    linkcolor=midnightblue,
    urlcolor=urlblue,
    citecolor=midnightblue,
    linktoc=page
}

\usepackage{amsmath}
\usepackage{hyperref}
\usepackage{framed}
\usepackage{siunitx,mhchem,todonotes}
\newcommand{\pone}[3]{\frac{\partial #1}{\partial #2}\bigg|_{#3}}% partial
                                % derivative with information of
                                % constant variables
\newcommand*{\vektor}[1]{\boldsymbol{#1}}%
\newcommand{\dd}[1]{\mathrm{d}{#1}}

\DeclareMathOperator*{\argmin}{arg\,min }

\usepackage[activate={true,nocompatibility},final,kerning=true,tracking=true,spacing=true,stretch=10,shrink=10]{microtype}
\microtypecontext{spacing=nonfrench}
\SetExtraKerning[unit=space]
    {encoding={*}, family={bch}, series={*}, size={footnotesize,small,normalsize}}
    {\textendash={400,400}, % en-dash, add more space around it
     "28={ ,150}, % left bracket, add space from right
     "29={150, }, % right bracket, add space from left
     \textquotedblleft={ ,150}, % left quotation mark, space from right
     \textquotedblright={150, }} % right quotation mark, space from left
\SetTracking{encoding={*}, shape=sc}{0}

\begin{document}
\frontmatter

%\tableofcontents

\section{Introduction}
The volume shift was introduced by P{\'e}neloux et al. \cite{Peneloux1982},
\begin{equation}
  c = \frac{1}{n}\underset{i}{\sum}c_i n_i,
\label{eq:volumeshift}
\end{equation}
where $c_i$ is a component constant representing the component volume
shift.

Different properties change when working with volume translations, see
Jaubert et al. \cite{Jaubert2016} for details.

The volume-shift have found application in many cubic based equations
of state (t-mPR\cite{Kordas1995}, PSRK\cite{Fischer1996},
VTPR\cite{Collinet2006}, tc-PR/tc-RK\cite{LeGuennec2016}, \dots), and
the component volume translations $c_i$, are often fixated to match the
liquid density at $T=0.7T_{\text{Crit}}$,
\section{Volume shifts for generic EOS}

The residual reduced Helmholtz function of a  generic EOS is found as follows,
\begin{align}
  F(T,V_{\text{eos}},\vektor{n}) = \frac{A^\text{r}(T,V_{\text{eos}},\vektor{n})}{RT}
  = \int^\infty_{V_{\text{eos}}} \left[ \frac{P(T,V_{\text{eos}}^\prime,\vektor{n})}{RT} - \frac{n}{V_{\text{eos}}^\prime} \right]\dd{V_{\text{eos}}^\prime}
  \label{eq:helmholtz_int_eos}
\end{align}
Introducing the volume shift,
\begin{equation}
V = V_{\text{eos}}- \sum n_ic_i = V_{\text{eos}}- C,
\label{eq:v_shift}
\end{equation}
The residual reduced helmholtz of the volume-shifted (vs) EOS can be
found, using $dV = dV_{\text{eos}}$ at constant $n$ and $T$,
\begin{align}
  F^{\text{vs}}(T,V,\vektor{n})
  &= \int^\infty_V \left[ \frac{P(T,V^\prime+C,\vektor{n})}{RT} - \frac{n}{V^\prime} \right]\dd{V^\prime} \\ &= \int^\infty_V \left[ \frac{P(T,V^\prime+C,\vektor{n})}{RT} - \frac{n}{V^\prime + C} \right]\dd{V^\prime} + n\int^\infty_V \left[\frac{1}{V^\prime + C}  - \frac{1}{V^\prime} \right]\dd{V^\prime}\\ &= \int^\infty_{V_{\text{eos}}} \left[ \frac{P(T,V_{\text{eos}}^\prime,\vektor{n})}{RT} - \frac{n}{V_{\text{eos}}^\prime} \right]\dd{V_{\text{eos}}^\prime} + n\int^\infty_V \left[\frac{1}{V^\prime + C}  - \frac{1}{V^\prime} \right]\dd{V^\prime}\\ &= F(T,V_{\text{eos}},\vektor{n})  + n \ln \left(\frac{V}{V_{\text{eos}}} \right)
  \label{eq:helmholtz_int}
\end{align}
Here we need to treat $V_{\text{eos}} = V_{\text{eos}}(V,\vektor{n})$ with the
chain rule when differentiating $F^{\text{vs}}$.

If we introduce $F^C$ as the corrected residual reduced Helmholtz energy, due to
the difference in ideal volume,
\begin{align}
  F^C(V,\vektor{n}) &= n \ln \left(\frac{V}{V+C} \right),
  \label{eq:F_corr}
\end{align}
the differentials can be derived in a organized manner.
\begin{align}
  F^C_{V} &= n \left(\frac{1}{V} - \frac{1}{V+C} \right) = n \left(\frac{1}{V} - \frac{1}{V_{\text{eos}}} \right), \\
  F^C_{VV} &= n \left(-\frac{1}{V^2} + \frac{1}{\left(V+C\right)^2} \right) = n \left(-\frac{1}{V^2} + \frac{1}{V_{\text{eos}}^2} \right), \\
  F^C_{i} &= \ln \left(\frac{V}{V+C} \right) - \frac{nc_i}{V+C} = \ln \left(\frac{V}{V_{\text{eos}}} \right) - \frac{nc_i}{V_{\text{eos}}}, \\
  F^C_{ij} &= -\frac{\left(c_j + c_i \right)}{V+C} +  \frac{n c_ic_j}{\left(V+C\right)^2} = -\frac{\left(c_j + c_i \right)}{V_{\text{eos}}} +  \frac{n c_ic_j}{V_{\text{eos}}^2}, \\
  F^C_{Vi} &= \frac{1}{V} - \frac{1}{V+C} + \frac{nc_i}{\left(V+C\right)^2} =  \frac{1}{V} - \frac{1}{V_{\text{eos}}} + \frac{nc_i}{V_{\text{eos}}^2}
\end{align}
In addition the compositional differentials change for since $V_{\text{eos}} = V + C$,
\begin{align}
  F^{\text{eos}}_{i} &= F^{\text{eos}}_{i} + F^{\text{eos}}_{V_{\text{eos}}} c_i , \\
  F^{\text{eos}}_{Ti} &= F^{\text{eos}}_{Ti} + F^{\text{eos}}_{TV_{\text{eos}}} c_i , \\
  F^{\text{eos}}_{ij} &= F^{\text{eos}}_{ij} + F^{\text{eos}}_{iV_{\text{eos}}} c_j + F^{\text{eos}}_{V_{\text{eos}}j} c_i + F^{\text{eos}}_{V_{\text{eos}}V_{\text{eos}}} c_ic_j .
\end{align}

\subsection{Test of the fugacity coefficient}
Let us test this for the fugacity coefficient. It is defined as
\begin{align}
  \ln \hat{\varphi}_i^{\text{vs}} = \biggl( \frac{\partial F^{\text{vs}}}{\partial n_i} \biggr)_{T,V,n_j} - \ln \left( Z \right) = F_{n_i}^{\text{vs}} - \ln \left( Z \right)
  \label{eq:fugacity}
\end{align}
Differentiating $F^{\text{vs}}$,
\begin{align}
  F_{n_i}^{\text{vs}} &= F_{n_i} + F_{V_{\text{eos}}}c_i  + \ln \left(\frac{V}{V_{\text{eos}}} \right) - \frac{n c_i}{V_{\text{eos}}} = F_{n_i} + \ln \left(\frac{V}{V_{\text{eos}}} \right) - \frac{P c_i}{RT}
  \label{eq:Fni}
\end{align}
Combining Equation \ref{eq:fugacity} and \ref{eq:Fni}, we get
\begin{align}
  \ln \hat{\varphi}_i^{\text{vs}} &= F_{n_i} + \ln \left(\frac{V}{V_{\text{eos}}} \right) - \frac{P c_i}{RT} - \ln \left( \frac{PV}{n RT} \right) \\
                      &= F_{n_i} - \ln \left( \frac{PV_{\text{eos}}}{n RT} \right) - \frac{P c_i}{RT} \\
  &= \ln \hat{\varphi}_i - \frac{P c_i}{RT}
  \label{eq:fugacity2}
\end{align}
which is the same result as reported by P{\'e}neloux et al.

\section{Correlations used for $c_i$}
The $c_i$ for the SRK EOS is calculated from the following equation:
\begin{equation}
  c_i = 0.40768\frac{R T_{c_i}}{P_{c_i}}\left(0.29441- Z_{\text{RA}}\right)
\label{eq:ci}
\end{equation}

$Z_{\text{RA}}$ are tabulated in TPlib. Reid et al. \cite{Reid1987}
also correlate $Z_{\text{RA}}$ as follows:
\begin{equation}
  Z_{\text{RA}} = 0.29056 - 0.08775 \omega
\label{eq:zra}
\end{equation}

Jhaveri and Youngren \cite{Jhaveri1988} have developed different paramaters for the PR EOS:
\begin{equation}
  c_i^{\text{PR}} = 0.50033\frac{R T_{c_i}}{P_{c_i}}\left(0.25969- Z_{\text{RA}}\right)
\label{eq:ci_PR}
\end{equation}
\clearpage
\bibliographystyle{plain}
\bibliography{../thermopack}

\end{document}

%%% Local Variables:
%%% mode: latex
%%% TeX-master: t
%%% End: