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 compsession 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
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
The <Old Channel ID> is the channel's old ID and the <New
Channel ID> is the new one that MUST replace the old one.
-
-
+ Server which receives this from router MUST re-announce the
+ channel to the router by sending SILC_PACKET_NEW_CHANNEL packet
+ with the new Channel ID.
11 SILC_NOTIFY_TYPE_SERVER_SIGNOFF
Sent when server quits SILC network. Those clients from this
server that are on channels must be removed from the channel.
- Max Arguments: 2000
+ Max Arguments: 256
Arguments: (1) <Server ID> (n) [<Client ID>] [...]
The <Server ID> is the server's ID. The rest of the arguments
document should define how this flag is interpreted
and define any associated payloads.
- 0x0100 - 0x0800 RESERVED
+ 0x0100 SILC_MESSAGE_FLAG_UTF8
+
+ This flag indicates that the message is UTF-8 encoded
+ textual message. When sending text messages this
+ flag SHOULD be used. When this flag is used the text
+ sent as message MUST be UTF-8 encoded.
+
+ 0x0200 - 0x0800 RESERVED
Reserved for future flags
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
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
-~ 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 channel
+ message. The MAC is computed after encryption from the
+ 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
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
projects / silc.git / blobdiff