☐: feature, ☑: implemented, ✔: verified

Functionality:

• ☑ Normal messages:
  • ☑ Plaintext message
  • ☑ Whitespace-tagged message
  • ☑ Query message
  • ☑ Error message
• ☑ Authenticated Key Exchange (AKE)
• ☑ Socialist Millionaire's Protocol (SMP)
  • ☑ SMP zero-knowledge secret verificaton (w/ or w/o user-provided question)
  • ☐ Manual verification (SSID)
• ☑ DSA signatures
• ☑ Encryption
• ☑ OTR-encoding
  • ☑ Reading
  • ☑ Writing
• ☐ Policies:
  • ☑ REQUIRE_ENCRYPTION take appropriate actions given that active policy requires encryption.
  • ☑ WHITESPACE_START_AKE automatically initiate AKE when whitespace tag is received.
  • ☑ ERROR_START_AKE initiate AKE upon receiving error message.
  • ☐ ability to change policy for account or individual instance (during use).
• ☑ Fragmentation:
  • ☑ Assemble fragments of incoming message.
  • ☑ Fragment outgoing messages.
• ☐ Heartbeat-messages: keep session alive and ensure regular key rotation.
• ☐ Store plaintext message for transmission under right circumstances (i.e. REQUIRE_ENCRYPTION policy, in-progress AKE, etc.)
  This is somewhat controversial due to risk of sending queued messages to wrong established session.
• ☐ Expose the Extra Symmetric Key (TLV type 8 in OTR3, TLV type 7 in OTRv4)
• ☑ Session expiration
  Session expiration is provided only as a method-call. This is currently an action that the host (chat-application) must perform.
• ☑ OTR 3:
  • ☑ Instance-tags (distinguish multiple clients for the same account)
  • ☑ Fragmentation with instance-tags.
• ☑ OTRv4:
  • ☑ Upgraded cryptographic primitives, DAKE, Double-Ratchet, mixed ephemeral keys
  • ☑ Client-profiles
  • ☑ Fragmentation with identifier
  • ☑ FIXME continue itemizing and include incomplete parts ...
  • ☐ Out-of-order message-keys:
    • ☑ messages in order,
    • ☑ skipping messages,
    • ☐ message-keys from skipped keys store, i.e. out-of-order reception

Operational:

• ☑ Single instance of Account represents single account on a chat network: allows for specific identity (DSA keypair), chat network/transport.
• ☐ Thread-safety. (Not yet determined necessary.)
  Given that most messages can be processed one at a time, most benefit is derived from having separate tasks for session expiration and heartbeats. However, these may be interleaved with message processing.

Developmental:

• ☑ No logic for managing multiple accounts:
  We keep this separated and up to the client to implement as necessary. Essentially, just tying the Account to the corresponding chat account logic is sufficient, and additional management risks prescribing a certain structure to the host application (e.g. chat application).
• ☐ API for managing multiple accounts, keys, policies?
• ☐ Unit tests: too few tests, even though rust syntax is that expressive.
• ☐ Resilient to faulty implementations of Host as provided by the client.
  At this moment it is not clear how to do this: std::panic::catch_unwind is not guaranteed to catch and handle all panics.

Known issues:

• How to deal with multiple instances, "default instance", "selected/active instance"? Especially when dealing with incidental reception of plaintext messages while encrypted session is established for some instance.
• The OTR specification documents that any message payload is in UTF-8 and may contain HTML. However, this makes it ambiguous for how the content should be interpreted and results and risks may very per chat network.
• There is no convention on how the Extra Symmetric Key should be used.