-- Leo's gemini proxy

-- Connecting to sunshinegardens.org:1965...

-- Connected

-- Sending request

-- Meta line: 20 text/gemini; lang=en

/g/ cryptogen(5)

private trust lattice

date: 2018-08-13T18:00:00-06:00

tags: #p2p #technology #cryptogen

research topics

zero knowledge proofs

sha-3

gossip protocols

DHT

ring signatures

double ratchet key exchange

abstract

p2p WoT

partially replicated block lattice

post-quantum crypto

blocks are content address objects linked by their hash

blocks are replicated based on trust relationships. the above example shows Bob and Alice publishing messages that indicate a level of mutual trust. using this block graph the lattice agent attempts to locate and copy all of the blockchains of their trusted peers. assertions about other peers can be used to generate a FoAF graph which can safely extend explicit WoT links up to `n` hops. block replication can use the same parameter or some factor of it to ensure that sufficient information is available to make trust decisions.

blocks may include encrypted payloads, with or without address meta (PrivateBox/SecretBox). this is not intended to function is a messaging tool, rather as a means for private key exchange. specifically, the ability to create private trust networks.

trust messages may include chain-links and external notarization. a chain-link includes both the top hash of the publisher, the key hash of some target chain, and the target's top hash. chain-links provide checkpoints for validating blockchains. individually, any agent is capable of rewriting their blockchain. chain-links prevent history modification. peers may collude to allow some chain to be modified, but ALL linked peers must agree.

external notaries may be used to provide an additional level of assurance to a chain-link. the same inputs are used and the resulting value is included in the chain-link's payload. an example of an external notary might be a smart contract on ETH or UBIQ. these are NOT required for validation. another example of an external notary could be a signature from and Estonian e-id keycard. the point is, civ-lattice is designed to connect many sources of trust.

`cryptogen` is a partially-replicated, encrypted block-lattice, designed to provide a secure and confidential alternative to DNS, CAs, and key servers. each peer publishes their own series of signed merkle linked blocks containing an arbitrary payload. the blocks are then encrypted with a group key. blocks can only be validated by members of the group.

blocks belonging to a particular group always originate from a new genesis block. a group origin block is the signed hash of the peer's public key, encrypted with the group secret.

block-lattice

a collection of tamper-resistent, hash-linked signatures that provide secure interoperability between various blockchain technologies, network, and proof systems.

single-writer, append-only log (user blockchain)

PoW blockchain

PoS blockchain

each peer publishes blocks with the following fields. the parent of the genesis block is the hash of the key that is used to sign the chain. subsequent blocks may contain a payload with an arbitrary length.

 ------------------------------------
| /ipfs/<genisis block hash>         |
|------------------------------------|
| parent: /ipfs/<user keyhash>       |
|------------------------------------|
|------------------------------------|
| sig: <ed15519 sig>                 |
 ------------------------------------

 ------------------------------------
| /ipfs/<block 0 hash>               |
|------------------------------------|
| parent: /ipfs/<genisis block hash> |
|------------------------------------|
| <payload>                          |
|------------------------------------|
| sig: <ed25519 sig>                 |
 ------------------------------------

a block-lattice is not designed to work with large payloads, to prevent chain-bloat a block size adjustment algorithm based on CryptoNote is used to re-target blocksize limits based on average block decryptions time, average block size, and total network overhead. there is no hard limit on the payload size in the protocol; this is a performance consideration for mobile clients. this function may look useful for proof-of-work, but the goal here is to *minimize* cpu and network utilization by re-targeting block sizes to the smallest useful value.

encrypted lattice regions

lattice regions are truncated when a new peer is added to the group.checkpoint blocks include the genesis block key hash and the top hash of the longest chains in the lattice region. these are published by all members of the original group. a second block is published by all members of the new group including the same metadata as the checkpoint block.

   ---------------------------------------
|0| encrypted with old group key: <block> |
   ---------------------------------------
<blocks from this point forward use a new group key>
|1| checkpoint: /ipfs/<block 0>, /ipfs/<user key hash>, ...
|2| genisis n: /ipfs/<block 1>, /ipfs/<new user key hash>, ...

before the block lattice can be updated, the group must agree on a new group encryption key. the two-step checkpoint interlinks the lattice, first: with a hidden set of blocks. the checkpoint blocks are then encrypted with the new group key and published to ipfs. at this point the new member is able to decrypt all of the blocks in the new lattice region. a set of genesis blocks are published by all members including key and checkpoint block links.

DHT gossip protocol

objects/messages transmitted via content-key lookup

`/mesh/<routing key>/gossip` -> `/ipfs/<hash>`

colony picks a random secret or use a double ratchet key exchange protocol

members of the group/colony publish encrypted objects.

rotatind peer ids over anon overlay network

publish merkle root hash signatures

we utilize ipfs to replicate encrypted blocks in order to simplify the design and minimize duplicate effort. however, the lack of privacy afforded by ipfs is an important issue that is addressed by controlling how cryptogen-ipfs clients communicate.

ipfs and bit torrent ''do not'' provide anonymity, but by combining anonymous overlay networking with encrypted block replication we can implement a confidential gossip protocol with support for group lattice regions.

user keys and ipns keys are always distinct values. in this scheme ipns keys are used to represent a resource that can be updated (the block lattice), not users. blocks are published under an ipns key:

/ipns/<peer_id> -> /ipfs/<top_hash>
/ipfs/<top_hash>
  gossip_metadata/
  blocks/
    <block_hash>

`gossip_metadata` includes encrypted group membership data that can quickly be decrypted to determine if the peers are members of the same group. if this process reveals that these peers belong to one or more of the same groups, each listed block is decrypted in a random order and pinned on success. randomly generated dht queries can be used to mask the which blocks are being accessed. in order to mask handshake success vs failure the top hash must always be replicated recursively.

an attacker may be able to determine if a particular handshake succeeded by asking for particular blocks from a set of peers after observing the handshake. the automatic garbage collection for un-pinned blocks may reveal that a particular handshake failed. this issue may be mitigated by periodically rotating the group key, using a new lattice region, and rotating peer keys.

anonymous overlay network

peers communicate over a modified cjdns router that implements an onion routing protocol at layer 2. this allows unmodified ipfs clients to communicate over an anonymous link. some care must be taken to ensure that ipfs cannot access unprotected networks.

> alternatively, an anonymous DHT could replace both cjdns-anon and ipfs

applications

distributed name system

`cryptogen` lattice regions can be used to store structured data. one interesting application of this capability is a distributed name system. for the sake of familiarity, we can use DNS as a template.

/mesh/@<public key base 64>/dns/<domain>/
  type AAAA
  domain <domain>
  data <enrypted mesh ip>
  ttl 1800

pet names

/mesh/@<public key base 64>/social/@<peer public key base 64>/
  name <example_user>
  inbox <relay host key>
  outbox <relay host key>

names are rendered in the UI based on identity labels:

@<agent  label>/<value>

clients MUST make the user aware of duplicate namespace labels.

smart contracts

programs written in familiar languages can interface with cryptogen to provide paid services accepting/managing payments on one or more blockchains. this affords greater flexibility than current-gen smart contracts which must fit within the execution parameters of a blockchain vm.

cryptogen smart contracts are identified by the ipfs hash of the program that executes them. combined with source-transparent package managment and reproducible builds, users can ensure that exactly one version of their intended program is being used to validate and execute the terms of their contract.

this architecture diverges significatly from the idea that "code is law" because there isn't a trustless execution engine to enforce the contract. rather, cryptogen smart contracts enable users to create secure, aditable software that is suitable for businiess and finance applications, which is flexible enough for ongoing changes and modifications to business logic, including complex computations that are too expensive to performed on any existing smart contract platform.