# Table-top discussion


## Documentation and Tutorials
1. [Enrollment](https://git.infra.nkode.tech/dkelly/pynkode/src/branch/main/docs/enrollment_diagram.md)
2. [Login](https://git.infra.nkode.tech/dkelly/pynkode/src/branch/main/docs/login_diagram.md)
3. [Cipher and Renew](https://git.infra.nkode.tech/dkelly/pynkode/src/branch/main/docs/encipher_decipher_renew_nkode.md)
4. [nKode API Tutorial 1](https://git.infra.nkode.tech/dkelly/pynkode/src/branch/main/notebooks/Enrollment_Login_Renewal_Simplified.ipynb)
5. [nKode API Tutorial 2](https://git.infra.nkode.tech/dkelly/pynkode/src/branch/main/notebooks/Enrollment_Login_Renewal_Detailed.ipynb)
6. [Dispersion Tutorial](https://git.infra.nkode.tech/dkelly/pynkode/src/branch/main/notebooks/Dispersion.ipynb)
7. [Split Shuffle](https://git.infra.nkode.tech/dkelly/pynkode/src/branch/main/notebooks/Split_Shuffle.ipynb)

## Discussion Topics
### nKode Length
[Memorized Secret](https://pages.nist.gov/800-63-3/sp800-63b.html#memsecret) `Memorized secrets SHALL be at least 8 characters in length if chosen by the subscriber. Memorized secrets chosen randomly by the CSP or verifier SHALL be at least 6 characters in length and MAY be entirely numeric.`
- The minimum entropy for a randomly chosen memorized secret is approximately 20 bits.
- A keypad with 6 keys, each having 9 properties, exceeds this requirement with a minimum 4-character nKode, providing approximately 23 bits of entropy.

### nKode Observation
- Cracking an nKode [Evil nKode](https://git.infra.nkode.tech/dkelly/evilkode)
- Replay Attack

### Dispersion Attack

### nKode Over low-bandwidth

### nKode Over Unencrypted Channel
- TOTP
- DARC

### Discussion Outcomes:

#### Attacks and controls
| Attacks                 | Controls                                                                       |
|-------------------------|--------------------------------------------------------------------------------|
| Screen Recording Attack | Split shuffle/more icons per key than keys                                     |
| Exfiltrated DB          | Physically separated keys and icons, partial or full encryption, nKode renewal |
| *APT                    | *Don't wait for garbage collector, manage timeouts                             |
| Phishing                | Dispersion Resistant Keypad, nKode policy, passkey protected keypad icons      |
| *MiTM                   | TLS, *TOTP shuffle, *DARC                                                      |
*not implemented yet/needs another look

#### asks for Dr. Kandah

- Evil nKode screen watching/key replay
    - Can we rig the shuffle in our favor? How long do we need to cache?
    - shoulder surfing
    - Keylogger resistance
    - split shuffle is unbiased
- Dispersion Attack/Phishing attack
    - CAC/passkey protection for server stored icons
    - is the dispersion algorithm unbiased?
- validate the cipher
  - validate the server-side values
  - validate the relationship between the mask and the hash
  - validate the renewal
  - are these processes secure?
- Minium amount of encryption needed
  - Least encryption:brute force crack with plain text database breach
  - Most encryption: everything is encrypted
  - Is there an secure inbetween? what stays plain text what gets encrypted with HSM?
  - How long does it take to brute-force with plain and what's gained?
- how often do nkode icons need to be changed to maintain security if at all?
  - if it does need to be changed can we roll the icons? can we start with 4 icons and add icons over time?
- Low-bandwidth: how low can we go?
  - TCP vs UDP
  - Security of RX/TX without tls/encrypted channel
- Hypothetical: Break the cipher keys onto different machines in different locations?
- TOTP shuffle on client and server


Other stuff:
- unbiased icons/psychology