JavaScript cryptography and OtR 10.3.12

From QED

Jump to: navigation, search

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.

3. The essay repeatedly emphasizes that secure delivery of Javascript to web browsers is a problem. Describe some concrete ways/attacks in which this security can be compromised.

Diego brought up the example of cross-site scripting, or XSS. The idea of this is that an attacker can send an input to a server which actually causes the attacker's code to be executed. This is possible, for example, when a server takes user input and displays it on the web page. Then if the server does not sanitize input, the attacker can insert his or her own JavaScript in between <script> tags. Arvind agreed that this is a common vulnerability, and said that there is even more of a problem if a website uses JavaScript cryptography. In this case, the attacker's code could alter this cryptography code because there is no notion of separation of privileges in the code execution.

Madhu's example of an attack on this security made use of the fact that just as an attacker could sniff passwords if no cryptography were used at all, the attacker could now observe the JavaScript cryptography code if there were a weakness. Furthermore, an attacker might be able to actually intercept the request and alter the JavaScript. If the JavaScript crypto code were to be sent over SSL, that would only help if everything on the page were sent through SSL, otherwise an attacker could exploit the weakest link. Arvind asked what made making everything in SSL so hard. Diego answered by saying that first of all, as Ptacek wrote, if everything is in SSL, then there would be no point in JavaScript cryptography. But the part that actually makes it difficult is that every element on the page, such as each image or video, would need to be sent in its own SSL message. Ajay built up on this answer and said that because of all these connections, the whole interaction would be much slower. In response to Arvind's asking why it was slower, Ajay noted that encrypted data is much harder to cache effectively. Arvind agreed, and pointed out that many people forget about the huge amount of work that takes place in between the two endpoints of a connection to make data transfer faster. This was part of the reason why Google took so long to offer SSL as a default option in many of its services.

Arvind shifted the discussion by asking how someone sitting in a shop on the same network as you could compromise JavaScript being sent to you. Diego's idea was to send bogus traffic, pretending to be the server. Arvind pointed out that an attacker has to do something active rather than watching your connection passively. Chris brought up one of his points from his wiki post, and said that if an attacker had a choice, he or she might prefer to go after the easier target. Therefore, JavaScript crypography, even though insecure, may be enough to convince an attacker to pick someone without any security at all over you. Arvind highlighted a major difference between active and passive attacks: an active attack leaves some sort of trace which can be noticed later, while a passive attack could potentially never be uncovered at all. This is one reason why all-or-nothing crypto may only matter when faced against very highly capable attackers, such as the government.

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.

4a. Imagine an encrypted chat application like cryptocat. It previously used to be purely web-based, and was only recently converted to a plugin-based app due to a chorus of criticism similar to Ptacek’s. Assume that the web version can be built to deliver Javascript securely (by delivering the entire page over SSL, etc.) Is there still a problem with this security model?

Arvind clarified the question. He said that Chris's response about not being able to verify user names and chat room names being guessable was fine, but wanted to go further an actually study the differences in the threat models of sending JavaScript crypto code versus using a browser plugin. Diego's earlier insight was germane here: if we have fully capable SSL, then there is no need to use JavaScript crypto. He also said that the threat model for JavaScript cryptography alone has to do with the integrity of the code (i.e., is this the code that the server sent to you), while the threat model for sending crypto code over SSL could have more to do with trusting the server to give you good code in the first place. Arvind reiterated that the only way to deliver the JavaScript securely is with SSL, but we are still trusting the server's SSL encryption. Rafi suggested that this could mean that the user might as well send the plaintext to the server directly over the SSL. Arvind assented to this, but pointed out further details. If the server changes the JavaScript code it sends, it is very hard for a user to observe this without constantly watching out. However, with a plugin, the user only needs to trust the code once, then does not necessarily need to download and trust all the future updates. Thus, an advantage of using a plugin is that it does not have to be updated, and the user need not worry about it changing.

Arvind summarized the main thrust of Ptacek's argument by writing two points on the board:

1. Delivery of JavaScript cryptography code is broken.
2. The threat model does not eliminate that fact.

4b. Can you think of any other applications where it actually makes sense to use Javascript cryptography, again assuming that it can be delivered securely?

Diego's example was of developing crypto for mobile applications. Technologies exist that take HTML5 and JavaScript and convert them to run natively on various platforms. Sometimes this is the only feasible approach when one is trying to write code for a large number of development environments. Part of the reason this might be secure is because the user, or an outside attacker, no longer has any way to influence the JavaScript code. Arvind said that the article focused mainly on the use of JavaScript being used on the browser, but Diego's example shows that JavaScript can be useful in cases where it is not tied to a browser.

Arvind pointed to Ajay's example of using JavaScript crypto not for security, but for something like computing hashsums. Nora wanted more details about this, so Arvind explained that hashsums are used to verify the correctness of data that has been downloaded from a server. It is some type of computation performed on the bits in the file that should indicate if something in the file was corrupted. Diego pointed out that attackers can alter the JavaScript code that computes the hash to send a fake file, but Arvind replied that this use case covers accidental error, and is not for security.

5. What can Javascript do to generate random numbers more securely? Are there famous examples of security failures caused by insufficient randomness?

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 Diffie-Hellman key exchange, we notify the user that we are about to start secure communication and display the fingerprint of the other party’s public key. A more cautious user will verify the fingerprint 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.

11. Do you think that Javascript crypto would still have security vulnerabilities even if someone were to successfully add and implement the features that the Matasano Security essay suggests Javascript crypto is lacking (secure erase, functions with known timing characteristics, secure keystore, CSPRNG)? Why or why not? Marcela

To address this final question, Arvind pointed to the earlier summary of Ptacek's argument. Specifically, even if these issues were resolved, the existing threat model is not eliminated. Users still have to trust the company sending the JavaScript code.

Personal tools