summaryrefslogtreecommitdiff
path: root/raw-wiki-dump/GitRepositories%2Fcore%2Fmath%2Fmodexpa7
blob: c112db2a1712adaf7e1c0239f60b5bef80cb94da (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
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
{{{
#!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>ModExpA7</h1>

<h2>Core Description</h2>

<p>This core implements modular exponentiation using the Artix-7 FPGA found on CrypTech Alpha board. It can be used during RSA operations such as encryption/decryption and signing.</p>

<h2>Compile-Time Settings</h2>

<p>The core has two synthesis-time parameters:</p>

<ul>
<li><p><strong>OPERAND_ADDR_WIDTH</strong> - Sets the _largest supported_ operand width. This affects the amount of block memory that is reserved for operand storage. Largest operand width in bits, that the core can handle is 32 * (2 ** OPERAND_ADDR_WIDTH). If the largest possible modulus is 1024 bits long, set OPERAND_ADDR_WIDTH = 5. For 2048-bit moduli support set OPERAND_ADDR_WIDTH = 6, for 4096-bit capable core set OPERAND_ADDR_WIDTH = 7 and so on.</p></li>
<li><p><strong>SYSTOLIC_ARRAY_POWER</strong> - Determines the number of processing elements in the internal systolic array, total number of elements is 2 <em>* SYSTOLIC_ARRAY_POWER. This affects the number of DSP slices dedicated to parallelized multiplication. Allowed values are 1..OPERAND_ADDR_WIDTH-1, higher values produce higher performance core at the cost of higher device utilization. The number of used DSP slices is NUM_DSP = 10 + 2 * (2 + 7 * (2 *</em> SYSTOLIC_ARRAY_POWER)). Here's a quick reference table:</p></li>
</ul>

<table>
<thead>
<tr>
  <th>SYSTOLIC_ARRAY_POWER</th>
  <th>NUM_DSP</th>
</tr>
</thead>
<tbody>
<tr>
  <td>1</td>
  <td>42</td>
</tr>
<tr>
  <td>2</td>
  <td>70</td>
</tr>
<tr>
  <td>3</td>
  <td>126</td>
</tr>
<tr>
  <td>4</td>
  <td>238</td>
</tr>
<tr>
  <td>5</td>
  <td>462</td>
</tr>
</tbody>
</table>

<p>Given that Alpha board FPGA has 740 DSP slices, SYSTOLIC_ARRAY_POWER=5 is the largest possible setting. Note that if two cores are needed (eg. to do the two easier CRT exponentiations simultaneously), this parameter should be reduced to 4 to fit two cores into the device.</p>

<h2>API Specification</h2>

<p>The interface of the core is similar to other CrypTech cores. FMC memory map is split into two parts, the first part contains registers and looks like the following:</p>

<table>
<thead>
<tr>
  <th>Offset</th>
  <th>Register</th>
</tr>
</thead>
<tbody>
<tr>
  <td>0x0000</td>
  <td>NAME0</td>
</tr>
<tr>
  <td>0x0004</td>
  <td>NAME1</td>
</tr>
<tr>
  <td>0x0008</td>
  <td>VERSION</td>
</tr>
<tr>
  <td>0x0020</td>
  <td>CONTROL</td>
</tr>
<tr>
  <td>0x0024</td>
  <td>STATUS</td>
</tr>
<tr>
  <td>0x0040</td>
  <td>MODE</td>
</tr>
<tr>
  <td>0x0044</td>
  <td>MODULUS_BITS</td>
</tr>
<tr>
  <td>0x0048</td>
  <td>EXPONENT_BITS</td>
</tr>
<tr>
  <td>0x004C</td>
  <td>BUFFER_BITS</td>
</tr>
<tr>
  <td>0x0050</td>
  <td>ARRAY_BITS</td>
</tr>
</tbody>
</table>

<p>The core has the following registers:</p>

<ul>
<li><p><strong>NAME0</strong>, <strong>NAME1</strong> <br />
Read-only core name ("mode", "xp7a").</p></li>
<li><p><strong>VERSION</strong> <br />
Read-only core version, currently "0.20".</p></li>
<li><p><strong>CONTROL</strong> <br />
Register bits: <br />
[31:2] Don't care, always read as 0 <br />
[1] "next" control bit <br />
[0] "init" control bit <br />
The core uses Montgomery modular multiplier, that requires precomputation of modulus-dependent speed-up coefficient. Every time a new modulus is loaded into the core, this coefficient must be precalculated before exponentiation can be started. Changing the "init" bit from 0 to 1 starts precomputation. The core is edge-triggered, this way to start another precomputation the bit must be cleared first and then set to 1 again. The "next" control bit works the same way as the "init" bit, changing the bit from 0 to 1 triggers new exponentiation operation. The "init" bit has priority over the "next" bit, if both bits go high at the same time, precomputation will be started. When repeatedly encrypting/signing using the same modulus, precomputation needs to be done only once before the very first exponentiation.</p></li>
<li><p><strong>STATUS</strong>
Read-only register bits: <br />
[31:2] Don't care, always read as 0 <br />
[1] "valid" control bit <br />
[0] "ready" control bit <br />
The "valid" status bit is cleared as soon as the core starts exponentiation, and gets set after the operation is complete. The "ready" status bit is cleared when the core starts precomputation and is set after the speed-up coefficient is precalculated.</p></li>
<li><p><strong>MODE</strong> <br />
Mode register bits: <br />
[31:2] Don't care, always read as 0 <br />
[1] "CRT enable" control bit <br />
[0] Don't care, always read as 0 <br />
The "CRT enable" control bit allows the core to take advantage of the Chinese remainder theorem to speed up RSA operations. When the CRT mode is disabled (MODE[1] = 0), the message (base) is assumed to be as large as the modulus. When the CRT mode is enabled (MODE[1] = 1), the message is assumed to be twice larger than the modulus and the core will reduce it before starting the exponentiation. Note that if the core was compiled for eg. 4096-bit operands (OPERAND_ADDR_WIDTH=7), it can only handle up to 2048-bit moduli in CRT mode. When singing using eg. 4096-bit public key without CRT, the modulus length must be set to 4096. When signing using the same 4096-bit public key with CRT, modulus length must be set to 2048.</p>

<ul>
<li><p><strong>MODULUS_BITS</strong> <br />
Length of modulus in bits, must be a multiple of 32. Smallest allowed value is 64, largest allowed value is 32 * (2 ** OPERAND_ADDR_WIDTH). If the modulus is eg. 1000 bits wide, it must be prepended with 24 zeroes to make it contain an integer number of 32-bit words.</p></li>
<li><p><strong>EXPONENT_BITS</strong> <br />
Length of exponent in bits. Smallest allowed value is 2, largest allowed value is 32 * (2 ** OPERAND_ADDR_WIDTH).</p></li>
<li><p><strong>BUFFER_BITS</strong> <br />
Length of operand buffer in bits. This read-only parameter returns the length of internal operand buffer and allows the largest supported operand width to be determined at run-time.</p></li>
<li><p><strong>ARRAY_BITS</strong> <br />
Length of systolic array in bits. This read-only parameter returns the length of internal systolic multiplier array, it allows SYSTOLIC_ARRAY_POWER compile-time setting to be determined at run-time.</p></li>
</ul></li>
</ul>

<p>The second part of the address space contains eight operand banks.</p>

<p>Length of each bank (BANK_LENGTH) depends on the largest supported operand width: 0x80 bytes for 1024-bit core (OPERAND_ADDR_WIDTH = 5), 0x100 bytes for 2048-bit core (OPERAND_ADDR_WIDTH = 6), 0x200 bytes for 4096-bit core (OPERAND_ADDR_WIDTH = 7) and so on.</p>

<p>The offset of the second part is 8 * BANK_LENGTH: 0x400 for 1024-bit core, 0x800 for 2048-bit core, 0x1000 for 4096-bit core and so on. The core has the following eight banks:</p>

<table>
<thead>
<tr>
  <th>Offset</th>
  <th>Bank</th>
</tr>
</thead>
<tbody>
<tr>
  <td>8 * BANK_LENGTH</td>
  <td>MODULUS</td>
</tr>
<tr>
  <td>9 * BANK_LENGTH</td>
  <td>MESSAGE (BASE)</td>
</tr>
<tr>
  <td>10 * BANK_LENGTH</td>
  <td>EXPONENT</td>
</tr>
<tr>
  <td>11 * BANK_LENGTH</td>
  <td>RESULT</td>
</tr>
<tr>
  <td>12 * BANK_LENGTH</td>
  <td>MODULUS_COEFF_OUT</td>
</tr>
<tr>
  <td>13 * BANK_LENGTH</td>
  <td>MODULUS_COEFF_IN</td>
</tr>
<tr>
  <td>14 * BANK_LENGTH</td>
  <td>MONTGOMERY_FACTOR_OUT</td>
</tr>
<tr>
  <td>15 * BANK_LENGTH</td>
  <td>MONTGOMERY_FACTOR_IN</td>
</tr>
</tbody>
</table>

<p>MODULUS, MESSAGE and EXPONENT banks are read-write, the RESULT bank stores the result of the exponentiation and is read-only.</p>

<p>After precomputation the modulus-dependent speed-up coefficient and the Montgomery factor are placed in "output" MODULUS_COEFF_OUT and MONTGOMERY_FACTOR_OUT banks, the two banks are read-only. Before exponentiation corresponding modulus-dependent coefficient and Montgomery factor must be placed in "input" MODULUS_COEFF_IN and MONTGOMERY_FACTOR_IN banks, they are read-write. This split input/output banks design allows precomputed quantities to be retrieved from the core and stored along with the key for later reuse. Note that each key requires three pairs of precomputed numbers: one for the public key and two for each of the secret key components.</p>

<h2>Implementation Details</h2>

<p>The top-level core module contains:</p>

<ul>
<li>Block memory buffers for input and output operands</li>
<li>Block memory buffers for internal quantities</li>
<li>Precomputation module (Montgomery modulus-dependent speed-up coefficient)</li>
<li>Precomputation module (Montgomery parasitic power compensation factor)</li>
<li>Exponentiation module</li>
</ul>

<p>The exponentiation module contains:</p>

<ul>
<li>Buffers for storage of temporary values</li>
<li>Two modular multipliers that do right-to-left binary exponentiation (one multiplier does squaring, the other one does multiplication simultaneously)</li>
</ul>

<p>The modular multiplier module contains:</p>

<ul>
<li>Buffers for storage of temporary values</li>
<li>Wide operand loader</li>
<li>Systolic array of processing elements</li>
<li>Adder</li>
<li>Subtractor</li>
</ul>

<p>The systolic array of processing elements contains:</p>

<ul>
<li>Array of processing elements</li>
<li>Two FIFOs that accomodate carries and products</li>
</ul>

<p>Note, that the core is supplemented by a reference model written in C, that has extensive comments describing tricky corners of the underlying math.</p>

<h2>Vendor-specific Primitives</h2>

<p>CrypTech Alpha platform is based on the Xilinx Artix-7 200T FPGA, this core takes advantage of Xilinx-specific DSP slices to carry out math-intensive operations. All vendor-specific math primitives are placed under /rtl/pe/artix7/. The core also offers generic replacements under /rtl/pe/generic, they can be used for simulation with 3rd party tools, that are not aware of Xilinx-specific stuff. When porting to other architectures, only those three low-level modules need to be ported. Selection of vendor/generic primitives is done in modexpa7_primitive_switch.v. Note that if you change the latency of the processing element, the SYSTOLIC_PE_LATENCY setting in modexpa7_settings.v must be changed accordingly.</p>
}}}

[[RepositoryIndex(format=table,glob=core/math/modexpa7)]]

|| Clone `https://git.cryptech.is/core/math/modexpa7.git` ||