I built a working SSL certificate replacement using Certificateless Public Key Cryptography (CL-PKC) – live demo inside

Dima Ulyanov — Tue, 16 Jun 2026 08:54:40 +0000

Hey,

I've been building a proof-of-concept called 0Cert that replaces
SSL certificates with Certificateless Public Key Cryptography (CL-PKC).

The core problem with SSL:
~150 Certificate Authorities can issue certificates for any domain.
One compromised CA breaks trust for the entire web. We've seen this
happen (DigiNotar, Comodo, etc.).

How 0Cert works:

Instead of CAs, a Key Generation Center (KGC) issues a partial
private key for your domain. You generate your own ECDH P-256 secret
locally. You combine them into a full private key that the KGC never
sees.

`partialKey = KGC.derive(masterSecret, identity) ← KGC knows this

userSecret = ECDH.random() ← never leaves device

fullPrivKey = combine(partialKey, userSecret) ← nobody else has this`

Even a fully compromised KGC cannot decrypt user traffic. This is
based on the Al-Riyami & Paterson 2003 CL-PKC scheme.

What I built:

Live KGC server: https://kgc.0cert.io
Web app (works on any device): https://app.0cert.io
iOS browser app (Swift) that detects 0Cert sites via DNS TXT records
npm middleware: npm install 0cert-middleware
All code: https://github.com/0cert

How site verification works:

Site owner adds DNS TXT record:

TXT @ ibc-kgc=https://kgc.0cert.io

Installs middleware:

app.use(zerocert({ identity: 'mysite.com', fullPrivKey: '...', userSecret: '...' }))

Browser checks DNS → calls /.well-known/0cert → shows verified badge.
No certificate chain. No CA involved.

Honest limitations (security folks will ask):

Browsers don't support this natively — runs alongside SSL for now
KGC trust problem — you're replacing CA trust with KGC trust. The difference: KGC provably can't decrypt (math), CAs just promise they won't fake certs (policy)
My implementation uses HMAC-SHA256 key derivation instead of actual Weil/Tate pairings over elliptic curves — the trust model is cryptographically sound, the underlying math is simplified
No IETF RFC yet

The path to browser adoption:

DNS TXT records are already trusted by browsers. DANE (RFC 6698)
proved the concept. The missing piece is a standardized KGC protocol
and browser-native verification — which starts with a working
implementation people can test.

Would love feedback from the security community, especially on:

The KGC trust model vs CA trust model
Whether the CL-PKC approach is worth pursuing seriously
Known attacks on this model I should address

https://0cert.io
https://github.com/0cert

Key point in Do List 100 v2.0 Brings Due Dates, Auto-Progress and Full iPad & Mac Support

Dima Ulyanov — Tue, 02 Jun 2026 18:47:24 +0000

Hi everybody.
We have created this app around two months and this is third version with fixed bugs. Now it is amazing app that synchronization your tasks throughs iPhone iPad Mac via iCloud with no Sign In! And in pocket you will already have a useful notes.

It was a huge code work. Hours and hours. Such a pleasure.

What I want to note here for you fellas, we were going from these scheme:

What's really happening

The self-overwrite loop

User edits subtask title
        ↓
onChange fires → scheduleSave() → debounce 1s
        ↓
...debounce fires → DataManager.save() writes todos.json to iCloud
        ↓
NSMetadataQuery detects file change on disk
        ↓                         ↑
        └── todosChanged() ───────┘
              ↓
        taskManager.loadTodos()
              ↓
        self.todos = loadedTodos   ← 💥 replaces entire array mid-edit

The core problem is that NSMetadataQuery watches the file at the OS level. It has no concept of who made the change — your own app writing the file looks identical to another device syncing a change over iCloud. So every save you make triggers a reload that cancels whatever the user is currently doing.

Why subtask titles are worst affected

A TextField bound to $subtask.title is live — it reflects the array value character by character. The moment self.todos = loadedTodos runs, SwiftUI throws away the in-memory array and rebuilds from the freshly decoded JSON. If the save hasn't happened yet (debounce still counting down), the loaded file has the old title, and the field visually snaps back.

Progress sliders have the same issue but it's less noticeable because a slider value is a Double — the snap-back is a jump rather than disappearing characters.

Why it only shows up on real devices

The simulator runs everything on the same Mac so iCloud writes are near-instant and the race window is tiny. On a real device the file system is slower and iCloud sync adds latency, making the timing gap between "user is editing" and "reload fires" much more visible.

The three fixes needed

Fix 1 — Ignore self-triggered reloads in DataManager
Track a isSavingLocally flag. Set it true before writing, false after. In todosChanged() skip the reload if the flag is set. This stops your own saves from triggering reloads entirely.

Fix 2 — Add an isEditing guard in TaskManager
Expose a simple isUserEditing: Bool flag that ContentView sets to true when a TextField is focused and false on onSubmit/focus loss. loadTodos() checks this flag and skips the reload if the user is mid-edit, queuing it for after they finish.

Fix 3 — Debounce the reload too, not just the save
Right now saves are debounced (1 second) but reloads are instant. If a remote change does arrive legitimately, it should also wait briefly before replacing the array — giving any in-flight edits time to be committed first. A 0.5-second debounce on todosChanged() is enough.

TO THIS:

Own save → flag set → reload blocked entirely
Mid-edit → isEditing → reload deferred until focus lost

Remote sync → debounced → reload waits 0.5s before replacing array

Interesting in your opinions.

[LINK TO THE APP(https://apps.apple.com/us/app/do-list-100/id6758045201)]