diff options
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 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 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ömbergson.md b/content/Joachim Strömbergson.md index 5a74548..77475a6 100644 --- a/content/Joachim Strömbergson.md +++ b/content/Joachim Strömbergson.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@dolmacbook ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCnskRpNxWJE/YgDR3o6sMWwwmbUJ8f2SJa0gHfHM+fcxxC2zQN9/9mqJSxS1E9QdeuRbbHpYxEUtHoX0vSrmia/VALDiQAMps51RBqq6YlrYqvP/Rb0hZ0Z4/YgjTosLdu1PeTzih6mwbyNNF0+gY987Ig31qXQytNF+9G1oSY9dgBAq52lu170QXTRwum4B6Gh4/pCnM6xx+7nY2oqlgvl2wYHVAOJ39W9r4y9kBhcVs51XvJqYehjaoyKYf1+PzA0FsvhJkZuG6ws5eEGSB90lAzKGyFZXedvOLmnFmqAraoLeuKajHIFJDfKNfHHbYpn8ERIfVW66nbqlXFO2g3 fredrik@thulin.net ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQCo3wT4gGyEmGGw5ePMO+jscvq7lo4hIPQHVZNgrChVWphvD1MkkH6PfoUYNfKwagFjUPQcDotQxGaVfvxL6Y4WzOfwiONHTj/4b2skxdRw5B/K2ZnGw2pbfXP4Nhjb1gry2K+BSVWqP3pVZk5tQ+P0YqbwKNfBFlaqS1dR8uIwo6E/8wGIjcMcDMAioMyRlU2R/u1aXQliol75GWu0jP9xrDyE3mRxoptn7kiUi9JAs/iZtlsiJh51IOADhhNMLWcmQEzKrcR2zytWZqEPzCx9C72/nPl3WacNXqdrMMT5tjt18TOFCf1jhBCHzXMu+biaoHB5sSBtue0zLFyO1A1XxLYxCp+jqlwJm2xAkS1rpFhdW3qlJZe0dV3a3TwepMGi/ObhggEk8ygwDNpYPEbgKqBcKb5RMpPJS2aEKbKd1+UStCagwPNwgRLrBME9YIAI9zyN8sFgHyy70q2XzhUJ5zz+X8JMVaKEKMTVh31u01jQchdvHkkGD7/xbp3hluFOCI1ChYKSlRdakoS6XnPopZ/0tHrkpk+k5lScu9lPHvBTMa3gq+b++TDbkW8dtYq3c78xHcAmOEjXvezbTnKpe/dRfWEUbmrGOch3mzDPoYAtjj7fdEWUGELhCSJB813B7HcGS6oXmW0PYEtOEIgeo83JX6i2qYiTQmjY1kOgBw== jakob@kirei.se 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", []), ] |