Distributed systems i Wed 19.10.2005 Exercise 8 Note the changed time: both groups together at Wed 08-10 at T/B180. 2nd intermediate exam at Fri 21st October 08.00 -- 10.00 at K1 (Chemistry building (Futura) opposite to Math building (Metria)). In the following exercises we estimate the performance of a situation where a single server and multiple clients are connected by the Internet. In all cases, compute the performance 1) with SSL handshake, 2) without SSL handshake. In addition to the throughput computation, state also the possible bottleneck of the transaction. A SSL handshake includes 6 messages of total length 1000 bytes. The key generation and checking of the SSL handshake takes 500 million operations for both participants (client and server). After SSL handshake, the communication proceeds using symmetric encryption (which also takes time). If there is not SSL handshake (e.g., continuing an earlier session), the participants directly start with encrypted request and reply. The following table presents these and other values needed to calculate the performances. Those values that are in italics have several values in the following exercises. B is byte, b is bit. CPU speed (Moper/s) 3000 Average reply length (B) 20000 Server number of CPUs 1 Session decrypting speed (oper/B) 100 Client network bandwidth (kb/s) 28 Network delay (ms) 50 Server network bandwidth (Mb/s) 500 SSL handshake total length (B) 1000 Average request length (B) 200 # of SSL handshake messages 6 Session encryption speed (oper/B) 200 SSL handshake oper/participant 5¥108 36) How long (real, wall-clock time) it takes for a client to make and complete a request (from start to finishing the decrypting of the reply) if the client network connection speed is a) 28 kbit/s (modem), b) 512 kbit/s (ADSL). 1) with SSL handshake, 2) without SSL handshake. You need to compute also the time used by the server. 37) How many new requests/second the server can handle a) with one processor, b) with 10 processors, c) with 1000 processors. 1) with SSL handshake, 2) without SSL handshake. The "new" stands for the fact that even if each request takes more than 1 second, it does not require 1 second of server resources, and thus the server can time-share its resources for several concurrent clients. In other words, compute the throughput. 38) Analyze the security of the protocol for X4. How it protects against different attack types and security concerns? Explain why each field is needed in the messages. How it could be improved to handle the missing features? We'll continue the X3 UDP p2p chat by using encrypted messages and restricted access. For simplicity we use shared secret key approach where anyone having the key can access, others are rejected. All messages will be encrypted using Blowfish encryption and the shared key. The messages are delivered as binary data with full blocks (of size 8B). After decrypting (and before encryption), all characters of the valid messages must be printable ascii characters (isprint() in C, isWhitespace || isLetterOrDigit in Java). Join message is now "J username 123.45.67.89:12345 98.76.54.32:54321\r\n" where 123.45.67.89:12345 is the host:port of the new joining node and 98.76.54.32:54321 is the node it tries to connect to. Join ack message is "OK username\r\n", where username is the username of the new joined node. New message is sent by "M 123 username message text\r\n", where 123 is a sequence number for messages sent by this person. Disconnect is "D 124 username\r\n". A message with the same sequence number sent by same person is ignored. Also joining from the same host:port cannot be accepted again. Further all messages not fulfilling the above protocol can be (silently) dropped. For debugging purposes you may print and/or reply diagnostics about the reason of ignoring. Encryption keys are prompted from user either in hexadecimal, or via a longer passphrase and taking MD5 hash of the passphrase. X4) Continue your X3 to make a secure p2p chat node using UDP messages and Blowfish encryption. You may use Java (and javax.crypto API) or C (and openssl libraries). Those who wish to reduce the programming work (at expense of some points) may leave out the detection of repeating message sequence number or join addresses (which makes the protocol vulnerable to some attacks). As before, it is better to submit something than nothing, especially if the self evaluation states the missing features. Send your answer to using cs to user sjuva with a subject DS_X4_username case-sensitive, with underscores, and the answer (with self-evaluation) as the body of the message (no attachments). At simplest using program mail at cs: /usr/ucb/mail -s DS_X4_username sjuva < answer Where username is your cs username and answer is the single source code file containing your answer. Deadline for submission is Mon 24.10. at 08:00. You may use either C or Java to write the application. If you use Java, write all functionality in one file and name the public class with your username. Solution will be compiled with javac if it contains string "import java", with gcc otherwise. Take examples from web-page.