*** empty log message ***

Rev: ChangeLog:1.201
Rev: NEWS:1.48
Rev: doc/srp-spec.txt:1.5(DEAD)

ChangeLog

 2000-05-28  Niels Mller  <nisse@cuckoo.localdomain>
 
+	* src/werror.c (werror_hexdump): Include an ascii column in the
+	output. 
+
+	* src/unix_user.c (do_read_file): Fixed call to ssh_format.
+
+	* src/publickey_crypto.h (make_dh): Added prototype.
+
+	* src/dh_exchange.c (init_dh_instance): Use hex in debug output. 
+
+	* src/client_keyexchange.c (srp_client_instance): Removed salt
+	attribute. 
+	(do_handle_srp_reply): Bug fixes.
+
+	* doc/Makefile.am.in: Added pattern rule for RFC-like nroff
+	formatting. 
+
 	* src/srp_exchange.c (srp_make_verifier): New function.
 	(srp_hash_password): Fixed call to ssh_format.
 	(srp_make_init_msg): Likewise.
@@ -9,6 +25,7 @@
 
 	* src/lshd.c: Added SRP support. New options --srp-keyexchange,
 	--no-srp-keyexchange, --dh-keyexchange, --no-dh-keyexchange.
+	* src/lsh.c: Likewise.
 
 	* src/dh_exchange.c (make_dh): New function.
 	(make_dh1): Use make_dh() and make_ssh_group1().

NEWS

+News for the 0.9.10 release
+
+	Fixed bug that caused buffered output to be lost at channel
+	close.
+
+	Experimental SRP support.
+
+	New program srp-gen.
+	
+	Improved the hex dumps in debug output.
+
 News for the 0.9.9 release
 
 	autoconf fixes. Add -R-flags when appropriate. Recognize

doc/srp-spec.txt

-This document specifies the use of the Secure Remote Password as a key
-exchange method in LSH.
-
-/Niels Möller, 2000-05-23 
-
-
-INTRODUCTION
-
-The main virtue of the SRP protocol [SRP] is that it provides authentication
-based on a small secret (typically a password). It is useful in
-situations where no authentic host key is known. For SSH/LSH, it can
-be used as a bootstrapping procedure to get the host key of a server
-in a safe way. SRP also provides authentication of the user, which
-means that it might make sense to skip the secsh
-"ssh-userauth"-service [SSH-USERAUTH] when using SRP. 
-
-
-KEY EXCHANGE
-
-The name of the method is "srp-group1-sha1". Below, the same
-conventions are used as in the description of the
-"diffie-hellman-group1-sha1" method:
-
-C is the client, S is the server; p is a large safe prime, g is a
-generator for a subgroup of GF(p), and q is the order of the subgroup;
-V_S is S's version string; V_C is C's version string; K_S is S's
-public host key; I_C is C's KEXINIT message and I_S S's KEXINIT
-message which have been exchanged before this part begins. (See
-[SSH-TRANS] for more information).
-
-Furthermore, HASH is a hash function (currently SHA1), n is the user's
-name (used for looking up salt and verifier in the server's database),
-p is a password, and s is a random salt string.
-
-x is constructed from the strings n, p and s as HASH(s || HASH(n ||
-p)), and the verifier is computed as g^x mod p. S keeps a database
-containing triples <n, s, v>, indexed by n.
-
-Knowledge of the verifier enables an attacker to mount an offline
-search (also known as a "dictionary attack") on the user's password.
-So it should be kept secret. The <name, salt, verifier> entry can be
-created on the user's machine and transferred to the server, just like
-a user's public key, or it could be created on the server. The former
-approach has the advantage that the cleartext password is not even
-temporarily known by the server.
-
-1. C renerates a random number a (lg(p) < a < q) and computes e = g^a mod
-   p. C sends e and n to S.
-
-2. S uses n to find v and s in its database. S generates a random
-   number b, (lg(p) < b < q) and computes f = v + g^b mod p. S selects
-   u as the integer corresponding to the first 32 bits of HASH(f). If
-   f or u happens to be zero, S must try another b. S computes K = (e *
-   v^u)^b mod p. S sends s and f to C.
-
-3. C gets the password p and computes x = HASH(s || H(n || p)) and v =
-   g^x mod p. C also computes u in the same way as S. Finally, C
-   computes K = (f - v) ^ (a + u * x) mod p.
-
-Each party must check that e and f are in the range [1, p-1]. If not,
-the key exchange fails.
-
-Note that the addition in v + g^b mod p in step 2 is not a group
-operation, and the result could be zero, or, if g doesn't generate the
-entire multiplicative group of Z/p, some other element not in the
-group. In principle, we could use any invertible binary operation, say
-XOR, instead of addition modulo p. In step 3, v is subtracted again,
-and f - v is used for further computations. Perhaps C should check
-here that f - v belongs to the group?
-
-At this point C and S have a shared secret K. They must now prove that
-they know the same value. Even if we're primarily interested in
-authenticating the server, the user must prove knowledge of the key
-*first*. (Otherwise, the server leaks information about the verifier).
-
-
-MESSAGES
-
-Group and hash function is negotiated with the KEXINIT messages. No
-host key algorithm is used, and it MAY be specified as "none".
-
-First, the client sends:
-
-  byte      SSH_MSG_KEXSRP_INIT
-  string    n
-  mpint     e
-
-The server responds with
-
-  byte      SSH_MSG_KEXSRP_REPLY
-  string    s
-  mpint     f
-
-The server MUST NOT send this message until it has received the
-SSH_MSG_KEXSRP_INIT message. At this point, both sides can compute the
-exchange hash H, as the HASH of the concatenation of the following:
-
-  string    V_C, the client's version string (CR and NL excluded)
-  string    V_S, the server's version string (CR and NL excluded)
-  string    I_C, the payload of the client's SSH_MSG_KEXINIT
-  string    I_S, the payload of the server's SSH_MSG_KEXINIT
-  string    n, the user name
-  string    s, the salt
-  mpint     e, exchange value sent by the client
-  mpint     f, exchange value sent by the server
-  mpint     K, the shared secret
-
-The client computes m1 = H, and sends it to the server, to prove that
-it knows the shared key. It sends
-
-  byte SSH_MSG_KEXSRP_PROOF
-  string m1
-
-(FIXME: Would it be better not to send the exchange hash in the clear,
-e.g. use m1 = HASH(H)?)
-
-The server verifies that m is correct using its own K. If they don't
-match, the keyexchange fails, and the server MUST NOT send any proof
-back to the client.
-
-Finally, the server computes m2 as the HASH of the concatenation of
-
-  mpint e
-  string m1
-  mpint K
-
-and sends
-
-  byte SSH_MSG_KEXSRP_PROOF
-  string m2
-
-to the client. The client verifies that m2 is correct, and if so, the
-key exchange is successful and its output is H and K.
-
-
-MESSAGE NUMBERS
-
-The following message numbers have been defined in this protocol
-
-  /* Numbers 30-49 used for kex packets.
-     Different kex methods may reuse message numbers in
-     this range. */
-  #define SSH_MSG_KEXSRP_INIT            30
-  #define SSH_MSG_KEXSRP_REPLY           31
-  #define SSH_MSG_KEXSRP_PROOF           32
-
-
-REFERENCES
-
-[SRP]  T. Wu, "The SRP Authentication and Key Exchange System",
-Internet Draft, draft-wu-srp-auth-03.txt
-
-[SSH-ARCH] Ylonen, T., et al, "SSH Protocol Architecture", Internet
-Draft, draft-ietf-secsh-architecture-05.txt
-
-[SSH-TRANS] Ylonen, T., et al, "SSH Transport Layer Protocol", Internet
-Draft, draft-ietf-secsh-transport-07.txt
-
-[SSH-USERAUTH] Ylonen, T., et al, "SSH Authentication Protocol",
-Internet Draft, draft-ietf-secsh-userauth-07.txt
-