Lösungsvorschlag Information Security FS14

Aus VISki
Wechseln zu: Navigation, Suche


  • a) False, Alice should use Bob's public key.
  • b) False, MACs only provide authenticity and integrity
  • c) False, public key crypto is way more inefficient
  • d) True
  • e) False, anyone can compute hash functions
  • f) True, a pseudorandom function is a pseudorandom permutation without the requirement of being an actual permutation
  • g) True
  • h) False, it relies on the DDH assumption
  • i) True
  • j) False, the encryption function is no injection (ciphertext 7)


The adversary computes by:



We build a distinguisher D who is given access to an oracle, which answers to our queries with either for a randomly chosen or (where ) is a truly random function. We now query the oracle for any message and get back . We outputs 1 for "pseudo-random" if the last bit of is 1. Our distinguisher D works in constant time and therefore is a legitimate polynomial time attacker.

The probability of success is

This is non-negligible. Therefore is no PRF.


We recall the security definition of a PRF. A PRF is called secure if there is no polynomial time probabilistic attacker that can win the following game: The attacker is given access to an oracle. The oracle either chooses a truly random function , or a PRF with a random key . The attacker can query the oracle for messages m and the oracle answers with either or . In the end, the attacker wins the game if he can tell correctly what function the oracle used with a probability which is non negligibly better than 0.5.

We use this definition in a reduction proof. We assume that is not a secure PRF and build an attacker for . From the definition we know that there exists a distinguisher which (when given access to an oracle) can tell if we used either or a truly random function.

We build a distinguisher which can tell apart from a truly random function . We now instantiate the distinguisher and answer oracle queries in the following way: If asks for , we ask our oracle for . When our distinguisher D made its decision, we output the same decision.

Our only adds constant overhead to , which is why it is a legitimate polynomial time distinguisher.

To see why this construction of has the same probability of winning as , we just have to recall the definition of . If the oracle of our distinguisher has chosen the function (and not the truly random function), then we simulate a perfect oracle for for function .



To encrypt block i of the message compute

The encryption of the "counter" is used as a key stream to encrypt the message using xor. The IV is optional and used to randomize the encryption and make it IND-CPA secure.


  • Parallel block encryption and decryption possible
  • Errors in one block do not propagate
  • No additional randomness needed during encryption
  • Random Read Access



The attacker must output a pair such that and


No it is not. The attacker asks for the tags to two distinct messages of equal length and obtains the tags for them. He divides the messages and tags at the same position (of course at block border) and joins the first half of with the second half of . The same procedure is performed with the tags. Now is a valid message the attacker has not queried for.

Alternative proof using two concrete messages:

We ask the oracle to encode the two messages and . The two tags (see definition of MAC) will be and (where denotes the 8-bit encoding of the integer x). Now we can trivially compute a valid tag for by setting .



  • It does not protect from replay attacks.
  • Any receiver can impersonate Alice and do a broadcast himself, since he owns the key.


We need to assign the keys for user to set such that for all pairs of users, no key set is included in the other and vice versa. Formally . A possible implementation would be that Alice shares two keys with every recipient such that two recipients have at most one key in common.


The set of all distinct pairs is . Hence, the number of possible pairs is . For 5 keys, Alice can generate different pairs for 10 recipients, thus fulfilling the requirements.

The above argument is delicate in my opinion. I would argue via a concrete number of keys per recipient. As those pairs are binomialy distributed the highest number of combinations lies in the middle. Hence I define recipients. In our example with .



  • Modulo addition is defined as which is a function . Alternative proof: Addition of integers yields another integer. Say . Now .
  • Identity is 0 which is inherited by the integers ( since )
  • Commutativity is inherited by the integers ()



Therefore is cyclic with the generator


Therefore is cyclic with the generator



Given , it is hard to compute m if we do not know .


Let be prime, in

  • public key: where
  • private key: where

Now, encryption works as follows:

Decryption works similarly:


and can only be 3 and 7.

  • is ok.
  • is ok.



i. F) Reasoning: First-preimage resistance would be sufficient as the hash must be one of the chain and hence we have a given hash. (Note that weak collision resistance implies second-preimage resistance and second-preimage resistance implies first-preimage resistance.)

ii. T) Reasoning: It's not sufficient to precompute one rainbow table for the whole database as two identical passwords with different salts result in different hashes.


Given the long-term secret of an honest communicating party it is not possible for an adversary to decrypt previously intercepted communication with other parties.


Explain stuff here.
Alle momentan zu editierenden Einträge werden hier gesammelt.


i. prevention, ii. resilience, iii. detection and recovery, iv. deterrence


a) A definition obtained from ([1]): key freshness A key is fresh (from the viewpoint of one party) if it can be guaranteed to be new, as opposed to possibly an old key being reused through actions of either an adversary or authorized party.

Yes, if we assume that the old key K_AB wasn't used for a long time as is common and K_AB' is in a message enciphered by K_AB. (really unsure...)

I think not since with the attack detailed in b) the K_AB' is then not "new data", thus I wouldn't consider it a fresh key.

Alternative solution: I think an attacker can do a simple replay attack: Steps 1-3 are performed as usual. However then the Attacker can intercept B's message in step 4 and replace it with an old one. There is nothing in this message that guarantees freshness. (I think this is the correct solution...)

Comment on alternative solution: In message 4 there is a nonce that is supposed to be fresh. If A compares that to previously used nonces, an old message would be detected.

b) No. Adversary Eve could to a replay attack and replace the original message B->A: {K'_AB, N'_B}_K_AB with the first message and thus make A agree on the key A. (I think this is called an "reflection attack", because the message goes back to its originator...)

No, I think it's a typeflow attack (reuse the format of the message to alter the communication). A reflection attack would use one party has a "service" (to decrypt, encode etc.) and usually use another thread to do so.

c) No. A can be fooled but B creates his K'_AB itself. Therefore B can never be convinced to agree on a different secret than K'_AB.

d) add B to message 4, or add the hash of K'_AB in the 4th message. Or B signs the key in the 4th message. (not 100% sure)

I think the solution above does not prevent the attacker from replaying an older message sent by B. My idea would be to add another nonce which couples steps 1-3 with step 4. So we would have:

3: A->B :

4: A->B :



Using a second-preimage attack he could replace the entry for the previously accessed document .


Insertion and verificationn now take both where before insertion took and verification took .


Prepend i to the input before hashing.

12 SSL


secure I guess? The attacker has no way in finding out the password hash and therefore can't generate any message himself. Also the observation of the protocol doesn't let the attacker find out the key or the password hash.

I don't think so. A passive attacker can bruteforce J (if a weak password is used) and check if the password is correct by generating the MAC with J and verifiyng the tag.

Usually, precondition are that crypto is considered as "Perfect" for protocol modeling (c.f. Formal Methods for Information Security). Therefore, even in the real world this assumption would be true, it's behind the scope of the analysis. So I believe this one is "secure" under these asumptions. And J is not a password, but a hash of a password. Which is usually above 100 bits and with high entropy. (We may argue about rainbow table .. but well)


An attacker can alter messages (there is no MAC that ensures integrity) and the client and server would "agree" on different keys.

Seems secure to me, since an attacker doesn't have J and thus can't correctly encrypt his own secret for DH. Even if an attacker alters the message he can't make any use of it, since he doesn't know the actual plaintext of what he sent. He also doesn't have a good way to try and brute force J as he doesn't know the plaintext of the two messages being sent.


A man-in-the-middle attacker can intercept and instead send (where he knows ). Now, the attacker can compute and therefore gains knowledge over the password hash .


secure I guess?

I don't think so. short key (56bit DES) -> brute-force attacks are possible



Stack canaries are used to detect a stack buffer overflow before execution of malicious code can occur. A, at program start randomly chosen, small integer is placed in memory just before the stack return pointer. Most buffer overflows overwrite memory from lower to higher memory address, so in order to overwrite the return pointer, the canary value must be overwritten. This value is checked to make sure, it has not changed before a routine uses the return pointer on the stack.


A capability list stores to each subject a list of permissions (on objects) and an ACL stores to each object a list of permissions and users.


OS layer

  • One might want a quick overview on all apps requesting a particular permission.
  • If a permission changes (e.g. due to a OS upgrade) one can easily select and handle the affected apps.

application layer

  • Uninstalling an app is faster as only the permission list for this app must be deleted (not every "file" has to be checked for permission given to this app) and the same holds for the installation of a new app.
  • If only on app is launched at a time we are only interested in the permissions of this specific app as it is the only instance possibly able to request a "file".


storage covert channel: TR can lock a particular file to signal motion and unlock it otherwise s.t. AB can check if the file is currently locked or not and act accordingly.

timing covert channel: TR could use 100% of the CPU to signal motion and sleep otherwise s.t. AB could measure time passed between two context switches and send messages over the network respectively.


15 DDoS attacks

b) Coremelt attack


"[T]he attacker uses a collection of subverted machines sending data to each other to flood and disable a network link [...] There are 3 steps to launching a Coremelt attack:

1. Select a link in the network as the target link.

2. Identify what pairs of subverted machines can generate traffic that traverse the target link.

3. Send traffic between the pairs identified in step 2 to overload the target link."

Direkt zitiert von The Coremelt-Attack (Studer, Perrig), S. 3.


"an attacker can elude capability- and filtering-based DoS defenses because all traffic is desired by the receiver".

Wieder von The Coremelt-Attack (Studer, Perrig), S. 3.


"After acquiring the capability, the legitimate traffic requires no additional work and can proceed unhampered by the DoS attack. If we were to adopt puzzles for every packet, the puzzles may become the bottleneck rather than the links. During a Coremelt attack, the target link will increase the re- sources senders need to invest to complete puzzles, effectively degrading the performance of any machine using the target link."

Immer noch The Coremelt-Attack (Studer, Perrig), S. 14f.