From 891730d13b324fad916572a82f0bd610c5de9aad Mon Sep 17 00:00:00 2001
From: Rob Austein <sra@hactrn.net>
Date: Sun, 13 Sep 2020 23:06:24 +0000
Subject: Rename for conversion

---
 ...GitRepositories%2Fuser%2Fshatov%2Fecdsa256.trac | 102 +++++++++++++++++++++
 1 file changed, 102 insertions(+)
 create mode 100644 raw-wiki-dump/GitRepositories%2Fuser%2Fshatov%2Fecdsa256.trac

(limited to 'raw-wiki-dump/GitRepositories%2Fuser%2Fshatov%2Fecdsa256.trac')

diff --git a/raw-wiki-dump/GitRepositories%2Fuser%2Fshatov%2Fecdsa256.trac b/raw-wiki-dump/GitRepositories%2Fuser%2Fshatov%2Fecdsa256.trac
new file mode 100644
index 0000000..417cbf8
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Fuser%2Fshatov%2Fecdsa256.trac
@@ -0,0 +1,102 @@
+{{{
+#!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>ecdsa256</h1>
+
+<h2>Core Description</h2>
+
+<p>This core implements the scalar base point multiplier for ECDSA curve P-256. It can be used during generation of public keys, the core can also be used as part of the signing operation. </p>
+
+<h2>API Specification</h2>
+
+<p>The core interface is similar to other Cryptech cores. FMC memory map looks like the following:</p>
+
+<p><code>0x0000 | NAME0</code>
+<code>0x0004 | NAME1</code>
+<code>0x0008 | VERSION</code></p>
+
+<p><code>0x0020 | CONTROL</code>
+<code>0x0024 | STATUS</code></p>
+
+<p><code>0x0080 | K0</code>
+<code>0x0084 | K1</code>
+<code>...</code>
+<code>0x009C | K7</code>
+<code>0x00A0 | X0</code>
+<code>0x00A4 | X1</code>
+<code>...</code>
+<code>0x00BC | X7</code>
+<code>0x00C0 | Y0</code>
+<code>0x00C4 | Y1</code>
+<code>...</code>
+<code>0x00DC | Y7</code></p>
+
+<p>The core has the following registers:</p>
+
+<ul>
+<li><p><strong>NAME0</strong>, <strong>NAME1</strong>
+Read-only core name ("ecdsa256").</p></li>
+<li><p><strong>VERSION</strong>
+Read-only core version, currently "0.11".</p></li>
+<li><p><strong>CONTROL</strong>
+Control register bits:
+[31:2] Don't care, always read as 0
+[1] "next" control bit
+[0] Don't care, always read as 0
+The core starts multiplication when the "next" control bit changes from 0 to 1. This way when the bit is set, the core will only perform one multiplication and then stop. To start another operation, the bit must be cleared at first and then set to 1 again.</p></li>
+<li><p><strong>STATUS</strong>
+Read-only status register bits:
+[31:2] Don't care, always read as 0
+[1] "valid" control bit
+[0] "ready" control bit (always read as 1)
+The "valid" control bit is cleared as soon as the core starts operation, and gets set after the multiplication operations is complete. Note, that unlike some other Cryptech cores, this core doesn't need any special initialization, so the "ready" control bit is simply hardwired to always read as 1. This is to keep general core interface consistency.</p></li>
+<li><p><strong>K0</strong>-<strong>K7</strong>
+Buffer for the 256-bit multiplication factor (multiplier) K. The core will compute Q = K * G (the base point G is the multiplicand). K0 is the least significant 32-bit word of K, i.e. bits [31:0], while K7 is the most significant 32-bit word of K, i.e. bits [255:224].</p></li>
+<li><p><strong>X0</strong>-<strong>X7</strong>, <strong>Y0</strong>-<strong>Y7</strong>
+Buffers for the 256-bit coordinates X and Y of the product Q = K * G. Values are returned in affine coordinates. X0 and Y0 contain the least significant 32-bit words, i.e. bits [31:0], while X7 and Y7 contain the most significant 32-bit words, i.e. bits [255:224].</p></li>
+</ul>
+
+<h2>Implementation Details</h2>
+
+<p>The top-level core module contains block memory buffers for input and output operands and the base point multiplier, that reads from the input buffer and writes to the output buffers.</p>
+
+<p>The base point multiplier itself consists of the following:</p>
+
+<ul>
+<li>Buffers for storage of temporary values</li>
+<li>Configurable "worker" unit</li>
+<li>Microprograms for the worker unit</li>
+<li>Multi-word mover unit</li>
+<li>Modular inversion unit</li>
+</ul>
+
+<p>The "worker" unit can execute five basic operations:</p>
+
+<ul>
+<li>comparison</li>
+<li>copying</li>
+<li>modular addition</li>
+<li>modular subtraction</li>
+<li>modular multiplications</li>
+</ul>
+
+<p>There are two primary microprograms, that the worker runs: curve point doubling and addition of curve point to the base point. Those microprograms use projective Jacobian coordinates, so one more microprogram is used to convert the product into affine coordinates with the help of modular inversion unit.</p>
+
+<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 Xilinx Artix-7 200T FPGA, so this core takes advantage of Xilinx-specific DSP slices to carry out math-intensive operations. All vendor-specific math primitives are placed under /rtl/lowlevel/artix7, the core also offers generic replacements under /rtl/lowlevel/generic, they can be used for simulation with 3rd party tools, that are not aware of Xilinx-specific stuff. Selection of vendor/generic primitives is done in ecdsa_lowlevel_settings.v, when porting to other architectures, only those four low-level modules need to be ported.</p>
+}}}
+
+[[RepositoryIndex(format=table,glob=user/shatov/ecdsa256)]]
+
+|| Clone `https://git.cryptech.is/user/shatov/ecdsa256.git` ||
-- 
cgit v1.2.3