hammer/notes
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Migrate Markdown-Notes: projects, meetings, reference, personal

Browse Source
This commit is contained in:
Hammer
2026-01-26 22:05:01 +00:00
parent 9507ddf856
commit 49025b3586
93 changed files with 3422 additions and 11 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
archive/100 Mistakes in Go.md Normal file
View File

@@ -0,0 +1,6 @@
## Ch. 2 Code and Project Organization
##### 2.12 Project misorganization
- main.go should be in /cmd/projectname
- api integration test like main_test.go should be in /test
- sqlc should be in /vendor/sqlc

0
archive/2025-01-01.md Normal file
View File

18
archive/AU Ask for Craig.md Normal file
View File

@@ -0,0 +1,18 @@
# Meeting Notes 12/2/24: AU Ask for Craig
### Highest Priority
- Cipher: Validate our passcode and set cipher.
- Shuffle: Quantify our shuffle algorithm with different policies. Given a policy, what's the average number of observations to crack an nKode? What's the variance? What does the distribution curve look like?
### Middle Priority
- Database: Analysis of database encryption. What are the security implications of encrypting different parts of our database? What's the minimum amount of encryption we can do?
### Low Priority
- DARC: Analyis our post quantum passkey (aka DARC)
Start off with by quantifing, and qualifing our shuffle algorithm and passcode cipher. We'll need some statistics people on the shuffle algo and encryption people on the cipher.
After that, we'll need encryption people to help use figure out what the minimum about of encryption we can do with our database.

10
archive/Auburn Ask.md Normal file
View File

@@ -0,0 +1,10 @@
Date: 1/23/25
1. One of our original asks was: **How many key-selection observations are required to crack an nKode under a given policy configuration?**
1. Now that I've written the code, we need them to validate its accuracy.
2. Our new ask should be:
1. We've developed a simulation to answer: **How many key-selection observations are required to crack an nKode under a given policy configuration?**
Our new ask is, please provide your Github handles so Donovan can add you to the repository.
2. Another ask is:
1. How many observations are required to execute a reentrancy attack on an nKode under a given policy configuration?
3. Validate the nKode cipher.

8
archive/Chat with Tim Tucker about nKode.md Normal file
View File

@@ -0,0 +1,8 @@
# Chat with Tim Tucker about nKode
- no more anaconda it requires a license
- do we need a docker license? --- it does but it's not that bad
- what about all the other stuff like gitea? --- gitea is open sources
- Can we open source nkode with license? --- maybe
- customers want isolation. they don't want share machines
- Is SSO feasible? if everyone wants their own nKode then people will have memorize many nKodes

99
archive/DARPA Slides.md Normal file
View File

@@ -0,0 +1,99 @@
Here's what i've got so far
Intro slide 1
title: Warfighter Zero Trust Authentication at the Tactical Edge
Slide 2
Title: Authentication Factors – Passwords Are the Weak Link
Content:
•Something You Have: CAC Card, Passkey – Physical, secure, warfighter-ready.
•Something You Are: Face, Fingerprint, Voice – Unique, hard to steal.
•Something You Know: Passwords, Codes, Questions – Easy to crack, forget, or intercept.
Slide 3
title: Passwords Are Old – And Obsolete
content:
•1961: First password login on a time-sharing OS.
•1962: Bug exposed all passwords in plain text—exploited instantly.
•2022: 24+ billion stolen credentials flood the dark web.
•Today: nKode replaces ancient passwords with edge-ready security.
Slide 4
title: Good Passwords Are Hard to Remember – And Still Fail
content:
•Problem: Complex passwords (e.g., 99$T7oEJ^&pHp%5#hb) defy memory.
•Weakness: Reuse invites credential stuffing; keyloggers grab every stroke.
•Flaw: Reliance on perfect encryption—compromised channels doom passwords.
•Fix: nKode ditches passwords for secure, simple warfighter auth.
Slide 5
title: Credential Stuffing – Passwords Betray the Mission
content:
•Threat: 80% of breaches start with stolen passwords reused in automated attacks.
•Risk: Commercial breaches (e.g., email, banking) expose military accounts if warfighters overlap.
•Problem: You can’t control external leaks; passwords make it your mess.
•Solution: nKode ends password risks with edge-ready security.
Slide 6
title: Keyloggers + Passwords = Warfighter Risk
content:
•Threat: Keyloggers (software/hardware) steal passwords by recording keystrokes.
•Risk: Exposes military networks and tactical edge ops to adversaries.
•Problem: Hard to detect; passwords are the weak link.
•Solution: nKode eliminates passwords, secures warfighters.
Slide 7
title: nKode Authenticates Over Compromised Channels
content:
•Challenge: Encrypted channels (e.g., TLS) can be compromised by MITM attacks.
•Risk: Adversaries intercept or spoof credentials, disrupting tactical edge ops.
•nKode Advantage: Authenticates reliably even if encryption is breached.
•How: An nKode keypad randomly shuffles making it impossible to know what icons are getting selected
Slide 8
title: nKode Outclasses Passwords – Warfighter Ready
content:
•Passwords Fail: Hard to recall, reused, nabbed by keyloggers.
•nKode Wins: Pictographic, unique, keylogger-proof.
•Edge Power: Authenticates over compromised channels, <1KB bandwidth.
•Bottom Line: Simple to use, impossible to crack.
Slides 9-11
Explains what nKode is and how it works
Slide 12
Title: The Team
Content:
content about the team...
Slide 13
Demo
I think the flow should be different:
The 2nd slide "Authentication Factors... " is a good intro.
I think the slides that discuss all the different attacks then explain how nkode fixes the issue should be change.
I think the slides should first introduce the problem of passwords.
It should explain how the state-of-the-art in Something you know authentication has stagnated for the last 60 years where something you have and something you are have made progress in leaps and bounds.
Then i should explain what nKode is. After the audience has a basic explanation of nkode, i can wrap up by explaining how nkode can solve all the vulnerabilities of passwords followed by the demo

48
archive/Eagle Venture Lab application.md Normal file
View File

@@ -0,0 +1,48 @@
# Eagle Venture Lab
## Step 1
### Your Elevator Pitch should summarize the problem that needs to be addressed and why your startup is the best solution to that problem.
#### 30-Second Elevator Pitch (100 words max)*
Password authentication has two main problems.
1) People choose bad passwords. Only 1/3 of Americans use password managers. The other 2/3rds pick their own, and most people choose bad passwords.
2) People reuse their bad passwords on multiple sites. If you aren't using a password manager, you're likely reusing the same password over and over.
nKode is a pictographic passcode where users can only choose a strong passcode, and no two people will be able to choose the same passcode.
### One-Sentence Pitch (25 words max)*
nKode is a pictographic passcode that is easier to remember and more secure than a password.
### Briefly describe your revenue model for your offering (50 words max)*
We have two revenue models.
1) B2B model: nKode is used by businesses for employee authentication.
2) B2C model: nKode is used by individuals to login into their accounts as you would with "Sign in with Google" or "Sign in with Apple". Arcanum Technology creates services like Clerk.com or Auth0.com.
### Briefly describe your startup's journey to date:
- Tell us about yourself and why you started the business
- Describe your team and how they came together, if applicable
- How have you validated your idea?
- How have you executed on your idea?
- What is your greatest need to help you get launched?
Brooks Brown invented nKode after a credit card skimmer stole his debit card pin number. nKode prototype version was a modified keypad with numbers instead of images.
Before the pandemic, Arcanum developed nKode for banks and financial institutions. Most financial institutions we've approached over the years want to use nKode, but none want to be the first to integrate it.
I'm the most recent founder to join Arcanum. I joined because I saw a company with a patent for an incredible technology that could dominate the identity and access management space.
Since joining, I've also developed nKode Gen2 an even more secure implementation of nKode.
We've also pivoted from trying to sell nKode to finding a strategic partner. We need a large company or institution with industry trust to stand behind our technology.
### Briefly describe your go-to-market plan, including how you will acquire customers and any applicable sales channels you plan on selling through (50 words or less)
Our Go-to-Market plan is to find strategic partners in industry or academia with cybersecurity expertise to validate our technology. With the backing of our strategic partner, we'll reapproach the companies that expressed interest in nKode but were unwilling to try it first.
### Briefly describe your potential exits and the profile of the mostly likely acquirer of your company (50 words or less)*
Our exit strategy is to be acquired by a company in the identity and access management space. A company like Okta has the most to gain with a Arcanum's patent.

9
archive/Email to Jonathan.md Normal file
View File

@@ -0,0 +1,9 @@
Tabletop Senarios
Hi Jonathan,
Great talk on Wednesday! I’d like to set up a time next week to go over some tabletop scenarios together via Teams. Could you let me know what days and times work best for you?
Thanks,
Donovan

65
archive/Gitea Server.md Normal file
View File

@@ -0,0 +1,65 @@
# Gitea Server
- ChatGPT conversation: https://chatgpt.com/share/672ece16-da60-8009-83de-9b33c08aed6a
- follow the basic ubuntu setup first
### Install docker
https://docs.docker.com/engine/install/ubuntu/
### Docker compose
```
version: "3"
networks:
gitea:
external: false
services:
server:
image: gitea/gitea:latest
container_name: gitea
environment:
- USER_UID=1000
- USER_GID=1000
- GITEA__service__DISABLE_REGISTRATION=true
- GITEA__service__ENABLE_OPENID_SIGNIN=false
- GITEA__service__ENABLE_OPENID_SIGNUP=false
restart: always
networks:
- gitea
volumes:
- ./gitea:/data
- /etc/timezone:/etc/timezone:ro
- /etc/localtime:/etc/localtime:ro
ports:
- "3000:3000" # Gitea web interface
- "2222:22" # Gitea SSH
```
### Run docker compose
`docker-compose up -d`
`docker exec -it gitea /bin/bash`
`gitea admin user create --username admin --password YourPassword --email admin@example.com --admin`
### SQLITE DB
to get into the database
sqlite3 /data/gitea/gitea.db
for users, go to the user table
#### Delete a user
```
DELETE FROM user WHERE email = 'donovan.a.kelly@pm.me';
DELETE FROM email_address WHERE email = 'donovan.a.kelly@pm.me';
DELETE FROM external_login_user WHERE email = 'donovan.a.kelly@pm.me';
```

140
archive/OpenID Connect Passport Notes.md Normal file
View File

@@ -0,0 +1,140 @@
## Ch. 2
## Ch. 3 OpenId Connect Endpoints
##### 3.1 Authorization Endpoint
- displays authentication and consent screen
- returns `authorization_code` See ch. 5
- client initiates the call to the authorization endpoint
###### 3.1.2 input parameters with examples
```
scope: openid profile email address phone
response_type: code (backend flow) || id_token token (frontend flow) || code id_token (hybrid)
client_id: id of the client
redirect_uri: redirect url
state: cross-site scripting protection
nonce: required for implict flow (frontend flow)
Optional Params: (more research on each)
claims:
display:
prompt:
max_age: maximum lifetime of the token in seconds after which the user must re-authenticate
ui_locales:
id_token_hint:
login_hint:
acr_values:
```
###### 3.1.3 Output
Sends authentication and access delegation (authorization) tokens to redirect endpoint. Token/s are sent as an HTTP 302 redirect.
##### Ch 3.2 Resource Endpoint
Managed by the resource provider. Serves protected resources to authorized parties. valid OAuth `access_token` required
##### Ch 3.3 Userinfo Endpoint
This is a resource endpoint `/userinfo` that serves profile information of the authenticated end-user.
This endpoint returns a list of claims like DOB, name, email, phone_number, profile_picture or any other claim.
This is Defined in the OpenID Connect Standard.
To the OAuth server, it's just a resource endpoint.
1) Will typically be a GET request but should support POST (not sure why)
2) should support CORS
3) Should return JSON `Content-Type: application/json` Might need to be a JWT `Content-Type: application/jwt`
```
List of Claims:
sub: something to id the user
name
family_name
preferred_username
picture
email
birthday
zoneinfo: time zone
updated_at: last updated to the profile
Other Claims:
nonce
auth_time
at_hash: access_token hash
c_hash: authorization_code hash
acr: more research
amr: more research
sub_jwk: public key to check the signature of the id_token
```
##### 3.4 Token Endpoint
Called by the Client.
Client sends client_id, client_secret, and authorization_code to get an access_token, refresh_token, or id_token
```
Client->/token
HTTP header
Content-Type: application/x-www-form-urlencoded
Authorization: Basic {Base64URL-encoding(clientID:clientSecret)}
Form Parameters:
grant_type: authorization_code
code: the authorization_code proved by the authorization endpoint
redirect_ur: redirect URL
Response:
Header:
Cache-Control: no-store
Pragma: no-cache
Body:
{
expires_in: access_token expiration in seconds,
access_token: OAuth access_token,
token_type: access token type `Bearer`,
refresh_token: OAuth refresh_token,
id_token: id_token for the end user
}
```
###### 3.4.4 Validations at the Token Endpoint
- Authenticate the client
- validate authorization_code
- was issued to client
- is valid
- hasn't been used
- validate redirect_uri matches pre-registered value
##### 3.5 Redirect Endpoint
authorization endpoint delivers `id_token, access_token, authorization_token`
## Ch. 4 Tokens in OpenID Connect
```
id_token
access_token
refresh_token
authorization_code
```
##### Two types of tokens:
**Reference Tokens
- Randomly Generated String
- Opaque
**Value Token
- Contain things like claims ie JWT
##### 4.2 Access Token
- typically reference tokens
- holder has access rights to Resource Provider
- short lived token
- bearer token
- id_token typically bound to the access token what the `at_hash` claim
##### 4.3 Refresh Token
- long lived token
- used to request new id_token and access_token
- not available with implicit flow
##### 4.4 Authorization Code
- very short lived token
- only give after authentication and consent
- only used to request an `access_token` (I think the book means refresh_token but access_token and id_tokens can be sent too)
##### 4.5 ID Token
- Contains claims
- is a value token
- is a JWT, JWE, or JWS
## Ch. 5 OpenID Connect Flows
## ChatGPT flow:
https://chatgpt.com/c/677a04ed-58cc-8009-b191-be8164bc4946

205
archive/OpenVPN and CA install.md Normal file
View File

@@ -0,0 +1,205 @@
# OpenVPN and CA install
### sources
- https://www.digitalocean.com/community/tutorials/how-to-set-up-and-configure-an-openvpn-server-on-ubuntu-20-04
- https://chatgpt.com/share/672b8e75-5a08-8009-9d13-f062d91bfac8
### Prereqs
ubunutu 24 with ufw configured
### Update/Upgrade
```
sudo apt update
sudo apt upgrade -y
```
### Install OpenVPN and Easy-RSA
`sudo apt install openvpn easy-rsa -y`
### Setup CA
```
make-cadir ~/openvpn-ca
cd ~/openvpn-ca
```
```
vi vars
```
```
set_var EASYRSA_REQ_COUNTRY "YourCountry"
set_var EASYRSA_REQ_PROVINCE "YourProvince"
set_var EASYRSA_REQ_CITY "YourCity"
set_var EASYRSA_REQ_ORG "YourOrganization"
set_var EASYRSA_REQ_EMAIL "email@example.com"
set_var EASYRSA_REQ_OU "YourOrganizationalUnit"
```
```
./easyrsa init-pki
./easyrsa build-ca
```
add password to ca
### Generate Certs and Keys
`./easyrsa gen-req server nopass`
`./easyrsa sign-req server server`
Type yes and enter ca password
`./easyrsa gen-dh`
`openvpn --genkey --secret ta.key` // this is deperacated need update
### Config OpenVPN Server
`sudo cp pki/ca.crt pki/private/server.key pki/issued/server.crt pki/dh.pem ta.key /etc/openvpn/`
`sudo vi /etc/openvpn/server.conf`
```
port 1194
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key # This file should be kept secret
dh dh.pem
tls-auth ta.key 0 # This file should be kept secret
cipher AES-256-CBC
auth SHA256
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "route {ip.addr.ess.0 last byte is masked} 255.255.255.0" # Replace with masked ip address
keepalive 10 120
persist-key
persist-tun
user nobody
group nogroup
status openvpn-status.log
verb 3
```
### Enable IP Forwarding
`sudo vi /etc/sysctl.conf`
```
net.ipv4.ip_forward=1
```
`sudo sysctl -p`
### Config Firewall
`sudo vi /etc/default/ufw`
change: `DEFAULT_FORWARD_POLICY="ACCEPT"`
`sudo vi /etc/ufw/before.rules`
Replace IP Address:
```
# START OPENVPN RULES
*nat
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -s 10.8.0.0/8 -o {ADD IP ADDRESS} -j MASQUERADE
COMMIT
# END OPENVPN RULES
```
`sudo ufw allow 1194/udp`
`sudo ufw enable`
### Start OpenVPN
```
sudo systemctl start openvpn@server
sudo systemctl enable openvpn@server
sudo systemctl status openvpn@server
```
### Client Config
```
mkdir -p ~/client-configs/keys
mkdir -p ~/client-configs/files
```
`vi ~/client-configs/base.conf`
Rplace MY IP ADDRESS
```
client
dev tun
proto udp
remote {MY IP ADDRESS} 1194
resolv-retry infinite
nobind
user nobody
group nogroup
persist-key
persist-tun
remote-cert-tls server
cipher AES-256-CBC
auth SHA256
key-direction 1
verb 3
```
### Client Certificates and Keys
`cd ~/openvpn-ca`
Replace client1 with client_name
```
./easyrsa gen-req client1 nopass
./easyrsa sign-req client client1
```
`cp pki/ca.crt pki/issued/client1.crt pki/private/client1.key ta.key ~/client-configs/keys/`
`vi ~/client-configs/make_config.sh`
### Generate Client Keys
Replace client name
```
#!/bin/bash
CLIENT_NAME={client name}
KEY_DIR=~/client-configs/keys
OUTPUT_DIR=~/client-configs/files
BASE_CONFIG=~/client-configs/base.conf
mkdir -p $OUTPUT_DIR
cat ${BASE_CONFIG} \
<(echo -e '<ca>') \
${KEY_DIR}/ca.crt \
<(echo -e '</ca>\n<cert>') \
${KEY_DIR}/${CLIENT_NAME}.crt \
<(echo -e '</cert>\n<key>') \
${KEY_DIR}/${CLIENT_NAME}.key \
<(echo -e '</key>\n<tls-auth>') \
${KEY_DIR}/ta.key \
<(echo -e '</tls-auth>') \
> ${OUTPUT_DIR}/${CLIENT_NAME}.ovpn
```
`chmod 700 ~/client-configs/make_config.sh`
`./client-configs/make_config.sh`
### Distribute Client Config
{client name}.ovpn is now available in ~/client-configs/files/.

52
archive/Table-Top Prep.md Normal file
View File

@@ -0,0 +1,52 @@
## nKode API
- Describe each endpoint; it's inputs and outputs
- Flowchart/network diagram of enrollment and login
## Table-Top Scenarios
- nKode observation (shoulder surfing)
- nKode observation (screen recording)
-
```mermaid
graph TD
A[Start] --> B[Process]
B --> C[End]
```
``` mermaid
sequenceDiagram
participant Client
participant Server
Note over Client,Server: Initial Connection
Client->>Server: Connection Request
Server-->>Client: Connection Accepted
Note over Client,Server: Data Transfer 1 - Client to Server
Client->>+Server: Send Matrix Data
Note right of Client: Matrix Data:
Note right of Client: | 10 | 15 | 20 |
Note right of Client: | 25 | 30 | 35 |
Note right of Client: | 40 | 45 | 50 |
Server->>Server: Process Matrix
Server-->>-Client: Acknowledge Receipt
Note over Client,Server: Data Transfer 2 - Server to Client
Server->>+Client: Return Processed Matrix
Note left of Server: Processed Matrix:
Note left of Server: | 20 | 30 | 40 |
Note left of Server: | 50 | 60 | 70 |
Note left of Server: | 80 | 90 | 100 |
Client->>Client: Display Results
Client-->>-Server: Acknowledge Receipt
Note over Client,Server: Connection Termination
Client->>Server: Disconnect Request
Server-->>Client: Disconnect Confirmed
```

7
archive/Talk with Tim Tucker about nKode.md Normal file
View File

@@ -0,0 +1,7 @@
- no more anaconda
- do we need a docker license?
- what about all the other stuff like gitea?
- Can we open source nkode with license?
- customers want isolation. they don't want share machines
- Is SSO feasible? if everyone wants their own nKode then people will have memorize many nKodes
- Is SSO feasible? if everyone wants their own nKode then people will have memorize many nKodes

7
archive/Thoughts on Nick Sellers action plan.md Normal file
View File

@@ -0,0 +1,7 @@
Craig:
Huntsville meeting 3/26-3/28 works for me.
Nick. Great action plan here are some of my thoughts:
I'll lead Arcanum's Phase I SBIR topics and solicitations.
https://www.sbir.gov/topics?keywords=&status=Open&agency=&program=&phase=&year=&open_date_from=&open_date_to=&close_date_from=&close_date_to=&page=0

12
archive/X Post VPS vs AWS.md Normal file
View File

@@ -0,0 +1,12 @@
I studied computer engineering in school and decided to change my career from an embedded system/firmware path to web development.
When I started down that path, spent a lot of time learning AWS, Azure and GCP (Big Cloud) thinking they were the only way to build web apps and APIs.
They offer so many tools and seemingly infinite scale.
This is a trap. These cloud platforms are difficult to use and expensive.
With @coolifyio and @Hetzner_Online, I spend less time on infrastructure and more time on building my app.
I'm not concerned with how I'll scale my app to infinity.
I'm focused on building something that works.
After that'll shift my efforts towards getting customers.
If my app is successful and my current infrastructure is struggling, I'll spend my time on that, but today that isn't my problem.
Big cloud solves problems most application don't have and never will.
Don't fall for their trap.
Keep it simple, stupid.

16
archive/email to Founder University.md Normal file
View File

@@ -0,0 +1,16 @@
# Email to Founder University
Hi Kelly and Lukas,
Thank you for taking the time to review our application. We're so delighted to have received an acceptance from you. It means a lot to me and the team that you'd include us in your 9th cohort.
I'm a big fan of the All In Podcast and This Week in Startups, so I leaped at the opportunity without considering whether I'd be a good fit for Founder University. After a deeper look at the program, I don't think we'd be a good fit.
My cofounders and I have been trying to get our technology into mostly fintech companies for over five years, and there is a lot of interest in nKode. Despite this interest, companies are unwilling to do so with a technology that has yet to be widely adopted or has the backing of a trusted identity provider.
This year, we have shifted our focus to finding a strategic partner (like Okta or Microsoft) with the credibility to back nKode as a secure authentication technology.
Here's our ask: can we set up a meeting with you or someone on your team to help us find a strategic partner?
Thanks,
Donovan

8
archive/google accelorator questions and answers.md Normal file
View File

@@ -0,0 +1,8 @@
# Why do you want to apply to this program? What are your expectations?
My cofounders and I have been trying to get our technology into mostly fintech companies for over five years, and there is a lot of interest in nKode. Despite this interest, companies are unwilling to do so with a technology that has yet to be widely adopted or has the backing of a trusted identity provider. We hope this will lead us to a strategic partner with the credibility to take nKode to market.
# How can you contribute to the success of other startups in your cohort?
As CTO of Arcanum Technology, I can contribute to the success of other startups by sharing my technical expertise in LLM/RAG development and authentication. I have experience accross a wide domain of tech stacks from embedded system to web development. I can provide mentorship on technicial problems other in my cohort migh have.
# Tell us about the founding team story
Brooks Brown, the inventor of nKode, got the idea for it when a family friend had their debit card number and pin stolen from credit card skimmer. He originally developed nKode as a way to make skimming impossible.

75
archive/hetzner_coolify_setup.md Normal file
View File

@@ -0,0 +1,75 @@
# Hetzner Coolify Setup
## Sources
- https://www.youtube.com/watch?v=taJlPG82Ucw&t=56s
## Hetzner dashboard setup
- add ssh key
- add this to cloud init
``` cloud_init.yml
# This config was written for Ubuntu 22.04
# If you are using a more recent version, see the comments of this gist for fixes
#cloud-config
users:
- name: dkelly
ssh_authorized_keys:
- "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIKQWloxYNqNyOw6KKXsQnYPakthlq9gqf5qR1QGR1g6w donovan.a.kelly@pm.me"
sudo: ALL=(ALL:ALL) ALL
groups: sudo
shell: /bin/bash
chpasswd:
expire: true
users:
- name: dkelly
password: replacethispasswordplease
type: text
runcmd:
- sed -i '/PermitRootLogin/d' /etc/ssh/sshd_config
- echo "PermitRootLogin without-password" >> /etc/ssh/sshd_config
- sed -i '/PubkeyAuthentication/d' /etc/ssh/sshd_config
- echo "PubkeyAuthentication yes" >> /etc/ssh/sshd_config
- sed -i '/PasswordAuthentication/d' /etc/ssh/sshd_config
- echo "PasswordAuthentication no" >> /etc/ssh/sshd_config
- systemctl restart sshd
- echo "\$nrconf{kernelhints} = -1;" > /etc/needrestart/conf.d/99disable-prompt.conf
- apt update
- apt upgrade -y --allow-downgrades --allow-remove-essential --allow-change-held-packages
- reboot
```
## Setup
- ssh into root
```
apt update
apt upgrade
reboot
```
- Don't mess with ufw or ssh config or worry about create a sudo user. Do this at the end
## Install Coolify
curl -fsSL https://cdn.coollabs.io/coolify/install.sh | bash
## Setup
- create username and password. we'll have to change this later because it doesn't use ssl
- select localhost
## Lock down the server
- ssh into dkelly user and change password
- Set the root password `passwd`
- setup ufw
## Add DNS Records
-add wildcard * and empty A records
## Proxy restart
- might need to restart the proxy for ssh keys to take effect

18
archive/nKode OIDC.md Normal file
View File

@@ -0,0 +1,18 @@
## Endpoints
### Client Portal
`https://client.nkode.tech/portal`
- Get Client Id
- displayed in portal
- Get and reset Client secret
- `POST https://client.nkode.tech/reset`
- return client secret
- Add Redirect uris
- Display client id
- `POST https://client.nkode.tech/update_redirect`
- add and remove
- select scopes
- display client id
- `POST https://client.nkode.tech/update_scopes`
- add and remove

46
archive/nKode Warfighter zero trust authentication at the tactical edge.md Normal file
View File

@@ -0,0 +1,46 @@
Points from Bill Playte
- paint a picture with an example:
- Warfighters in the field want to ID themselves as friendly to a UAV or call in a drone strike. Right now they call that in over the radio. What happens if a red threat actor impersonates their voice? ...
- when starlink brings high-bandwidth commutation to field, will warfighters be able to enter long complex passcodes every time the do anything on their phone?
- nKode should be Tactical Readiness Level (TRL) 6.5 or 6.6 maybe 6.7
- emphasize low-bandwidth
Video Submission process:
https://chatgpt.com/share/67b7b41f-0c38-8009-8513-49f843647c26
- **Video length**: No more than **7 minutes**.
- **Format**: MP4, HD 1280x720, under **1 GB**.
- **Required elements**: Problem definition, advancement beyond the current state, team capability, and defense/commercial impact.
Each video must address **four required elements**:
1. **Problem Definition & Current State of the Art**:
- Clearly define the problem your technology solves.
- Explain the **current state of the art** and why existing solutions are inadequate.
- Must fit within **at least one of the DARPA topic areas**.
2. **Advancing the State of the Art**:
- How does your solution improve on existing technologies?
- Identify what is "new" in your approach.
- Discuss potential barriers to innovation.
3. **Team Capability**:
- Highlight the key personnel, their expertise, and why they are the best team for the project.
- Demonstrate past experience and qualifications.
4. **Defense/Commercial Market Impact**:
- Describe **real-world applications** in both defense and commercial markets.
- Explain how the solution will impact national security and/or the private sector.
## Warfighter Situations
#### senario 1
Warfighters in the field communicate with the base by radio. Radio is line-of-sight. Warfighers want to do something that requires authentication like calling in backup, Identifying themselves as friendly if they've been out of communication range for awhile, or call in an airstrike
##### Questions
1) What are some situations where authentication (I am who i say i am) needed? Is it enough to have an encrypted radio?
2) Do warfighters have passphrase they used to authenticate?
3) Are these fighters using smart phones?
4) Are these guys the warfighers at the tactical edge?
#### Senario 2
A centralized base is setup with all it's own infrastructure including 5G networks. Warfighters radio in (from senario 1) that they want an air strike.
#### Questions
1) does the commanding officer of the base authroize that? If so, how do they authenticate? are they getting on smartphones and entering a password?
2) Are these guys also warfighters at the tactical edge?

30
archive/next auburn meeting.md Normal file
View File

@@ -0,0 +1,30 @@
# Next Auburn Meeting
Hi Auburn Team,
Last meeting, Jonathan mentioned that you guys can do some white/grey box testing.
We're in agreement that that is a great starting place.
## How many key-selection observations are required to crack an nKode under a given policy configuration?
### Policy Parameters
1. iconComplexity:
The total number of unique icons available in the system.
(Defines the diversity of visual elements used in the passcode.)
2. passcodeLength:
The number of icons in a passcode.
(Determines the sequence length required for authentication.)
3. maxFailedAttempts:
The number of incorrect login attempts allowed before an account is locked.
(Controls brute-force mitigation by limiting retries.)
4. keypadSize:
The total number of keys displayed on the keypad.
(Impacts usability and potential guesswork complexity.)
5. iconsPerKey:
The number of icons assigned to each key.
(Specifies the visual density per key, affecting recognition difficulty.)
6. keypadHashLimit:
The number of unique keypad layouts stored before old hashes are rotated out.
(Ensures keypads are randomized across logins while limiting memory usage.)

64
archive/nginx on vpn.md Normal file
View File

@@ -0,0 +1,64 @@
# Nginx on VPN
Configure server with OpenVPN and CA
### Install OpenVPN
`sudo apt install nginx`
### nginx config
`sudo vi /etc/nginx/sites-av.../default`
```
server {
listen 10.8.0.1:443 ssl;
# server_name _; # You can omit this line or use '_'
ssl_certificate /etc/ssl/certs/nginx-selfsigned.crt;
ssl_certificate_key /etc/ssl/private/nginx-selfsigned.key;
# SSL settings
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_prefer_server_ciphers on;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
ssl_session_tickets off;
# Add Diffie-Hellman parameter for DHE ciphersuites
ssl_dhparam /etc/ssl/certs/dhparam.pem;
# Add security headers
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;
add_header X-Content-Type-Options nosniff;
add_header X-Frame-Options DENY;
add_header X-XSS-Protection "1; mode=block";
# Reverse proxy settings
location / {
proxy_pass http://<SERVER_B_IP>:80;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
```
### SSL Certs
```
sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 \
-keyout /etc/ssl/private/nginx-selfsigned.key \
-out /etc/ssl/certs/nginx-selfsigned.crt \
-subj "/CN=10.8.0.1"
```
`sudo openssl dhparam -out /etc/ssl/certs/dhparam.pem 2048`
```
sudo nginx -t
sudo systemctl reload nginx
```

18
archive/nkode_tasks_before_marketing.md Normal file
View File

@@ -0,0 +1,18 @@
# nKode Tasks Before Marketing
## TODO in todoist
- sqlite cron job backup
- fail2ban
- logging and detailed errors
- Improve UX: remove example keypad, example what do to in set and confirm, fix bg color
## TODO not in todoist
- Written Documentation at docs.nkode.tech
- Video Documentation on Youtube
- What should the user see when they log in?
## DONE
- Email Verification and Forgot Password

184
archive/nkode_tutorial.md Normal file
View File

@@ -0,0 +1,184 @@
# nKode Tutorial
## nKode Keypad
- nKode keypad contains keys
- Each key has icons
- Each icon belongs to a set and has an index value associated with it
- The position within the key is the set value
- When attributes are shuffled, they'll always remain in the same position within the key
(note: the set value can be obuscated from the client but we find it helpful to quickly find the attribute)
## nKode Enrollment
- user sets then confirms their nKode
- Set and Confirm are dipersion of each other and allow the server to infer the users nKode
- the users login has additional icons added to each to key to make it dispersion resistant
- After the user as selected their nKode through the set and confirms,
the server can infer the users selection since each key selection will only have one icons in common.
- The users nKode is enciphered, salted and hashed.
## Dispersion
- Two keypads are dispersion of each other if:
Kp1: Keypad 1
Kp2: Keypad 2
for each key1 in Kp1:
for each key2 in Kp2:
iconsIntersection(key1, key2) <= 1
## Dispersion Algo
- Convert a Keypad view into a matrix view
- each row is key and each column is a set
- Fisher Yates the keys i.e. the rows in the matrix
- Fisher Yates an identity matrix equivalent to the number of keys
- The shuffled permutation is used to rotate the columns
## Dispersion Resistance
- Dispersion is only possible if {number of icons per key} <= {number keys in the keypad}
- If there are more icons per key than keys, it makes it difficult to phish for a users nkode
## Cipher Keys
#### attribute key
- randomly generated array of unsigned integars
- array of length {numb of keys} * {number of attributes per key}
- xored with ss-attr to give each user a unique
#### passcode key
- randomly generated array of unsigned integars
- array of length {max nKode length}
- xored with final user passcode
#### set key
- used to recover users nkode set values
- array of unsigned integars
- each elemenet in the array is a random number XOR'ed with the set value of the users nKode
- so `for set_key_i in user_set_key`
`set_key_i = user_passcode_set_i ^ random_set_key_i`
#### mask key
- used to recover users nkode set values
- array of random unsigned integars
#### server-side attributes (ss-attr) and sets (ss-set)
- Each icon has a server side attribute.
- The icon and the ss-attr are indexed to the same place in an array.
- The dispersion and shuffle operation are applied to the index array and the index array is applied to the icon and ss-attr
- ss-attrs are randomly generated permutation of unsigned ints (or byte arrays of any length for extra security)
### Encipher and Hash nKode Passcode
passcode = index values of the selected icons infered in set/comfirm
user_attrs = arr_xor(ss_attr, user_attr_key)
passcode_attr = [user_attrs[idx] for idx in passcode]
ciphered_passcode = arr_xor(passcode_attr, user_passcode_key)
// optional sha256 if ciphered_passcode is more than 72 bytes
passcode_digest = sha256(ciphered_passcode)
hashed_passcode = bcrypt(passcode_digest)
### Enicphering nKode Set
nKode mask is used to recover the users nKode
1. set_key_i = (set_rand_numb_i ^ set_val_i)
2. mask_key_i = mask_rand_numb_i
passcode = index values of the selected icons infered in set/comfirm
// recall ss_set array is an order list
set_idx = get_set_value(passcode)
user_set_keys = [set_key[idx] for idx in set_idx]
user_set_vals = [ss_sets[idx] for idx in set_idx]
mask = arr_xor(user_set_val, user_set_keys, mask_key)
- mask_i = mask_key_i ^ padded_passcode_server_set_i ^ set_key_i
- mask_i = mask_rand_num_i ^ set_val_i ^ set_rand_numb_i ^ set_val_i
- mask_i = mask_rand_num_i ^ set_rand_numb_i # set_val_i is cancelled out
#### nKode Validation
// set_val_i = mask_i ^ set_key_i ^ mask_key_i
// selected_keys the keys the user selects
recovered_set_vals = arr_xor(mask, set_key, mask_key)
user_keypad = get_user_keypad(username)
presumed_password = get_pressumed_passcode(user_key, selected_keys, recovered_set_val)
if is_valid_passcode(presumed_password, hashed_passcode)
return LOGIN_SUCCESS
else
return LOGIN_FAIL
## nKode Login Shuffle
- After a successful login, the users keypad is shuffled in a two step process:
1. the keys are randomly shuffled
2. half the sets are randomly shuffled
- We've found this works best for xyz reason and we're also working on simulations to find a probablity curve for number of overserveration before an adversery can crack an nkode
## nKode Login
- When a user request their nkode keypad, the server sends a list of svgs in the order they should be displayed
- The Gen2 demo implementation works a bit different it sends the svgs indexed in order from 0-total_numb_of_attr along with an index array for how the svgs should be ordered
- this is a legacy from the gen 1 keypad but it helps to make the implemntation more concrete so we'll use this legacy
- The frontend organized the svgs into keys and displays them.
- The user selects keys for their nkode and their key selection is sent back to the server for validation
## Preventing User Enumeration
- This isn't applied in the demo application
- We can prevent a threat actor from enumerating users.
- if a valid email is entered into the login for a user that dne, we can create a ghost keypad and have it behave as if it were a real user.
- if there are too many "failed nkode attempts" we lock the non-existing user out.
- We can prevent timing attacks by either mocking the real control flow or setting a 1 or 2 sec response delay from the time the login request was recieved thereby completely elimiating timing attacks
## Renew
Renew changes user ciphers, user salt, ss_attr, and ss_set.
This is import in the event of a partial database hack or leak.
An admin or cron job can run the renew with any frequency (daily, weekly, monthly)
Users are aware of this process.
Nothing changes for them.
### Three Step Renew
Renew has three phases
1. Server-Side Attribute Renewal: ss_attr and ss_set values are replaced with new values
2. Intermdiate User Renewal: every user goes through an intermediate phase before full Renewal
3. Full User Renewal: The user's first successful login completes the renewal. User has gets new salt, and cipher
#### Server-Side Attribute Renewal
old_ss_attr, old_ss_set = get_ss_vals()
renew_ss_vals() // new randomly generated values
new_ss_attr, new_ss_set = get_ss_vals()
xor_ss_attr = arr_xor(old_ss_attr, new_ss_attr)
xor_ss_set = arr_xor(old_ss_set, new_ss_set)
#### Intermdiate User Renewal
all_users = get_all_users()
for user in all_users:
user.renew = True // This flags the server to complete phase 3, full user renewal
user.set_key = xor_lists(user.set_key, xor_ss_set) // recall user.set_key = rand_num ^ old_ss_set. this operation cancels out old_ss_set and replaces it with new_ss_set
user.attribute_key = xor_lists(user.attribute_key, xor_ss_attr) // recall user.attribute_key ^ old_ss_attr are the user's nkode ss attributes so when we
#### Full User Renewal
After a successful login user keys are reset as if the user was signing up for the first time