+
+.ti 0
+3.10.1.1 CBC Mode
+
+The "cbc" encryption mode is CBC mode with inter-packet chaining. This
+means that the Initial Vector (IV) for the next encryption block is
+the previous ciphertext block. The very first IV MUST be random and is
+generated as described in [SILC3].
+
+
+.ti 0
+3.10.1.2 CTR Mode
+
+The "ctr" encryption mode is CTR mode. The CTR mode in SILC is stateful
+in encryption and decryption. Both sender and receiver maintain the
+counter for the CTR mode and thus can precompute the key stream for
+encryption and decryption. By default, CTR mode does not require
+plaintext padding, however implementations MAY apply padding to the
+packets. If the last key block is larger than the last plaintext block
+the resulted value is truncated to the size of the plaintext block and
+the most significant bits are used. When sending authentication data
+inside packets the maximum amount of padding SHOULD be applied with
+CTR mode as well.
+
+In CTR mode only the encryption operation of the cipher is used. The
+decryption operation is not needed since both encryption and decryption
+process is simple XOR with the plaintext block and the key stream block.
+
+The counter block is used to create the key for the CTR mode. When
+SILC specifications refer to Initial Vector (IV) in general cases, in
+case of CTR mode it refers to the counter block. The format of the
+128 bit counter block is as follows:
+
+.in 5
+.nf
+ 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Truncated HASH from SKE |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Sending/Receiving IV from SKE |
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Block Counter |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+.in 3
+
+.ce
+Figure 6: Counter Block
+
+.in 6
+o Truncated HASH from SKE (4 bytes) - This value is the 32 most
+ significant bits from the HASH value that was computed as a
+ result of SKE protocol. This acts as session identifier and
+ each rekey MUST produce a new HASH value.
+
+o Sending/Receiving IV from SKE (8 bytes) - This value is the 64
+ most significant bits from the Sending IV or Receiving IV
+ generated in the SKE protocol. When this mode is used to
+ encrypt sending traffic the Sending IV is used, when used to
+ decrypt receiving traffic the Receiving IV is used. This
+ assures that two parties of the protocol use different IV
+ for sending traffic. Each rekey MUST produce a new value.
+
+o Block Counter (4 bytes) - This is the counter value for the
+ counter block and is MSB ordered number starting from one (1)
+ value for first block and incrementing for subsequent blocks.
+ The same value MUST NOT be used twice. The rekey MUST be
+ performed before this counter value wraps.
+.in 3
+
+CTR mode MUST NOT be used with "none" MAC. Implementations also MUST
+assure that the same counter block is not used to encrypt more than
+one block. Also, the key material used with CTR mode MUST be fresh
+key material. Static keys (pre-shared keys) MUST NOT be used with
+CTR mode. For this reason using CTR mode to encrypt for example
+channel messages or private messages with a pre-shared key is
+inappropriate. For private messages, the Key Agreement could be
+performed to produce fresh key material.
+
+If the IV Included flag was negotiated in SKE, implementations SHOULD
+still use the same counter block format as defined above. However,
+implementations are RECOMMENDED to replace the Truncated HASH field
+with a 32 bit random value for each IV (counter block) per encrypted
+SILC packet. Also note, that in this case the decryption process is
+not stateful and receiver cannot precompute the key stream.
+
+
+.ti 0
+3.10.1.3 Randomized CBC Mode
+
+The "rcbc" encryption mode is CBC mode with randomized IV. This means
+that each IV for each packet MUST be chosen randomly. In this mode the
+IV is appended at the end of the last ciphertext block and thus delivered
+to the recipient. This mode increases the ciphertext size by one
+ciphertext block. Note also that some data payloads in SILC are capable
+of delivering the IV to the recipient. When explicitly encrypting these
+payloads with randomized CBC the IV MUST NOT be appended at the end
+of the ciphertext.