# Sub Rosa Analysis 

## Checkpoint 1

Decrypt the message you received from the Sub Rosa administrator. 
Include the code you used to decrypt it. What does the message say?

I attempted to retrieve and decrypt the message from the Sub Rosa administrator using my generated private key. However, the Sub Rosa server did not respond to requests and returned a connection timeout error, so I was unable to obtain the encrypted message.

The code I would use to decrypt the message is shown below:

```python
from encryption import PrivateKey

private = PrivateKey.load("subrosa_private_key.pem")

ciphertext = "<ciphertext from server>"

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.