Saturday, November 4, 2017

NaMeCryReNoWriMo, day 4: Feistel ciphers and HSMs

Feistel cipher


https://en.wikipedia.org/wiki/Feistel_cipher

Class of block cipher.  Encryption/decryption very similar, so less to implement.  Made up of a "round" that gets performed many times.

Encryption:
(For each round)
The input is either the plaintext or the result from the previous round.  Split it into two halves, Li (Left input) and Ri (Right input).
Lo (Left output) is Ri.
Ro (Right output) is Li xored with F(Ri, Kr), where F is the underlying function of the cipher and Kr is the key for that specific round.
And now Lo and Ro are Li and Ri for the next round.

Decryption:
(For each round)
The input is the ciphertext, made up of Lo and Ro.  We want to find Li and Ri.
Ri is just Lo.
Li is Ro xored with F(Ri, Kr) [and because of above, remember that F(Ri, Kr)==F(Lo, Kr)]
And Li and Ri are Lo and Ro from the previous round, so this can be repeated back down to the plaintext.

L and R are not always balanced; Skipjack is moderately unbalanced, while the Thorp Shuffle has L as a single bit.

Most block ciphers are based on either Feistel ciphers or substitution-permutation networks (or potentially a mix of the two?)

RC4


https://en.wikipedia.org/wiki/RC4

Stream cipher.  Functions by performing repeated permutations on a block of 256 bytes and after each permutation outputs a number that's a combination of a couple of them.
Does not use a nonce, only a key.
Exact algorithm is on the wikipedia page.  I don't feel like rewriting it.
Basic weakness is that the first couple bytes of the output leak information about the initial generating key.  Key recovery attacks can be performed with millions or billions of messages (wikipedia calls out 2^26 and 2^34)
"The use of RC4 in TLS is prohibited by RFC 7465 published in February 2015."

PKCS #11


https://en.wikipedia.org/wiki/PKCS_11
http://docs.oasis-open.org/pkcs11/pkcs11-base/v2.40/errata01/os/pkcs11-base-v2.40-errata01-os-complete.pdf
http://wiki.ncryptoki.com/introduction-to-pkcs-11-specifications.ashx
https://www.opendnssec.org/softhsm/

Standardized programming interface for cryptographic operations.  Cryptoki API communicates with crypto stuff via "slots".  Slots map to crypto "tokens", usually hardware devices specifically built for cryptographic operations.  (It's possible to have a software-backed slot for testing, though, such as with the SoftHSM linked above.)  Each token can have a number of data blobs, keys, and certificates, and supports various operations on each depending on data type and configuration settings.

FIPS 140-2


https://en.wikipedia.org/wiki/FIPS_140-2
http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-2.pdf

Federal Information Processing Standard 140-2: Security Requirements for Cryptographic Modules
Defines four different levels of security for hardware+software cryptographic modules.  1 is weakest, 4 is strongest.

According to wikipedia:

Level 1: It can do some form of approved crypto.

Level 2: Has physical tamper-evident features and/or pick-resistant locks.

Level 3: Has features that wipe the crypto material in the module if it's tampered with.

Level 4: Like level 3, but to the extreme.  Must either be shown to be unaffected by abnormal environmental conditions or, if it is affected, to wipe crypto material before it's compromised.

I seem to recall there also being software components to FIPS 140-2...
Yep, wikipedia leaves out a lot of the NIST guidelines.  Good job, guys.

Level 1: Basically as shown on wikipedia.

Actually, it appears that whoever wrote the wikipedia article just grabbed the first couple sentences from each of the level summaries in the NIST doc, and as the summaries start with the physical requirements, that completely omits the interesting stuff.

Level 2: Also requires role-based auth to perform crypto operations, and requires that the hardware module be used from a computer meeting Common Criteria Protection Profiles (Annex B) and meeting CC EAL2. (whatever that means)

Level 3: Also requires identity-based auth, not just role-based.  Input or output of plaintext critical security parameters (passwords, keys, etc) must travel through physically or logically isolated ports.  Must meet Annex B plus a Trusted Path (the isolated ports thing), as well as EAL3.

Level 4: Also needs to meet EAL4.

(If it wasn't clear, Level n+1 also needs to meet all of the requirements for Level n.)

New questions/topics:

??? Pseudorandom function?  Pseudorandom permutation?  Pseudorandom generator?
??? Skipjack, key escrow, and general government chicanery
??? Thorp Shuffle? http://web.cs.ucdavis.edu/~rogaway/papers/thorp.pdf
??? Substitution–permutation network?
??? eSTREAM?
??? Play around with PKCS #11 a bit and get some code up.
??? Identity-based auth vs. just role-based?
??? Common Criteria Protection Profiles, Annex B?  EAL2/3/4?

No comments: