Péter Szilágyi

Mind you, this is the *half price for large order* quote. One less costs 64K-epsilon.

In December I was quoted $4000 for a batch of eMMC chips. I didn't want to commit because I wasn't yet sure if they are large enough (128GB; it would be better to have 256GB). Today's quote is $32000. I can't afford that for my project. ¯\_(ツ)_/¯

How secure is the @dark.bio pipeline?
Yes.

When you realise both the boomers and the zoomers got it wrong on what the real store of value is.

Me in December: Hmm, storage chips for the Ark is $50-ish. I should postpone a bit to make sure I get the correct one.

Me now: WTF do you mean it's $277 ??? 😭

Ugh, today was insane. I've replaced x509 certificates with CWT attestations throughout Dark Bio.

Needed to update 10 repositories in lockstep:

- Rust/Go/Flutter/TypeScript crypto
- Ark firmware, Ark CLI
- Cloud worker, cloud CLI
- Web dash, mobile app

Thank you Claude

Péter Szilágyi (1).png

It’s time for something really dark 👀

Péter Szilágyi is gonna have is first talk about Dark Bio! 🖤

This May at ETHPrague ☀️
🎟️ Get tickets in bio

Seems I'll be doing my first talk about Dark Bio at @ethprague.bsky.social in May this year! 🥳 No pressure... 😅

AI and the illusion of sandboxing:

OpenCode: You can't access files outside this folder.
Claude: Lol, hold my beer

Turns out that the CBOR ecosystem gets you everything you need, standardised:

Encoding: CBOR
Cryptography: COSE
Credentials: CWT
Attestations: EAT

FWIW, I did reimplement the entire stack due to security concerns \facepalm, but at least I only need to secure a few K LOC.

x509 certificates are a pretty ancient technology. Everybody uses them only because everybody else uses them. But the spec is so insane, that I strongly suggest everyone to consider it an absolute last resort.

The neat part about these is that they are CBOR structs signed via COSE; exactly what I do everywhere already.

Downside? Nothing! x509's purpose:
- Chains of trust, not just one hop attestations.
- Interoperability with the kitchen sink.

But nobody does PQC, so both futile.

After investigating, I found CWT (CBOR Web Tokens), which is a tiny structure that can just hold a few fields and attest some pubkeys. Perfect for cloud identities.

There's another small standard, EAT (Entity Attestation Token) on top, that defines tags for hardware devices.

Long story short, yes, the PR works, yes it does what I wanted it, but it was past the complexity threshold I was willing to tolerate.

Then I introduced x509, I had no meaningful protocols in place, so it was an arbitrary decision. Since then I've reworked all my protocols based on CBOR and COSE.

The issue was that the x509 certificate spec is such a monstrosity, that it's horror to work with it. And since nothing supports post-quantum, you need to reinvent the entire wheel from Adam and Eve. And since the format is very permissive, it's an infinite whack-a-mole.

x509, xdsa, xhpke: flesh out certificate handling better by karalabe · Pull Request #4 · dark-bio/crypto-rs This PR expands the x509 certificate support with cert chaining / validation and support for custom extensions.

This week I reworked it all again, to support custom extensions so I could use it for offline device authentication with the Arks.

It was a 2500 line diff that *barely* worked for what I needed it, never mind actual utility for anyone else.

In the early days of Dark Bio, I used x509 certificates to advertise cloud identities, but even then I had to start hacking because they didn't support X25519 pubkeys.

Then I extended the cert format to support composite ML-DSA and hybrid ML-KEM pubkeys, which was a nightmare.

A little background. Pretty much *nothing* supports post quantum interoperability yet. Many companies use it, but they short circuit within their networks. As such, encodings and common formats (DER, PEM, x509) are not well defined and mostly not supported at all.

Monday I started reworking the x509 certificate support in the Dark Bio crypto libraries. By Friday, I'm on a path of deleting the whole thing and replacing it with CWT credentials / attestations. Wild week... 🥲 🧵

🙈

I have received the biggest bribe ever to switch back from Rust to Go 🥰

Courtesy of Vlad Cealicu and BespokeYarnCreation. Thank you!!!

Today I've spent 5 hours with Codex writing an x509 wrapper. 3000 LOC with tests.

I'm one hour in with Claude and it's deleting code like there's no tomorrow.

> No, you don't need it. It's a textbook unnecessary abstraction.

Was told Codex is good, it's a complexity generator.

I look forward to it

Installed OpenAI Codex 20 minutes ago. In the *first* thread:

I asked Codex to double check the code. It helpfully told me that Claude messed up and my temperature won't report correctly when it reaches 209℃/409℉.

One one hand, Codex is right. On the other hand, why does it prepare me for the apocalypse? 😅

We're fucked.

Took Claude 80 minutes, most of which was waiting for the samples. That said, Claude did find protocol analysis remnants and old attempts on the internet, so it didn't to everything from scratch.

I'll need to redo the test forbidding it to use internet sources.

I wanted to only set up the experiment tonight and start tomorrow, but Clause seems to oneshot this :/

Ok, station works and transmits "something", receiver works and receives "something". Also hot as fuck; mental note, don't leave it plugged in my laptop overnight.

Now I need to figure out a closed loop to provide some feedback to the AIs to optimise for. To be continued...

Lets assemble everything and just dry-run a spectrum visualiser to see if the station / receiver even works.

I have a European model so it transmits on 868MHz according to the spec sheet. With a bit of parameter fiddling on the receiver, we have our first signs of life! 🥳

We don't want to do any invasive hardware changes to the weather station, only listen to radio waves emitted. For that, gonna use an RTL-SDR module, a small USB dongle that can listen in on radio frequencies and process them via software.

See that "HOT" warning? 40-60℃, yikes.