{"id":30,"date":"2006-06-17T04:56:47","date_gmt":"2006-06-17T10:56:47","guid":{"rendered":"http:\/\/www.p14nd4.com\/blog\/projects\/encryption-client-server\/"},"modified":"2014-07-11T17:15:17","modified_gmt":"2014-07-11T22:15:17","slug":"encryption-client-server","status":"publish","type":"page","link":"http:\/\/www.p14nd4.com\/blog\/projects\/encryption-client-server\/","title":{"rendered":"Encryption Client-Server"},"content":{"rendered":"

Assigned during fall 2005 for csci4061<\/a> — Introduction to Operating Systems, this is a client and server combination that encrypts files using a simple shift cipher. Obviously the practical applications for such a client and server are virtually non-existent, but it was an easy proof of concept<\/q> of sorts, in network protocols, sockets, multithreading, and file I\/O (in C). The README<\/a> is pretty comprehensive on this project, so I won’t waste much more breath here, and just let you read it for yourself:<\/p>\n

Spoiler<\/summary>\n
NAME\r\nencrypt - encrypt files using a simple shift cipher\r\n\r\nSYNOPSIS\r\nencrypt-server num_threads port_number [-v]\r\nencrypt-client host_name port_number [-v]\r\n\r\nDESCRIPTION\r\nEncrypt is a utility based in C for the encryption and decryption of \r\nfiles using a static byte offset shift cipher.\r\n\r\nEncrypt is interactive, requiring user input in the form of encrypt\r\ncommands, each in the form of in_filename byte_offset.\r\n\r\nThe client is exited cleanly by sending an EOF (ctrl-d) character.\r\n\r\nThe encrypted files are automatically created as a separate file in\r\nthe working directory of the client, with the filename\r\nin_filename.encrypt\r\n\r\nIf a byte_offset is known, decryption of a file can be accomplished\r\nby 'encrypting' an in_filename.encrypt -byte_offset (a negative\r\nbyte_offset), which would save the decrypted file in\r\nin_filename.encrypt.encrypt\r\n\r\nAll valid commands issued to the program are logged at the server,\r\nindicating the thread that handled the request, the number of the\r\nrequest being handled by the given thread, the socket number from which\r\nthe request was sent, and either the integer_add (byte shift), or a\r\ndescription of an error encountered.\r\n\r\nOPTIONS\r\nThere are two required options for encrypt-server: the number of\r\nworker threads to spawn, and the port number on which to listen for\r\nclient requests. Both of these are integers, though their valid ranges\r\nvary. The valid range for num_threads is [1,100] inclusive, and the \r\nvalid range for port_number is [1,65535] inclusive (though ports below\r\n1024 generally require root access to listen). Optionally, a third\r\nswitch can be passed to encrypt-server, which is a -v flag, resulting\r\nin verbose debugging output to the terminal.\r\n\r\n\r\nThere are also two required options for encrypt-client, which are\r\nhost_name and port_number. The hostname option can contain either a \r\nhostname or fully qualified domain name (FQDN) resolvable by the\r\nclient system, or a standard dotted IP address. As with the server, the\r\nvalid range for ports is [1,65535] (root access is not required to\r\nconnect to a port number below 1024). The encryption client can also\r\naccept an optional third flag, -v, to produce verbose debugging output\r\nto the terminal.\r\n\r\nNOTES\r\nA makefile is provided for convenience. To compile encrypt, simply\r\nrun `make' from the directory containing encrypt-server.c and\r\nencrypt-client.c.\r\n\r\nencrypt_log is overwritten every time encrypt is called, as are any\r\nin_filename.encrypt files that may already exist.\r\n\r\nencrypt-client can be cleanly terminated by reaching an EoF or ctrl-d\r\non its standard input. encrypt-server must be terminated with ctrl-c.\r\n\r\nBUGS\r\nThis program will not compile on Sun\/Solaris machines due to the\r\nabsence of the thread-safe strerror_r function. Additionally, the\r\nfunction char *strerror_r(int errnum, char *buf, size_t n) does\r\nnot function as documented, in that char *buf is not actually\r\nused (but rather it returns the char *buf). This is contrary to the\r\nfunction definition of int strerror_r() defined in the manpages.\r\n\r\nThere is a current limitation of 1024 unhandled requests in the\r\ncommand buffer. This is due to the request buffer implementation as\r\na statically sized array rather than a linked list, as a conscious\r\ndecision due to the scope of the program's use. It seems unlikely that\r\nthe program will be called upon to encrypt over 1024 files at all, and\r\nfurthermore, will have time between requests for threads to process\r\nthese files, thus freeing up space in the request buffer (which will\r\nwrap around to allow more than 1024 requests total, just not\r\nsimultaneous requests).\r\n\r\nIn addition to the problem with strerror_r on Sun\/Solaris machines,\r\nthis program is not compatible to run a client and a server on machines\r\nof different byte-ordering. This results in a workaround to enable\r\nnegative encryptionKeys, which were non-functional with the ntohs and\r\nhtons commands, as they return unsigned integers.\r\n\r\nWhen compiled as currently coded on a linux machine under gcc 3.3.2,\r\nthere are no known bugs. Tests have been performed to check for\r\nincorrectly formed commands, and present versus non-present files.\r\n\r\nHOMEPAGE\r\nhttp:\/\/www-users.itlabs.umn.edu\/classes\/Fall-2005\/csci4061\/assignments\/asgn5\/\r\n\r\nAUTHOR\r\nDavid R. Hedges  is the author of both this\r\ndocumentation and the encrypt program.\r\n\r\n2005-12-07T23:22-0600-drh<\/hedg0029><\/return><\/pre>\n
<\/p><\/details>\n