[Cryptech-Commits] [core/util/keywrap] 94/95: Updated README to current status. Added section about the auto zeroise functionality that has been merged. Moved sections around to be in a (hopefully) more pedagogical order.

[git at cryptech.is]

This is an automated email from the git hooks/post-receive script.

paul at psgd.org pushed a commit to branch master
in repository core/util/keywrap.

commit 7d0ab8d8fc7c56d4256df55ab46681740b350ab6
Author: Joachim Strömbergson <joachim at assured.se>
AuthorDate: Tue Jan 29 14:53:25 2019 +0100

    Updated README to current status. Added section about the auto zeroise functionality that has been merged. Moved sections around to be in a (hopefully) more pedagogical order.
---
 README.md | 55 +++++++++++++++++++++++++++++++++++++------------------
 1 file changed, 37 insertions(+), 18 deletions(-)

diff --git a/README.md b/README.md
index 9873ae0..29d971e 100644
--- a/README.md
+++ b/README.md
@@ -13,18 +13,26 @@ The core supports 128 and 256 bit wrapping keys.
 First complete version developed. The core does work.
 
 The core has been simulated with two different simulators and
-linted.
+linted. The core has been used on the Cryptech Alpha and verified to
+work.
 
-The core has been implemented for Xilinx Artix7-t200 using ISE with the
-following results:
 
-Regs:    2906 (1%)
-Slices:  1991 (5%)
-RamB36E: 32 (8%)
-Clock:   100+ MHz
+## API
+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.
+
+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.
 
 
 ## Implementation details
+### Key Wrap
 The core implements the wrap block processing part of the AES Key Wrap
 as specified in chapter 2.1.1 of RFC 3394:
 
@@ -45,15 +53,26 @@ perform padding as meeded.
 chapter 2.2.2 of RFC 3394.)
 
 
-### API
-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.
+### Auto Zeroise
+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.
 
-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.
+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.
+
+
+## Implementation results
+The core has been implemented for Xilinx Artix7-t200 using ISE with the
+following results:
+
+Regs:    2906 (1%)
+Slices:  1991 (5%)
+RamB36E: 32 (8%)
+Clock:   100+ MH