| 1 | t_* stuff is from the srp 1.7.1 dist |
| 2 | bn_* stuff is from openssl 0.9.6 |
| 3 | |
| 4 | (The 7 in libtinysrp's version number reflects the srp version.) |
| 5 | |
| 6 | Licensing and copyright for srp and openssl are as indicated in the relevant |
| 7 | source files. Everything else here is GPL, including the tinysrp protocol. |
| 8 | |
| 9 | Changelog since initial release: |
| 10 | |
| 11 | 0.7.4 more robust terminal modes in t_getpass |
| 12 | a potential buffer overflow in tinysrp |
| 13 | 0.7.5 uninitialized pointer bug in tconf |
| 14 | |
| 15 | Changes from the base srp and openssl distributions: |
| 16 | |
| 17 | I've removed everything that's not needed for client/server operations, and |
| 18 | all the bn_* stuff that's only used for prime generation has been moved to |
| 19 | t_conf.c, which isn't part of the library anymore. Also, all the routines |
| 20 | used for passphrase file maintenance have been moved to tphrase.c. |
| 21 | |
| 22 | The library has been optimized (a bit) for space instead of speed. Since |
| 23 | authentication is usually only done once, this isn't a big problem. Modern |
| 24 | CPUs are plenty fast for this task, and even 100 MHz CPUs are fine. If you |
| 25 | really need the speed, get the regular distributions. |
| 26 | |
| 27 | Note that if the server sends the client a prime that the client doesn't |
| 28 | know about, the client MUST test for primality. Since this is pretty |
| 29 | expensive, and takes 30 seconds on a 100 MHz machine, and uses lots of code, |
| 30 | I've removed that ability from the client. So only KNOWN primes can be |
| 31 | used. You can still generate new ones with tconf, but you have to install |
| 32 | them in the table of known primes (pre_params) in t_getconf.c that's common |
| 33 | to the client and server, and recompile. The configuration file is gone. |
| 34 | |
| 35 | The default prime (the last entry in the table) is 1024 bits; there are |
| 36 | others with more bits but they will be correspondingly slower. |
| 37 | |
| 38 | The default tpasswd file (which is an ascii file that may be editted with a |
| 39 | regular text editor) contains two users: moo (passphrase "glub glub") and |
| 40 | "new user" (passphrase "this is a test"). Passphrases may be added or |
| 41 | changed with tphrase; you can also change the user's prime. To delete a |
| 42 | user, edit the tpasswd file and remove that line. The tpasswd file's |
| 43 | default name is DEFAULT_PASSWD in t_pwd.h. Note that you can't change a |
| 44 | user's username by editting the file: the username is encoded in the |
| 45 | verifier. If you change a username you must set a new passphrase with |
| 46 | tphrase. |
| 47 | |
| 48 | Here is an example session, using the supplied srvtest and clitest. First, |
| 49 | start both programs in different windows, and enter the user names. Normally, |
| 50 | the client would send the username to the server. Server lines are marked |
| 51 | with S>, client lines with C>. |
| 52 | |
| 53 | S> % srvtest |
| 54 | S> Enter username: moo |
| 55 | S> index (to client): 5 |
| 56 | S> salt (to client): 19AI0Hc9jEkdFc |
| 57 | |
| 58 | C> % clitest |
| 59 | C> Enter username: moo |
| 60 | C> Enter index (from server): 5 |
| 61 | C> Enter salt (from server): 19AI0Hc9jEkdFc |
| 62 | |
| 63 | The server reports the index and salt values used for that user. They |
| 64 | are sent over the network to the client. (Simulate this by cutting and |
| 65 | pasting from one window to the other.) |
| 66 | |
| 67 | C> A (to server): 5wCDXRxLIv/zLazYfKupV/OY3BlhTZuJ71wVgI0HcL1kSJEpkMuWF.xEz/BV2wlJl7vk5Eoz9KMS1ccnaatsVP5D6CBm7UA.yVB59EQFN0dNBirvX29NAFdtdMsMppo5tHRy987XjJWrWSLpeibq6emr.gP8nYyX75GQqSiMY1j |
| 68 | C> Enter password: |
| 69 | |
| 70 | S> Enter A (from client): 5wCDXRxLIv/zLazYfKupV/OY3BlhTZuJ71wVgI0HcL1kSJEpkMuWF.xEz/BV2wlJl7vk5Eoz9KMS1ccnaatsVP5D6CBm7UA.yVB59EQFN0dNBirvX29NAFdtdMsMppo5tHRy987XjJWrWSLpeibq6emr.gP8nYyX75GQqSiMY1j |
| 71 | |
| 72 | Now the client calculates A and sends it to the server, and while the |
| 73 | server is munching on that, the client gets the password from the user. |
| 74 | |
| 75 | S> B (to client): 9dcCpulxQAbaDXI0NHWY6B.QH6B9fsoXs/x/5SCNBNJm/6H6bYfbVrwNmdquhLZjYMvpcgGc2mBYqL77RNfw1kVQo17//GfsByECBIjRnrAn02ffX9Y/llJcfscAQiii0hyZhJf9PT5wE7pC7WUjIgSqckIZ0JLNDbSr7fJcrgw |
| 76 | S> Session key: ebbcf3a45c968defdcfff6e144ad8d4f5412167c9716e79cbf7cacfe18257947ad46fa5d6418a1fd |
| 77 | |
| 78 | The server now calculates B and sends it to the client. The session key |
| 79 | is not sent -- it is a shared secret that can be used for encryption. |
| 80 | |
| 81 | C> Enter B (from server): 9dcCpulxQAbaDXI0NHWY6B.QH6B9fsoXs/x/5SCNBNJm/6H6bYfbVrwNmdquhLZjYMvpcgGc2mBYqL77RNfw1kVQo17//GfsByECBIjRnrAn02ffX9Y/llJcfscAQiii0hyZhJf9PT5wE7pC7WUjIgSqckIZ0JLNDbSr7fJcrgw |
| 82 | C> Session key: ebbcf3a45c968defdcfff6e144ad8d4f5412167c9716e79cbf7cacfe18257947ad46fa5d6418a1fd |
| 83 | C> Response (to server): b9ea99094a176c4be28eb469982066cc7146d180 |
| 84 | |
| 85 | The client uses the B value to calculate its own copy of the shared secret |
| 86 | session key, and sends a response to the server proving that it does know |
| 87 | the correct key. |
| 88 | |
| 89 | S> Enter response (from client): b9ea99094a176c4be28eb469982066cc7146d180 |
| 90 | S> Authentication successful. |
| 91 | S> Response (to client): cd46c839ccad2d0c76f3ca1905ae8ceda8d1c1dc |
| 92 | |
| 93 | The server authenticates the client. (You're in!) |
| 94 | |
| 95 | C> Enter server response: cd46c839ccad2d0c76f3ca1905ae8ceda8d1c1dc |
| 96 | C> Server authentication successful. |
| 97 | |
| 98 | The client authenticates the server (prevents server spoofing in the case |
| 99 | where the session key isn't used to encrypt the channel -- a spoofed server |
| 100 | might just respond with random values and _pretend_ to authenticate the |
| 101 | client; but the spoofed server won't know the session key and this check |
| 102 | catches that). |
| 103 | |
| 104 | Final note: |
| 105 | |
| 106 | Remember that many breaches of security involve buggy software, such as |
| 107 | servers susceptible to buffer overflow exploits that totally bypass any |
| 108 | passphrase, secure or not. If an attacker roots your client, or the server, |
| 109 | no form of authentication will work. Consider MAC-based schemes if this |
| 110 | worries you. |
| 111 | |
