{{{
#!htmlcomment

This page is maintained automatically by a script.  Don't modify this page by hand,
your changes will just be overwritten the next time the script runs.  Talk to your
Friendly Neighborhood Repository Maintainer if you need to change something here.

}}}

{{{
#!html
<h1>cryptlib</h1>

<h2>Introduction</h2>

<p>This is a port of Peter Gutmann's
<a href="https://www.cs.auckland.ac.nz/~pgut001/cryptlib/">cryptlib package</a>
to the Cryptech project's environment.  This is a work in progress,
and still at a very early stage as of this writing.</p>

<p>The main addition to the stock cryptlib environment is a set of
Hardware Adaption Layer (HAL) implementations that use the Cryptech
FPGA cores.</p>

<p>While we expect to be making more significant use of cryptlib in the
future, the main purposes of this code at the moment are
proof-of-concept and connecting the Cryptech cores to a more complete
cryptographic programming environment for testing and development
purposes.</p>

<h2>Current status</h2>

<p>At present, the Cryptech HAL code runs only on the Novena PVT1.  There
are three variants of the HAL, all using the I2C bus, but speaking
different protocols:</p>

<ul>
<li><p>An implementation using the <code>coretest</code> byte-stream protocol
implemented by the <code>core/novena</code> FPGA build.</p></li>
<li><p>An implementation using the simpler interface implemented by the
<code>core/novena_i2c_simple</code> environment.</p></li>
<li><p>An implementation using the <code>coretest</code> byt-stream protocol as
implemented by the <code>test/novena_trng</code> FPGA build.  This differs from
the others in that it supports the Cryptech TRNG.  Note that neither
this HAL nor this FPGA build supports any cryptographic algorithms.</p></li>
</ul>

<p>All of these HAL implementations are in the <code>src/</code> directory.  See the
<code>GNUmakefile</code> for details on how to select the variant you want.</p>

<p>At present, the only relevant Cryptech cores are the TRNG and several
digest algorithms.   The current HAL uses the SHA-1, SHA-256, and
SHA-512 cores to implement the SHA-1, SHA-256, SHA-384, and SHA-512
digests.  SHA-512/224 and SHA-512/256 are not supported.</p>

<p>In principal there is no reason why one could not write a HAL which
spoke to a Terasic board, perhaps via the <code>coretest</code> protocol over a
UART, but to date this has not been done.</p>

<h2>Code import status</h2>

<p>Cryptlib itself is present in the repository in the form of a verbatim
copy of the Cryptlib 3.4.2 distribution zipfile, which the top-level
makefile unpacks while building.  This has proven simpler to work with
than importing the entire Cryptlib distribution into a vendor branch.</p>

<p>Packaging Cryptlib this way has two implications:</p>

<ul>
<li><p>You may need to <code>apt-get install unzip</code> on your Novena.</p></li>
<li><p>Any changes you might make to Cryptlib itself will be lost when you
run <code>make clean</code>.</p></li>
</ul>

<h2>Test code</h2>

<p>The <code>tests/</code> directory contains a few test scripts, written in Python,
using the standard Cryptlib Python bindings.  The Cryptlib Python
environment is a fairly literaly translation of the Cryptlib C
environment, so portions of it will be a bit, um, surprising to Python
programmers, but the basic functionality works.  Note that it's normal
for test scripts to fail when the functionality they're testing isn't
loaded on the FPGA.</p>

<h2>Copyright status</h2>

<p>Cryptlib itself is copyright by Peter Gutmann.  See the Cryptlib web
site for licensing details.</p>

<p>Code written for the Cryptech project is under the usual Cryptech
BSD-style license.</p>
}}}

[[RepositoryIndex(format=table,glob=sw/cryptlib)]]

|| Clone `https://git.cryptech.is/sw/cryptlib.git` ||