OpenWrt – Blame information for rev 1
?pathlinks?
Rev | Author | Line No. | Line |
---|---|---|---|
1 | office | 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. |