
Cryptography is a specialist subject, requiring people with many different
backgrounds to cooperate in its secure and efficient implementation.
Where possible, we have written this specification to be understandable by
all, though we recognise that the motivations and references to
algorithms or other specifications and standards may be unfamiliar to those
who are not domain experts.

This specification anticipates being read and acted on by various people
with different backgrounds.
We have tried to capture these backgrounds
here, with a brief explanation of what we expect them to know, and how
it relates to the specification.
We hope this aids people's understanding of which aspects of the specificaiton
are particularly relevent to them, which they may (safely!) ignore, and
pass to a colleague.

\begin{itemize}
\item Cryptographers and cryptographic software developers.
  These are the people we expect to write code using the instructions
  in this specification.
  They should understand fairly obviously the motivations for the
  instructions we include, and be familiar with most of the algorithms
  and outside standards which we refer to.
  We expect the sections on constant time exection
  (Section \ref{sec:scalar:timing})
  and the entropy source (Section \ref{sec:entropy-source})
  to be chiefly understood with their help.
\item Computer architects.
  We do not expect architects to have a cryptography background.
  We nonetheless expect architects to be able to examine our instructions
  for implementation issues, understand how the instructions will be used
  in context, and advise on how best to fit the functionality the
  cryptographers want to the ISA interface.
\item Digital design engineers \& micro-architects.
  These are the people who will implement the specification inside a
  core. Again, no cryptography expertise is assumed, but we expect them to
  interpret the specification and anticipate any hardware implementation
  issues. E.g., where high-frequency design considerations apply, or where
  latency/area tradeoffs exist etc.
  In particular, they should be aware of the literature around efficiently
  implementing AES and SM4 SBoxes in hardware.
\item Verification engineers.
  Responsible for ensuring the correct implementation of the extension
  in hardware.
  No cryptography background is assumed.
  We hope they are able to identify interesting test cases from the
  specification, and knowing how the instructions are used in the real world.
  We do not expect verification engineers in this sense to be experts
  in entropy source design or certification, since this is a very
  specialised area.
  We do expect them however to identify all of the {\em architectural}
  test cases around the entropy source interface.
\end{itemize}

These are by no means the only people concerned with the specification,
but they are the ones we considered most while writing it.

