From b092ffbcbe2c9398494f7dc9db6f0796971633e0 Mon Sep 17 00:00:00 2001
From: Rob Austein <sra@hactrn.net>
Date: Sun, 13 Sep 2020 23:04:30 +0000
Subject: Import Cryptech wiki dump

---
 .../GitRepositories%2Fuser%2Fjs%2Fkeywrap          | 96 ++++++++++++++++++++++
 1 file changed, 96 insertions(+)
 create mode 100644 raw-wiki-dump/GitRepositories%2Fuser%2Fjs%2Fkeywrap

(limited to 'raw-wiki-dump/GitRepositories%2Fuser%2Fjs%2Fkeywrap')

diff --git a/raw-wiki-dump/GitRepositories%2Fuser%2Fjs%2Fkeywrap b/raw-wiki-dump/GitRepositories%2Fuser%2Fjs%2Fkeywrap
new file mode 100644
index 0000000..2eea765
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Fuser%2Fjs%2Fkeywrap
@@ -0,0 +1,96 @@
+{{{
+#!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>keywrap</h1>
+
+<h2>Introduction</h2>
+
+<p>This core implememts AES KEY WRAP as defined in <a href="https://tools.ietf.org/html/rfc3394">RFC
+3394</a> and the keywrap with padding
+according to <a href="https://tools.ietf.org/html/rfc5649">RFC 5694</a></p>
+
+<p>The core supports wrap/unwrap of objects up to 64 kByte in size.
+The core supports 128 and 256 bit wrapping keys.</p>
+
+<h2>Status</h2>
+
+<p>First complete version developed. The core does work.</p>
+
+<p>The core has been simulated with two different simulators and
+linted. The core has been used on the Cryptech Alpha and verified to
+work.</p>
+
+<h2>API</h2>
+
+<p>Objects to be processed are written in word order (MSB words). The
+caller writes the calculated magic value to the A regsisters in word
+order. The caller also needs to write the number of blocks (excluding
+magic block) into the RLEN register. Finally the caller needs to write
+the wrapping key.</p>
+
+<p>Due to address space limitations in the Cryptech cores (with 8-bit
+address space) the object storage is divided into banks [0 .. 127]. Each
+bank supports 128 32-bit words or 4096 bits. For objects lager than 4096
+bits, it is the callers responsibilty to switch banks when reading and
+writing to the storage.</p>
+
+<h2>Implementation details</h2>
+
+<h3>Key Wrap</h3>
+
+<p>The core implements the wrap block processing part of the AES Key Wrap
+as specified in chapter 2.1.1 of RFC 3394:</p>
+
+<p>For j = 0 to 5
+           For i=1 to n
+               B = AES(K, A | R[i])
+               A = MSB(64, B) ^ t where t = (n*j)+i
+               R[i] = LSB(64, B)</p>
+
+<p>The core does not perform the calculation of the magic value, which is
+the initial value of A. The core also does not perform padding om the
+message to an even 8 byte block.</p>
+
+<p>This means that SW needs to generate the 64-bit initial value of A and
+perform padding as meeded.</p>
+
+<p>(Similarly, the core implements the unwrap processng as specifie in
+chapter 2.2.2 of RFC 3394.)</p>
+
+<h3>Auto Zeroise</h3>
+
+<p>The core implements an auto zeroise functionality for secret key. This
+means that any loaded wrapping key will automatically be wiped from all
+registers storing key information after a specified timeout. Timeout
+countdown is halted when the core is performing any wrap/unwrap operation,
+and the timeout is reset to its defined start value after an operation
+has been completed.</p>
+
+<p>SW can set the timout value (in cycles), SW can also inspect the key
+status and timeout status. Reading status also triggers a reset of the
+timeout counter. This allows SW to keep a loaded key alive by simply
+checking status. Finally SW can actively trigger a key zeroisation
+operation.</p>
+
+<h2>Implementation results</h2>
+
+<p>The core has been implemented for Xilinx Artix7-t200 using ISE with the
+following results:</p>
+
+<p>Regs:    2906 (1%)
+Slices:  1991 (5%)
+RamB36E: 32 (8%)
+Clock:   100+ MH</p>
+}}}
+
+[[RepositoryIndex(format=table,glob=user/js/keywrap)]]
+
+|| Clone `https://git.cryptech.is/user/js/keywrap.git` ||
-- 
cgit v1.2.3