diff options
Diffstat (limited to 'raw-wiki-dump/GitRepositories%2Fuser%2Fjs%2Fkeywrap.trac')
| -rw-r--r-- | raw-wiki-dump/GitRepositories%2Fuser%2Fjs%2Fkeywrap.trac | 96 |
1 files changed, 0 insertions, 96 deletions
diff --git a/raw-wiki-dump/GitRepositories%2Fuser%2Fjs%2Fkeywrap.trac b/raw-wiki-dump/GitRepositories%2Fuser%2Fjs%2Fkeywrap.trac deleted file mode 100644 index 2eea765..0000000 --- a/raw-wiki-dump/GitRepositories%2Fuser%2Fjs%2Fkeywrap.trac +++ /dev/null @@ -1,96 +0,0 @@ -{{{ -#!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` || |