1. Each of the encryption tools PGP, OtR and cryptocat have a slow “key generation” process. Why is key generation slow?
There were two main possibilities brought up online. Rafi pointed out that computers need to find sources of true randomness from inputs such as environmental noise, while Chris suggested the idea that perhaps computation is the bottleneck in the generation process. An informal poll of the class showed that most people felt that finding true randomness would actually be the time-consuming part.
Arvind noted that of the ideas that Chris brought up, primality testing and modular exponentiation are the two that actually have high complexity. Both problems can be approached with knowledge of Fermat's Little Theorem. In practice, most of the primality tests done in crypto protocols are probabilistic, and there are very fast methods for probabilistic tests that make the probability of incorrectness very low. For example, to exponentiate quickly, one approach is two repeatedly go up by powers of two, which takes logarithmic time.
2. Ptacek views security as all-or-nothing — as long as there is any viable attack, the system is completely worthless, perhaps even worse than useless. Is this a good principle? Argue for or against.
Nora first argued against the all-or-nothing view. She said that as long as users know the limits of the security protocol, they should be able to choose and limit the type and amount of information they share using this system. Furthermore, if users exercise appropriate caution with systems like these, then perhaps hackers will lose some of the incentive to break the system if they know that users are more careful with extremely sensitive data.
Will countered by pointing out that practically speaking, users would not bother to look into what the limits of a security system are. Because users can't be expected to be careful, security should be viewed as all-or-nothing. However, Will also thought that a good system requires both a good implementation as well as the ability to be understood by the user. Arvind acknowledged the opposing views, and informed us that even among cryptographers and security experts, the answer to this question is still up for debate. Since there is an entire market for zero-day vulnerabilities in almost any security system that sees prominent use, he questioned if it's even a tangible goal to design a completely secure system. Especially with the possibility that the NSA is keeping much of its knowledge secret, it becomes much harder for non-governmental security systems to be perfect.
2. (going back to the second part). Do you know of any examples of powerful entities attempting to or successfully compromising the web security of regular users?
Ajay cited the story last year of Iranian hackers (suspected to be from the government) issuing fake DigiNotar certificates. Since DigiNotar was a certificate authority, these fake certificates were used to compromise user connections to Yahoo, Google, Facebook, etc, but also to intelligence agencies like the CIA, MI6, and Mossad. Arvind noted that this was an example of a successful attack, and that even though it only affected Iranian users, the attackers could have issued the certificates beyond geographical borders. He also brought up an example from Tunisia, where the government injected code into Facebook connections and were able to fully view accounts. The attack was not too sophisticated, but is more evidence for the fact that expecting an attack from the government is not such a strange idea to include in threat models today.
Arvind summarized the main thrust of Ptacek's argument by writing two points on the board:
- 2. The threat model does not eliminate that fact.
Arvind thought that all the examples posted to the wiki were good. He pointed to the “Ron was wrong, Whit is right” paper as a good read. Ajay forgot the details, but recalled an anecdote wherein one programmer intentionally left a value uninitialized, but did not comment it. Later, the code was changed to initialize the value to zero, but it turned out that this was used later to seed a pseudorandom number generator.
6. Think about email vs. instant messaging. In which application is authentication more important? Is there another form of communication in which it is even less important?
Arvind said that although the question was interpreted a bit differently than he intended, the answers revealed good discussion. Chris thought about which medium contains more important information. He said that he has the general feeling that emails are more likely to contain important information, while IM is mostly trivial conversation. Because of this, email authentication might be more important. Nora agrees about the relative importance of the content, but also considered that in IM, people usually have spontaneous conversation without giving much thought of privacy or bothering to verify their contacts. Because of this conversational nature, authentication in IM might be more important. Borislav also thought that IM might be more important to authenticate, since in IM one is respected to respond to immediately. Thus, it is better to be certain about the other party's identity, while in email one has much more time to verify that the message is authentic.
Arvind revealed that his intention with the question was to ask how easy it is to verify that a message is indeed from a trusted party. In email, it would appear to be very hard, since the other party is not expected to write back. However, in IM, because of the immediate responses, it is easier to ask security questions to verify someone's identity. Borislav noted that he actually was considering this point, but interestingly, he reached the opposite conclusion: email gives more time to verify an identity so it is easier to do so in that medium.
Arvind then addressed the last part of the question. In voice or personal communication, authentication is probably less important, since one can more easily verify someone's voice or personal knowledge. Margo said that in family contexts, especially in her personal experience, it is extremely common to confuse identities over the phone because of different people sounding similar. Arvind said that in business, it would be harder to imitate voice and knowledge necessary to impersonate someone. He wanted to check on any impersonation attempts that have worked in a practical sense.
7. OtR claims to “append an identifier” to the first message to determine if the other party is using OtR. How come you don’t see this identifier when you chat?
Arvind saw that no one quite got to the answer. It seems that OTR encodes this identifier message as a combination of tabs, spaces, and other whitespace. This way, the other party won't notice and be scared off by a strange OTR message when they don't have OTR set up. Abu said he actually noticed a lot of extra whitespace when he first received an OTR message before he set it up. Ajay brought up an example where he saw the base64 encoded messages being sent through his Google Talk window, but thought this was contrived. Arvind said that on the other hand, this use case actually occurs very often. For example, when one has two programs open, this would happen, which is an answer to the 8th question on the wiki. Ideally, Google Talk only goes to the device from which the user responded, but Ajay noticed that he got the garbage messages on all of his devices. Margo explained that the messages always go to the Google Talk window in Gmail, but there is supposed to be some protocol that makes it only go to a phone if you had checked the message there. Arvind thought it was interesting to see how OTR's hack of encrypting data interacted with Google's hack to send only to specific devices.
8. What happens if a user has multiple chat programs open, some of which do support OtR and some don’t?
This was mostly answered, so we moved on.
9. This is one of the key paragraphs of the OtR paper. Every sentence makes a nontrivial point about security. Explain each one. “During the initial Diﬃe-Hellman key exchange, we notify the user that we are about to start secure communication and display the ﬁngerprint of the other party’s public key. A more cautious user will verify the ﬁngerprint out-of-band; for others, a man-in-the-middle attack is possible at this point. We record the public key value and make sure the same key is used in future sessions. Thus, a successful impostor must be able to carry out an active attack during the first and every subsequent session; failure to do so will result in detection. This model of handling public keys is analogous to that used in SSH, and has proven an effective way to distribute public keys in the absence of a widely-deployed public key infrastructure. Of course, if a public key can be securely obtained by other means, it can be imported into the key store and used in the future.”
Borislav's explanation is that the key exchange requires a public key, but doesn't have any public key infrastructure. This means that each public key has a fingerprint, which has to be verified by other means. Arvind specified that these other means could be something like calling up the other party, or posting the information on a personal website. Borislav observed that the website could be compromised, but it would be difficult to attack both the website and the keys themselves. Arvind related this back to the all-or-nothing question. Although it has a weakness, in practice it is another thing that an attacker must compromise, and Google may also cache the web page, adding another layer of protection.
Borislav returned back to the explanation. In practice, most users probably don't go through the trouble of verifying this key, and they would just assume it's fine. But this means that if someone compromises this step, then all future communication is compromised as well. However, the nice feature is that if any other communication is compromised, it won't allow an attacker to immediately access all other communications. The verification of public keys is similar to the approach of SSH.
Arvind said there is a mechanism to make sure that the party you're talking to is the same as the party you talked to before, but asked if there could be anything wrong with the usability of this feature. Margo pointed out that getting a new computer would mean that in all likelihood, the old public key is incorrect. Arvind also added that reinstalling the client or just wiping the home directory could cause this. Interestingly, when the program displays a message saying that their buddy's public key is no longer valid, sometimes the message is counter-productive. One common user reaction is for users to become desensitized to this message, meaning they won't heed it when it really matters. Another problem is when users overreact to the message, and do something radical, like deleting the entire fingerprint store on their computer. This shows that people can often find a way to make a system insecure.
Borislav asked what the correct way to revoke a key is in OTR. Arvind said that this model just relies on the user to tell other people that the key is no longer valid. However, in public key infrastructure approaches, there must be an explicit revocation mechanism built into the system.
Arvind asked if it was clear why we need some random values as long as 2048 bits, while others are useful just as 128 bits. Chris said that it depends what algorithm is using the random keys. For example, RSA relies on factoring being a difficult computational task, so it needs very large numbers so factors can't be found easily. On the other hand, breaking a pseudorandom generator would require one to enumerate all 2^128 possibilities for a key, which is more than enough. Arvind clarified by saying that RSA uses the large, 2048 bit primes since factoring methods don't need to check every possibility. As such, a much larger search space is needed. On the other hand, a symmetric key for something like a stream cipher can be smaller since in order to break the cipher, all values of the key must be checked.
10. One notion that I found interesting in the OtR paper was the idea that repudiability is desired in a truly private conversation. This means that neither of the participants ought to be able to prove that the other participants truly made a specific statement. Do you agree that repudiability is a necessary characteristic of a private conversation? How do you think in-person conversations compare with online conversations in this regard? Marcela
Arvind wondered what people thought about Marcela's question. Borislav agreed that repudiability is definitely desired. Margo thought of any laws regarding the recording of private conversations. For example, it might be the case that a conversation can only be recorded by someone partaking in it, or if a majority of the participants agree to it. Arvind wanted to check up on what these laws are more specifically. Margo said that perhaps people should be responsible for their IMs, just as they are for letters or emails in some cases, so maybe repudiability is not a good feature. Borislav disagreed, since electronic communication is different from physical.
Margo clarified by saying that when trying to repudiate what one says online, perhaps it would be better to argue “That's not what I meant,” rather than relying on the other person to never reveal what was said. Diego pointed out that in a conversation, some type of initial agreement must take place where both parties agree to have a private conversation, or not. Margo said that still, in the physical world, someone could just record a private conversation even if they agreed to this.
Arvind moved to a higher level discussion. He said that privacy of two people is a very different matter than privacy of an activist from an oppressive government. For example, Mark Zuckerburg received a lot of bad press when a conversation from early in his career surfaced, in which he referred to users as “dumb fucks” for giving up their data. Even if there was a crypto scheme that allowed him to repudiate this message, it probably would not have mattered to the media, and they still would report on this. However, repudiation can be enough legally in a court.
Chris also discussed the differences between written and spoken communication. In speech, it is hard to prove if something was said, apart from physically recording it. However, often a written copy is enough to give some weight to the authenticity of a conversation. For example, Chris saw a Windows 8 announcement that had a lot of protections preventing copy and paste, screenshots, and other things. But nothing was there to stop him from taking a picture of it with his phone. Arvind pointed to the movie and music industries for more examples of similar things. In one case, the movie industry had altered the frame rate of a film so that people could not notice anything strange, but was chosen such that it corresponded to the sampling rate of video recorders, making the video useless.