Rename for conversion

1 files changed, 0 insertions, 136 deletions

diff --git a/raw-wiki-dump/Requirements b/raw-wiki-dump/Requirements
deleted file mode 100644
index 50c54b0..0000000
--- a/raw-wiki-dump/Requirements
+++ /dev/null
@@ -1,136 +0,0 @@
-= HSM Requirements

-

-Requirements for the Cryptech Alpha System. Derived from Use Cases (see below). There are also utility, internal requirements (again, see below).

-

-== Capacity

-=== Per key storage requirements

-In addition to the actual key data, each key requires 

-- Key type – 4 bytes

-- Key identifier – 4 bytes

-- Key flags, e.g. exportable – 8 bytes

-This results a total 16 bytes overhead for each key.

-

-=== Examples per algorithm

-(For RSA, we  might also want to include the primes p and q might also be included which requires additional storage.)

-

-- RSA-8192 requires 1024 bytes secret key, 1024 bytes public key + 4 bytes exponent + 16 bytes overhead = 2068 bytes

-- RSA-4096 requires 512 bytes secret key,   512 bytes public key + 4 bytes exponent + 16 bytes overhead = 1044 bytes

-- RSA-2048 requires 256 bytes secret key,   256 bytes public key + 4 bytes exponent + 16 bytes overhead = 532 bytes

-- EC P-256 requires 32 bytes secret key, 64 bytes public key + 16 bytes overhead = 112 bytes

-- EC P-384 requires 48 bytes secret key, 96 bytes public key + 16 bytes overhead = 160 bytes

-- Curve 25519 requires 32 bytes secret key, 32 bytes public key + 16 bytes overhead = 80 bytes

-

-

-== Use Cases

-=== DNSSEC

-==== Number of keys

-- TLD (or provider using key sharing) requires ~ 100 key pairs

-- 3 KSK per zone (previous, current, new)

-- 3 ZSK per zone (previous, current, new)

-==== Possibly dual algorithms

-- A typical TLD operator usually has less than 10 TLDs

-- Other DNS providers may use key sharing to limit number of keys required

-==== Algorithms

-- RSA-1024/SHA-256

-- RSA-2048/SHA-256

-- EC-P256/SHA-256

-==== Performance

-Each update to a zone requires 3-4 signatures (per algorithm)

-- Resign SOA (signed by ZSK)

-- Resign updated RR (signed by ZSK)

-- Resign NSEC/NSEC3 (signed by ZSK), may require multiple signatures

-Non-interactive latency (batch), dynamic updates may require faster signing

-

-=== SAML 

-==== Number of keys

-SAML federation operator requires max 10 key pairs (including space for roll)

-==== Algorithms

-- RSA-2048/SHA-256

-==== Performance

-- Non-interactive latency (batch)

-  - non-MDX: …

-- Interactive latency

-  - MDX: …

-

-=== PKIX (including RPKI)

-==== Number of keys

-- Typical Certification Authority ~ 10 key pairs

-  - CA key, OCSP, CRL per level in the CA

-  - Root CA is one level

-  - For subordinate CAs, perhaps 2-5 CAs in a HSM is reasonable?

-==== Algorithms

-- RSA-2048/SHA-256

-- RSA-4096/SHA-256

-- RSA-4096/SHA-512 ?

-- EC-P256/SHA-256

-==== Performance

-- Non-interactive latency

-  - Root CA: Less than 1 signature per day

-  - Issuing CA: One signature per issued certificate

-  - CRL: Less than 1 signature per hour

-- Interactive latency

-  - OCSP: Multiple signatures per second

-

-=== Tor

-Requirements according to (section 1): https://gitweb.torproject.org/torspec.git/plain/dir-spec.txt

-==== Number of keys

-- 1 private key

-- 10 public keys

-==== Algorithms

-- RSA-2048/SHA-1 ?

-- RSA-2048/SHA-256

-- RSA-4096/SHA-256 ?

-- RSA-4096/SHA-512 ?

-==== Performance

-- 2 signatures per hour

-- 20 verification operations per hour

-- 1 second max latency for RSA-2048 based verification

-

-=== Certificate Transparency (CT)

-==== Number of keys

-CT requires 1 key (ECDSA or RSA) per log

-==== Algorithms

-- RSA-2048/SHA-256

-- RSA-4096/SHA-256 ?

-- RSA-4096/SHA-512 ?

-- EC-P256/SHA-256

-==== Performance

-- A Certificate Transparency log uses one ECDSA or one RSA key to sign two separate documents:

-- STH's might need to be signed once per hour

-- SCT's might need to be signed once per second (*)

-

-See RFC 6962, section 2.1.4 – https://tools.ietf.org/html/rfc6962

-

-

-== Internal Functional Requirements

-

-=== Algorithms and functions

-- Key wrapping using AES-256 with SIV, http://tools.ietf.org/html/rfc5297

-- Internal Storage Master Key (ISMK) in battery backed RAM connected to FPGA

-  - Battery connection controlled by tamper mechanism

-  - Active erasure controlled by tamper mechanism

-- 32-bit high quality random number generation

-

-=== PKCS11

-

-The following PKCS11 mechanisms are required to fulfill the aforementioned use cases:

-

-- RSA

-  - CKM_RSA_PKCS_KEY_PAIR_GEN

-  - CKM_RSA_PKCS

-  - CKM_RSA_X_509 ?

-  - CKM_SHA256_RSA_PKCS

-  - CKM_SHA512_RSA_PKCS ?

-- ECDSA

-  - CKM_EC_KEY_PAIR_GEN

-  - CKM_ECDSA

-- AES

-  - … TBD …

-- Random

-  - … TBD …

-- Key Wrapping

-  - … TBD …

-- Hash

-  - CKM_SHA256

-  - CKM_SHA512 (?)

-