diff options
Diffstat (limited to 'raw-wiki-dump/GitRepositories%2Fcore%2Fhash%2Fsha256')
-rw-r--r-- | raw-wiki-dump/GitRepositories%2Fcore%2Fhash%2Fsha256 | 182 |
1 files changed, 182 insertions, 0 deletions
diff --git a/raw-wiki-dump/GitRepositories%2Fcore%2Fhash%2Fsha256 b/raw-wiki-dump/GitRepositories%2Fcore%2Fhash%2Fsha256 new file mode 100644 index 0000000..5892619 --- /dev/null +++ b/raw-wiki-dump/GitRepositories%2Fcore%2Fhash%2Fsha256 @@ -0,0 +1,182 @@ +{{{ +#!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>sha256</h1> + +<p>Hardware implementation of the SHA-256 cryptographic hash function. The +implementation is written in Verilog 2001 compliant code. The +implementation includes a core and a wrapper that provides a 32-bit +interface for simple integration. There is also an alternative wrapper +that implements a Wishbone compliant interface.</p> + +<p>This is a low area implementation that iterates over the rounds but +there is no sharing of operations such as adders.</p> + +<p>The hardware implementation is complemented by a functional model +written in Python.</p> + +<h2>Implementation details</h2> + +<p>The sha256 is divided into the following sections.</p> + +<ul> +<li>src/rtl - RTL source files</li> +<li>src/tb - Testbenches for the RTL files</li> +<li>src/model/python - Functional model written in python</li> +<li>doc - documentation (currently not done.)</li> +<li>toolruns - Where tools are supposed to be run. Includes a Makefile for +building and simulating the design using <a href="http://iverilog.icarus.com/">Icarus Verilog</a></li> +</ul> + +<p>The actual core consists of the following files:</p> + +<ul> +<li>sha256_core.v - The core itself with wide interfaces.</li> +<li>sha256_w_mem.v - W message block memort and expansion logic.</li> +<li>sha256_k_constants.v - K constants ROM memory.</li> +</ul> + +<p>The top level entity is called sha256_core. This entity has wide +interfaces (512 bit block input, 256 bit digest). In order to make it +usable you probably want to wrap the core with a bus interface.</p> + +<p>Unless you want to provide your own interface you therefore also need to +select one top level wrapper. There are two wrappers provided:</p> + +<ul> +<li>sha256.v - A wrapper with a 32-bit memory like interface.</li> +<li>wb_sha256.v - A wrapper that implements a <a href="http://opencores.org/opencores,wishbone">Wishbone</a> interface.</li> +</ul> + +<p><strong><em>Do not include both wrappers in the same project.</em></strong></p> + +<p>The core (sha256_core) will sample all data inputs when given the init +or next signal. the wrappers provided contains additional data +registers. This allows you to load a new block while the core is +processing the previous block.</p> + +<p>The W-memory scheduler is based on 16 32-bit registers. Thee registers +are loaded with the current block. After 16 rounds the contents of the +registers slide through the registers r5..r0 while the new W word is +inserted at r15 as well as being returned to the core.</p> + +<h2>FPGA-results</h2> + +<h3>Altera Cyclone FPGAs</h3> + +<p>Implementation results using Altera Quartus-II 13.1.</p> + +<p><strong><em>Cyclone IV E</em></strong></p> + +<ul> +<li>EP4CE6F17C6</li> +<li>3882 LEs</li> +<li>1813 registers</li> +<li>74 MHz</li> +<li>66 cycles latency</li> +</ul> + +<p><strong><em>Cyclone IV GX</em></strong></p> + +<ul> +<li>EP4CGX22CF19C6</li> +<li>3773 LEs</li> +<li>1813 registers</li> +<li>76 MHz</li> +<li>66 cycles latency</li> +</ul> + +<p><strong><em>Cyclone V</em></strong></p> + +<ul> +<li>5CGXFC7C7F23C8</li> +<li>1469 ALMs</li> +<li>1813 registers</li> +<li>79 MHz</li> +<li>66 cycles latency</li> +</ul> + +<h3>Xilinx Artix-7 FPGAs</h3> + +<p>Implementation results using Xilinx ISE 14.7 +This implementation includes pipeline regsisters.</p> + +<ul> +<li>xc7a200t-1fbg484</li> +<li>2229 Slice LUTs</li> +<li>775 Slices</li> +<li>1935 registers</li> +<li>101 MHz</li> +<li>130 cycles latency</li> +</ul> + +<h2>TODO</h2> + +<ul> +<li>Extensive verification in physical device.</li> +<li>Complete documentation.</li> +</ul> + +<h2>Status</h2> + +<p><strong><em>(2016-05-31)</em></strong></p> + +<p>The core now supports both sha224 and sha256 modes. The default mode is +sha256.</p> + +<p>NOTE: The mode bit is located in the ADDR_CTRL API register and this +means that when writing to this register to start processing a block, +care must be taken to set the mode bit to the intended mode. This means +that old code that for example simply wrote 0x01 to initiate SHA256 +processing will now initiate SHA224 processing. Writing 0x05 will +now initiate SHA256 processing.</p> + +<p>The API version has been bumped a major number to reflect this change.</p> + +<p>Regarding SHA224, it is up to the user to only read seven, not eight +words from the digest registers. The core will update the LSW too.</p> + +<p><strong><em>(2013-02-23)</em></strong></p> + +<p>Cleanup, more results etc. Move all wmem update logic to a separate +process for a cleaner code.</p> + +<p><strong>(2014-02-22)</strong></p> + +<p>Redesigned the W-memory into a sliding window solution. This not only +removed 48 32-registers but also several muxes and address decoders.</p> + +<p>The old implementation resources and performance:</p> + +<ul> +<li>9587 LEs</li> +<li>3349 registers</li> +<li>73 MHz</li> +<li>66 cycles latency</li> +</ul> + +<p>The new implementation resources and performance:</p> + +<ul> +<li>3765 LEs</li> +<li>1813 registers</li> +<li>76 MHz</li> +<li>66 cycles latency</li> +</ul> + +<p><strong>(2014-02-19)</strong> +- The core has been added to the Cryptech repo. The core comes from + https://github.com/secworks/sha256</p> +}}} + +[[RepositoryIndex(format=table,glob=core/hash/sha256)]] + +|| Clone `https://git.cryptech.is/core/hash/sha256.git` || |