0.7.3

• Fragment-assembly: update tick value on every fragment. Highest tick value represents the (incomplete) message most recently updated with an incoming fragment.
• Fragment-assembly: practical, liberal maximum fragment size of 250 KiB to prevent abuse. Fragments are refused when exceeding this limit.
• Fragment-assembly: practical, liberal maximum message size of 100 MiB to prevent abuse. All fragments of a message are evicted when their combined size exceeds this limit.

0.7.2

• Fragment-assembly: set maximum limit of 100 (incomplete) messages. After reaching this limit, the oldest message will be removed from the assembler.
• Marked message-queuing as "won't fix"; explanation added to "Known issues" section.
• Added changelog section in README.md.

0.7.1

• Moved working notes to lib.rs comments.

0.7.0

Initial release.

☐: 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.
  • ☑ Limit number of incomplete distinct messages for OTRv4.
• ☐ 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 removed from otr4j and will not be implemented here. See "known issues" below for details.
• ☐ 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:

• Fragments and reassembly (exact limits open for discussion):
  • ☑ Maximum number of incomplete messages: 100
  • ☑ Maximum fragment size: 250 kiB
  • ☑ Maximum message size: 100 MiB
  • ☐ Maximum over-all memory usage for fragments store
  • ☑ Logging reports on dropped fragments/messages that exceed limits.
• ☑ The interactive DAKE is an independent state-machine. This ensures that the protocol only transitions away after DAKE has completed successfully. It is not possible to trigger DAKE starts causing OTRv4 to transition away from encrypted-messaging state.
• ☑ Single instance of Account represents single account on a chat network: allows for specific identity (DSA keypair), chat network/transport.
• ☐ Per-account thread-safe implementation. (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.