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

18
projects/nkode/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.

48
projects/nkode/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.

113
projects/nkode/OpenID Connect Passport Notes.md Normal file
View File

@@ -0,0 +1,113 @@
## 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
-

16
projects/nkode/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
projects/nkode/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.

18
projects/nkode/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
projects/nkode/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