[Cryptech-Commits] [user/sra/pelican] 60/68: Finally get hanging text in lists mostly right
git at cryptech.is
git at cryptech.is
Mon Jul 19 22:25:39 UTC 2021
This is an automated email from the git hooks/post-receive script.
sra at hactrn.net pushed a commit to branch pelican
in repository user/sra/pelican.
commit 78b3ed35c726cf8ef0ec4c4e7753e6f4775b9001
Author: Rob Austein <sra at hactrn.net>
AuthorDate: Sun May 9 23:45:48 2021 +0000
Finally get hanging text in lists mostly right
---
pelican/content/AlphaBoardComponents.md | 10 ++--------
pelican/content/BinaryPackages.md | 20 ++++++--------------
pelican/content/BuildingFromSource.md | 6 +++---
pelican/content/CoretestHashesC5G.md | 26 +++++++++++++-------------
pelican/content/CoretestHashesNovena.md | 12 ++++++------
pelican/content/InterconnectStandards.md | 22 +++++++++++-----------
pelican/content/MiscStuff.md | 2 --
pelican/content/OpenDNSSEC.md | 2 +-
pelican/content/RoughV1.md | 2 --
pelican/content/SecureChannel.md | 13 ++++++-------
pelican/content/StateOfPlay.md | 8 ++++----
pelican/content/SunetInitialDevelopment.md | 6 +++---
pelican/content/UpgradeToKSNG.md | 3 ---
trac2md.py | 4 +++-
14 files changed, 58 insertions(+), 78 deletions(-)
diff --git a/pelican/content/AlphaBoardComponents.md b/pelican/content/AlphaBoardComponents.md
index 9cd79f6..2e005a0 100644
--- a/pelican/content/AlphaBoardComponents.md
+++ b/pelican/content/AlphaBoardComponents.md
@@ -118,9 +118,7 @@ No external RAM or Flash memories for FPGA application functionality shall be pr
* The Master Key Memory (MKM) is a serial SRAM memory.
* The MKM is connected to the FPGA with a SPI interface.
-
The MKM is connected to the Tamper Sub System with the same SPI interface.
-
* The FPGA can read and write to the memory.
* The Tamper Sub System controller can read and writeto the memory. Optionally the MISO input wire to the Tamper Sub System can be tied low by setting using a jumper. This should cause the tamper controller to only read zeros from the memory and thus only be able to write to the memory. The Tamper Sub System Controller has strict priority over the CPU. Basically an external switch between the memory, the controller and CPU.
* The MKM is powered by a separate power supply using a CR2032 cell battery. The VCC pin connected to the battery should be under control from the Tamper Sub System controller. A transistor or analog switch controlled by the Tamper Sub System controller.
@@ -144,10 +142,10 @@ Suggested components for the MKM and the switch:
* The avalanche noise entropy source should be implemented according to [existing schematics]({attach}AlphaBoardComponents/alpha_board_noise_source.pdf).
* The noise source should have a shielding can and suitable ground plane etc. to keep radiation of entropy bits as low as possible.
* The "12-15v stable" VCC should be controllable by the FPGA (enable/disable controlled by output pin on FPGA) to increase life time of components.
-
Power requirements for this VCC is < 100 mA (needs measuring, but probably < 50 mA).
+
# Processor Sub System
### CPU
@@ -196,13 +194,11 @@ The STM32 CPU supports two separate SDRAM banks. We use both of them with as big
### Real Time Clock
* Battery backed RTC with calendar/date information.
-
Connected to the CPU via serial, SPI or other interface.
-
* Suggested chip: Microchip MCP79411 or MCP79412 connected to the CPU via I2C.
-
<http://www.microchip.com/wwwproducts/Devices.aspx?product=MCP79411>
+
<http://ww1.microchip.com/downloads/en/DeviceDoc/20002266G.pdf>
This chip requires an external 32 kHz crystal.
@@ -279,9 +275,7 @@ The Tamper Sub System on the Alpha Board is simplistic and does not do a lot of
* A simple 8-bit MCU. Atmel AVR.
* Suggested chip: ATTINY828R-AU. Has 28 GPIOs which is definitely more than we've used for this design.
* The Tamper Detection Sub System Controlller may need a separate 32 kHz crystal for periodical wake up.
-
(The MCU should be able to wake up based on internal clock source.)
-
* The JTAG interface for debug and firmware download should be accessible via a header.
* The MCU should at least have four LEDs under GPIO control to allow heartbeat, status and debug signalling.
diff --git a/pelican/content/BinaryPackages.md b/pelican/content/BinaryPackages.md
index ea6788a..636551e 100644
--- a/pelican/content/BinaryPackages.md
+++ b/pelican/content/BinaryPackages.md
@@ -17,10 +17,10 @@ CPU, and AVR ATtiny828 MCU.
* Fetch and validate the repository key. Presumably you're security
-
concious (otherwise, why are you installing this stuff?), so you may
want to pay attention to what `gpg --check-sig` says here.
+
```
$ id=37A8E93F5D7E7B9A
$ wget https://apt.cryptech.is/apt-gpg-key.gpg
@@ -30,9 +30,9 @@ CPU, and AVR ATtiny828 MCU.
* Install the repository key. We used to use `apt-key(8)` for this,
-
these days the cool kids use the `/etc/apt/trusted.gpg.d/` directory:
+
```
$ sudo chown root:root apt-gpg-key.gpg
$ sudo mv apt-gpg-key.gpg /etc/apt/trusted.gpg.d/cryptech.gpg
@@ -40,36 +40,28 @@ CPU, and AVR ATtiny828 MCU.
* Configure apt to use the repository. You need to add a couple of
-
entries to `/etc/apt/source.list.d/`; which entries you need to add
depends on which distribution you're running.
-
* For Debian Stretch, do:
```
$ sudo wget -q -O /etc/apt/sources.list.d/cryptech.list http://apt.cryptech.is/sources.stretch.list
-
```
-
* For Debian Buster, do:
```
$ sudo wget -q -O /etc/apt/sources.list.d/cryptech.list http://apt.cryptech.is/sources.buster.list
-
```
-
* For Ubuntu Xenial, do:
```
$ sudo wget -q -O /etc/apt/sources.list.d/cryptech.list http://apt.cryptech.is/sources.xenial.list
-
```
-
* For Ubuntu Bionic, do:
```
$ sudo wget -q -O /etc/apt/sources.list.d/cryptech.list http://apt.cryptech.is/sources.bionic.list
-
```
+
* Update the package index.
@@ -99,10 +91,10 @@ $ sudo apt-get upgrade
* Fetch and validate the repository key. Presumably you're security
-
concious (otherwise, why are you installing this stuff?), so you may
want to pay attention to what `gpg --check-sig` says here.
+
```
$ id=37A8E93F5D7E7B9A
$ gpg --recv-key $id
@@ -127,22 +119,22 @@ $ sudo apt-get upgrade
* Check the commit signature on the cryptech-alpha package formula.
-
This is optional (Homebrew doesn't care whether you do this), but if
you want to know whether the formula was signed by the Cryptech
project, this is how to check.
+
```
$ brew log --max-count=1 --show-signature cryptech-alpha
```
* Install the `cryptech-alpha` package. At the moment, this is only
-
available as a Homebrew source package due to licensing issues in
the MacOS Xcode SDK, so the installation will probably take several
minutes, as some of the libraries are a bit slow to compile (sorry...).
+
```
$ brew install cryptech-alpha
```
diff --git a/pelican/content/BuildingFromSource.md b/pelican/content/BuildingFromSource.md
index 55a4460..0190824 100644
--- a/pelican/content/BuildingFromSource.md
+++ b/pelican/content/BuildingFromSource.md
@@ -155,21 +155,21 @@ their tools do run on Debian and Ubuntu. A few caveats:
* Debian and Ubuntu symlink `/bin/sh` to `/bin/dash`, which can't handle
-
some of the syntax used in XiLinx's shell scripts, so you'll need to
change that symlink to point to `/bin/bash`.
-* Although the XiLinx software can be installed as user or root, by
+* Although the XiLinx software can be installed as user or root, by
default it wants to install into /opt/Xilinx, so you need to install
as root if you want to do that.
-* The XiLinx tools are disk hogs, so if you're building a VM for this,
+* The XiLinx tools are disk hogs, so if you're building a VM for this,
you'll probably want to give it at least 30-40 GB of disk space.
+
Step-by-step installation:
1. Unpack `Xilinx_ISE_DS_Lin_14.7_1015_1.tar` (or whatever version you have).
diff --git a/pelican/content/CoretestHashesC5G.md b/pelican/content/CoretestHashesC5G.md
index 381fba8..117fd6c 100644
--- a/pelican/content/CoretestHashesC5G.md
+++ b/pelican/content/CoretestHashesC5G.md
@@ -49,18 +49,18 @@ interface connected to a FPGA device. The subsystem consists of:
- [coretest](https://git.cryptech.is/core/coretest): A command parser that accepts read/write commands from a
-
host, executes the commands and sends the response.
+
- [uart](https://git.cryptech.is/core/usrt): A simple serial interface that connects coretest to the host.
- [coretest_hashes](https://git.cryptech.is/core/coretest_hashes): A top level wrapper that connects all the cores as
-
well as connecting the rxd and txd ports on the uart to external pins as well as clk and reset. This core repo also contains the Python command line program hash_tester we will be using to talk to coretester and perform tests of the sha1 and sha256 cores.
+
*The coretest_hashes subsystem with sha1 and sha256 cores. The system is connected to a host computer via a serial interface.*
@@ -157,18 +157,18 @@ sha1.v sha1_core.v sha1_w_mem.v
These files are:
- sha1.v: A top level wrapper that provides an interface to the core. In
-
this case a 32-bit memory like interface.
+
- sha1_core.v: The actual SHA-1 hash function core.
- sha1_w_mem.v: The W memory including sliding window functionality used
-
by the core.
+
The other cores follows a similar pattern with a top level wrapper named
<core_name>.v, the main functionality in <core_name>_core.v and then one
or more submodules.
@@ -177,24 +177,24 @@ or more submodules.
## Creating the project in Quartus
- Start Quartus and select file/new... and select New Quartus II
-
Project.
-- Select destination directory to be toolruns/ in your project
+- Select destination directory to be toolruns/ in your project
directory.
+
- Set 'coretest_hashes' as name of the project
- Set 'coretest_hashes' as nem of the top level design entity. (Should be
-
done automatically when entering the name of the project.)
+
- Press next.
@@ -208,32 +208,32 @@ or more submodules.
- Select coretest and press 'Open'. (Note: Quartus seems to sometimes omit the .v suffix
-
for the files depending on Windows/OS version.)
-- Back on the 'Add Files' page. Press Add to actually add coretest to
+- Back on the 'Add Files' page. Press Add to actually add coretest to
the project.
-- Press '...' again and navigate to the rtl directory in
+- Press '...' again and navigate to the rtl directory in
coretest_hashes. Add it like you did with coretest.
-- Navigate to test_coretest_hashes/cores/sha1/src/rtl and add the files sha1, sha1_core,
+- Navigate to test_coretest_hashes/cores/sha1/src/rtl and add the files sha1, sha1_core,
sha1_w_mem. This time you don't need to press 'Add' on the 'Add
Files'. It is done automatically when adding more than one file at a
time.
-- Navigate to test_coretest_hashes/cores/sha256/src/rtl and add the files sha256, sha256_core,
+- Navigate to test_coretest_hashes/cores/sha256/src/rtl and add the files sha256, sha256_core,
sha256_k_constants, sha256_w_mem. Do **NOT** add the file wb_sha256. This file contains an alternative top level wrapper to the one in sha256.v that instead provides a [WISHBONE](http://opencores.org/opencores,wishbone) interface. This interface is not used in the coretest_hashes design.
+
- Finally navigate to test_coretest_hashes/cores/uart/src/rtl and add uart, uart_core.
@@ -293,10 +293,10 @@ also a pin list available in the coretest_hashes directory.
- The file coretest_hashes.qsf contains assignments for a project like
-
the one we are setting up. It contains the pin assignments. The
follwing list is a slightly cleaned up version of the pin assignments:
+
```
set_location_assignment PIN_R20 -to clk
set_location_assignment PIN_P11 -to reset_n
diff --git a/pelican/content/CoretestHashesNovena.md b/pelican/content/CoretestHashesNovena.md
index f761f4c..54024cf 100644
--- a/pelican/content/CoretestHashesNovena.md
+++ b/pelican/content/CoretestHashesNovena.md
@@ -46,25 +46,25 @@ I2C serial bus. The subsystem consists of:
- [sha256](https://git.cryptech.is/core/sha256): A HW implementation of the SHA-256 hash
-
function.
-- [sha512](https://git.cryptech.is/core/sha512): A HW implementation of the SHA-512 hash
+- [sha512](https://git.cryptech.is/core/sha512): A HW implementation of the SHA-512 hash
function.
-- [coretest](https://git.cryptech.is/core/coretest): A command parser that accepts read/write
+- [coretest](https://git.cryptech.is/core/coretest): A command parser that accepts read/write
commands from a host, executes the commands and sends the response.
-- [i2c](https://git.cryptech.is/core/i2c): A serial interface that connects coretest to the
+- [i2c](https://git.cryptech.is/core/i2c): A serial interface that connects coretest to the
host.
+
- [novena](https://git.cryptech.is/core/novena): A top-level wrapper that connects all
the cores, and connects i2c to external pins as well as clk and
@@ -89,16 +89,16 @@ install, but with a few extra notes:
- ISE Design Suite uses a graphical installer, so has to be installed
-
on a desktop edition, not a server edition.
-- Although the software can be installed as user or root, by default
+- Although the software can be installed as user or root, by default
it wants to install into `/opt/Xilinx`, so you need to install as root
if you want to do that.
+
- The Xilinx tools are disk hogs, so if you're building a VM for this, you'll probably want to give it at least 30-40 GB of disk space.
diff --git a/pelican/content/InterconnectStandards.md b/pelican/content/InterconnectStandards.md
index de0e81c..4ce1c83 100644
--- a/pelican/content/InterconnectStandards.md
+++ b/pelican/content/InterconnectStandards.md
@@ -28,29 +28,29 @@ system. Typical differences are:
- Intelligence. Simple master-slave read/write access or DMA-transfers,
-
coherence support etc.
- - point to point or point to multipoint. Basically bus based or switch
+ - point to point or point to multipoint. Basically bus based or switch
fabric.
+
There are also non-technical differences:
- Licensing and pricing. Does using a standard add monetary cost and
-
does using the standard infer restrictions in sharing, disclosure of
source code?
- - Market share. The market share is primarily interesting as basis for
+ - Market share. The market share is primarily interesting as basis for
the availability of other cores that could be integrated.
+
## Description of Standards
### AMBA
@@ -64,26 +64,26 @@ AMBA currently contains four main interconnect types:
- APB. A simple register read/write bus used to connect simpler
-
devices such as timers, IRQ handlers, slow serial I/O such as UARTS
and GPIO interfaces. The peripherals are connected to a common bus
with a single master.
- - AHB. A more advanced bus based interconnect. Supports more complex
+ - AHB. A more advanced bus based interconnect. Supports more complex
data transfers of up to 1 kByte data. Supports multiple masters.
- - AXI. A switch fabric based interconnect that supports multiple
+ - AXI. A switch fabric based interconnect that supports multiple
parallel transfers, multiple masters etc.
- - ACE. A low latency interconnect that supports cache coherency to
+ - ACE. A low latency interconnect that supports cache coherency to
allow the design of multicore, multiprocessor systems on-chip.
+
(There are also additional protocols in the AMBA specification for
things like tracing etc.)
@@ -98,19 +98,19 @@ different AMBA interconnect types.
Pros:
- Technically advanced and covers a wide range of system
-
requirements.
+
- A huge user base.
- A huge selection of third party support in terms of tools as well as
-
cores. Most of these cores and tools are commercial and proprietary,
closed source.
+
Cons:
- Licensing. Would Cryptech need to get a license?
@@ -153,11 +153,11 @@ Cons:
- Low support from open and proprietary third party suppliers of tools
-
and cores.
+
### CoreConnect
CoreConnect [(8)](#fn8) is an interconnect standard initially developed by
IBM. The standard is now used by several vendors, for example the
diff --git a/pelican/content/MiscStuff.md b/pelican/content/MiscStuff.md
index b4d3038..dd034f9 100644
--- a/pelican/content/MiscStuff.md
+++ b/pelican/content/MiscStuff.md
@@ -27,9 +27,7 @@ Advisory board, reviewers etc.
* [Remote timing attacks are practical](https://crypto.stanford.edu/~dabo/pubs/abstracts/ssl-timing.html), D. Boneh and D. Brumley.
* [Common Critiera Security Target for the AEP Keyper](http://www.cybersecurity.my/mycc/document/mycpr/C037/AEP_Keyper_EAL4_ASE_1.3.pdf)
* [Cryptographic hardware: how to make it cool, fast and unbreakable](https://www.cosic.esat.kuleuven.be/ches2012/tutorials.shtml),
-
Junfeng Fan, KU Leuven
-
* [REC FPGA Seminar IAP 1998](http://web.mit.edu/bunnie/www/xi/rec.html), Bunnie Huang
* [the formal verification of realistic compilers usable for critical embedded software](http://compcert.inria.fr/)
diff --git a/pelican/content/OpenDNSSEC.md b/pelican/content/OpenDNSSEC.md
index 3d1996f..5150f26 100644
--- a/pelican/content/OpenDNSSEC.md
+++ b/pelican/content/OpenDNSSEC.md
@@ -10,9 +10,9 @@ Modified: 2017-05-13 21:34
- A Cryptech Alpha board, preferrably revision "rev03"
- APT on the host system configured to find packages in the Cryptech
-
repository, see [BinaryPackages]({filename}BinaryPackages.md) for instructions
+
```
apt-get install cryptech-alpha opendnssec opensc
```
diff --git a/pelican/content/RoughV1.md b/pelican/content/RoughV1.md
index b52a3cf..c6bb597 100644
--- a/pelican/content/RoughV1.md
+++ b/pelican/content/RoughV1.md
@@ -121,11 +121,9 @@ Verilog.
* What components we ship - life is compromise
* Toolchains, Verilog, C, ...
* FPGAs and ASICs use a Verilog-based toolchain. There are no mature open
-
Verilog compilers so the [DDC approach](http://www.dwheeler.com/trusting-trust/)
will not work. Net-list optimization is also an issue. We're looking into this,
but it's going to be really hard. Research for v2.
-
* Protoyping platform
* [Bunnie's Novena laptop](http://www.bunniestudios.com/blog/?p=3265)
* Altera Evaluation Board
diff --git a/pelican/content/SecureChannel.md b/pelican/content/SecureChannel.md
index 3f6f1b5..7469716 100644
--- a/pelican/content/SecureChannel.md
+++ b/pelican/content/SecureChannel.md
@@ -20,41 +20,40 @@ Basic design goals:
* Not require yet another presentation layer if we can avoid it (so,
-
reuse XDR if possible, unless we have some strong desire to switch
to something else).
+
* Provide end-to-end message integrity between client library and HSM.
* Provide end-to-end message confidentiality between client library
-
and HSM. We only need this for a few operations, but between PINs
and private keys it would be simpler just to provide it all the time
than to be selective.
-* Provide some form of mutual authentication between client library
+* Provide some form of mutual authentication between client library
and HSM. This is tricky, since it requires either configuration (of
the other party's authenticator) or leap-of-faith. Leap-of-faith is
probably good enough for most of what we really care about (insuring
that we're talking to the same dog now as we were earlier).
+
Not 100% certain we need this at all, but if we're going to leave
ourselves wide open to monkey-in-the-middle attacks, there's not
much point in having a secure channel at all.
* Use boring simple crypto that we already have (or almost have) and
-
which runs fast.
-* Continue to support multiplexer. Taken together with end-to-end
+* Continue to support multiplexer. Taken together with end-to-end
message confidentiality, this may mean two layers of headers: an
outer set which the multiplexer is allowed to mutate, then an inner
set which is protected. Better, though, would be if the multiplexer
@@ -62,10 +61,11 @@ Basic design goals:
anything.
-* Simple enough that we can implement it easily in HSM, PKCS #11
+* Simple enough that we can implement it easily in HSM, PKCS #11
library, and Python library.
+
## Why not TLS?
We could, of course, Just Use TLS. Might end up doing that, if it
@@ -176,7 +176,6 @@ doing at all, etc. Maybe clients just shouldn't do that.
* The Cryptography Engineering protocols include a hack to work around
-
a length extension weakness in SHA-2 (see section 5.4.2). Do we
need this? Would we be better off using SHA-3 instead? The book
claims that SHA-3 was expected to fix this, but that was before NIST
diff --git a/pelican/content/StateOfPlay.md b/pelican/content/StateOfPlay.md
index cf0aa01..31075e0 100644
--- a/pelican/content/StateOfPlay.md
+++ b/pelican/content/StateOfPlay.md
@@ -57,15 +57,15 @@ rather than attempting to use the [XiLinx]({filename}XiLinx.md) GUI environment.
* `core/novena` builds the current set of digest cores into a
-
framework that uses the "coretest" byte stream protocol over an I2C
bus.
-* `core/novena_i2c_simple` builds the current set of digest cores into
+* `core/novena_i2c_simple` builds the current set of digest cores into
a framework that uses a simplfied write()/read() API over an I2C bus.
+
There's a third build, `core/novena_eim`, which was only just updated
today, and which is reported as not quite stable yet. Will try
building it soon and report here.
@@ -111,15 +111,15 @@ than a few makefile tricks, are:
* A set of HALs that make use of the `core/novena` and
-
`core/novena_i2c_simple` FPGA builds, using the Linux /dev/i2c
device interface; and
-* Another Python script to test the resulting Cryptlib build, using
+* Another Python script to test the resulting Cryptlib build, using
the stock Cryptlib Python bindings.
+
No HAL for `core/novena_eim` yet.
The Cryptlib Python bindings build kind of slowly on the Novena, sorry
diff --git a/pelican/content/SunetInitialDevelopment.md b/pelican/content/SunetInitialDevelopment.md
index 4ff0580..6fea985 100644
--- a/pelican/content/SunetInitialDevelopment.md
+++ b/pelican/content/SunetInitialDevelopment.md
@@ -16,10 +16,10 @@ DONE. We have a Terasic DE0 board and a Terasic Cyclone V GX starter kit board.
- Create a working development and verification flow from RTL design
-
downto FPGA.
+
- Verify the functionality of the SHA-256 core in a physical FPGA.
@@ -30,10 +30,10 @@ DONE. We have a Terasic DE0 board and a Terasic Cyclone V GX starter kit board.
- Large enough to test sub systems and possibly a complete HSM.
- Good external interfaces for communication with host systems.
- Good external interfaces to entropy sources, memories,
-
GPIO. Arduino Shields would be good.
+
- Create a survey on interconnect standards usable for Cryptech
- Availability and market share/usage in third party cores.
- License
@@ -43,11 +43,11 @@ DONE. We have a Terasic DE0 board and a Terasic Cyclone V GX starter kit board.
- Create base coretest functionality to allow testing of cores in the
-
FPGA on the development board. Read and write access to registers
over a known communication channel.
+
- Verify the development flow from Verilog RTL downto FPGA.
diff --git a/pelican/content/UpgradeToKSNG.md b/pelican/content/UpgradeToKSNG.md
index cd6e1fc..87288b6 100644
--- a/pelican/content/UpgradeToKSNG.md
+++ b/pelican/content/UpgradeToKSNG.md
@@ -188,10 +188,7 @@ if anybody needs it, but the short version is:
* Open up the Alpha's case, take the board out.
* Connect the programmer and power the board back up.
* Use the `flash-target` script from the `sw/stm32` repository to
-
stuff the `hsm.elf` and `bootloader.elf` files from the binary
firmware tarball into the HSM.
-
* Power down, disconnect the programmer, put the Alpha back in its
-
case, done.
diff --git a/trac2md.py b/trac2md.py
index 37c70ba..98374ce 100755
--- a/trac2md.py
+++ b/trac2md.py
@@ -164,17 +164,19 @@ class Trac2Markdown:
prev_indent = 0
in_list = True
indent = len(line) - len(nested_line)
+ text_indent = len(line) - len(nested_line[1:].lstrip())
if indent > prev_indent:
nested_level += 1
elif indent < prev_indent:
nested_level -= 1
prev_indent = indent
line = ' ' * nested_level + nested_line
- elif in_list:
+ elif in_list and len(line) < len(nested_line) + text_indent:
new_content.append("\n")
in_list = False
nested_level = 0
prev_indent = 0
+ text_indent = 0
# Convert headers
line = self.convert_headers(line)
More information about the Commits
mailing list