[katzenpost] Katzenpost client library tasks

[masala at riseup.net]

Hi All,

David and I had a voice meeting where we discussed TODO tasks on the
client library: https://github.com/katzenpost/client

Here are the notes I took from the meeting.
Comments and questions welcome.

================

Misc tasks:
work on the heartbeat protocol stuff
heartbeat threshold from loopix paper
switch to different tasks through the day - blocked, stuck, etc

would be a good idea to do generative testing
 - testing PKI
 - might be able to get into unknown states

load testing of mix servers
 - find performance bugs and stuff
 
Cryptographic persistent storage library
  - name ??
  - KISS
  - serialization format, CBOR?
  - serialize and encrypt, write to disk as ciphertext
  - transactional, NOT ACID style
    - write to temporary file and move it, ala Pond

Client Library TODO:
Name of library: client
  - bookkeeping for forward messages (SURB IDs)
  - pass received messages to the application
  - nice API golang interface
  - tests for each component
  - persists stuff to data structures in memory (1 or 2), queue and
something else
  - implement sending/receiving messages
  - onMessage (complete this method, pass data to the caller)
  - cache and store the consensus in the store (perf. improvement,
priority ?)
    - might be downloading the consensus too often
    - should cache provider descriptors and try to download consensus
from provider

Fragmentation transport library:
Name of library: ??
  - end to end message encryption using Noise XX HFS or Signal protocol
    - how often to rekey (n messages?)
  - key/fingerprint verification interface (to application?)
  - information necessary to identify where messages belong
    - suggest trial decryption (assume average user doesn't have that
many sessions?)
  - dont want to expose fragmentation metadata to the provider
  - messages are fragmented before encryption, so messages sizes are
uniform
    - fragmentation metadata is therefore concealed from the provider
  - figure out if Noise CipherStates can be serialized and stored on
disk and if this is a good idea or not.
    - otherwise messages cannot be received asynchronously (if key
material is lost at shutdown)
  - cryptographic storage library used for storing cipherstates,
fragmentation metadata, messages ids, etc
  - what should the receiver do if a message never arrives (tear down
state, etc. how long? since this is async proto)
  - applications must be indistinguishable to the provider, so the same
cryptographic transport encapsulates application messages.

  - key verification or key (long term identity) exchange ? leave to
application developer, provide PANDA library and write interface or
re-use Verifier interface ?