@node Packet
@unnumbered Packet format

All packets are
@url{https://tools.ietf.org/html/rfc4506, XDR}-encoded structures.

@menu
* Plain packet: Plain.
* Encrypted packet: Encrypted.
@end menu

@node Plain
@section Plain packet

Plain packet contains either the whole file, or file request (freq), or
transition packet or email message. It is called "plain", because it
contains plaintext, but plain packets would never be stored on your hard
drive.

@verbatim
            HEADER
+-------------------------------+--...---+
| MAGIC | TYPE | PATHLEN | PATH | PAYLOAD|
+-------------------------------+--...---+
@end verbatim

@multitable @columnfractions 0.2 0.3 0.5
@headitem @tab XDR type @tab Value
@item Magic number @tab
    8-byte, fixed length opaque data @tab
    @verb{|N N C P P 0x00 0x00 0x01|}
@item Payload type @tab
    unsigned integer @tab
    0 (file), 1 (freq), 2 (mail), 3 (transition)
@item Path length @tab
    unsigned integer @tab
    actual length of @emph{path} field's payload
@item Path @tab
    255 byte, fixed length opaque data @tab
    @itemize
    @item UTF-8 encoded destination path for file transfer
    @item UTF-8 encoded source path for file request
    @item UTF-8 encoded, space separated, email recipients list
    @item Node's id the transition packet must be relayed on
    @end itemize
@end multitable

Path has fixed size because of hiding its actual length -- it is
valuable metadata. Payload is appended to the header -- it is not stored
as XDR field, because most XDR libraries will store all that data in the
memory.

Depending on the packet's type, payload could store:

@itemize
@item File contents
@item Destination path for freq
@item @url{http://zlib.net/, zlib} compressed email
@item Whole encrypted packet we need to relay on
@end itemize

@node Encrypted
@section Encrypted packet

Encrypted packets are the only files found in spools, in exchangeable
storages and that are synchronized between TCP daemons.

Each encrypted packet has the following header:

@verbatim
  +------------ HEADER -------------+   +-------- ENCRYPTED --------+
 /                                   \ /                             \
+--------------------------------------------+------------+----...-----------+------+
| MAGIC | NICE | SENDER | RCPT | EPUB | SIGN | SIZE | MAC | CIPHERTEXT | MAC | JUNK |
+-------------------------------------/------\------------+----...-----------+------+
                                     /        \
                      +-------------------------------------+
                      | MAGIC | NICE | SENDER | RCPT | EPUB |
                      +-------------------------------------+
@end verbatim

@multitable @columnfractions 0.2 0.3 0.5
@headitem @tab XDR type @tab Value
@item Magic number @tab
    8-byte, fixed length opaque data @tab
    @verb{|N N C P E 0x00 0x00 0x01|}
@item Niceness @tab
    unsigned integer @tab
    1-255, packet @ref{Niceness, niceness} level
@item Sender @tab
    32-byte, fixed length opaque data @tab
    Sender node's id
@item Recipient @tab
    32-byte, fixed length opaque data @tab
    Recipient node's id
@item Exchange public key @tab
    32-byte, fixed length opaque data @tab
    Ephemeral curve25519 public key
@item Signature @tab
    64-byte, fixed length opaque data @tab
    ed25519 signature for that packet's header
@end multitable

Signature is calculated over all previous fields.

All following encryption is done using
@url{https://www.schneier.com/academic/twofish/, Twofish} algorithm with
256-bit key in
@url{https://en.wikipedia.org/wiki/Counter_mode#Counter_.28CTR.29, CTR}
mode of operation with zero initialization vector (because each
encrypted packet has ephemeral exchange key). @url{https://blake2.net/,
BLAKE2b-256} MAC is appended to the ciphertext.

After the headers comes an encrypted payload size and MAC of that size.

@multitable @columnfractions 0.2 0.3 0.5
@headitem @tab XDR type @tab Value
@item Size @tab
    unsigned hyper integer @tab
    Payload size.
@end multitable

Next comes the actual encrypted payload with corresponding MAC.

Each node has static @strong{exchange} and @strong{signature} keypairs.
When node A want to send encrypted packet to node B, it:

@enumerate
@item generates ephemeral @url{http://cr.yp.to/ecdh.html, curve25519} keypair
@item prepares structure for signing
@item signs that structure using private
    @url{http://ed25519.cr.yp.to/, ed25519} signature key
@item takes remote node's exchange public key and performs
    Diffie-Hellman computation on this remote static public key and
    private ephemeral one
@item derived ephemeral key is used as an input to
    @url{https://en.wikipedia.org/wiki/HKDF, HKDF}-BLAKE2b-256 KDF
@item derives four session keys using
    @url{https://en.wikipedia.org/wiki/HKDF, HKDF}-BLAKE2b-256 KDF:
    @enumerate
    @item "Size" encryption (for Twofish) key
    @item "Size" authentication (for BLAKE2b-MAC) key
    @item Payload encryption key
    @item Payload authentication key
    @end enumerate
@item encrypts size, appends its ciphertext to the header
@item appends MAC tag over that ciphertext
@item encrypts and appends payload ciphertext
@item appends MAC tag over that payload ciphertext
@item possibly appends any kind of "junk" noise data to hide real
    payload's size from the adversary
@end enumerate