



Study with the several resources on Docsity
Earn points by helping other students or get them with a premium plan
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
The answer key for information assurance homework 3, covering topics such as aes and des encryption, diffie-hellman key exchange algorithm, and gnu privacy guard. Students are expected to decrypt files, encrypt files using different key lengths, understand the impact of finding an efficient solution for discrete logarithms on diffie-hellman algorithm, and perform tasks related to gpg.
Typology: Assignments
1 / 5
This page cannot be seen from the preview
Don't miss anything!




Due September 19, 2007 on compass. Late homeworks will only be accepted until September 21, 2007 to ensure that answer keys can be posted before the exam.
We would expect to see that the performance slows as the key length increases. AES runs more rounds to incorporate more keying material. For the size of the files you are testing, the performance difference is negligible. But it is good to see the difference and it is important to know the rate difference when designing a system. The network bandwidth requirements may dictate an upper bound on the key length. d. Repeat part c using DES with its 56 bit key. On Linux the function ecb_crypt and des_setparity should do the trick. On Windows the base provider for the Crypto API should provide a DES encryption operation. Add a row to your table from part c showing the average time for the DES encryption operation. I would expect to see the DES performance be worse than the AES performance. Certainly this is the case for triple DES which would give you similar crypto security to the AES-128. Your mileage may vary though based on the particular DES implementation you system has.
n = 2^ 1 + klg2(2^32-1) < 32k 1/(32 – lg2(2^32-1) < k 2,977,044,474 < k (plus or minus a few, there was some variance between the calculators we used) Another way of thinking about this is in terms of expected value rather than probability. Expected number of trials = 1P(find match in first trial) + 2P(find match in second trial) + 3P(find match in third trial) +.... = 11/n + 2 1/n(n-1)/n + ... = sum(i=1 to infinity) i * ((n-1)/n)^(i-1) * 1/n If you take the limit you get a value that is within a factor of two of the probability method. Either way is fine for this homework. The key thing to note that the value in part a is much bigger than the value in part b. b. Alice is willing to make changes to the original document too (by adding spaces or other changes that don't change the meaning of the document). How many document comparisons will Alice need to make on average to find an original document variant and a variant of the new document with the same crypto hash. In this case, we also consider the probability that in k people we don't have a matching birthday. This is equivalent to thinking about a bag of n black marbles. Each person picking replaces with a white marble. P(no one picks a white marble in k people) = Prod(i = 1 to k) (n-i)/n = n!/((n-k)! * n^k) We need to solve for k so this probability is less than ½. However, there is no nice closed form for this. The wikipedia page presents some bounds. From the wikipedia article we get the bound (letters translated to match what we have been using in this writeup). k(p, n) = sqrt(2n * ln(1/(1-p))) k(.5, 2^32) = sqrt(2 * 2^32 * ln(2)) = 77, This is close to the 2^(m/2) discussed in class. 2^16 = 65,536. The wikipedia article on the birthday attack (http://en.wikipedia.org/wiki/Birthday_attack) also gives a more specific bound of 1.17 * 2^(m/2). 1.17 * 2^16 = 76,677. Then for this to work out for a match between two groups of message variants, you would need to create one group of that size for the Alice desired message and another group that size for the Bob desired message. So this adds another factor of two for the number of message hashes you would need to compute.
I assume you would make two hash maps one for each message type. As you compute a message variant, you put it in the hash map keyed by the crypto hash value. Then you look in the other hash map to see if it already has an entry for your crypto hash value. In either case, these bounds are much, much less than the result for part a. In the case of the 32 bit hash, they are very attackable.