From 71487660812754e5f26f26595b6c3d456f9f6db8 Mon Sep 17 00:00:00 2001
From: Rob Austein <sra@hactrn.net>
Date: Fri, 8 Oct 2021 00:30:08 -0400
Subject: Get rid of conversion stuff, just build content -> website

---
 pelican/content/RoughV1.md | 128 ---------------------------------------------
 1 file changed, 128 deletions(-)
 delete mode 100644 pelican/content/RoughV1.md

(limited to 'pelican/content/RoughV1.md')

diff --git a/pelican/content/RoughV1.md b/pelican/content/RoughV1.md
deleted file mode 100644
index 910e977..0000000
--- a/pelican/content/RoughV1.md
+++ /dev/null
@@ -1,128 +0,0 @@
-Title: RoughV1
-Author: sra
-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
-to be the basis for further development into a more useful second stage,
-in the sense of
-[agile development](https://en.wikipedia.org/wiki/Agile_software_development).
-It very intentionally is not a
-[waterfall design](https://en.wikipedia.org/wiki/Waterfall_model),
-
-The interface between the Green and Yellow layers is seen as an important design
-inflection.
-
-Some code will be in C in the Green (auxiliary core) because we can get it open
-source out of the can.  for v.2 (or whatever) we would move it down to the FPGA in
-Verilog.
-
-## FPGA Overview
-![HW_sketch_v0001.png]({attach}/RoughV1/HW_sketch_v0001.png)
-<br/>
-<br/>
-## Sketch of TRNG Chain
-![HW_RNG.png]({attach}/RoughV1/HW_RNG.png)
-<br/>
-<br/>
-
-## Off-FPGA
-
-* Persistent Storage
-    * For Keys and Time
-    * Or the battery for tamper wipe is big enough to hold the FPGA up
-    * Or the Green processor has enough non-volatile store
-* Entropy Source
-* Realtime Clock
-* Tamper Mechanism
-
-
-## Layers
-
-```
-#!html
-<h1 style="text-align: left; color: blue">
-  Blue / FPGA
-</h1>
-```
-
-
-* TRNG
-* BigNumber, Modular, & Exponentiation (expose to green for RSA)
-* SHA-256
-* AES-128
-* EC for ECDH. Curve3617 would be nice, but whatever we can get open source to start
-* OpenRISC Core or ARM to support Green (maybe FreeScale from Bunnie)
-
-
-```
-#!html
-<h1 style="text-align: left; color: green">
-  Green / On-Chip Core
-</h1>
-```
-
-
-* RSA 2048 & 4096 (move to blue later) \[ 1024 for Tor? \]
-* MACs: HMAC, 1305, uMAC
-* DH (move to blue later)
-* Device Activation, Move Authorization, Wiping
-
-
-```
-#!html
-<h1 style="text-align: left; color: yellow">
-  Yellow / Off-Chip Support
-</h1>
-```
-
-
-* Interface to Red
-    * PKCS#8
-    * PKCS#11
-    * PGP Support
-* X.509 and PGP
-* PKCS#11 for POLA resistance
-* No PKCS#10 because it will take a year
-* Backup may be just dump/restore of the whole FPGA/CoreState
-
-
-```
-#!html
-<h1 style="text-align: left; color: red">
-  Red / Applications
-</h1>
-```
-
-
-* X.509 CA
-* DNSSEC
-* PGP (asymmetric key sign/verify + symmetric message encryption/decryption)
-* Tor consensus(?)
-
-
-## Issues in v0.01
-
-
-* License of tool chain to build
-* License for borrowed components (open cores, open fpga)
-* License for result
-    * What we build ourselves - BSD
-    * What components we ship - life is compromise
-* Toolchains, Verilog, C, ...
-* FPGAs and ASICs use a Verilog-based toolchain.  There are no mature open
-  Verilog compilers so the [DDC approach](http://www.dwheeler.com/trusting-trust/)
-  will not work.  Net-list optimization is also an issue.  We're looking into this,
-  but it's going to be really hard.  Research for v2.
-* Protoyping platform
-    * [Bunnie's Novena laptop](http://www.bunniestudios.com/blog/?p=3265)
-    * Altera Evaluation Board
-* RTC, external connectivity to et some sort of assured time
-* Repository - too many git junkies.  Keep main repo on our server for the security boundary.  Can mirror on GitHub to be socially cool.
-* Emacs or vi (no Rob, not TECO) :)
-- 
cgit v1.2.3