[Cryptech-Commits] [wiki] 75/75: A lot of minor cleanup
git at cryptech.is
git at cryptech.is
Fri Oct 8 18:52:41 UTC 2021
This is an automated email from the git hooks/post-receive script.
sra at hactrn.net pushed a commit to branch production
in repository wiki.
commit b2f9504254a3d4894d4f9a8b13f4cdbcb26fa395
Author: Rob Austein <sra at hactrn.net>
AuthorDate: Fri Oct 8 14:39:03 2021 -0400
A lot of minor cleanup
---
GNUmakefile | 11 +-
content/ASICImplementations.md | 6 +-
content/AlphaBoard.md | 7 +-
content/AlphaBoardComponents.md | 9 +-
content/AlphaBoardPictures.md | 10 +-
content/AlphaBoardStrategy.md | 4 +-
content/AlphaReviewLog.md | 298 +++++++++----------------------
content/AlphaSchematics.md | 4 +-
content/AlphaSealedBags.md | 8 +-
content/AssuredTooChain.md | 6 +-
content/BerlinWorkshop.md | 7 +-
content/BinaryPackages.md | 8 +-
content/BuildingFromSource.md | 8 +-
content/CoretestHashesC5G.md | 117 ++++++------
content/CoretestHashesNovena.md | 6 +-
content/DNSSEC-Requirements.md | 2 +-
content/DNSSEC.md | 5 +-
content/Dashboard.md | 4 +-
content/DevBridgeBoard.md | 7 +-
content/DevelopersGuide.md | 7 +-
content/DisasterRecovery.md | 6 +-
content/DocMeet.md | 5 +-
content/Documents.md | 14 +-
content/EDAToolchainSurvey.md | 15 +-
content/ExternalProjects.md | 3 +-
content/ExternalProjectsTorHSM.md | 6 +-
content/GettingStartedNovena.md | 8 +-
content/Hardware.md | 5 +-
content/InterconnectStandards.md | 4 +-
"content/Joachim Str\303\266mbergson.md" | 5 +-
content/MailingLists.md | 7 +-
content/MiscStuff.md | 4 +-
content/NoisyDiode.md | 6 +-
content/OpenCryptoChip.md | 6 +-
content/OpenDNSSEC.md | 7 +-
content/PKCS11Proxy.md | 4 +-
content/Pelican.md | 15 ++
content/PostAlphaPlan.md | 4 +-
content/PrahaWorkshop.md | 7 +-
content/PrahaWorkshopSSH.md | 6 +-
content/ProjectArchive.md | 4 +-
content/ProjectManagement.md | 4 +-
content/ProjectMetadata.md | 5 +-
content/ProjectStatus.md | 5 +-
content/QuickStart.md | 11 +-
content/RandomnessTesting.md | 6 +-
content/RelatedWork.md | 4 +-
content/ReleaseNotes.md | 12 +-
content/Requirements.md | 4 +-
content/RoughV1.md | 8 +-
content/SecureChannel.md | 7 +-
content/SideChannel.md | 6 +-
content/StateOfPlay.md | 10 +-
content/SunetInitialDevelopment.md | 5 +-
content/TRNGDevelopment.md | 6 +-
content/UpgradeToKSNG.md | 9 +-
content/Upgrading.md | 8 +-
content/UsingSTLink.md | 6 +-
content/WhoWeAre.md | 51 +++---
content/WikiStart.md | 6 +-
content/trac-to-pelican-home.md | 35 ----
pelicanconf.py | 2 +-
62 files changed, 312 insertions(+), 573 deletions(-)
diff --git a/GNUmakefile b/GNUmakefile
index 25cd904..36b12d7 100644
--- a/GNUmakefile
+++ b/GNUmakefile
@@ -1,4 +1,3 @@
-HERE := $(dir $(abspath $(lastword $(MAKEFILE_LIST))))
HTTP_HOST := $(shell hostname -f)
HTTP_PORT := 8000
@@ -6,6 +5,9 @@ HTTP_PORT := 8000
all:
pelican --output website --settings pelicanconf.py --fatal errors content
+clean:
+ git clean -dfx
+
server:
@echo http://${HTTP_HOST}:${HTTP_PORT}/
python3 -m http.server --directory website --bind ${HTTP_HOST} ${HTTP_PORT}
@@ -13,4 +15,9 @@ server:
check:
linkchecker website
-.PHONY: all server check
+tags: TAGS
+
+TAGS: GNUmakefile pelicanconf.py $(shell git ls-tree -r --name-only HEAD | egrep '[.]md$$')
+ etags $^
+
+.PHONY: all clean server check tags
diff --git a/content/ASICImplementations.md b/content/ASICImplementations.md
index ba997c7..a5ff4a6 100644
--- a/content/ASICImplementations.md
+++ b/content/ASICImplementations.md
@@ -1,8 +1,6 @@
-Title: ASICImplementations
-Author: trac
+Title: Development of a Cryptech ASIC Implementation
Date: 2016-12-15 22:44
-
-# Development of a Cryptech ASIC Implementation
+Category: FutureWork
## Introduction
The aim of the Cryptech project is to develop an open, free, and
diff --git a/content/AlphaBoard.md b/content/AlphaBoard.md
index f0e0f1a..828e64e 100644
--- a/content/AlphaBoard.md
+++ b/content/AlphaBoard.md
@@ -1,9 +1,8 @@
-Title: AlphaBoard
-Author: joachims
+Title: Alpha Board
+Author: Joachim Strömbergson
Date: 2016-12-15 22:39
Modified: 2019-01-22 08:46
-
-# Alpha Board
+Category: AlphaBoard
## Rev 02
diff --git a/content/AlphaBoardComponents.md b/content/AlphaBoardComponents.md
index 39eb30e..b963bb8 100644
--- a/content/AlphaBoardComponents.md
+++ b/content/AlphaBoardComponents.md
@@ -1,8 +1,9 @@
-Title: AlphaBoardComponents
-Author: trac
-Date: 2016-12-15 22:43
+Title: CrypTech Alpha Board BOM and PCB design requirement sketch
+Authors: Joachim Strömbergson, Fredrik Thulin
+Date: 2015-03-09
+Modified: 2015-03-25
+Category: AlphaBoard
-# CrypTech Alpha Board BOM and PCB design requirement sketch
This document contains a list of component level description and requirements for the Crypteh Alpha board.<br/>
The document is to be used as a BOM (Bill Of Materials) and PCB design requirement description for discussing with PCB designers on what we want to have designed.<br/>
The block diagram for the Alpha board can be seen at: [Hardware]({filename}Hardware.md)
diff --git a/content/AlphaBoardPictures.md b/content/AlphaBoardPictures.md
index 41fe3f6..072a704 100644
--- a/content/AlphaBoardPictures.md
+++ b/content/AlphaBoardPictures.md
@@ -1,17 +1,17 @@
-Title: AlphaBoardPictures
-Author: sra
+Title: High resolution pictures of the Alpha board
+Author: Rob Austein
Date: 2016-12-15 22:44
Modified: 2017-05-19 17:49
-
-
-## High resolution pictures of the Alpha board
+Category: AlphaBoard
Attached to this page are high resolution pictures.
The current revision of the Alpha board is rev03.
rev01 was the board known as the 'dev-bridge'.
+
rev02 was functionally the same as the rev03, but in another form factor.
+
diff --git a/content/AlphaBoardStrategy.md b/content/AlphaBoardStrategy.md
index 22a78fd..0f6ae6c 100644
--- a/content/AlphaBoardStrategy.md
+++ b/content/AlphaBoardStrategy.md
@@ -1,6 +1,6 @@
-Title: AlphaBoardStrategy
-Author: trac
+Title: Alpha Board Strategy
Date: 2016-12-15 22:43
+Category: AlphaBoard
# The Cryptech Alpha Board
diff --git a/content/AlphaReviewLog.md b/content/AlphaReviewLog.md
index 17a2998..fe28367 100644
--- a/content/AlphaReviewLog.md
+++ b/content/AlphaReviewLog.md
@@ -1,210 +1,115 @@
-Title: AlphaReviewLog
-Author: trac
+Title: Review feedback of the Alpha schematics
Date: 2016-12-15 22:43
-
-# Review feedback of the Alpha schematics
+Category: AlphaBoard
## Power subsystem
-|Comment |Who |Resolution |Status |
-|---|---|---|---|
-|The LTS3060ITS8 is a 8-lead device but the symbol shows only 6 (there are 3 GND leads). | \
-|Kent | \
-|ft to correct mapping of pins between symbol and package | \
-|Done |
-|The output capacitor C13 can have higher capacitance. The 2.2 uF is the lowest recommended value and since this is a X7R/25V type it may well fall below that. I recommend 4.7uF to add some margin. C7 may also be changed to 4.7uF. | \
-|Kent | \
-|Updated schematics | \
-|Done |
-|LMZ13608 has 11 pins plus an exposed pad (must be connected to pin 5) but only 9 pins are shown in the schematic symbol. | \
-|Kent | \
-|Will change symbol to show both name and pin number(s) | \
-|Done |
-|The output voltage for LMZ13608 is calculated as 0.795 V * (1 + R8/R9) which is 4.93 V. It is a bit low for a 5.0 V supply. | \
-|Kent | \
-|5 volts not used, just an intermediate voltage. No change required. | \
-|Done |
-|I don't see any SH pin in the datasheet for the LMZ13608 device. Is it the one called NC? | \
-|Kent | \
-|ft check symbol, then ask Pavel to review | \
-|ft done, pavel |
-|What form factor and main power supply should we use for the Alpha? | \
-|ft | \
-|Try to find drawing with dimensions for NUC computers, to see if we can use that form factor and power supplies | \
-|Pavel |
-
-
+| Comment | Who | Resolution | Status |
+| --- | --- | --- | --- |
+| The LTS3060ITS8 is a 8-lead device but the symbol shows only 6 (there are 3 GND leads). | Kent | ft to correct mapping of pins between symbol and package | Done |
+| The output capacitor C13 can have higher capacitance. The 2.2 uF is the lowest recommended value and since this is a X7R/25V type it may well fall below that. I recommend 4.7uF to add some margin. C7 may also be changed to 4.7uF. | Kent | Updated schematics | Done |
+| LMZ13608 has 11 pins plus an exposed pad (must be connected to pin 5) but only 9 pins are shown in the schematic symbol. | Kent | Will change symbol to show both name and pin number(s) | Done |
+| The output voltage for LMZ13608 is calculated as 0.795 V * (1 + R8/R9) which is 4.93 V. It is a bit low for a 5.0 V supply. | Kent | 5 volts not used, just an intermediate voltage. No change required. | Done |
+| I don't see any SH pin in the datasheet for the LMZ13608 device. Is it the one called NC? | Kent | ft check symbol, then ask Pavel to review | ft done, pavel |
+| What form factor and main power supply should we use for the Alpha? | ft | Try to find drawing with dimensions for NUC computers, to see if we can use that form factor and power supplies | Pavel |
## Entropy source
-|Comment |Who |Resolution |Status |
-|---|---|---|---|
-|Add optocoupler as per Jacob's suggestion on tech@ 2015-07-24? The suggestion is to add a fast optocoupler to really isolate AGND from GND. | \
-|Jacob W | \
-| As this appears to require a bigger digitizer, which in turn might require another 3V3 regulator, we don't want to add that to this otherwise quite well tested part of the circuitry for the Alpha. | \
-|Done |
-
-
+| Comment | Who | Resolution | Status |
+| --- | --- | --- | --- |
+| Add optocoupler as per Jacob's suggestion on tech@ 2015-07-24? The suggestion is to add a fast optocoupler to really isolate AGND from GND. | Jacob W | As this appears to require a bigger digitizer, which in turn might require another 3V3 regulator, we don't want to add that to this otherwise quite well tested part of the circuitry for the Alpha. | Done |
## STM32
-|Comment |Who |Resolution |Status |
-|---|---|---|---|
-|The JTAG port is not connected. For debug puposes, it could be good to have access to the JTAG port, at least at the prototype board. | \
-|Kent | \
-|We don't know of a reason to add the full JTAG, when we have SWD. At least not if we keep the LQFP package because then we don't think we need to be able to do boundary scan. | \
-|Done |
-|The capacitors C22-C25 are connected between VCAP1/2 and VCCO_3V3. According to the datasheet as well as AN4488 they shall be connected to GND. It should be enough with one 2.2uF capacitor for each pin. | \
-|Kent | \
-|Yes, change to GND instead of 3V3. Our interpretation is that we actually should have 2x2.2 for both VCAP1 and VCAP2. We also prefer 2x2.2 over 1x4.7 so not changing that.| \
-|Done |
+| Comment | Who | Resolution | Status |
+| --- | --- | --- | --- |
+| The JTAG port is not connected. For debug puposes, it could be good to have access to the JTAG port, at least at the prototype board. | Kent | We don't know of a reason to add the full JTAG, when we have SWD. At least not if we keep the LQFP package because then we don't think we need to be able to do boundary scan. | Done |
+| The capacitors C22-C25 are connected between VCAP1/2 and VCCO_3V3. According to the datasheet as well as AN4488 they shall be connected to GND. It should be enough with one 2.2uF capacitor for each pin. | Kent | Yes, change to GND instead of 3V3. Our interpretation is that we actually should have 2x2.2 for both VCAP1 and VCAP2. We also prefer 2x2.2 over 1x4.7 so not changing that. | Done |
## 2x512 Mbit SDRAM for the ARM
-|Comment |Who |Resolution |Status |
-|---|---|---|---|
-|U6 has no speed grade specified. TSOP-II package is selected. The BGA package is much smaller and easier to handle in production. | \
-|Kent | \
-|We will investigate packages and speed | \
-|Pavel |
+| Comment | Who | Resolution | Status |
+| --- | --- | --- | --- |
+| U6 has no speed grade specified. TSOP-II package is selected. The BGA package is much smaller and easier to handle in production. | Kent | We will investigate packages and speed | Pavel |
## Keystore memory, 128 Mbit
-|Comment |Who |Resolution |Status |
-|---|---|---|---|
-|Hard to see which resistor is R17 and R18. What is R17 (the left one) intended for? | \
-|Kent | \
-|Fixed the resistors. CS should be connected to ARM, default is "not enabled" through pull-up. | \
-|Done |
+| Comment | Who | Resolution | Status |
+| --- | --- | --- | --- |
+| Hard to see which resistor is R17 and R18. What is R17 (the left one) intended for? | Kent | Fixed the resistors. CS should be connected to ARM, default is "not enabled" through pull-up. | Done |
## RTC
-|Comment |Who |Resolution |Status |
-|---|---|---|---|
-|From where is 3V3_BATT supplied? Is it an external power source from connector JP3? Or the JP4 jumper? | \
-|Kent | \
-|Yes, external power source connected to JP4. | \
-|Done |
-|Do we need a separate RTC chip at all? | \
-|Jacob W | \
-|Keeping it for the Alpha since it is already there. | \
-|Done |
+| Comment | Who | Resolution | Status |
+| --- | --- | --- | --- |
+| From where is 3V3_BATT supplied? Is it an external power source from connector JP3? Or the JP4 jumper? | Kent | Yes, external power source connected to JP4. | Done |
+| Do we need a separate RTC chip at all? | Jacob W | Keeping it for the Alpha since it is already there. | Done |
## Micro SD card
-|Comment |Who |Resolution |Status |
-|---|---|---|---|
-|Which connector to use? Haven't found a good one with Eagle symbol. Some different kinds available. | \
-|ft | \
-|Remove SD card. | \
-|Done |
-|Novena seems to have card reset capability (power control from MCU). Do we want the same? | \
-|ft | \
-|Remove SD card. | \
-|Done |
-|Novena has two SD slots, and list power at 200mA. Do we need a separate power regulator for the SD card, or can we use VCCO_3V3? | \
-|ft | \
-|Remove SD card. | \
-|Done |
+| Comment | Who | Resolution | Status |
+| --- | --- | --- | --- |
+| Which connector to use? Haven't found a good one with Eagle symbol. Some different kinds available. | ft | Remove SD card. | Done |
+| Novena seems to have card reset capability (power control from MCU). Do we want the same? | ft | Remove SD card. | Done |
+| Novena has two SD slots, and list power at 200mA. Do we need a separate power regulator for the SD card, or can we use VCCO_3V3? | ft | Remove SD card. | Done |
## 2x USB UARTs for management and application access
-|Comment |Who |Resolution |Status |
-|---|---|---|---|
-|Should we add an EEPROM for FTDI USB related settings or not? | \
-|ft | \
-|Not adding anything not strictly necessary to the schematics. | \
-|Done |
-|LED6 is the same type as LED1 at page 4 but they have different values at their resistors (220/330 ohm). | \
-|Kent | \
-|Went with 330 for consistency. | \
-|Done |
-|The recommended protection devices on D+ and D- are missing. | \
-|Kent | \
-|Pavel to look for reference | \
-|pavel |
-|Hard to see what reference designators that belong to which component in some places. | \
-|Kent | \
-|Fredrik will improve clarity | \
-|Done |
+| Comment | Who | Resolution | Status |
+| --- | --- | --- | --- |
+| Should we add an EEPROM for FTDI USB related settings or not? | ft | Not adding anything not strictly necessary to the schematics. | Done |
+| LED6 is the same type as LED1 at page 4 but they have different values at their resistors (220/330 ohm). | Kent | Went with 330 for consistency. | Done |
+| The recommended protection devices on D+ and D- are missing. | Kent | Pavel to look for reference | pavel |
+| Hard to see what reference designators that belong to which component in some places. | Kent | Fredrik will improve clarity | Done |
## AVR Tiny Tamper Detect MCU
Fredrik to verify if Kent had comments about AVR
-|Comment |Who |Resolution |Status |
-|---|---|---|---|
-| | \
-| | \
-| |
+| Comment | Who | Resolution | Status |
+| --- | --- | --- | --- |
+| | | |
## Analog switch controlling access to the MKM
-|Comment |Who |Resolution |Status |
-|---|---|---|---|
-|Suggest changing this chip to an 74AC244 like the one used for the FPGA config memory. | \
-|Pavel | \
-|Will change. | \
-|Done |
+| Comment | Who | Resolution | Status |
+| --- | --- | --- | --- |
+| Suggest changing this chip to an 74AC244 like the one used for the FPGA config memory. | Pavel | Will change. | Done |
## FPGA configuration
-|Comment |Who |Resolution |Status |
-|---|---|---|---|
-|The mode signals are fixed to SPI Master mode. If more flexibility is needed, see next comment, jumpers may be added.| \
-|Kent | \
-|This is intentional. | \
-|Done |
-|One-bit data us for the configuration memory makes the configuration rather slow. If higher speed is preferable the SPI memory supports 4-bit data. | \
-|Kent | \
-|Bitstream is around 65 MBit, takes 4-5 seconds to load using single bit (@ 15MHz). We think that should be good enough. | \
-|Done |
+| Comment | Who | Resolution | Status |
+| --- | --- | --- | --- |
+| The mode signals are fixed to SPI Master mode. If more flexibility is needed, see next comment, jumpers may be added. | Kent | This is intentional. | Done |
+| One-bit data us for the configuration memory makes the configuration rather slow. If higher speed is preferable the SPI memory supports 4-bit data. | Kent | Bitstream is around 65 MBit, takes 4-5 seconds to load using single bit (@ 15MHz). We think that should be good enough. | Done |
## FPGA I/O
-|Comment |Who |Resolution |Status |
-|---|---|---|---|
-|A lot of the FPGA I/Os are unused. For debug purposes some of these can be made available by connecting them to a pin header. Unconnected BGA balls are very hard to use. | \
-|Kent | \
-|Added two more GPIOs from AVR to FPGA and two more from AVR to ARM. Remaining question is how many we should add from FPGA to ARM. | \
-|Pavel |
-|A zero ohm resistor at the oscillator output can simplify debug. | \
-|Kent | \
-|Fredrik will add zero ohm resistor | \
-|Done |
-|Joachim suggests, that we may want to have some high-speed extension interface for debugging and dumping large amounts of data. For example, we can implement GMII or RGMII using external GbE PHY and GPIO header(s). In that sense, at least one of the GPIO header pins should be connected to clock-capable (MRCC) FPGA pin. | \
-|Pavel | \
-|Pavel will finalize notes in schematics to enable this. | \
-|pavel |
+| Comment | Who | Resolution | Status |
+| --- | --- | --- | --- |
+| A lot of the FPGA I/Os are unused. For debug purposes some of these can be made available by connecting them to a pin header. Unconnected BGA balls are very hard to use. | Kent | Added two more GPIOs from AVR to FPGA and two more from AVR to ARM. Remaining question is how many we should add from FPGA to ARM. | Pavel |
+| A zero ohm resistor at the oscillator output can simplify debug. | Kent | Fredrik will add zero ohm resistor | Done |
+| Joachim suggests, that we may want to have some high-speed extension interface for debugging and dumping large amounts of data. For example, we can implement GMII or RGMII using external GbE PHY and GPIO header(s). In that sense, at least one of the GPIO header pins should be connected to clock-capable (MRCC) FPGA pin. | Pavel | Pavel will finalize notes in schematics to enable this. | pavel |
## FPGA voltage regulators
-|Comment |Who |Resolution |Status |
-|---|---|---|---|
-|U14 and U15 have 38 pins but only 11 are visible in the schematic symbol. No pin numbers are visible. The NC pins must not be connected which should be shown.| \
-|Kent | \
-|Fredrik will update symbol to show pins. | \
-|Done |
-|I am not familiar with the EN6347Q device so I would add ferrite cores on the outputs, for debug and measurement. Maybe that's what the zero ohm resistors are intended for? | \
-|Kent | \
-|Will change 0-ohm to ferrites. Pavel will look up part number, Fredrik will update schematics. | \
-|pavel, ft|
+| Comment | Who | Resolution | Status |
+| --- | --- | --- | --- |
+| U14 and U15 have 38 pins but only 11 are visible in the schematic symbol. No pin numbers are visible. The NC pins must not be connected which should be shown. | Kent | Fredrik will update symbol to show pins. | Done |
+| I am not familiar with the EN6347Q device so I would add ferrite cores on the outputs, for debug and measurement. Maybe that's what the zero ohm resistors are intended for? | Kent | Will change 0-ohm to ferrites. Pavel will look up part number, Fredrik will update schematics. | pavel, ft |
## FPGA power regulators
-|Comment |Who |Resolution |Status |
-|---|---|---|---|
-|The EN5364 device has 68 pins and 2 exposed pads but the symbol only shows 19 pins, without pin number.| \
-|Kent | \
-|Fredrik will update symbol to show pins | \
-|Done |
+| Comment | Who | Resolution | Status |
+| --- | --- | --- | --- |
+| The EN5364 device has 68 pins and 2 exposed pads but the symbol only shows 19 pins, without pin number. | Kent | Fredrik will update symbol to show pins | Done |
@@ -219,56 +124,24 @@ have spent 8 hours on this review.
The block diagram does not comply with the schematics:
-|Analog switch replaced by line driver (IC2) | \
-|---|
-|Kent | \
-| |
-|There is no reset block to the Tamper Detect CPU (U10) in the schematics | \
-|Kent | \
-| |
-|I can't find any Reset_n signal to the FPGA (U13) nor any FPGA reset block (maybe it is supposed to indicate the FPGA configuration?). | \
-|Kent | \
-| |
-|Interfaces for Smart Card and display/control seems to be missing in the schematics JTAG port for the ARM (U4) is not present in the schematics | \
-|Kent | \
-| |
-|JTAG port for the Tamper Detect CPU (U10) is not present in the schematics | \
-|Kent | \
-| |
-|Master Key Memory (U12) type is different (23A640 vs 23K640) | \
-|Kent | \
-| |
-|Power supply voltages does not comply with the schematics | \
-|Kent | \
-| |
-|The battery near the RTC on the block diagram is not present in the schematics | \
-|Kent | \
-| |
-|Minor differences in component names (suggestion: remove details from block diagram) | \
-
-
-|The header information should be updated with design name/ID and author. | \
-|---|
-|Kent | \
-| |
-|Some components in the schematic (U1, U2, U14, U15, Q3) doesn't show pin numbers which make it harder to review | \
-|Kent | \
-| |
-|The sheets seems to have different sizes (1-13 differs from 14-26) and origo is placed in different positions in different pages. Not important but looks a bit odd. | \
-|Kent | \
-| |
-|Eagle doesn't seem to have a symbol for unconnected pins. If nothing else, a comment would be good so it is obvious that the pin shall be unconnected and is not forgotten. | \
-|Kent | \
-| |
-|On prototype boards it can sometimes be beneficial to insert zero ohm resistances on certain nets, typical clock and reset signals, to simplify debug. Typical places can be voltage regulator outputs and signals that are buried in the PCB. | \
-|Kent | \
-| |
-|The selected package for the CPU (U4) is LQFP208. The size is 30x30 mm compared to the TFBGA216 package that is only 13x13 mm. Also, the pitch is 0.5 mm for the LQFP208 while the TFBGA216 package has a ball pitch of 0.8 mm. | \
-|Kent | \
-|Joachim and ft thinks LQFP package makes sense for the Alpha - gives 208 "test points" and physical size not that important |
-|For debug purposes it is recommended to place test points for signals that are hard to reach, to simplify measurement. | \
-|Kent | \
-| |
+| Comment | Who | Resolution | Status |
+| --- | --- | --- | --- |
+| Analog switch replaced by line driver (IC2) | Kent | |
+| There is no reset block to the Tamper Detect CPU (U10) in the schematics | Kent | |
+| I can't find any Reset_n signal to the FPGA (U13) nor any FPGA reset block (maybe it is supposed to indicate the FPGA configuration?). | Kent | |
+| Interfaces for Smart Card and display/control seems to be missing in the schematics JTAG port for the ARM (U4) is not present in the schematics | Kent | |
+| JTAG port for the Tamper Detect CPU (U10) is not present in the schematics | Kent | |
+| Master Key Memory (U12) type is different (23A640 vs 23K640) | Kent | |
+| Power supply voltages does not comply with the schematics | Kent | |
+| The battery near the RTC on the block diagram is not present in the schematics | Kent | |
+| Minor differences in component names (suggestion: remove details from block diagram)
+| The header information should be updated with design name/ID and author. | Kent | |
+| Some components in the schematic (U1, U2, U14, U15, Q3) doesn't show pin numbers which make it harder to review | Kent | |
+| The sheets seems to have different sizes (1-13 differs from 14-26) and origo is placed in different positions in different pages. Not important but looks a bit odd. | Kent | |
+| Eagle doesn't seem to have a symbol for unconnected pins. If nothing else, a comment would be good so it is obvious that the pin shall be unconnected and is not forgotten. | Kent | |
+| On prototype boards it can sometimes be beneficial to insert zero ohm resistances on certain nets, typical clock and reset signals, to simplify debug. Typical places can be voltage regulator outputs and signals that are buried in the PCB. | Kent | |
+| The selected package for the CPU (U4) is LQFP208. The size is 30x30 mm compared to the TFBGA216 package that is only 13x13 mm. Also, the pitch is 0.5 mm for the LQFP208 while the TFBGA216 package has a ball pitch of 0.8 mm. | Kent | Joachim and ft thinks LQFP package makes sense for the Alpha - gives 208 "test points" and physical size not that important |
+| For debug purposes it is recommended to place test points for signals that are hard to reach, to simplify measurement. | Kent | |
@@ -277,10 +150,11 @@ The block diagram does not comply with the schematics:
A one day review doesn't allow a thorough design review. Some
prioritizations are necessary. I have not reviewed:
-| FPGA pinout. The FPGA vendor tool (Vivado) does some of the checks. It checks that clock signals are placed at clock pins, that selected I/O types are compatible with the bank structure. Vivado can also check that not to much I/O switching power per bank is used and can also calculate power consumption (with correct user input). |
-|---|
-|Power calculations. The FPGA power is heavily dependent on how it is used. This can be estimated with the Vivado tool. |
-|Supply voltage quality. This requires simulations that are out of scope for this review. |
-|Power sequencing. |
-|Physical properties like PCB symbols, layout issues, thermal design and board area use. |
-|Production test or optimization for production. |
+| Comment |
+| --- |
+| FPGA pinout. The FPGA vendor tool (Vivado) does some of the checks. It checks that clock signals are placed at clock pins, that selected I/O types are compatible with the bank structure. Vivado can also check that not to much I/O switching power per bank is used and can also calculate power consumption (with correct user input). |
+| Power calculations. The FPGA power is heavily dependent on how it is used. This can be estimated with the Vivado tool. |
+| Supply voltage quality. This requires simulations that are out of scope for this review. |
+| Power sequencing. |
+| Physical properties like PCB symbols, layout issues, thermal design and board area use. |
+| Production test or optimization for production. |
diff --git a/content/AlphaSchematics.md b/content/AlphaSchematics.md
index 6510842..5fd9c9f 100644
--- a/content/AlphaSchematics.md
+++ b/content/AlphaSchematics.md
@@ -1,6 +1,6 @@
-Title: AlphaSchematics
-Author: trac
+Title: Alpha Schematics
Date: 2016-12-15 22:39
+Category: AlphaBoard
The Alpha schematics are almost finished!
diff --git a/content/AlphaSealedBags.md b/content/AlphaSealedBags.md
index bd19e07..091fd86 100644
--- a/content/AlphaSealedBags.md
+++ b/content/AlphaSealedBags.md
@@ -1,8 +1,8 @@
-Title: AlphaSealedBags
-Author: ft
+Title: Alpha Sealed Bags
+Author: Fredrik Thulin
Date: 2016-12-16 14:09
Modified: 2016-12-16 14:12
-
+Category: AlphaBoard
## Chain of custody
@@ -16,8 +16,6 @@ To provide some assurance the devices have not been tampered with after they hav
As the model of bags might change over time, we will publish photos of the bags used here as well as PGP signed statements for what serial numbers can be expected.
At this time, we do not keep records of which exact unit was sent to whom.
-
-
This is a picture of the currently used bags:
diff --git a/content/AssuredTooChain.md b/content/AssuredTooChain.md
index f3d6f25..5374cf5 100644
--- a/content/AssuredTooChain.md
+++ b/content/AssuredTooChain.md
@@ -1,8 +1,6 @@
-Title: AssuredTooChain
-Author: trac
+Title: Issues of an Assured Tool-Chain
Date: 2016-12-15 22:44
-
-# Issues of an Assured Tool-Chain
+Category: FutureWork
We do not have any assurance that our basic tools are not compromised.
diff --git a/content/BerlinWorkshop.md b/content/BerlinWorkshop.md
index eac683c..e77033c 100644
--- a/content/BerlinWorkshop.md
+++ b/content/BerlinWorkshop.md
@@ -1,9 +1,8 @@
-Title: BerlinWorkshop
-Author: trac
+Title: Cryptech Workshop Agenda, Berlin, 15-16 July 2016
Date: 2016-12-15 22:43
+Category: Workshops
-# CRYPTECH Workshop Agenda
-### 15-16 July 2016
+## Overview
Intercontinental Berlin
Budapest Str. 2
diff --git a/content/BinaryPackages.md b/content/BinaryPackages.md
index 636551e..4caaedb 100644
--- a/content/BinaryPackages.md
+++ b/content/BinaryPackages.md
@@ -1,12 +1,10 @@
-Title: BinaryPackages
-Author: sra
+Title: Binary Packages for Cryptech Software and Firmware
+Author: Rob Austein
Date: 2016-12-15 22:44
Modified: 2019-09-03 15:23
+Category: Releases
-
-# Binary Packages for Cryptech Software and Firmware
-
The Cryptech Project maintains APT and Homebrew repositories
containing packaged software for the Cryptech Alpha board for Debian
and Ubuntu Linux and for Mac OS X. The binary packages also include
diff --git a/content/BuildingFromSource.md b/content/BuildingFromSource.md
index d39111d..4357d0d 100644
--- a/content/BuildingFromSource.md
+++ b/content/BuildingFromSource.md
@@ -1,12 +1,10 @@
-Title: BuildingFromSource
-Author: sra
+Title: Building Cryptech Software/Firmware/Bitstream From Source
+Author: Rob Austein
Date: 2017-05-13 17:47
Modified: 2017-05-17 21:28
+Category: Releases
-
-# Building Cryptech Software/Firmware/Bitstream From Source
-
Everything you need to build our software, firmware, and FPGA
bitstreams from source yourself is publicly available, but the process
is a bit complicated. Overall, there are two methods, one of which
diff --git a/content/CoretestHashesC5G.md b/content/CoretestHashesC5G.md
index d7b712d..f3843e2 100644
--- a/content/CoretestHashesC5G.md
+++ b/content/CoretestHashesC5G.md
@@ -1,9 +1,8 @@
-Title: CoretestHashesC5G
-Author: trac
+Title: How to start using coretest_hashes on the TerasIC C5G Board
Date: 2016-12-15 22:43
+Author: Joachim Strömbergson
-# How to start using coretest_hashes on the TerasIC C5G Board
-This is a writeup on how to setup, build and testrun the coretest_hashes
+This is a writeup on how to setup, build and testrun the `coretest_hashes`
Cryptech subsystem on a TerasiC C5G Cyclone V GX Starter Kit FPGA
development board [1].
@@ -16,7 +15,7 @@ The test setup consists of:
-- A host computer that runs the hash_tester application that communicates with the FPGA design downloaded into the FPGA and perform tests on the hash functions. The host computer is connected to the USB-serial port on the TerasIC board.
+- A host computer that runs the `hash_tester` application that communicates with the FPGA design downloaded into the FPGA and perform tests on the hash functions. The host computer is connected to the USB-serial port on the TerasIC board.
@@ -27,15 +26,15 @@ The test setup consists of:
*The TerasIC Cyclone 5 GX Starter Kit board.*
-The USB ports are the shown in the upper left corner. These are USB type B ports. The port to the left is the USB-blaster port. The port to the right is the USB-serial port. In the bottom right corner there is a row of buttons and just above them 8 LEDs. These will also be used by the coretest_hashes subsystem. There is a HDMI port on the C5G board but it will not be used. All communication is done in CLI on the host computer.
+The USB ports are the shown in the upper left corner. These are USB type B ports. The port to the left is the USB-blaster port. The port to the right is the USB-serial port. In the bottom right corner there is a row of buttons and just above them 8 LEDs. These will also be used by the `coretest_hashes` subsystem. There is a HDMI port on the C5G board but it will not be used. All communication is done in CLI on the host computer.
-**NOTE: You don't actually need two separate computers. You can use one computer with one or two USB ports. If you only have one USB port you will need to switch from connecting to the USB-Blaster port to the USB-serial port on the C5G board once the coretest_hashes FPGA configuration has been downloaded to the board.**
+**NOTE: You don't actually need two separate computers. You can use one computer with one or two USB ports. If you only have one USB port you will need to switch from connecting to the USB-Blaster port to the USB-serial port on the C5G board once the `coretest_hashes` FPGA configuration has been downloaded to the board.**
My personal setup is a laptop with two USB ports which allows me to have connections to both USB ports on the C5G boards simultaneously.
-### Coretest_hashes
-The coretest_hashes is a subsystem that is a FPGA design that contains Cryptech application cores as well as support cores used to run tests of the
+### `Coretest_hashes`
+The `coretest_hashes` is a subsystem that is a FPGA design that contains Cryptech application cores as well as support cores used to run tests of the
SHA-1 and SHA-256 hash functions from a host computer via a serial
interface connected to a FPGA device. The subsystem consists of:
@@ -57,13 +56,13 @@ interface connected to a FPGA device. The subsystem consists of:
-- [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.
+- [`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.*
+*The `coretest_hashes` subsystem with sha1 and sha256 cores. The system is connected to a host computer via a serial interface.*
## SW and system requirements
You need to download and install the Altera Quartus II Web Edition
@@ -71,23 +70,23 @@ software [2]. There are versions of Quartus II Web Edition for Windows and Linux
You will probably also install drivers for the Altera USB-blaster in order to program the FPGA on the development board. For instructions on how to install the driver, please see the Altera page for USB-blaster [7].
-For communication with the coretest_hashes in the FPGA we will be using the USB-serial device on the development board. The USB-serial chip on the
+For communication with the `coretest_hashes` in the FPGA we will be using the USB-serial device on the development board. The USB-serial chip on the
board is a FTDI FT232R [3]. If your host OS does not have support for this device you will need to install drivers. For Windows the correct file to download seems to be a VCP file [7].
-Finally, in order to talk to coretest_hashes from the host there is application SW. This SW is written in Python and uses the Pyserial[5] library. If you don't have Python and/or Pyserial installed you will need to install that too.
+Finally, in order to talk to `coretest_hashes` from the host there is application SW. This SW is written in Python and uses the Pyserial[5] library. If you don't have Python and/or Pyserial installed you will need to install that too.
**NOTE: Python and Pyserial does not have to be installed in the same OS as Quartus II but can be run from a separate system and OS.**
(I'm using Quartus II 13.1 64-bit version running in Win8.1 in a VM in Parallels Desktop in OX 10.9.2 during this writeup. And I use Python and Pyserial in an iTerm in OSX for the serial communication.)
With all this SW installed you should be ready to proceed to create the
-coretest_hashes project.
+`coretest_hashes` project.
**I also recommend that you download the TerasIC C5G User Manual [4]. It is a really good document that describes the boards with all functions, pins etc.**
## Downloading the cores
-Create a project directory. I'm using test_coretest_hashes. In it I add
+Create a project directory. I'm using test_`coretest_hashes`. In it I add
a core directory and a toolruns directory:
```
@@ -99,11 +98,11 @@ The cores we need to build the subsystem must be downloaded from the
Cryptech server. The cores we need are:
-- sha1
-- sha256
-- uart
-- coretest
-- coretest_hashes
+- `sha1`
+- `sha256`
+- `uart`
+- `coretest`
+- `coretest_hashes`
```
@@ -156,21 +155,17 @@ 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
+- `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_core.v: The actual SHA-1 hash function core.
-
-
-
-- sha1_w_mem.v: The W memory including sliding window functionality used
+- `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
+`<core_name>.v`, the main functionality in `<core_name>_core.v` and then one
or more submodules.
@@ -186,11 +181,11 @@ or more submodules.
-- Set 'coretest_hashes' as name of the project
+- Set`'coretest_hashes` as name of the project
-- Set 'coretest_hashes' as nem of the top level design entity. (Should be
+- Set `coretest_hashes` as nem of the top level design entity. (Should be
done automatically when entering the name of the project.)
@@ -203,7 +198,7 @@ or more submodules.
-- Navigate to test_coretest_hashes/cores/coretest/src/rtl.
+- Navigate to `test_coretest_hashes/cores/coretest/src/rtl`.
@@ -218,23 +213,23 @@ or more submodules.
- Press '...' again and navigate to the rtl directory in
- coretest_hashes. Add it like you did with coretest.
+ `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,
- sha1_w_mem. This time you don't need to press 'Add' on the 'Add
+- 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,
- 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.
+- 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.
+- Finally navigate to `test_coretest_hashes/cores/uart/src/rtl` and add `uart`, `uart_core`.
Back on the 'Add Files page you should now see a list of source files:
@@ -285,14 +280,14 @@ You now need to define the correct pins and define the clock to allow
Quartus to create a FPGA configuration for our board.
All pins needed are described in the C5G manual. To save time there is
-also a pin list available in the coretest_hashes directory.
+also a pin list available in the `coretest_hashes` directory.
-- Navigate to test_coretest_hashes/cores/coretest_hashes/toolruns/quartus/terasic_c5g
+- Navigate to `test_coretest_hashes/cores/coretest_hashes/toolruns/quartus/terasic_c5g`
-- The file coretest_hashes.qsf contains assignments for a project like
+- 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:
@@ -325,12 +320,12 @@ set_instance_assignment -name IO_STANDARD "2.5 V" -to debug[7]
```
As you can see, for each pin we want to use we need to define the actual
-pin in the FPGA (PIN_R20 for example) and the I/O standard the pin
+pin in the FPGA (`PIN_R20` for example) and the I/O standard the pin
should use/support.
In this design I've mapped the reset signal to the button 'KEY0' on the
board which you can find in the lower right corner. There is also a
-debug port that in the coretest_hashes design is connected to the debug
+debug port that in the `coretest_hashes` design is connected to the debug
port in the uart. This allows us to see byte values received by the
uart. This debug port is connected to pins that control the green LEDs
just above the row of buttons that includes 'KEY0'.
@@ -341,11 +336,11 @@ manually enter each of the assignments above. This will require two rows
for each pin. For example for the clock ('clk') we would enter:
-- Row 1: 'To': clk, 'Assignment name': Location, 'Value': PIN_R20
+- Row 1: 'To': clk, 'Assignment name': Location, 'Value': `PIN_R20`
- Row 2: 'To': clk, 'Assignment name': I/O Standard, 'Value': 3.3-V LVTTL
-An easier way is to open up the file coretest_hashes.qsf in test_coretest_hashes/cores/coretest_hashes/toolruns/quartus/terasic_c5g and add the pin assignment from that file to your qsf file in test_coretest_hashes/toolruns. If you then open up the Assignments Editor the same definitions should be shown.
+An easier way is to open up the file `coretest_hashes.qsf` in `test_coretest_hashes/cores/coretest_hashes/toolruns/quartus/terasic_c5g` and add the pin assignment from that file to your qsf file in `test_coretest_hashes/toolruns`. If you then open up the Assignments Editor the same definitions should be shown.
We now need to define the clock. Under 'Assignments' in the top level
menue select 'TimeQuest Timing Analyzer Wizard'. Press 'Next' to get
@@ -361,8 +356,8 @@ time scale. In the 'Equivalent SDC Commands' you should see:
Now press 'Next' four times to get to the final page and then press
'Finish' to complete the clock setup. If we now look in the
-test_coretest_hashes/toolruns directory there should be a file called
-coretest_hashes.sdc that contains the SDC command above.
+`test_coretest_hashes/toolruns` directory there should be a file called
+`coretest_hashes.sdc` that contains the SDC command above.
Now we are ready to build the real FPGA configuration. Press the purple
'Start Compilation' button again. After build we should now have an FPGA
@@ -384,7 +379,7 @@ chip with waves). Alternatively Select 'Tools' in the top level Menue
and then 'Programmer'.
In the Programmer window if everything is working magically we should
-see a list view with toolruns/output_files/coretest_hashes.sof
+see a list view with `toolruns/output_files/coretest_hashes.sof`
selected. And below this list a graphic that shows a 'TDI' arrow
pointing to an Altera 5CGXFC5C6F27C7 device with a 'TDO' going out from
the device.
@@ -395,19 +390,19 @@ fix the drivers for the USB-blaster in your OS. If the USB-blaster is
present make sure it is selected and then press 'Close'.
If the file is not showing, in the main Programmer window, select 'Add
-File' and navigate and to toolruns/output_files in the project
-directory. Select 'coretest_hashes.sof' and press 'Open'.
+File' and navigate and to `toolruns/output_files` in the `project`
+directory. Select `coretest_hashes.sof` and press 'Open'.
In the main Programmer window now press 'Start' to start
programming. When this has been completed (See 'Progress' in the upper
right hand corner in the Programmer board) the LEDs etc should have
-stopped blinking. We should now have coretest_hashes alive on the
+stopped blinking. We should now have `coretest_hashes` alive on the
development board. Time for host communication and testing!
-## Talking to coretest_hashes and test of SHA-1 and SHA-256
+## Talking to `coretest_hashes` and test of SHA-1 and SHA-256
There is a (currently rather ugly) test program for
-coretest_hashes. Navigate to test_coretest_hashes/cores/coretest_hashes/src/sw
+`coretest_hashes`. Navigate to `test_coretest_hashes/cores/coretest_hashes/src/sw`
```
#> ls
@@ -419,7 +414,7 @@ port and talk to coretest via the uart. The command and response format
used is a very simple byte oriented format. For more info, see the
README.md in [the top of coretest](https://git.cryptech.is/core/coretest).
-The program hash_tester.py needs to know which serial interface to
+The program `hash_tester.py` needs to know which serial interface to
use. This is defined in the main() function (yes, VERY ugly). You will
need to edit the program source to point to the serial interface
connected to the USB-serial chip on the C5G board. For me that device
@@ -444,7 +439,7 @@ If the communication has been set up properly you should now see:
```
That is the first test case that reads from specific registers in the
-SHA-1 core. If we look in sha1/src/rtl/sha1.v there are some defines:
+SHA-1 core. If we look in `sha1/src/rtl/sha1.v` there are some defines:
```
parameter CORE_NAME0 = 32'h73686131; // "sha1"
parameter CORE_NAME1 = 32'h20202020; // " "
@@ -454,21 +449,21 @@ SHA-1 core. If we look in sha1/src/rtl/sha1.v there are some defines:
As we can see those hex values matches what is being read from the FPGA
and is the name and version strings in the core.
-Moving on, hash_tester.py also performs single block message hash tests
+Moving on, `hash_tester.py` also performs single block message hash tests
of both the SHA-1 and SHA-256 core. The message is "abc" padded to the
correct block size for SHA-1 and SHA-256. These tests are defined by
NIST including the expected result in [6]. The block is written as a
sequence of 32-bit words to addresses mapped to the block registers in
the sha1 core.
-Finally we set the init_flag in the control register in
+Finally we set the `init_flag` in the control register in
sha1 to one which should make the sha1 core initialize and then process
the first (of possible several) message block. This takes in total 82
cycles for the core. This means that by the time the host gets the
-'WRITE_OK. address 0x1008.' message, the core is done since many cycles
+`WRITE_OK. address 0x1008.` message, the core is done since many cycles
ago. We therefore check status and try to extract the digest.
-Looking at the output from hash_tester.py we see:
+Looking at the output from `hash_tester.py` we see:
```
TC1-3: Reading SHA-1 status and digest.
READ_OK. address 0x1009 = 0x00000003.
@@ -515,8 +510,8 @@ Which again matches what is specified in [6]
## Summary
We have now set up a complete development and verification environment
-for Cryptech. We have setup and built the coretest_hashes subsystem for
-the TerasIC C5G board. Finally we have connected to coretest_hashes from
+for Cryptech. We have setup and built the `coretest_hashes` subsystem for
+the TerasIC C5G board. Finally we have connected to `coretest_hashes` from
SW in the host and verified that we can write to and receive response
needed to perform SHA-1 and SHA-256 hash operations and get correct
digest back.
diff --git a/content/CoretestHashesNovena.md b/content/CoretestHashesNovena.md
index 2c427b9..8b1ac43 100644
--- a/content/CoretestHashesNovena.md
+++ b/content/CoretestHashesNovena.md
@@ -1,8 +1,6 @@
-Title: CoretestHashesNovena
-Author: trac
+Title: How to start using coretest_hashes on the Novena PVT1
Date: 2016-12-15 22:44
-
-# How to start using coretest_hashes on the Novena PVT1
+Category: Novena
This is a writeup on how to setup, build and testrun the coretest_hashes
Cryptech subsystem on a Novena PVT1 development board.
diff --git a/content/DNSSEC-Requirements.md b/content/DNSSEC-Requirements.md
index cef61c4..20a7735 100644
--- a/content/DNSSEC-Requirements.md
+++ b/content/DNSSEC-Requirements.md
@@ -1,6 +1,6 @@
Title: DNSSEC/Requirements
-Author: trac
Date: 2016-12-15 22:44
+Category: DNSSEC
# DNSSEC Requirements
diff --git a/content/DNSSEC.md b/content/DNSSEC.md
index 427402b..e32eaf2 100644
--- a/content/DNSSEC.md
+++ b/content/DNSSEC.md
@@ -1,8 +1,5 @@
Title: DNSSEC
-Author: trac
Date: 2016-12-15 22:43
-
-# DNSSEC
-
+Category: DNSSEC
- [DNSSEC Requirements]({filename}DNSSEC-Requirements.md)
diff --git a/content/Dashboard.md b/content/Dashboard.md
index 4cba3a8..5ac8872 100644
--- a/content/Dashboard.md
+++ b/content/Dashboard.md
@@ -1,8 +1,6 @@
-Title: Dashboard
-Author: trac
+Title: Project Status Dashboard
Date: 2016-12-15 22:44
-# Project Status Dashboard
## Product Component Requirements
diff --git a/content/DevBridgeBoard.md b/content/DevBridgeBoard.md
index a9310c9..6e3e837 100644
--- a/content/DevBridgeBoard.md
+++ b/content/DevBridgeBoard.md
@@ -1,11 +1,8 @@
-Title: DevBridgeBoard
-Author: sra
+Title: dev-bridge board
+Author: Paul Selkirk
Date: 2016-12-15 22:43
Modified: 2021-02-14 17:30
-
-
-# dev-bridge board
In the process of developing the [AlphaBoardComponents]({filename}AlphaBoardComponents.md) design, the project has made what is known as the "dev-bridge board".
This is a board, 100x70 mm, with about 2/3 of the components intended to be on the Alpha design. What is missing is basically the FPGA and it's supporting circuits.
diff --git a/content/DevelopersGuide.md b/content/DevelopersGuide.md
index 215d69c..4d3a87a 100644
--- a/content/DevelopersGuide.md
+++ b/content/DevelopersGuide.md
@@ -1,11 +1,8 @@
-Title: DevelopersGuide
-Author: trac
+Title: Developers' Guide
Date: 2016-12-15 22:39
*Page Under Development*
-# Developers Guide
-
## Architecture
* [OpenCryptoChip]({filename}OpenCryptoChip.md)
@@ -17,8 +14,6 @@ Date: 2016-12-15 22:39
* [AssuredTooChain]({filename}AssuredTooChain.md)
-
-
* EDAToolchainSurvey
diff --git a/content/DisasterRecovery.md b/content/DisasterRecovery.md
index 18b325d..299f88e 100644
--- a/content/DisasterRecovery.md
+++ b/content/DisasterRecovery.md
@@ -1,8 +1,8 @@
-Title: DisasterRecovery
-Author: pselkirk
+Title: Disaster Recovery on the Alpha Board
+Author: Paul Selkirk
Date: 2017-05-13 00:30
+Category: AlphaBoard
-# Disaster Recovery
This page covers a few likely (hopefully unlikely) oh-noes.
diff --git a/content/DocMeet.md b/content/DocMeet.md
index b253c8d..1c87dd0 100644
--- a/content/DocMeet.md
+++ b/content/DocMeet.md
@@ -1,8 +1,7 @@
-Title: DocMeet
-Author: trac
+Title: Documents, Meetings, etc.
Date: 2016-12-15 22:39
+Category: Workshops
-# Documents, Meetings, etc.
## Meetings
diff --git a/content/Documents.md b/content/Documents.md
index b988bbc..9a2549e 100644
--- a/content/Documents.md
+++ b/content/Documents.md
@@ -1,18 +1,6 @@
-Title: Documents
-Author: trac
+Title: Presentations and Design Documents
Date: 2016-12-15 22:43
-# Presentations and Design Documents
-
-```
-#!comment
-
-Remember that links from this page to files in git repositories should use the "export:" tag, eg:
-
-[export:/doc/blarg.pdf "An interesting presentation about Blargs"]
-
-```
-
[Randomness Testing Tools]({filename}RandomnessTesting.md)<br/>
[Alpha board strategy]({filename}AlphaBoardStrategy.md)
diff --git a/content/EDAToolchainSurvey.md b/content/EDAToolchainSurvey.md
index b8632a6..287d5af 100644
--- a/content/EDAToolchainSurvey.md
+++ b/content/EDAToolchainSurvey.md
@@ -1,8 +1,17 @@
-Title: EDAToolchainSurvey
-Author: trac
+Title: EDA Toolchain Survey
Date: 2016-12-15 22:43
-The major issue is finding tools that allows a designer, user to verify that the RTL source code (in Verilog or VHDL) matches what is generated at the physical level. As part of the project we need to investigate the current status of open tools in the toolchain for implementation and verification of hardware. This includes RTL simulation, synthesis, place & route, netlist verification, timing analysis and configuration file generation and analysis. (This implies that the target is an FP [...]
+The major issue is finding tools that allows a designer, user to
+verify that the RTL source code (in Verilog or VHDL) matches what is
+generated at the physical level. As part of the project we need to
+investigate the current status of open tools in the toolchain for
+implementation and verification of hardware. This includes RTL
+simulation, synthesis, place & route, netlist verification, timing
+analysis and configuration file generation and analysis. (This implies
+that the target is an FPGA.). If there are no open tools we need to
+find ways of verifying pre- and post-functionality to check that the
+black box tool does not alter (subvert) the design in ways not
+intended.
The basic action flow is:
diff --git a/content/ExternalProjects.md b/content/ExternalProjects.md
index 8a86b9b..5584ed5 100644
--- a/content/ExternalProjects.md
+++ b/content/ExternalProjects.md
@@ -1,5 +1,4 @@
-Title: ExternalProjects
-Author: ln5
+Title: External Projects
Date: 2018-09-17 10:12
Modified: 2018-09-17 10:27
diff --git a/content/ExternalProjectsTorHSM.md b/content/ExternalProjectsTorHSM.md
index 46fe696..29aedf3 100644
--- a/content/ExternalProjectsTorHSM.md
+++ b/content/ExternalProjectsTorHSM.md
@@ -1,10 +1,8 @@
-Title: ExternalProjectsTorHSM
-Author: ln5
+Title: External Project Tor HSM
+Author: Linus Nordberg
Date: 2018-09-17 10:26
Modified: 2018-10-01 14:38
-# External project TorHSM
-
## Problem
The [Tor network](https://www.torproject.org/about/overview.html.en) is defined by a small number, about ten, of special relays called Directory Authorities (DAs).
diff --git a/content/GettingStartedNovena.md b/content/GettingStartedNovena.md
index 68b55ed..f5d2001 100644
--- a/content/GettingStartedNovena.md
+++ b/content/GettingStartedNovena.md
@@ -1,10 +1,6 @@
-Title: GettingStartedNovena
-Author: trac
+Title: Getting Started on the Novena
Date: 2016-12-15 22:44
-
-
-
-# Getting Started on the Novena
+Category: Novena
## The Novena Board
diff --git a/content/Hardware.md b/content/Hardware.md
index c685503..f2feb84 100644
--- a/content/Hardware.md
+++ b/content/Hardware.md
@@ -1,8 +1,7 @@
-Title: Hardware
-Author: trac
+Title: Cryptech Hardware
Date: 2016-12-15 22:43
+Category: Hardware
-# Cryptech Hardware
## Generation 1
diff --git a/content/InterconnectStandards.md b/content/InterconnectStandards.md
index a31da2c..2710ebb 100644
--- a/content/InterconnectStandards.md
+++ b/content/InterconnectStandards.md
@@ -1,8 +1,6 @@
-Title: InterconnectStandards
-Author: trac
+Title: Comparison of On-Chip Bus Standards
Date: 2016-12-15 22:44
-# Comparison of On-Chip Bus Standards
## Introduction
This document contains a brief summary of different on-chip bus
diff --git "a/content/Joachim Str\303\266mbergson.md" "b/content/Joachim Str\303\266mbergson.md"
index 5a74548..77475a6 100644
--- "a/content/Joachim Str\303\266mbergson.md"
+++ "b/content/Joachim Str\303\266mbergson.md"
@@ -1,11 +1,10 @@
Title: Joachim Strömbergson
-Author: trac
+Author: Joachim Strömbergson
Date: 2016-12-15 22:54
+Category: People
-# Joachim Strömbergson
## Bio
-
## Current activities
* Developing coretest - a core testing framework for FPGAs.
diff --git a/content/MailingLists.md b/content/MailingLists.md
index 3207f9e..696b9c4 100644
--- a/content/MailingLists.md
+++ b/content/MailingLists.md
@@ -1,11 +1,6 @@
-Title: MailingLists
-Author: trac
+Title: Mailing Lists
Date: 2016-12-15 22:39
-# Communications
-
-## Mailing Lists
-
The following lists are open to all:
* Cryptech Project Announcements<br/>
diff --git a/content/MiscStuff.md b/content/MiscStuff.md
index dd034f9..b57cde1 100644
--- a/content/MiscStuff.md
+++ b/content/MiscStuff.md
@@ -1,8 +1,6 @@
-Title: MiscStuff
-Author: trac
+Title: References & Miscellaneous
Date: 2016-12-15 22:39
-# References & Miscellaneous
## Interesting research and people
Advisory board, reviewers etc.
diff --git a/content/NoisyDiode.md b/content/NoisyDiode.md
index 2ee3711..d56ce3a 100644
--- a/content/NoisyDiode.md
+++ b/content/NoisyDiode.md
@@ -1,10 +1,8 @@
-Title: NoisyDiode
-Author: trac
+Title: Noisy Diode entropy source
Date: 2016-12-15 22:44
+Category: TRNG
-## Noisy Diode entropy source
-
The Cryptech project is using Avalanche Noise as a physical entropy source connected to the FPGA.
Avalanche breakdown is a physical process that occurs when current is forced backwards through a diode until it cannot hold back anymore. The diode will then begin conducting for a brief time until the voltage drops to a point where the diode recovers. The breakdown and recovery points are not deterministic, and can thus be used as a source of real physical entropy.
diff --git a/content/OpenCryptoChip.md b/content/OpenCryptoChip.md
index 78a0bcf..21cf356 100644
--- a/content/OpenCryptoChip.md
+++ b/content/OpenCryptoChip.md
@@ -1,11 +1,7 @@
-Title: OpenCryptoChip
-Author: trac
+Title: An Open Crypto Chip
Date: 2016-12-15 22:44
-
-# An Open Crypto Chip
-
## The Layer Cake Architecture Picture
<br/>
diff --git a/content/OpenDNSSEC.md b/content/OpenDNSSEC.md
index 5150f26..e18f3cc 100644
--- a/content/OpenDNSSEC.md
+++ b/content/OpenDNSSEC.md
@@ -1,9 +1,8 @@
-Title: OpenDNSSEC
-Author: sra
+Title: DNSSEC signing using OpenDNSSEC and a Cryptech alpha board rev03
+Author: Rob Austein
Date: 2016-12-15 22:43
Modified: 2017-05-13 21:34
-
-# DNSSEC signing using OpenDNSSEC and a Cryptech alpha board rev03
+Category: DNSSEC
## Before you start, you'll need
diff --git a/content/PKCS11Proxy.md b/content/PKCS11Proxy.md
index 792d49d..c845377 100644
--- a/content/PKCS11Proxy.md
+++ b/content/PKCS11Proxy.md
@@ -1,6 +1,6 @@
-Title: PKCS11Proxy
-Author: trac
+Title: PKCS11 Proxy
Date: 2016-12-15 22:44
+Category: Novena
The pkcs11-proxy is a way to tunnel PKCS11 over TCP (TLS). This page explains how to build and install PKCS11 proxy on the novena. There are various forks of this on github. We're going to use the SUNET fork since it support TLS-PSK for authentication out of the box. The proxy does not currently support different word length on each side of the tunnel so to use it with the novena platform your PKCS11 client must be 32 bit.
diff --git a/content/Pelican.md b/content/Pelican.md
new file mode 100644
index 0000000..932de00
--- /dev/null
+++ b/content/Pelican.md
@@ -0,0 +1,15 @@
+Date: 2021-10-07 18:55
+Title: Trac Wiki converted to Pelican Markdown
+
+The Trac Wiki that used to hold this site has been converted to a
+wiki-like setup using git, Markdown, Pelican, and m.css.
+
+* [git repository behind this Wiki](https://git.cryptech.is/wiki).
+* [Pelican documentation](https://docs.getpelican.com/en/stable/).
+* [m.css documentation](https://mcss.mosra.cz/themes/pelican/).
+
+The git repository is configured to generate the web content from the
+Markdown automatically upon receiving a `git push`.
+
+[linkchecker](https://linkcheck.github.io/linkchecker/) may also be
+useful in validating the generated content.
diff --git a/content/PostAlphaPlan.md b/content/PostAlphaPlan.md
index 1d4e152..2f38853 100644
--- a/content/PostAlphaPlan.md
+++ b/content/PostAlphaPlan.md
@@ -1,5 +1,5 @@
-Title: PostAlphaPlan
-Author: pselkirk
+Title: Post Alpha Plan
+Author: Paul Selkirk
Date: 2016-12-15 22:44
Modified: 2017-05-16 14:53
diff --git a/content/PrahaWorkshop.md b/content/PrahaWorkshop.md
index ee05282..2840629 100644
--- a/content/PrahaWorkshop.md
+++ b/content/PrahaWorkshop.md
@@ -1,11 +1,8 @@
-Title: PrahaWorkshop
-Author: trac
+Title: CrypTech Workshop, Praha, 18 July 2015
Date: 2016-12-15 22:44
+Category: Workshops
-
-# CrypTech Workshop - 2015.07.18 Praha
-
## Logistics
* Hilton Hotel, the IETF venue
diff --git a/content/PrahaWorkshopSSH.md b/content/PrahaWorkshopSSH.md
index c142f16..a99ff3d 100644
--- a/content/PrahaWorkshopSSH.md
+++ b/content/PrahaWorkshopSSH.md
@@ -1,12 +1,10 @@
-Title: PrahaWorkshopSSH
-Author: trac
+Title: Praha Workshop SSH keys
Date: 2016-12-15 22:43
+Category: Workshops
## The list of all known SSH keys
```
-
-
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDZJUtfVH0KQfdGhVetTQRpg9Ki8xGKNnO07r6df9DrrmDrsHVSsDOv8zxMoNh4XHbaLtmSCT8IkB8xLU6dXVCH4vWZZwfzaKKRNgMOSfOSc6blKKBV6xEw9qXeMe4dWcfknl3yAr6EqYsg5Lrmqgalr8Vyd6FGAoGbLR4Qh7vrahMqXp3+20kn1xfDm5reSJDbNPmU4eNhJykTNtr6l6CbK/OFzhqcMI/AW5AO0wL8f5wIoHQzescZWQMDMW+1gVyDiS8lGS6nhsSZwZZeAJrXHK/LF3ldz1To5HBxzpU5Sziav8C5bgTeYo5YfqDuBq8m9mgZTzqocXFcXUCr0I6x dol at dolmacbook
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCnskRpNxWJE/YgDR3o6sMWwwmbUJ8f2SJa0gHfHM+fcxxC2zQN9/9mqJSxS1E9QdeuRbbHpYxEUtHoX0vSrmia/VALDiQAMps51RBqq6YlrYqvP/Rb0hZ0Z4/YgjTosLdu1PeTzih6mwbyNNF0+gY987Ig31qXQytNF+9G1oSY9dgBAq52lu170QXTRwum4B6Gh4/pCnM6xx+7nY2oqlgvl2wYHVAOJ39W9r4y9kBhcVs51XvJqYehjaoyKYf1+PzA0FsvhJkZuG6ws5eEGSB90lAzKGyFZXedvOLmnFmqAraoLeuKajHIFJDfKNfHHbYpn8ERIfVW66nbqlXFO2g3 fredrik at thulin.net
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQCo3wT4gGyEmGGw5ePMO+jscvq7lo4hIPQHVZNgrChVWphvD1MkkH6PfoUYNfKwagFjUPQcDotQxGaVfvxL6Y4WzOfwiONHTj/4b2skxdRw5B/K2ZnGw2pbfXP4Nhjb1gry2K+BSVWqP3pVZk5tQ+P0YqbwKNfBFlaqS1dR8uIwo6E/8wGIjcMcDMAioMyRlU2R/u1aXQliol75GWu0jP9xrDyE3mRxoptn7kiUi9JAs/iZtlsiJh51IOADhhNMLWcmQEzKrcR2zytWZqEPzCx9C72/nPl3WacNXqdrMMT5tjt18TOFCf1jhBCHzXMu+biaoHB5sSBtue0zLFyO1A1XxLYxCp+jqlwJm2xAkS1rpFhdW3qlJZe0dV3a3TwepMGi/ObhggEk8ygwDNpYPEbgKqBcKb5RMpPJS2aEKbKd1+UStCagwPNwgRLrBME9YIAI9zyN [...]
diff --git a/content/ProjectArchive.md b/content/ProjectArchive.md
index b19a926..59e8f6a 100644
--- a/content/ProjectArchive.md
+++ b/content/ProjectArchive.md
@@ -1,8 +1,6 @@
-Title: ProjectArchive
-Author: trac
+Title: Project Archive and Far Future Planning
Date: 2016-12-15 22:44
*Page Under Construction*
-# Project Archive and Far Future Planning
## [Assured Tool Chain]({filename}AssuredTooChain.md)
diff --git a/content/ProjectManagement.md b/content/ProjectManagement.md
index 3908c61..64b4931 100644
--- a/content/ProjectManagement.md
+++ b/content/ProjectManagement.md
@@ -1,9 +1,7 @@
-Title: ProjectManagement
-Author: trac
+Title: Project Management
Date: 2016-12-15 22:44
-
# v0.1 Resources
## Human - 4-5 FTE
diff --git a/content/ProjectMetadata.md b/content/ProjectMetadata.md
index ac848ad..1568cc7 100644
--- a/content/ProjectMetadata.md
+++ b/content/ProjectMetadata.md
@@ -1,10 +1,7 @@
-Title: ProjectMetadata
-Author: trac
+Title: Project Metadata
Date: 2016-12-15 22:43
-# Project Metadata
-
## Project Logo Files
* See "Attachments" at the bottom of this page
diff --git a/content/ProjectStatus.md b/content/ProjectStatus.md
index a07c1c6..e36a113 100644
--- a/content/ProjectStatus.md
+++ b/content/ProjectStatus.md
@@ -1,11 +1,8 @@
-Title: ProjectStatus
-Author: trac
+Title: Project Status
Date: 2016-12-15 22:44
*Page Under Development*
-# Project Status
-
## [Project Dashboard]({filename}Dashboard.md)
## Crypto Chip Design and Prototype
diff --git a/content/QuickStart.md b/content/QuickStart.md
index e7f5477..24cf82c 100644
--- a/content/QuickStart.md
+++ b/content/QuickStart.md
@@ -1,24 +1,21 @@
-Title: QuickStart
-Author: sra
+Title: Quick Start
Date: 2016-12-15 22:43
Modified: 2017-05-13 20:39
-
*Page Under Development*
-# Git Repositories
+## Git Repositories
The team uses Git to store and track project development. All submissions are [signed](https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work).
The active repositories are automatically posted to GitRepositories.
-# The Alpha Board
+## The Alpha Board
The current hardware is the AlphaBoard. More information (to be organized at some point -- yes, this wiki is a mess, again):
* [AlphaBoardComponents]({filename}AlphaBoardComponents.md)
* [AlphaBoardPictures]({filename}AlphaBoardPictures.md)
-* [AlphaBoardReview]({filename}AlphaBoardReview.md)
* [AlphaBoardStrategy]({filename}AlphaBoardStrategy.md)
* [AlphaReviewLog]({filename}AlphaReviewLog.md)
* [AlphaSchematics]({filename}AlphaSchematics.md)
@@ -26,6 +23,6 @@ The current hardware is the AlphaBoard. More information (to be organized at so
The Alpha board currently ships with very old firmware, but you can [upgrade it yourself]({filename}Upgrading.md).
-# DNSSEC signing using OpenDNSSEC
+## DNSSEC signing using OpenDNSSEC
* [OpenDNSSEC]({filename}OpenDNSSEC.md)
diff --git a/content/RandomnessTesting.md b/content/RandomnessTesting.md
index 67d528e..6d8fdc7 100644
--- a/content/RandomnessTesting.md
+++ b/content/RandomnessTesting.md
@@ -1,8 +1,6 @@
-Title: RandomnessTesting
-Author: trac
+Title: Randomness Testing Tools
Date: 2016-12-15 22:43
-
-# Randomness Testing Tools
+Category: TRNG
This page explains some basics on testing for randomness, and the background necessary to understand their outputs.
diff --git a/content/RelatedWork.md b/content/RelatedWork.md
index 4526667..711e4ec 100644
--- a/content/RelatedWork.md
+++ b/content/RelatedWork.md
@@ -1,8 +1,6 @@
-Title: RelatedWork
-Author: trac
+Title: Related Work
Date: 2016-12-15 22:44
-# Related Work
## Richard Lamb / ICANN
[Presentation at ICANN](http://ccnso.icann.org/file/32383/download/37379)<br/>
diff --git a/content/ReleaseNotes.md b/content/ReleaseNotes.md
index ca48599..d9876de 100644
--- a/content/ReleaseNotes.md
+++ b/content/ReleaseNotes.md
@@ -1,15 +1,11 @@
-Title: ReleaseNotes
-Author: sra
+Title: Release Notes
+Author: Rob Austein
Date: 2017-05-13 19:06
Modified: 2017-05-13 19:18
-
-
-
-# Release Notes
+Category: Releases
## 3.0, May 2017
-
* New keystore implementation. Basically a very small flash filesystem, including basic wear leveling. Maximum number of keys varies depending on key size and how many options are attached, but for any reasonable use it should hold on the order of 2,000 keys at least.
* In-memory keystore moved to HSM (previously was in memory of the client library), uses same API as flash keystore.
* RPC mechanism extended to support the new keystores (`hal_rpc_pkey_match()`, `hal_rpc_pkey_set_attributes()`, etc).
@@ -27,11 +23,9 @@ Modified: 2017-05-13 19:18
Getting started with 3.0:
-
* [Install the software]({filename}BinaryPackages.md).
* [Upgrade the firmware]({filename}Upgrading.md). **Please note the warnings about bricking your HSM**, how to avoid that, and what to do if you failed to avoid it.
* Set the usual environment variables, perhaps using `cryptech_probe`.
* Start the multiplexer daemon `cryptech_muxd`.
-
At this point, you should be able to use the PKCS #11 library, the `cryptech_backup` script, and so forth.
diff --git a/content/Requirements.md b/content/Requirements.md
index dd15669..c0e4d8c 100644
--- a/content/Requirements.md
+++ b/content/Requirements.md
@@ -1,8 +1,6 @@
-Title: Requirements
-Author: trac
+Title: HSM Requirements
Date: 2016-12-15 22:39
-# HSM Requirements
Requirements for the Cryptech Alpha System. Derived from Use Cases (see below). There are also utility, internal requirements (again, see below).
diff --git a/content/RoughV1.md b/content/RoughV1.md
index 910e977..9a48963 100644
--- a/content/RoughV1.md
+++ b/content/RoughV1.md
@@ -1,12 +1,7 @@
-Title: RoughV1
-Author: sra
+Title: Rough Cut at v0.01 Proof of Concept Feature Set
Date: 2016-12-15 22:43
Modified: 2021-02-14 17:33
-# Rough Cut at v0.01 Proof of Concept Feature Set
-
-
-
This is a proposed version 0.01 product as a proof of concept. The
intent is not to have a very useful product, but rather to gain
confidence in our architecture, tools, and team. The result is intended
@@ -52,7 +47,6 @@ Verilog.
</h1>
```
-
* TRNG
* BigNumber, Modular, & Exponentiation (expose to green for RSA)
* SHA-256
diff --git a/content/SecureChannel.md b/content/SecureChannel.md
index 7469716..6a40c63 100644
--- a/content/SecureChannel.md
+++ b/content/SecureChannel.md
@@ -1,9 +1,8 @@
-Title: SecureChannel
-Author: sra
+Title: Secure Channel
+Author: Rob Austein
Date: 2017-07-27 00:24
Modified: 2017-07-27 19:02
-
-# Secure Channel
+Category: FutureWork
This is a sketch of a design for the secure channel that we want to
have between the Cryptech HSM and the client libraries which talk to
diff --git a/content/SideChannel.md b/content/SideChannel.md
index 9fd350e..f293753 100644
--- a/content/SideChannel.md
+++ b/content/SideChannel.md
@@ -1,10 +1,6 @@
-Title: SideChannel
-Author: trac
+Title: Side Channel Attacks
Date: 2016-12-15 22:44
-
-# Side Channel Attacks
-
Side Channel attacks on hardware are hard to avoid, detect and mitigate. But this should not stop us from trying. The CrypTech platform should be developed with side channel issues in mind. This page tries to collect information about relevant side channel attacks, mitigation strategies, side channel resistant design methods (blinding for example) and detection.
diff --git a/content/StateOfPlay.md b/content/StateOfPlay.md
index 4d9be51..6d833c8 100644
--- a/content/StateOfPlay.md
+++ b/content/StateOfPlay.md
@@ -1,10 +1,6 @@
-Title: StateOfPlay
-Author: trac
-Date: 2016-12-15 22:44
-
-
-
-# A Completely Informal Snapshot Of The Current State Of The Cryptech Project As Of 2014-11-06
+Title: A Completely Informal Snapshot Of The Current State Of The Cryptech Project As Of 2014-11-06
+Date: 2014-11-06
+Updated: 2016-12-15
This page contains a snapshot of the status in the project and will almost certainly be obsolete by the time you read it. If you find something that's wrong, please fix it!
diff --git a/content/SunetInitialDevelopment.md b/content/SunetInitialDevelopment.md
index 4b64d86..af63692 100644
--- a/content/SunetInitialDevelopment.md
+++ b/content/SunetInitialDevelopment.md
@@ -1,8 +1,7 @@
-Title: SunetInitialDevelopment
-Author: trac
+Title: Planning for SUNET funded Cryptech Work
Date: 2016-12-15 22:43
-# Planning for SUNET funded Cryptech Work
+
The following documents the first two development steps in Cryptech
funded by SUNET. The development is being done by Joachim Strömbergson
from Secworks AB.
diff --git a/content/TRNGDevelopment.md b/content/TRNGDevelopment.md
index d466093..f29e1f0 100644
--- a/content/TRNGDevelopment.md
+++ b/content/TRNGDevelopment.md
@@ -1,8 +1,8 @@
-Title: TRNGDevelopment
-Author: trac
+Title: TRNG Development
Date: 2016-12-15 22:44
+Category: TRNG
+
-# TRNG Development
One, if not THE key functionality in the Cryptech system is the True Random Number Generator (TRNG). We therefore need to discuss, investigate and test to find a TRNG that we and the users of Cryptech can trust and can verify to be trusted.
diff --git a/content/UpgradeToKSNG.md b/content/UpgradeToKSNG.md
index bb4d02d..d79a5fb 100644
--- a/content/UpgradeToKSNG.md
+++ b/content/UpgradeToKSNG.md
@@ -1,11 +1,8 @@
-Title: UpgradeToKSNG
-Author: sra
+Title: Upgrading Cryptech Alpha HSM to "ksng" development package
+Author: Rob Austein
Date: 2016-12-22 22:33
Modified: 2016-12-22 22:53
-
-
-
-# Upgrading Cryptech Alpha HSM to "ksng" development package
+Category: Releases
This page attempts to explain the upgrade procedure for testing out
the new "ksng" development branch of the Cryptech Alpha firmware.
diff --git a/content/Upgrading.md b/content/Upgrading.md
index ffeb2ef..b87038b 100644
--- a/content/Upgrading.md
+++ b/content/Upgrading.md
@@ -1,11 +1,7 @@
-Title: Upgrading
-Author: ln5
+Title: Upgrading the Cryptech Alpha HSM
Date: 2017-05-12 23:15
Modified: 2018-04-07 23:03
-
-
-
-# Upgrading the Cryptech Alpha HSM
+Category: Releases
This page explains how to upgrade the Cryptech Alpha firmware, bootloader,
and FPGA bitstream (as needed).
diff --git a/content/UsingSTLink.md b/content/UsingSTLink.md
index c51104f..a8cbda8 100644
--- a/content/UsingSTLink.md
+++ b/content/UsingSTLink.md
@@ -1,9 +1,9 @@
-Title: UsingSTLink
-Author: joachims
+Title: Using ST-Link on the Alpha Board
+Author: Joachim Strömbergson
Date: 2017-05-13 03:37
Modified: 2019-01-24 14:37
+Category: AlphaBoard
-# Using ST-LINK
ST-LINK is STM's implementation of the [| Serial Wire Debug (SWD)](https://developer.arm.com/products/architecture/cpu-architecture/debug-visibility-and-trace/coresight-architecture/serial-wire-debug) protocol.
Think of it as JTAG if you're more comfortable with that.
diff --git a/content/WhoWeAre.md b/content/WhoWeAre.md
index 0a05f78..6ad3edb 100644
--- a/content/WhoWeAre.md
+++ b/content/WhoWeAre.md
@@ -1,8 +1,6 @@
-Title: WhoWeAre
-Author: trac
+Title: Who We Are
Date: 2016-12-15 22:43
-
-# Who We Are
+Category: People
This effort was started at the suggestion of Russ Housley, Stephen Farrell, and Jari Arkko of the IETF, to meet the assurance needs of supporting IETF protocols in an open and transparent manner.
@@ -10,35 +8,28 @@ But this is not an IETF, ISOC, ... project. As the saying goes, we work for the
## Tech Core
-Fredrik Thulin<br/>
-Jakob Schlyter<br/>
-[Joachim Strömbergson]({filename}Joachim Strömbergson.md)<br/>
-Leif Johansson<br/>
-Linus Nordberg<br/>
-Lucy Lynch<br/>
-Patrik Wallström <br/>
-Павел Шатов (Pavel Shatov)<br/>
-Peter Stuge<br/>
-[Randy Bush](https://psg.com/~randy)<br/>
-[Rob Austein](https://www.hactrn.net/sra/)<br/>
-Steven Bellovin<br/>
-Basil Dolmatov<br/>
-
-```#!comment == Technical Help ==
-Bart Preneel ![0]<br/>
-Tero Kivinenv ![0]<br/>
-```
+* Fredrik Thulin
+* Jakob Schlyter
+* [Joachim Strömbergson]({filename}Joachim Strömbergson.md)
+* Leif Johansson
+* Linus Nordberg
+* Lucy Lynch
+* Patrik Wallström
+* Павел Шатов (Pavel Shatov)
+* Peter Stuge
+* [Randy Bush](https://psg.com/~randy)
+* [Rob Austein](https://www.hactrn.net/sra/)
+* Steven Bellovin
+* Basil Dolmatov
## IETF Help
-Russ Housley<br/>
-Sean Turner<br/>
-Stephen Farrell<br/>
+* Russ Housley
+* Sean Turner
+* Stephen Farrell
## Coordination
-Leif Johansson - Administration<br/>
-Randy Bush - Technical<br/>
-Russ Housley / Lynn StAmour - Finding Funding<br/>
-
-------
+* Leif Johansson - Administration
+* Randy Bush - Technical
+* Russ Housley / Lynn StAmour - Finding Funding
diff --git a/content/WikiStart.md b/content/WikiStart.md
index 872a16f..20321dc 100644
--- a/content/WikiStart.md
+++ b/content/WikiStart.md
@@ -1,8 +1,8 @@
-Title: WikiStart
-Author: sra
+Title: Welcome to the Cryptech Project
Date: 2016-12-15 20:46
Modified: 2017-05-13 20:30
-
+URL:
+save_as: index.html
# Overview
diff --git a/content/trac-to-pelican-home.md b/content/trac-to-pelican-home.md
deleted file mode 100644
index 8f1b7d9..0000000
--- a/content/trac-to-pelican-home.md
+++ /dev/null
@@ -1,35 +0,0 @@
-Date: 2021-10-07 18:55
-Title: Trac Wiki converted to Pelican Markdown
-URL:
-save_as: index.html
-
-Trac Wiki converted to Pelican Markdown
-=======================================
-
-This is a dummy landing page for a Trac Wiki site converted to
-Markdown and fed through Pelican to create a static web site.
-
-See [the conversion scripts that produced
-this](https://git.hactrn.net/sra/trac-wiki-to-markdown) for details on
-the conversion process. Be warned that it's a lot of nasty regular
-expressions, because nothing other than Trac really understand's
-Track's Wiki format.
-
-Trac's landing page is always called [WikiStart](wikistart.html).
-
-Pelican's [automatically-generated index](pelican-index.html) is the
-default Pelican landing page, but we had to move it aside to make room
-for this one.
-
-For the initial conversion we just use Pelican's default theme.
-There's a *lot* of room to adjust the appearance, and a lot of
-[example themes already available for Pelican](http://pelicanthemes.com/).
-
-Similarly, we don't do anything with Pelican's "category" mechanism
-because it has no direct analogue in TracWiki. See [the Pelican
-documentation](https://docs.getpelican.com/en/stable/) for details on
-how to use the category mechanism, or how to disable it completely.
-
-Feel free to clean all of this up, this page is just a placeholder to
-make it easy to navigate the converted wiki until a human takes over.
-
diff --git a/pelicanconf.py b/pelicanconf.py
index c6814d5..a8324d0 100644
--- a/pelicanconf.py
+++ b/pelicanconf.py
@@ -38,7 +38,7 @@ M_LINKS_NAVBAR1 = [
("Home", "wikistart.html", "wikistart", []),
("Repositories", "https://git.cryptech.is/", "git", []),
("Documents", "documents.html", "documents", []),
- ("Mailing Lists", "mailinglists.html", "mailinglists", []),
+ ("Mailing Lists", "mailing-lists.html", "mailinglists", []),
("Archives", "archives.html", "archives", []),
]
More information about the Commits
mailing list