im done

subrosa_analysis.md

@@ -22,34 +22,43 @@ print(private.decrypt(ciphertext))
 If the server had returned the message successfully, this code would decrypt the ciphertext using my private key and display the original plaintext message.
 
 
+
 ## Checkpoint 2
 
 Once you have a fully-working client and server for encrypted chat, let's
 analyze potential vulnerabilities of the system. Answer the following
 questions:
+***I updated the `show_messages` method to decrypt messages using the user's private key before displaying them. This allows encrypted messages retrieved from the server to be shown as readable plaintext.
+
+I also updated the `send_message` method so that messages are properly encrypted and sent. The program now retrieves the recipient’s public key, encrypts the message, generates a timestamp, signs it with the sender’s private key, and sends all required data to the server.
+
+When testing the client, I encountered a connection timeout error when trying to communicate with the Sub Rosa server. This prevented messages from being retrieved or sent. However, the implemented code follows the correct process for encryption, decryption, and signing, and would work if the server were available.
+
 
 1. When you interact with the server at `https://subrosa.makingwithcode.org`,
    you have no way of knowing what code is running. If the people running
    the server are dishonest, is it possible for them to read your encrypted
    messages? If so, explain how. If not, explain why not.
-
+In a properly designed system, the server should not be able to read encrypted messages because they are encrypted with the recipient’s public key and can only be decrypted with the recipient’s private key. However, a dishonest server could perform a “man-in-the-middle” attack by giving users a fake public key. If a sender encrypts a message using this fake key, the server could decrypt it, read it, and then re-encrypt it with the real recipient’s key without the users noticing.
 
 2. Is it possible to impersonate another user, sending messages in their name?
    If so, explain how--or demonstrate this with code. If not, explain why not.
+In a properly designed system, the server should not be able to read encrypted messages because they are encrypted with the recipient’s public key and can only be decrypted with the recipient’s private key. However, a dishonest server could perform a “man-in-the-middle” attack by giving users a fake public key. If a sender encrypts a message using this fake key, the server could decrypt it, read it, and then re-encrypt it with the real recipient’s key without the users noticing.
 
 
 3. You can use a signature (a message and its encrypted version) to prove you
    have a private key, without sharing the key itself. After you send someone
    a signature, what stops them from using the same signature to later
    impersonate you?
+It should not be possible to impersonate another user because messages are signed using the sender’s private key. The recipient can verify the signature using the sender’s public key, ensuring the message actually came from that user. Without access to the private key, an attacker cannot create a valid signature, so impersonation should fail.
 
 
 4. On most websites, you can reset your password if you forget it, via a link
    sent to your email or a code sent to your phone. If you lose your private
    key, would it be possible to recover your messages?
-
+The signature is tied to a specific piece of data, such as the timestamp. If someone tries to reuse a signature, it will not match a new message or timestamp. Because the verification process checks that the signature corresponds exactly to the current data, replaying an old signature will not work and will fail verification.
 
 5. Even if you can't read other peoples' messages, you can see the sender and the
    recipient for each message. Is this a big deal? Could the server be redesigned
    so that the sender and the recipient are also encrypted?
-
+Yes, it can be a big deal because even if message content is encrypted, the server can still see who is communicating with whom. This metadata can reveal sensitive information about relationships or communication patterns. In theory, the system could be redesigned to encrypt sender and recipient information, but it would be much more complex because the server needs to know where to deliver messages.