Pubki Work 【360p】

Without PKI, the internet as we know it would collapse.

| Problem | Impact | |---------|--------| | No Sybil resistance | Attacker can register millions of user_id variants. | | First-use trust | No bootstrap security — first lookup vulnerable to MITM. | | Gossip overhead | Every client must audit, which scales poorly on mobile. | | No revocation mechanism | Only rotation; compromised key can sign bogus rotation unless caught quickly. |

---

If PKI is so great, why does IT hate managing it? pubki work

Because keys expire. And keys are heavy metal objects.

If a bank loses its Private Key, they lose the kingdom. If a certificate expires, the website breaks (users see the "Not Private" error). Managing the lifecycle—creating, renewing, revoking, and destroying keys—is the "Infrastructure" part of Public Key Infrastructure. It is a logistical nightmare for large companies, which is why we have automated tools like ACME (the protocol behind Let's Encrypt) to do it automatically. Without PKI, the internet as we know it would collapse

Simple UDP-based gossip protocol with Merkle tree roots exchanged over random peer sampling.

# Pseudo-code for Pubki log entry verification
class PubkiEntry:
    user_id: bytes
    key: bytes
    timestamp: int
    prev_sig: bytes   # signature of previous entry's hash
def verify_chain(entries):
prev_hash = b'\x00' * 32
for entry in entries:
if not verify_sig(entry.prev_sig, prev_hash, entry.user_id):
return False
prev_hash = hash(entry)
return True
 If PKI is so great, why does IT hate managing it

Log node returns:

  "user_id": "alice@example.com",
  "key": "-----BEGIN PUBLIC KEY-----\n...",
  "timestamp": 1700000000,
  "prev_sig": "MEUCIQD...",
  "merkle_proof": ["hash1", "hash2", ...]

Client verifies Merkle proof against a trusted root hash obtained from 3+ random gossip peers.

---