Not

Hacker News!

Beta
Home
Jobs
Q&A
Startups
Trends
Users
Live
AI companion for Hacker News

Not

Hacker News!

Beta
Home
Jobs
Q&A
Startups
Trends
Users
Live
AI companion for Hacker News
  1. Home
  2. /Story
  3. /1-of-1 AES Encryption UX Artifacts
  1. Home
  2. /Story
  3. /1-of-1 AES Encryption UX Artifacts
Nov 25, 2025 at 3:09 AM EST

1-of-1 AES Encryption UX Artifacts

0north
1 points
1 comments

Mood

informative

Sentiment

neutral

Category

tech_discussion

Key topics

Aes-Encryption

Ux-Design

Security-Tools

Github-Release

Discussion Activity

Light discussion

First comment

N/A

Peak period

1

Hour 1

Avg / period

1

Comment distribution3 data points
Loading chart...

Based on 3 loaded comments

Key moments

  1. 01Story posted

    Nov 25, 2025 at 3:09 AM EST

    8h ago

    Step 01
  2. 02First comment

    Nov 25, 2025 at 3:09 AM EST

    0s after posting

    Step 02
  3. 03Peak activity

    1 comments in Hour 1

    Hottest window of the conversation

    Step 03
  4. 04Latest activity

    Nov 25, 2025 at 10:26 AM EST

    47m ago

    Step 04

Generating AI Summary...

Analyzing up to 500 comments to identify key contributors and discussion patterns

Discussion (1 comments)
Showing 3 comments
0north
8h ago
1 reply
hey dudes i built this new thing, its basically singular offline encryption environments where you can encrypt words and text. It’s inspired by genesis blockchains but applied to the AES runtime key pairing to create cross decryptable cipher environments.

i can make infinite of them, and they're not cross-decryptable. so if you have one on a USB for example, its literally your own personal, private encryption language. theyre like little artifacts.

heres a video explanation i recorded in my kitchen: https://youtube.com/shorts/LfW- gDmJKs?si=PzFfJkh6Z55Tg8tr

same password + same message in any two vaults = impossible to cross-decrypt

click the link in the title for the demo I have two demo vaults, bear with me on the huge size. they are that big because each one electron package bundles chromium, not because of my encryption logic. sorry about that.

the encryption environments work offline, and I store nothing, theyre deleted server side after my API delivers them. no cloud, no backup server, no seeds.

you can check out more details at my github at github.com/Onorth-eth if you wanna peep the actual post or the original devpost submission. (some of the terminology in my original video may be weird, its AES)

didn't post my actual API link to generate individual vaults because im pretty sure my digital ocean droplet would literally explode, but the 2 vaults in the demo can encrypt and decrypt anything you guys want; and you can see that they don't decrypt one-another.

if you want a personal one i can give some to the first commentors or whatever just comment 'encrypt pls or something and I can make you one.

tldr: 1-of-1 encryption vaults, like Minecraft seeds for personal encryption kinda. mess with my demos and sorry about the size.

why build it: journalists can encrypt sensitive data then delete their .exe, keep the encrypted output, and decrypt it all on their backup at home. people can keep a vault on a usb in a safety deposit box and encrypt data or messages for their family. lots of stuff.

if you like it: https://buymeacoffee.com/dantehorton

if you think its dumb/malware: its not, also tell me why i guess.

slooonz
4h ago
1 reply
I think you should clearly spell out how the key is derived.

From the description, I believe it's random string hard-coded in the executable + user-provided password => AES key ?

0north
47m ago
You’ve mostly got it.

The API on DigitalOcean just builds a fresh .exe and embeds a unique seed into the runtime build. After that, everything is offline.

The seed is made server-side during creation as a SHA-256 over a timestamp + jitter source, and is written as (vault-seed.txt)in the .zip.

Inside the .exe, the vault reads its own embedded seed, and the key is derived as

key = SHA256(SHA256(password||seed))

Each encryption uses a fresh 16-byte IV and encodes ciphertexts as:

ivHex + "." + encryptedHex

So the text is turned into encrypted garbage, locked behind an AES key and an ivHex per click.

The result is simply: same password + different builds => different AES keys, because each .exe simply has a different seed baked into it.

That’s what creates the conditions where two environments can never decrypt each-other’s ciphertexts and can be generated endlessly.

View full discussion on Hacker News
ID: 46043479Type: storyLast synced: 11/25/2025, 8:10:09 AM

Want the full context?

Jump to the original sources

Read the primary article or dive into the live Hacker News thread when you're ready.

Read ArticleView on HN

Not

Hacker News!

AI-observed conversations & context

Daily AI-observed summaries, trends, and audience signals pulled from Hacker News so you can see the conversation before it hits your feed.

LiveBeta

Explore

  • Home
  • Jobs radar
  • Tech pulse
  • Startups
  • Trends

Resources

  • Visit Hacker News
  • HN API
  • Modal cronjobs
  • Meta Llama

Briefings

Inbox recaps on the loudest debates & under-the-radar launches.

Connect

© 2025 Not Hacker News! — independent Hacker News companion.

Not affiliated with Hacker News or Y Combinator. We simply enrich the public API with analytics.