4.4 KiB
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?
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:
-
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.I think it would depend on the level of encryption that you use to disguise your message. If a message was encrypted using a Caesar Cipher or something that is easy/predictable to crack, then yes, the individuals running the server could read the messages that are sent. Additionally, if you (as a user) used a more complex form of encryption then it would be more difficult for the people running the server to read the messages. However, if the server user did not have access to a piece of the keys (either public or private) then they may not have access to decode your messages. But if the server user was to replace the public key with something that they have control over, then they could decipher messages.
-
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.
Yes, because the user is the one who decides the signature that is being used. Other than its creation, there is no verification process for who is behind the signature. So, in theory someone would have a user key and signature and name and could simply login as the user and read the messages. It is missing some form of two factor authentication or verification.
-
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?
I don’t think there is much keeping people from impersonating you if you send them your signature. The message tracking includes the text, a sender, and a recipient. If you sent your signature to someone then the sender and recipient would be reporting accurate information about what the message is coming from but not really ensuring that the person sending it is accurate. "messages": [ { "ciphertext": "MXGwPnazj0JK+tE6Qmi62FXQVTMAmlePPe1mtGE6Qb...", "recipient": "funkychicken5", "sender": "subrosa_admin"
-
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?
No. Like I had talked about before, there is no recovery or additional authentication tied to the server. It is just between the server and the user. There is no information that the server has to give you as a user the information if you do not have the private key. It simply could not be accessed any other way.
- 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?
It could be an issue. Being able to track who is corresponding with whom can inherently compromise the integrity of the “secure” message. How secure can it be if people can see who the messages are to and from? That being said, sure, there must be ways to secure that information through more complex encryption. However, at that point it might make more sense to change the structure of the receipts sent to the user of the server. The sender and recipient information could be redacted and it is the responsibility of the sender to identify themselves. Theoretically, if they know who they are sending the information to, then the recipient information is superfluous. Then the only thing left to do is to identify oneself. Which, if you are going through all the trouble of using the server to send encrypted messages, then it should be inherently not that big of a deal.
There is probably another way to disguise this information rather than fully redact it as well. But that just seems like more complication than would be needed for this particular server.