Reference no: EM13870380

Week 3 Assignment

Diffie-Hellman key exchange protocol (Individual Hand-In)

The security of many cryptographic techniques depends on a challenging mathematical concept-the discrete log problem (Anderson, 2008, Section 5.7.2). For this Assignment, you will review the Diffie-Hellman key exchange protocol and describe how to address common attacks on that protocol. You will also perform some basic calculations.
To complete this Assignment:

For this Assignment, submit a single document with your answers to the following: Review the Diffie-Hellman key exchange protocol discussed in the lecture and list some of the attacks on Diffie-Hellman. Explain your solutions for avoiding such attacks. Calculate the value of the symmetric key and the values of R1 and R2 in the Diffie-Helman Protocol for the set of given values.

The legality and exploitation of international MiTM attacks (Individual Paper)

Recently, there is strong evidence that the US National Security Agency (NSA) has launched many MiTM attacks either by exploiting some known flaws in the techniques used to protect our data or by ‘planting' some back doors in the algorithms used to encrypt the data. It is not only the US; in some cases, such as the Flame virus, other countries engage in similar practices. In this Assignment, you will explore the leaks and news media accusing the US and other countries of launching MiTM attacks.
To complete this Assignment:
For this Assignment, you will write a paper on this topic. Choose one of the MiTM cases discussed in this Week's lecture notes (the section ‘Sophisticated Attacks') and study it. Based on your country's laws, evaluate the legality of these actions in your own country. Express your opinion regarding your own interests to protect your assets against such exploitation.
For all Assignments:
Your document should have 750-1,000 words (not including the list of works cited), but it is the quality of the answer that matters, not the number of words. Cite and reference all sources use the Harvard Liverpool Referencing System. 

Week 3 Group Project
Public- and private-key pair (Group Project)

This is a 2-Week project that contains two main tasks. You need to manage your time well to be able to finish both tasks on time. The submission of the final document is due by Wednesday of Week 4, but your contribution in the Group Project forum will be marked throughout the 2-Week period, so your regular participation is important. As you progress in your work, use the ‘Sample Template for document submission' to track your deliverables.

Task 1 (to be completed by the end of Week 3):

Install an OpenPGP-compliant email software package on your computer, like any of the ones found at the OpenPGP Alliance (n.d.) Web site or any product in compliance with RFC 4880 (Network Working Group, 2007). GnuPG (The GnuPG Project, 2014) in particular is freely available and widely used. You are welcome to use PGP itself, but note that as of 2010, PGP is owned by Symantec and is only available as a commercial product (Symantec, 2014). You may wish to try the Enigmail add-ons for Thunderbird (Brunschwig, 2013). For the purposes of this Group Project, any of these OpenPGP-compliant products will be referred to as ‘PGP'.

For the project, generate a public- and private-key pair for yourself. If you have any problem in installing it properly, please discuss this in the Group Project forum with your team members. Publish your public key in your project exchange folder. Optionally, export your public keys to one or more of the PGP key servers. If you publish your keys there, your email address will also be public there. If you feel you do not want to publish your email address there, you can choose not to do so. You can also generate a key for some email address that you do not care about and publish the corresponding key for that email address to the PGP key servers.
Post some encrypted messages for each of your project colleagues in the Group Project forum. You can also publish the ciphertext in your Group Project forum. Be sure to post these encrypted messages in the Group Project forum, not private email boxes, since the Instructor cannot read your private email box and, hence, cannot give you a grade. If you get an encrypted message for yourself, decrypt it and ask the sender to verify that the message is correct.

By the end of Week 3, you should have finished the installation of PGP, published your public key, published the encrypted messages to your colleagues and decrypted the messages for you (posting the messages in the folder for verification). All work should be done in the Group Project forum.

Task 2 (to be completed by the end of Week 4):

In this task, you will concentrate on the digital signatures and certificate chain. Try posting messages signed with your private key and ask your colleagues to verify whether your signature on the message is valid. The message should not be encrypted; that is, the format is a clear message, with a signature on the message.
Your task is detailed in the ‘Sample Template for document submission' at the end of this Assignment. However, generally speaking your task is to compare what happens in the following situations:

1. Get signature by A and check whether A's signature on one message is valid.
2. Let B sign A's key, and you sign B's key. Then check whether A's signature on one message is valid.
As you know, various PGP tools may implement the same service differently. The technical details in the following example were written for PGP 7.x; however, the basic theory is the same for all versions of PGP. If you are using GnuPG or another OpenPGP installation, the interface may look different, but the basic process should be the same. Stepping through the following example in your own software may give you a deeper understanding of how the digital signature process works.
PGP 7.x Example

You have talked about CA (certificate authority) in several places. The PGP trust model is different from the CA trust model. When you open the PGPKeytools, you will find that for several public keys you have imported, the small ball under the ‘validity' item is not highlighted (green). This means that that these public keys are not ‘valid' according to current certificate chains. The impact is that when you verify a signature using that public key, you will get a message like ‘valid signature with an invalid key'. If the ball for your own public key is not green, you may right-click your key and choose ‘key properties'. Under the ‘Trust Model', choose ‘Implicit trust'. Then your key should be green.

Now how can you make other keys valid (green)? An obvious way is to sign that key. When you sign a key, you will see that key is highlighted. Do you have to sign all keys to make all keys valid? The answer is NO. That is, you need to find a way to make one key highlighted (green), but you have never signed that key. If you know that a key is really from Alice, then you can certainly click the small ball corresponding to that key and sign that key, and then you can export that public key, thus making Alice's key green. If you do not know Alice, but you know Bob in person and Bob knows Alice well, then if Bob signs Alice's key and sends Alice's signed key to you, you should trust Alice's key. This is the PGP trust model. Practice this kind of trust model this Week.

In particular, do the following exercise: You sign A's key and mark A's key as trusted (you can do this by right-clicking A's key and choose ‘key properties' and then move the sliding bar to trust). A signs B's key and publishes the signed key to the Group Project forum. Check whether B's key is valid in your screen (small ball is highlighted). Post your screenshot to convince others that you have not signed B's key but that it is valid. Also check a message signed by B to see whether it is valid. The following is a sample screenshot. Note that Yongge Wang has not signed Ali Ahmed's key but that it is a valid key. Also note that Yongge Wang trusts Craig's key at the 50% level.