aboutsummaryrefslogtreecommitdiff
path: root/README.md
blob: 41430f17f27bbb8b3b5a46e9bd7b94e04881aecf (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59

   

keywrap

Introduction

This core implememts AES KEY WRAP as defined in RFC 3394 and the keywrap with padding according to RFC 5694

The core supports wrap/unwrap of objects up to 32 kbits in size. The core supports 128 and 256 bit keys.

Status

First complete version developed. The core does work.

The core has been simulated with two different simulators and linted.

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

Implementation details

The core implements the wrap block processing part of the AES Key Wrap as specified in chapter 2.1.1 of RFC 3394:

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)

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.

This means that SW needs to generate the 64-bit initial value of A and perform padding as meeded.

(Similarly, the core implements the unwrap processng as specifie in 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.

Due to address space limitations in the Cryptech cores (with 8-bit address space) the object storage is divided into banks (bank 0..3). Each bank supports 4096 bits. For objects lager than 4096 bits, it is the callers responsibilty to switch banks when reading and writing to the storage.