t_* stuff is from the srp 1.7.1 dist
bn_* stuff is from openssl 0.9.6

(The 7 in libtinysrp's version number reflects the srp version.)

Licensing and copyright for srp and openssl are as indicated in the relevant
source files.  Everything else here is GPL, including the tinysrp protocol.

Changelog since initial release:

0.7.4   more robust terminal modes in t_getpass
	a potential buffer overflow in tinysrp
0.7.5   uninitialized pointer bug in tconf

Changes from the base srp and openssl distributions:

I've removed everything that's not needed for client/server operations, and
all the bn_* stuff that's only used for prime generation has been moved to
t_conf.c, which isn't part of the library anymore.  Also, all the routines
used for passphrase file maintenance have been moved to tphrase.c.

The library has been optimized (a bit) for space instead of speed.  Since
authentication is usually only done once, this isn't a big problem.  Modern
CPUs are plenty fast for this task, and even 100 MHz CPUs are fine.  If you
really need the speed, get the regular distributions.

Note that if the server sends the client a prime that the client doesn't
know about, the client MUST test for primality.  Since this is pretty
expensive, and takes 30 seconds on a 100 MHz machine, and uses lots of code,
I've removed that ability from the client.  So only KNOWN primes can be
used.  You can still generate new ones with tconf, but you have to install
them in the table of known primes (pre_params) in t_getconf.c that's common
to the client and server, and recompile.  The configuration file is gone.

The default prime (the last entry in the table) is 1024 bits; there are
others with more bits but they will be correspondingly slower.

The default tpasswd file (which is an ascii file that may be editted with a
regular text editor) contains two users: moo (passphrase "glub glub") and
"new user" (passphrase "this is a test").  Passphrases may be added or
changed with tphrase; you can also change the user's prime.  To delete a
user, edit the tpasswd file and remove that line.  The tpasswd file's
default name is DEFAULT_PASSWD in t_pwd.h.  Note that you can't change a
user's username by editting the file: the username is encoded in the
verifier.  If you change a username you must set a new passphrase with
tphrase.

Here is an example session, using the supplied srvtest and clitest.  First,
start both programs in different windows, and enter the user names.  Normally,
the client would send the username to the server.  Server lines are marked
with S>, client lines with C>.

S> % srvtest
S> Enter username: moo
S> index (to client): 5
S> salt (to client): 19AI0Hc9jEkdFc

C> % clitest
C> Enter username: moo
C> Enter index (from server): 5
C> Enter salt (from server): 19AI0Hc9jEkdFc

The server reports the index and salt values used for that user.  They
are sent over the network to the client.  (Simulate this by cutting and
pasting from one window to the other.)

C> A (to server): 5wCDXRxLIv/zLazYfKupV/OY3BlhTZuJ71wVgI0HcL1kSJEpkMuWF.xEz/BV2wlJl7vk5Eoz9KMS1ccnaatsVP5D6CBm7UA.yVB59EQFN0dNBirvX29NAFdtdMsMppo5tHRy987XjJWrWSLpeibq6emr.gP8nYyX75GQqSiMY1j
C> Enter password:

S> Enter A (from client): 5wCDXRxLIv/zLazYfKupV/OY3BlhTZuJ71wVgI0HcL1kSJEpkMuWF.xEz/BV2wlJl7vk5Eoz9KMS1ccnaatsVP5D6CBm7UA.yVB59EQFN0dNBirvX29NAFdtdMsMppo5tHRy987XjJWrWSLpeibq6emr.gP8nYyX75GQqSiMY1j

Now the client calculates A and sends it to the server, and while the
server is munching on that, the client gets the password from the user.

S> B (to client): 9dcCpulxQAbaDXI0NHWY6B.QH6B9fsoXs/x/5SCNBNJm/6H6bYfbVrwNmdquhLZjYMvpcgGc2mBYqL77RNfw1kVQo17//GfsByECBIjRnrAn02ffX9Y/llJcfscAQiii0hyZhJf9PT5wE7pC7WUjIgSqckIZ0JLNDbSr7fJcrgw
S> Session key: ebbcf3a45c968defdcfff6e144ad8d4f5412167c9716e79cbf7cacfe18257947ad46fa5d6418a1fd

The server now calculates B and sends it to the client.  The session key
is not sent -- it is a shared secret that can be used for encryption.

C> Enter B (from server): 9dcCpulxQAbaDXI0NHWY6B.QH6B9fsoXs/x/5SCNBNJm/6H6bYfbVrwNmdquhLZjYMvpcgGc2mBYqL77RNfw1kVQo17//GfsByECBIjRnrAn02ffX9Y/llJcfscAQiii0hyZhJf9PT5wE7pC7WUjIgSqckIZ0JLNDbSr7fJcrgw
C> Session key: ebbcf3a45c968defdcfff6e144ad8d4f5412167c9716e79cbf7cacfe18257947ad46fa5d6418a1fd
C> Response (to server): b9ea99094a176c4be28eb469982066cc7146d180

The client uses the B value to calculate its own copy of the shared secret
session key, and sends a response to the server proving that it does know
the correct key.

S> Enter response (from client): b9ea99094a176c4be28eb469982066cc7146d180
S> Authentication successful.
S> Response (to client): cd46c839ccad2d0c76f3ca1905ae8ceda8d1c1dc

The server authenticates the client.  (You're in!)

C> Enter server response: cd46c839ccad2d0c76f3ca1905ae8ceda8d1c1dc
C> Server authentication successful.

The client authenticates the server (prevents server spoofing in the case
where the session key isn't used to encrypt the channel -- a spoofed server
might just respond with random values and _pretend_ to authenticate the
client; but the spoofed server won't know the session key and this check
catches that).

Final note:

Remember that many breaches of security involve buggy software, such as
servers susceptible to buffer overflow exploits that totally bypass any
passphrase, secure or not.  If an attacker roots your client, or the server,
no form of authentication will work.  Consider MAC-based schemes if this
worries you.