protocol. The data payload area is always encrypted.
The last part of SILC packet is the packet MAC that assures the
-integrity of the packet. The MAC is always computed from the packet
-before the encryption is applied to the packet. If compression is used
-in the packet the MAC is computed after the compression has been
-applied. The compression, on the other hand, is always applied before
-encryption. See more details in the section 2.6 Packet MAC Generation.
+integrity of the packet. See the section 2.6 Packet MAC Generation
+for more information. If compression is used the compsession is
+always applied before encryption.
All fields in all packet payloads are always in MSB (most significant
byte first) order.
| Public Key Length | Public Key Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
-~ Public Key of the party (or certificate) ~
+~ Public Key (or certificate) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.in 3
o Payload Length (2 bytes) - Length of the entire Notify Payload
including any associated Argument Payloads.
-o Argument Nums (2 bytes) - Indicates the number of Argument
+o Argument Nums (1 byte) - Indicates the number of Argument
Payloads associated to this payload. Notify types may define
arguments to be send along the notify message.
.in 3
notify arguments is same as in SILC commands described in [SILC4].
Note that all ID's sent in arguments are sent inside ID Payload. Also
note that all passphrases that may be sent inside arguments MUST be
-UTF-8 [RFC2279] encoded.
-
+UTF-8 [RFC2279] encoded. Also note that all public keys or certificates
+sent in arguments are actually Public Key Payloads.
.in 6
.ti 0
2.3.9 Channel Message Payload
-Channel messages are the most common messages sent in the SILC.
-Channel Message Payload is used to send message to channels. These
-messages can only be sent if client has joined to some channel.
-Even though this packet is the most common in SILC it is still
-special packet. Some special handling on sending and reception
-of channel message is required.
+Channel Message Payload is used to send message to channels, a group
+of users. These messages can only be sent if client has joined to
+some channel. Even though this packet is very common in SILC it
+is still special packet. Some special handling on sending and
+reception of channel message is required.
Padding MUST be applied into this payload since the payload is
encrypted separately from other parts of the packet with the
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
-~ MAC ~
+~ Initial Vector * ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
-~ Initial Vector * ~
+~ MAC * ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.in 3
applied because this payload is encrypted separately from
other parts of the packet.
+o Initial Vector (variable length) - The initial vector
+ that has been used in packet encryption. It needs to be
+ used in the packet decryption as well. Contents of this
+ field depends on the encryption algorithm and mode. This
+ field is not encrypted, is not included in padding
+ calculation and its length equals to cipher's block size.
+ This field is authenticated by the channel message MAC.
+
o MAC (variable length) - The MAC computed from the
Message Flags, Message Length, Message Data, Padding Length,
- Padding and Initial Vector fields in that order. This
- protects the integrity of the plaintext channel message.
- The receiver can verify from the MAC whether the message
- decrypted correctly. Also, if more than one private key
+ Padding and Initial Vector fields in that order. The MAC
+ is computed after the payload is encrypted. This is so
+ called Encrypt-Then-MAC order; first encrypt, then compute
+ MAC from ciphertext. The MAC protects the integrity of
+ the channel message. Also, if more than one private key
has been set for the channel, the receiver can verify which
- of the keys decrypted the message correctly. Note that,
- this field is encrypted and MUST be added to the padding
- calculation.
-
-o Initial Vector (variable length) - The initial vector
- that has been used in packet encryption. It needs to be
- used in the packet decryption as well. What this field
- includes is implementation issue. However, it is
- RECOMMENDED that it would be random data, or perhaps
- a timestamp. It is NOT RECOMMENDED to use zero (0) as an
- initial vector. This field is not encrypted. This field
- is not included into the padding calculation. Length
- of this field equals the cipher's block size. This field
- is, however authenticated.
+ of the keys must be used in decryption. This field is not
+ encrypted.
.in 3
two clients (or users for that matter). The messages are sent only
to the specified user and no other user inside SILC network is
able to see the message. The message is protected by the session
-key established by the SILC Key Exchange Protocol. However,
-it is also possible to agree to use a private key to protect
-just the private messages. See section 2.3.11 Private Message
-Key Payload for detailed description of how to agree to use
-specific key.
+key established by the SILC Key Exchange Protocol.
+
+However, it is also possible to agree to use a private key to
+protect just the private messages. It is for example possible to
+perform Key Agreement between two clients. See section 2.3.20
+Key Agreement Payload how to perform key agreement. See also
+section 2.3.12 Private Message Key Payload for another way of
+using private keys with private messages. See [SILC1] section
+4.6 for detailed description for private message key generation
+procedure.
If normal session key is used to protect the message, every server
between the sender client and the receiving client MUST decrypt the
packet. It MUST NOT be sent in any other packet type. The following
diagram represents the Private Message Payload.
+(*) indicates that the field is not encrypted.
+
.in 5
.nf
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
-~ Padding ~
+~ Padding ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| |
+~ MAC * ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.in 3
same purpose.
o Message Data Length (2 bytes) - Indicates the length of the
- Message Data field, not includes any other field.
+ Message Data field, not including any other field.
o Message Data (variable length) - The actual message to
- the client. Rest of the packet is reserved for the message
- data.
+ the client.
o Padding (variable length) - This field is present only
when the private message payload is encrypted with private
the payload multiple by eight (8), or by the block size of
the cipher, which ever is larger. When encrypted with
normal session keys, this field MUST NOT be included.
+
+o MAC (variable length) - This field is present only when
+ the private message payload is encrypted with private
+ message key. The MAC is computed from the Message Flags,
+ Message Data Length, Message Data and Padding fields in
+ that order. The MAC protects the integrity of the private
+ message. The MAC is computed after encryption from the
+ ciphertext. This is so called Encrypt-Then-MAC order;
+ first encrypt, then compute MAC from ciphertext. Note that,
+ this field is not encrypted and thus not included in the
+ padding calculation. When encrypted with normal session
+ keys, this field MUST NOT be included.
.in 3
are other, more secure ways of exchanging private message keys in
the SILC network. Instead of sending this payload it is possible to
negotiate the private message key with SKE protocol using the Key
-Agreement payload directly peer to peer.
+Agreement payload directly peer to peer, see section 2.3.20.
This payload may only be sent by client to another client. Server
MUST NOT send this payload at any time. After sending this payload
~ Cipher Name ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| HMAC Name Length | |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
+| |
+~ HMAC Name ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.in 3
.ce
in the private message encryption. If this field does not
exist then the default cipher of the SILC protocol is used.
See the [SILC1] for defined ciphers.
-.in 3
+o HMAC Name Length (2 bytes) - Indicates the length of the
+ HMAC Name field in the payload, not including any other
+ field.
+
+o HMAC Name (variable length) - Name of the HMAC to use
+ in the private message MAC computation. If this field does
+ not exist then the default HMAC of the SILC protocol is used.
+ See the [SILC1] for defined HMACs.
+.in 3
.ti 0
processed as the [SILC3] describes. If the key material is used as
channel private key then the Sending Encryption Key, as defined in
[SILC3] is used as the channel private key. Other key material must
-be discarded. The [SILC1] defines the way to use the key material if
-it is intended to be used as private message keys. Any other use for
-the key material is undefined.
+be discarded. The [SILC1] in section 4.6 defines the way to use the
+key material if it is intended to be used as private message keys.
+Any other use for the key material is undefined.
.ti 0
Data integrity of a packet is protected by including a message
authentication code (MAC) at the end of the packet. The MAC is computed
from shared secret MAC key, that is established by the SILC Key Exchange
-protocol, from packet sequence number, and from the original contents
-of the packet. The MAC is always computed before the packet is
-encrypted, although after it is compressed if compression is used.
+protocol, from packet sequence number, and from the encrypted packet
+data. The MAC is always computed after packet is encrypted. This is
+so called Encrypt-Then-MAC order; packet is first encrypted, then MAC
+is computed from the encrypted data.
The MAC is computed from entire packet. Every bit of data in the packet,
including SILC Packet Header is used in the MAC computing. This way
the entire packet becomes authenticated.
-If the packet is special packet MAC is computed from the entire packet
-but part of the packet may be encrypted before the MAC is computed.
-This is case, for example, with channel messages where the message data
-is encrypted with key that server may not now. In this case the MAC
-has been computed from the encrypted data.
-
Hence, packet's MAC generation is as follows:
- mac = MAC(key, sequence number | SILC packet)
+ mac = MAC(key, sequence number | Encrypted SILC packet)
The MAC key is negotiated during the SKE protocol. The sequence number
is a 32 bit MSB first value starting from zero for first packet and
increasing for subsequent packets, finally wrapping after 2^32 packets.
-The value is never reset, not even after rekey has been performed. Note
-that the sequence number is incremented only when MAC is computed for a
-packet. If packet is not encrypted and MAC is not computed then the
-sequence number is not incremented. Hence, the sequence number is zero
-for first encrypted packet.
+The value is never reset, not even after rekey has been performed.
+However, rekey MUST be performed before the sequence number wraps
+and repeats from zero. Note that the sequence number is incremented only
+when MAC is computed for a packet. If packet is not encrypted and MAC is
+not computed then the sequence number is not incremented. Hence, the
+sequence number is zero for the very first encrypted packet.
See [SILC1] for defined and allowed MAC algorithms.
may be calculated as follows:
.in 6
-padding length = 16 - (packet_length mod block_size)
+padding_length = 16 - (packet_length mod block_size)
+if (padding_length < 8)
+ padding_length += block_size
.in 3
The `block_size' is the block size of the cipher. The maximum padding
-length is 128 bytes, and minimum is 1 byte. The above algorithm calculates
-the padding to the next block size, and always returns the padding
-length between 1 - 16 bytes. However, implementations may add padding
-up to 128 bytes. For example packets that include a passphrase or a
-password for authentication purposes SHOULD pad the packet up to the
-maximum padding length.
+length is 128 bytes, and minimum is 8 bytes. For example, packets that
+include a passphrase or a password for authentication purposes SHOULD
+pad the packet up to the maximum padding length. The maximum padding
+is calculated as follows:
+
+.in 6
+padding_length = 128 - (packet_length mod block_size)
+.in 3
For special packets the padding calculation is different as special
packets may be encrypted differently. In these cases the encrypted
length.
The padding MUST be random data, preferably, generated by
-cryptographically strong random number generator.
+cryptographically strong random number generator for each packet
+separately.
.ti 0
If the sender wants to compress the packet it MUST apply the
compression now. Sender MUST also compute the padding as described
-in above sections. Then sender MUST compute the MAC of the packet.
-
-Then sender MUST encrypt the packet as has been described in above
-sections according whether the packet is normal packet or special
+in above sections. Then sender MUST encrypt the packet as has been
+described in above sections according whether the packet is normal
+packet or special packet. Then sender MUST compute the MAC of the
packet. The computed MAC MUST NOT be encrypted.
projects / runtime.git / blobdiff