{Notes to self, programming, technology, linux, windows, git} U {Papers, reviews, games, coffee, tabletennis, ramblings} = {things worth saving}

Showing posts with label security. Show all posts
Showing posts with label security. Show all posts

Wednesday, March 25, 2009

On security: Authenticity

Problem

Two solutions can be employed in order for users to send requests R to a database for data and receive said data. Users have a private RSA key skA, and also know the public key of the database pkD. But one of these solutions has a security problem. Which?

  • The first solution involves the user encrypting R under D’s public key, appending his signature on the encrypted request (RSA = public key system = digital signature), and then appending his username A.
  • The second solution involves the user appending his signature on the request, encrypting this under D’s public key, and appending his username A.

Solution

First method

Using the first method the signature of the message is not encrypted with D’s public key, only the R. Since a User ID is also added to the message, unencrypted, a user B is able to intercept the message, sign it with his own signature, replace the existing User ID with his own, and send it to D. The database now takes A’s request, looks up B’s public key, encrypts the response and sends it to B instead of A. This was not supposed to happen.

Second method

The second method avoids this by encrypting everything with D’s public key and by doing so we maintain authenticity. We can therefore conclude that the second method is the most secure.

(solution to old assignment from dSik)

On security: One-time pads

Problem

We’re trying to compromise a One-Time Pad by applying facts we have about the original message. Bits 0-20 (LSB first) contain salary information. What we’re trying to do is to get the recipient of the salary an extra mill. A message will be mentioned as m, a key will be mentioned as k and a ciphertext will be mentioned as c.

Solution

What do we know? We know that the salary is encoded in m in bits 0-20, and we know that we get paid less than a million per month. This is enough information to manipulate m encoded with a One-Time pad! In binary 1 million has MSB 1, using our own encoded notation. We know
that the one-time pad uses XOR to generate c using k. Knowing the location of the MSB in the encoded message, and knowing what it should be, to get an extra million (1), we can change the original message to our liking. For example, if the bit corresponding to our salary MSB bit in c is 0, and we know that we do NOT get paid a million or more, then the corresponding bit in m should also be 0, which means the corresponding bit in k is 0 aswell. Now we can change the bit in c to our liking, 1, which adds a million to our salary.

One-time pad security

The only reason we have been able to compromise the One-Time Pad is because we have enough knowledge about m, to make certain changes. If we did not know anything about the original message, c would be total jibberish.

(solution to old assignment from dSik)

Followers