updates.
authorPekka Riikonen <priikone@silcnet.org>
Mon, 26 Feb 2001 22:47:24 +0000 (22:47 +0000)
committerPekka Riikonen <priikone@silcnet.org>
Mon, 26 Feb 2001 22:47:24 +0000 (22:47 +0000)
apps/silc/clientconfig.c
doc/draft-riikonen-silc-pp-01.nroff
lib/silcclient/README
lib/silcclient/client.c
lib/silcclient/client.h
lib/silcclient/command.c
lib/silcclient/command.h
lib/silcclient/command_reply.c
lib/silcclient/command_reply.h
lib/silcclient/protocol.c

index 1e85aa4f2150e490f7a8604d1a331f86ca7307c5..65d9b2756fb4b714f7d86c240fa0321fcc67a5dc 100644 (file)
@@ -4,7 +4,7 @@
 
   Author: Pekka Riikonen <priikone@poseidon.pspt.fi>
 
-  Copyright (C) 1997 - 2000 Pekka Riikonen
+  Copyright (C) 1997 - 2001 Pekka Riikonen
 
   This program is free software; you can redistribute it and/or modify
   it under the terms of the GNU General Public License as published by
index 7a87af28411de04c2ab7e7f8ba136389e30c4a71..68283cb7e4eba210337e3ec855148b435128ec1c 100644 (file)
@@ -195,7 +195,7 @@ the packet type, origin of the packet and the destination of the packet.
 The header is variable in length and first two (2) bytes of the
 header (thus first two bytes of the packet) are not encrypted.  The
 first two (2) bytes are the length of the packet which is not encrypted.
-See following section for description of SILC Packet header.  Packets
+See The following section for description of SILC Packet header.  Packets
 without SILC header or with malformed SILC header must be dropped.
 
 Padding follows the packet header.  The purpose of the padding is to
@@ -228,7 +228,7 @@ detailed information about the packet.  The receiver of the packet uses
 the packet header to parse the packet and gain other relevant parameters
 of the packet.
 
-Following diagram represents the default SILC header format.
+The following diagram represents the default SILC header format.
 (*) indicates that this field is never encrypted.  Other fields are
 always encrypted.
 
@@ -269,7 +269,7 @@ o Flags (1 byte) - Indicates flags to be used in packet
   processing.  Several flags may be set by ORing the flags
   together.
 
-  Following flags are reserved for this field:
+  The following flags are reserved for this field:
 
 
      No flags                  0x00
@@ -766,7 +766,7 @@ packet payloads.
 This payload can be used to send an ID.  ID's are variable length thus
 this payload provides a way to send variable length ID's.
 
-Following diagram represents the ID Payload.
+The following diagram represents the ID Payload.
 
 .in 5
 .nf
@@ -804,7 +804,7 @@ needs and supports arguments, such as commands.  Number of arguments
 associated with a packet must be indicated by the packet payload who
 needs the arguments. Argument Payloads must always reside right after
 the packet payload needing the arguments.  Incorrect amount of argument
-payloads must cause rejection of the packet.  Following diagram represents
+payloads must cause rejection of the packet.  The following diagram represents
 the Argument Payload.
 
 
@@ -849,7 +849,7 @@ Disconnect payload is sent upon disconnection.  The payload is simple;
 reason of disconnection is sent to the disconnected party.
 
 The payload may only be sent with SILC_PACKET_DISCONNECT packet.  It
-must not be sent in any other packet type.  Following diagram represents
+must not be sent in any other packet type.  The following diagram represents
 the Disconnect Payload.
 
 
@@ -992,7 +992,7 @@ not send this payload.  The receiver of this payload may totally ignore the
 contents of the payload, however, notify message should be audited.
 
 The payload may only be sent with SILC_PACKET_NOTIFY packet.  It must
-not be sent in any other packet type.  Following diagram represents the
+not be sent in any other packet type.  The following diagram represents the
 Notify Payload.
 
 .in 5
@@ -1022,7 +1022,7 @@ o Argument Nums (2 bytes) - Indicates the number of Argument
   arguments to be send along the notify message.
 .in 3
 
-Following list of currently defined notify types.  The format for notify
+The following list of currently defined notify types.  The format for notify
 arguments is same as in SILC commands described in [SILC1].  Also, all
 ID's sent in arguments are sent inside ID Payload.
 
@@ -1271,7 +1271,7 @@ the source ID from the header which tells the client who sent
 the message.
 
 The payload may only be sent with SILC_PACKET_CHANNEL_MESSAGE packet.
-It  must not be sent in any other packet type.  Following diagram 
+It  must not be sent in any other packet type.  The following diagram 
 represents the Channel Message Payload.
 
 (*) indicates that the field is not encrypted.
@@ -1360,7 +1360,7 @@ Channel key should expire periodically, say, in one hour, in
 which case new channel key is created and distributed.
 
 The payload may only be sent with SILC_PACKET_CHANNEL_KEY packet.
-It must not be sent in any other packet type.  Following diagram 
+It must not be sent in any other packet type.  The following diagram 
 represents the Channel Key Payload.
 
 
@@ -1457,7 +1457,7 @@ packet.  Section 4.8.2 Client To Client in [SILC1] gives example of
 this scheme as well.
 
 The payload may only be sent with SILC_PACKET_PRIVATE_MESSAGE 
-packet.  It must not be sent in any other packet type.  Following 
+packet.  It must not be sent in any other packet type.  The following 
 diagram represents the Private Message Payload.
 
 
@@ -1515,7 +1515,7 @@ the sender of private messages must set the Private Message Key
 flag into SILC Packet Header.
 
 The payload may only be sent with SILC_PACKET_PRIVATE_MESSAGE_KEY 
-packet.  It must not be sent in any other packet type.  Following 
+packet.  It must not be sent in any other packet type.  The following 
 diagram represents the Private Message Key Payload.
 
 
@@ -1553,7 +1553,7 @@ o Private Message Key (variable length) - The actual private
 2.3.13 Command Payload
 
 Command Payload is used to send SILC commands from client to server.
-Also server may send commands to other servers.  Following diagram
+Also server may send commands to other servers.  The following diagram
 represents the Command Payload.
 
 
@@ -1637,7 +1637,7 @@ established by the SILC Key Exchange protocol.  See section Key
 Exchange Start Payload in [SILC3] for detailed information.
 
 The payload may only be sent with SILC_PACKET_CONNECTION_AUTH_REQUEST
-packet.  It must not be sent in any other packet type.  Following 
+packet.  It must not be sent in any other packet type.  The following 
 diagram represents the Connection Auth Request Payload.
 
 
@@ -1656,7 +1656,7 @@ Figure 16:  Connection Auth Request Payload
 
 .in 6
 o Connection Type (2 bytes) - Indicates the type of the ID.
-  Following connection types are defined:
+  The following connection types are defined:
 
      1    Client connection
      2    Server connection
@@ -1666,7 +1666,7 @@ o Connection Type (2 bytes) - Indicates the type of the ID.
   discarded and the authentication must be failed.
 
 o Authentication Method (2 bytes) - Indicates the authentication
-  method to be used in the authentication protocol.  Following
+  method to be used in the authentication protocol.  The following
   authentication methods are defined:
 
 
@@ -1744,7 +1744,7 @@ set the real nickname of the user which is then used to create new
 client ID.
 
 The payload may only be sent with SILC_PACKET_NEW_CLIENT packet.  It
-must not be sent in any other packet type.  Following diagram represents
+must not be sent in any other packet type.  The following diagram represents
 the New Client Payload.
 
 
@@ -1797,7 +1797,7 @@ of the server that it has created by itself.  It also includes a
 name of the server that is associated to the Server ID.
 
 The payload may only be sent with SILC_PACKET_NEW_SERVER packet.  It
-must not be sent in any other packet type.  Following diagram represents
+must not be sent in any other packet type.  The following diagram represents
 the New Server Payload.
 
 
@@ -1853,7 +1853,7 @@ then processes the command and creates the channel.  Client never sends
 this packet.
 
 The payload may only be sent with SILC_PACKET_NEW_CHANNEL packet.
-It must not be sent in any other packet type.  Following diagram
+It must not be sent in any other packet type.  The following diagram
 represents the New Channel Payload.
 
 
@@ -1899,7 +1899,7 @@ o Channel ID (variable length) - The created Channel ID.
 2.4 SILC ID Types
 
 ID's are extensively used in the SILC network to associate different
-entities.  Following ID's has been defined to be used in the SILC
+entities.  The following ID's has been defined to be used in the SILC
 network.
 
 .in 6
@@ -1953,7 +1953,7 @@ of the packet must first decrypt the SILC Packet header, or some parts
 of it, usually first 16 bytes of it.  Then the receiver checks the
 packet type from the decrypted part of the header and can determine
 how the rest of the packet must be decrypted.  If the packet type is
-any of the special cases described in following sections the packet
+any of the special cases described in The following sections the packet
 decryption is special.  If the packet type is not among those special
 packet types rest of the packet may be decrypted with the same key.
 
index cdd1011cf1aec58e555ee30bc1e64c479a2f31ff..39555b6d4ce7b25aea514d2e683c3119dc890b99 100644 (file)
@@ -5,20 +5,19 @@ This directory includes the SILC Client implementation.  The library uses
 common and core components of SILC protocol from lib/silccore library and
 normal utility routines from lib/silcutil library.  The library has been
 designed to be complete SILC Client implementation without actual user
-interface.  The library provides API for the application which can use
-it to implement generally what ever user interface it wants.
+interface.  The library provides the API for the application which it can
+use to implement generally whatever user interface it wants.
 
 The `ops.h' file defines the function prototypes that application must
 implement in order to be able to create the user interface with the
-library.  The idea is that the application can implement what ever user
-interface routines in the functions and display the data what ever way
+library.  The idea is that the application can implement whatever user
+interface routines in the functions and display the data whatever way
 it wants.  The library is entirely transparent to the user interface and
 it does not include any user interface specific issues such as window
 handling or item handling on the screen etc.  These does not interest
 the library.
 
 
-
 Creating Client
 ===============
 
@@ -54,6 +53,7 @@ SilcClientOperations ops = {
   get_auth_method:      silc_get_auth_method,
   verify_server_key:    silc_verify_server_key,
   ask_passphrase:       silc_ask_passphrase,
+  failure:              silc_failure,
 };
 
 
@@ -122,7 +122,7 @@ Using Own Connecting
 Application might not want to use silc_client_connect_to_server function
 if it wants to perform its own connecting for some reason.  In this case
 application must call function silc_client_start_key_exchange after it
-has created the connection by itself.  This function starts key exhange
+has created the connection by itself.  This function starts the key exhange
 protocol between the client and server and the library takes care of
 everything after that.
 
index 08b643ea33c3d1c2d72053e811c59590fa0d57a3..d393ec3f0e970ef16818c2a8b2fd9d5ee2265b8c 100644 (file)
@@ -4,7 +4,7 @@
 
   Author: Pekka Riikonen <priikone@poseidon.pspt.fi>
 
-  Copyright (C) 1997 - 2000 Pekka Riikonen
+  Copyright (C) 1997 - 2001 Pekka Riikonen
 
   This program is free software; you can redistribute it and/or modify
   it under the terms of the GNU General Public License as published by
@@ -970,6 +970,7 @@ void silc_client_packet_send_to_channel(SilcClient client,
   SilcCipher cipher;
   SilcHmac hmac;
   unsigned char *id_string;
+  unsigned int block_len;
 
   SILC_LOG_DEBUG(("Sending packet to channel"));
 
@@ -980,14 +981,15 @@ void silc_client_packet_send_to_channel(SilcClient client,
   }
 
   /* Generate IV */
+  block_len = silc_cipher_get_block_len(channel->channel_key);
   if (channel->iv[0] == '\0')
-    for (i = 0; i < 16; i++) channel->iv[i] = silc_rng_get_byte(client->rng);
+    for (i = 0; i < block_len; i++) channel->iv[i] = silc_rng_get_byte(client->rng);
   else
-    silc_hash_make(client->md5hash, channel->iv, 16, channel->iv);
+    silc_hash_make(client->md5hash, channel->iv, block_len, channel->iv);
 
   /* Encode the channel payload */
-  payload = silc_channel_payload_encode(data_len, data, 16, channel->iv
-                                       client->rng);
+  payload = silc_channel_payload_encode(data_len, data, block_len
+                                       channel->iv, client->rng);
   if (!payload) {
     client->ops->say(client, conn, 
                     "Error: Could not create packet to be sent to channel");
@@ -1028,13 +1030,10 @@ void silc_client_packet_send_to_channel(SilcClient client,
 
   packetdata.buffer = sock->outbuf;
 
-  SILC_LOG_HEXDUMP(("IV"), channel->iv, 16);
-  SILC_LOG_HEXDUMP(("channel key"), channel->key, channel->key_len/8);
-
   /* Encrypt payload of the packet. This is encrypted with the channel key. */
   channel->channel_key->cipher->encrypt(channel->channel_key->context,
                                        payload->data, payload->data,
-                                       payload->len - 16, /* -IV_LEN */
+                                       payload->len - block_len, /* -IV_LEN */
                                        channel->iv);
 
   /* Put the actual encrypted payload data into the buffer. */
@@ -2069,6 +2068,7 @@ void silc_client_channel_message(SilcClient client,
   SilcIDCacheEntry id_cache = NULL;
   SilcClientID *client_id = NULL;
   int found = FALSE;
+  unsigned int block_len;
 
   /* Sanity checks */
   if (packet->dst_id_type != SILC_ID_CHANNEL)
@@ -2089,20 +2089,14 @@ void silc_client_channel_message(SilcClient client,
 
   channel = (SilcChannelEntry)id_cache->context;
 
-  SILC_LOG_HEXDUMP(("channel key"), channel->key, channel->key_len);
-
   /* Decrypt the channel message payload. Push the IV out of the way,
      since it is not encrypted (after pushing buffer->tail has the IV). */
-  SILC_LOG_HEXDUMP(("Packet"), buffer->data, buffer->len);
-  silc_buffer_push_tail(buffer, channel->channel_key->cipher->block_len);
-  SILC_LOG_HEXDUMP(("Packet"), buffer->data, buffer->len);
-  SILC_LOG_HEXDUMP(("IV"), buffer->tail, 16);
+  block_len = silc_cipher_get_block_len(channel->channel_key);
+  silc_buffer_push_tail(buffer, block_len);
   channel->channel_key->cipher->decrypt(channel->channel_key->context,
                                        buffer->data, buffer->data,
                                        buffer->len, buffer->tail);
-  SILC_LOG_HEXDUMP(("Packet"), buffer->data, buffer->len);
-  silc_buffer_pull_tail(buffer, channel->channel_key->cipher->block_len);
-  SILC_LOG_HEXDUMP(("Packet"), buffer->data, buffer->len);
+  silc_buffer_pull_tail(buffer, block_len);
 
   /* Parse the channel message payload */
   payload = silc_channel_payload_parse(buffer);
index 0cf57a4964d0ae46e8a4f9d2fcdd3952c43b76eb..864aaf8f533343fad035d5079b996f48a378c3d7 100644 (file)
@@ -4,7 +4,7 @@
 
   Author: Pekka Riikonen <priikone@poseidon.pspt.fi>
 
-  Copyright (C) 1997 - 2000 Pekka Riikonen
+  Copyright (C) 1997 - 2001 Pekka Riikonen
 
   This program is free software; you can redistribute it and/or modify
   it under the terms of the GNU General Public License as published by
index 815c6cafabd86756b25b2aaacafe0ce0bc9a88c0..e81fa2303ca92db5cc93d989b34e5e0858fb2bcc 100644 (file)
@@ -4,7 +4,7 @@
 
   Author: Pekka Riikonen <priikone@poseidon.pspt.fi>
 
-  Copyright (C) 1997 - 2000 Pekka Riikonen
+  Copyright (C) 1997 - 2001 Pekka Riikonen
 
   This program is free software; you can redistribute it and/or modify
   it under the terms of the GNU General Public License as published by
index a47c7461f420a0edc6f6bacbda15544e86a451b4..d36ae1305277a11ed695abf50e5e0dd161269f6e 100644 (file)
@@ -4,7 +4,7 @@
 
   Author: Pekka Riikonen <priikone@poseidon.pspt.fi>
 
-  Copyright (C) 1997 - 2000 Pekka Riikonen
+  Copyright (C) 1997 - 2001 Pekka Riikonen
 
   This program is free software; you can redistribute it and/or modify
   it under the terms of the GNU General Public License as published by
index 468a012ea2fafef672b37e3e639a62305daa3231..b1187bb9fe89f0359988906a59abe991d591089c 100644 (file)
@@ -4,7 +4,7 @@
 
   Author: Pekka Riikonen <priikone@poseidon.pspt.fi>
 
-  Copyright (C) 1997 - 2000 Pekka Riikonen
+  Copyright (C) 1997 - 2001 Pekka Riikonen
 
   This program is free software; you can redistribute it and/or modify
   it under the terms of the GNU General Public License as published by
index d6f9faf1e28a2ffb88253d38f7d71bb91a2faecf..e27fcb9165fb3c57b4ac68766f276d3ca470cbe9 100644 (file)
@@ -4,7 +4,7 @@
 
   Author: Pekka Riikonen <priikone@poseidon.pspt.fi>
 
-  Copyright (C) 1997 - 2000 Pekka Riikonen
+  Copyright (C) 1997 - 2001 Pekka Riikonen
 
   This program is free software; you can redistribute it and/or modify
   it under the terms of the GNU General Public License as published by
index 06e0efd08f59b82b8e41110cc0d1d585afdace17..1cc78d5267221991a71a638df27e964da501b76c 100644 (file)
@@ -4,7 +4,7 @@
 
   Author: Pekka Riikonen <priikone@poseidon.pspt.fi>
 
-  Copyright (C) 1997 - 2000 Pekka Riikonen
+  Copyright (C) 1997 - 2001 Pekka Riikonen
 
   This program is free software; you can redistribute it and/or modify
   it under the terms of the GNU General Public License as published by