diff options
author | Felix Fietkau <nbd@openwrt.org> | 2008-12-24 10:42:12 +0000 |
---|---|---|
committer | Felix Fietkau <nbd@openwrt.org> | 2008-12-24 10:42:12 +0000 |
commit | 073a2a82844a0ff3fbe844c9c19be258bfb4d7fc (patch) | |
tree | 91368c1d3b51e419ca42ee0196df3553a19b976e /package/ead/src/tinysrp/Notes | |
parent | dbb49737c14b89d98d06d0173bca40e08d074524 (diff) | |
download | master-187ad058-073a2a82844a0ff3fbe844c9c19be258bfb4d7fc.tar.gz master-187ad058-073a2a82844a0ff3fbe844c9c19be258bfb4d7fc.tar.bz2 master-187ad058-073a2a82844a0ff3fbe844c9c19be258bfb4d7fc.zip |
add the 'ead' package (emergency access daemon),
which can provide remote access to your device, even if the ip
and firewall settings are broken
git-svn-id: svn://svn.openwrt.org/openwrt/trunk@13738 3c298f89-4303-0410-b956-a3cf2f4a3e73
Diffstat (limited to 'package/ead/src/tinysrp/Notes')
-rw-r--r-- | package/ead/src/tinysrp/Notes | 110 |
1 files changed, 110 insertions, 0 deletions
diff --git a/package/ead/src/tinysrp/Notes b/package/ead/src/tinysrp/Notes new file mode 100644 index 0000000000..a8620aa700 --- /dev/null +++ b/package/ead/src/tinysrp/Notes @@ -0,0 +1,110 @@ +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. |