MD5 - Message Digest 5 : Information Security - BE-[Comp/IT]

   What is a Message Digest -  A simple answer to this question is  - Message Digest is basically a Cryptographic Hash Function. Still, if you are not yet clear with the term Message Digest, lets make it even more simple - Message Digest is simply  a digital summary for a given piece of information. Basically, it is the 'fingerprint' of the message, i.e. the message digest can be used to uniquely identify a message.

    I had used the term 'cryptographic' when i intended to explain the term Message Digest. How does crytography come into the picture, what does it mean? - well, cryptography is simply the scrambling of data i.e representing the data in such a way, that no one else except for the intended recipient can make sense out of it. Lets say , like 'Monday' can be represented as 'npoebz' (here,scrambling is done in the fashion of shifting all alphabets towards the right by 1. Eg : 'a' is replaced by b, 'b' is replaced by 'c' etc ). When we use both the terms together - Cryptographic + Hashing : Things gradually start making sense.

  Lets get a little more technical.

Defining : Cryptographic Hashing

   MD5 stands for Message Digest algorithm 5, and was invented by US cryptographer Professor Ronald Rivest in 1991 to replace the old MD4 standard. MD5 is simply the name for a type of cryptographic hashing function Ron came up with, way back in ’91.

   The idea behind cryptographic hashing is to take an arbitrary block of data and return a fixed-size “hash” value. It can be any data, of any size but the hash value will always be fixed. 

The ideal cryptographic hash function has four main or significant properties:

• it is easy to compute the hash value  (but not necessarily quick)  for any given message
• it is infeasible to generate a message that has a given hash
• it is infeasible to modify a message without changing the hash
• it is infeasible to find two different messages with the same hash

    Cryptographic hashing has a number of uses, and there are a vast number of algorithms (other than MD5) designed to do a similar job. One of the main uses for cryptographic hashing is for verifying the contents of a message or file after transfer.

Like ,consider the following case,

  The  method works for messages, with the hash verifying that the message received matches the message sent.

  On a very basic level, if you and a friend have a large file each and wish to verify they’re exactly the same without the hefty transfer, the hash code will do it for you.

   Hashing algorithms also play a part in data or file identification. A good example for this is peer to peer file sharing networks, such as eDonkey2000. The system used a variant of the MD4 algorithm (below) which also combined file’s size into a hash to quickly point to files on the network.

   A signature example of this is in the ability to quickly find data in hash tables, a method commonly used by search engines.

   Another use for hashes is in the storage of passwords. Storing passwords as clear text is a bad idea, for obvious reasons so instead they are converted to hash values. When a user inputs a password it is converted to a hash value, and checked against the known stored hash. As hashing is a one-way process, provided the algorithm is sound then there is theoretically little chance of the original password being deciphered from the hash.

  Cryptographic hashing is also often used in the generation of passwords, and derivative passwords from a single phrase.

Message Digest algorithm 5

  The MD5 function provides a 32 digit hexadecimal number. If we were to turn ‘makeuseof.com’ into into an MD5 hash value then it would look like:64399513b7d734ca90181b27a62134dc. It was built upon a method called the Merkle”“DamgÃ¥rd structure (below), which is used to build what are known as “collision-proof” hash functions.

    No security is everything-proof, however and in 1996 potential flaws were found within the MD5 hashing algorithm. At the time these were not seen as fatal, and MD5 continued to be used. In 2004 a far more serious problem was discovered after a group of researchers described how to make two separate files share the same MD5 hash value. This was the first instance of a collision attack being used against the MD5 hashing algorithm. A collision attack attempts to find two arbritary outputs which produce the same hash value ““ hence, a collision (two files existing with the same value).

   Over the next few years attempts to find further security problems within MD5 took place, and in 2008 another research group managed to use the collision attack method to fake SSL certificate validity. This could dupe users into thinking they are browsing securely, when they are not. The US Department of Homeland Security announced that: “users should avoid using the MD5 algorithm in any capacity. As previous research has demonstrated, it should be considered cryptographically broken and unsuitable for further use“.

    Despite the government warning, many services still use MD5 and as such are technically at risk. It is however possible to “salt” passwords, to prevent potential attackers using dictionary attacks (testing known words) against the system. If a hacker has a list of random often-used passwords and your user account database, they can check the hashes in the database against those on the list. Salt is a random string, which is linked to existing password hashes and then hashed again. The salt value and resulting hash is then stored in the database.

   If a hacker wanted to find out your users’ passwords then he would need to decipher the salt hashes first, and this renders a dictionary attack pretty useless. Salt does not affect the password itself, so you must always choose a hard-to-guess password.

Conclusion

   MD5 is one of many different methods of identifying, securing and verifying data. Cryptographic hashing is a vital chapter in the history of security, and keeping things hidden. As with many things designed with security in mind, someone’s gone and broken it.

Read More

Encryption & Decryption : Information Security

Download this guide as PDF

Encryption is the conversion of data into a form, called a ciphertext, that cannot be easily understood by unauthorized people. Decryption is the process of converting encrypted data back into its original form, so it can be understood.

The use of encryption/decryption is as old as the art of communication. In wartime, a cipher, often incorrectly called a code, can be employed to keep the enemy from obtaining the contents of transmissions. Simple ciphers include the substitution of letters for numbers, the rotation of letters in the alphabet, and the "scrambling" of voice signals by inverting the sideband frequencies. More complex ciphers work according to sophisticated computer algorithms that rearrange the data bits in digital signals.

In order to easily recover the contents of an encrypted signal, the correct decryption key is required. The key is an algorithm that undoes the work of the encryption algorithm. Alternatively, a computer can be used in an attempt to break the cipher. The more complex the encryption algorithm, the more difficult it becomes to eavesdrop on the communications without access to the key.

Encryption/decryption is especially important in wireless communications. This is because wireless circuits are easier to tap than their hard-wired counterparts. Nevertheless, encryption/decryption is a good idea when carrying out any kind of sensitive transaction, such as a credit-card purchase online, or the discussion of a company secret between different departments in the organization. The stronger the cipher -- that is, the harder it is for unauthorized people to break it -- the better, in general. However, as the strength of encryption/decryption increases, so does the cost.

Encryption is mainly of two types :

•  Asymmetric Key Encryption (Public-Key Encryption)
•  Symmetric Key Encryption

Symmetric-Key Encryption

   With symmetric-key encryption, the encryption key can be calculated from the decryption key, and vice versa. With most symmetric algorithms, the same key is used for both encryption and decryption. 

The following figure shows a symmetric-key encryption.

Symmetric-Key Encryption

Implementations of symmetric-key encryption can be highly efficient, so that users do not experience any significant time delay as a result of the encryption and decryption. Symmetric-key encryption also provides a degree of authentication, since information encrypted with one symmetric key cannot be decrypted with any other symmetric key. Thus, as long as the symmetric key is kept secret by the two parties using it to encrypt communications, each party can be sure that it is communicating with the other as long as the decrypted messages continue to make sense.

   Symmetric-key encryption is effective only if the symmetric key is kept secret by the two parties involved. If anyone else discovers the key, it affects both confidentiality and authentication. A person with an unauthorized symmetric key not only can decrypt messages sent with that key, but can encrypt new messages and send them as if they came from one of the two parties who were originally using the key.

    Symmetric-key encryption plays an important role in the SSL protocol, which is widely used for authentication, tamper detection, and encryption over TCP/IP networks. SSL also uses techniques of public-key encryption, which is described in the next section.

 Asymmetric Key Encryption :

Public-Key Encryption

The most commonly used implementations of public-key encryption are based on algorithms patented by RSA Data Security. Therefore, this section describes the RSA approach to public-key encryption.

   Public-key encryption (also called asymmetric encryption) involves a pair of keys—a public key and a private key—associated with an entity that needs to authenticate its identity electronically or to sign or encrypt data. Each public key is published, and the corresponding private key is kept secret. 

The following figure shows a simplified view of the way public-key encryption works.

Public-Key Encryption

    Public—key encryption lets you distribute a public key, and only you can read data encrypted by this key. In general, to send encrypted data to someone, you encrypt the data with that person’s public key, and the person receiving the encrypted data decrypts it with the corresponding private key.

   Compared with symmetric-key encryption, public-key encryption requires more computation and is therefore not always appropriate for large amounts of data. However, it’s possible to use public-key encryption to send a symmetric key, which can then be used to encrypt additional data. This is the approach used by the SSL protocol.

     As it happens, the reverse of the scheme shown in Figure also works: data encrypted with your private key can be decrypted with your public key only. This would not be a desirable way to encrypt sensitive data, however, because it means that anyone with your public key, which is by definition published, could decrypt the data. Nevertheless, private-key encryption is useful, because it means you can use your private key to sign data with your digital signature—an important requirement for electronic commerce and other commercial applications of cryptography. Client software can then use your public key to confirm that the message was signed with your private key and that it hasn’t been tampered with since being signed. Digital Signatures on Digital Signatures and subsequent sections describe how this confirmation process works.

========================

Video Lectures

Symmetric Key Cryptography : part 1

Symmetric Key Cryptography : part 2

Symmetric Key Cryptography : Block Ciphers & DES

Block Ciphers, DES, Triple DES

Integrity & message Authentication

Symmetric & Asymmetric Encryption

Asymmetric Encryption

============================================

Read More

RSA Algorithm - Information Security: Cryptography BE [ Computer / IT / E&TC ]

(Download as PDF)

       Suppose, we want to do: We have a "piece of data" that we want to somehow "scramble" so nobody can learn what this data is, and we want to send this data over unsecure lines to the recipient. Upon receipt of this scrambled data, the recipient must be able to "unscramle" this data to its original shape. The important thing here is that we want to do this "scrambling/unscrambling" process without requiring usage of any secret keys that both the sender and the recipient must posses in order to scramble and descramble the data. This is why the method we are going to discuss here is called "Public Key Cryptography". There are several Public Key Cryptography algorithms in use today. The most popular is called RSA algorithm, and is named after the initials of its inventors: R for Rivest, S for Shamir, and A for Adelman. By the way, they were students when they invented this algorithm. This is their picture at the time. 

     So here is the summary of operations. Please continue reading below for the detailed explanation of how this is achieved. Let's say that your WEB Browser has a piece of data, say number 14 (we'll call it a Plain message and label it as P=14). and it wants to encrypt this Plain message first and then send it to the Server. Upon receipt of this encrypted message, the Server wants to decrypt it to its original value. Here is the summary of what transpires. Before any communication happens, the Server had calculated, in advance, its public (n =33 and k=7) and private (j=3) keys. Now, to initiate the transaction, the Browser sends this message to the server: Hey Server, please send me your public key. The Server obliges: Here it comes, it's n=33, k=7. After receiving the Server's public key, the Browser converts the Plain message P=14 into the Encrypted message E=20 and sends it to the Server. The Server receives this encrypted message E=20 and using its secret key j=3 (and publicly known key n=33) decrypts the E=20 message into its original Plain message P=14.

Now, let's look a bit more into the math behind all this. 

Section1. Generating Public and Private Keys
First, as we mentioned above, before any transmission happens, the Server had calculated its public and secret keys.  Here is how. 

1.1) pick two prime numbers, we'll pick p = 3 and q = 11
1.2) calculate n = p * q = 3 * 11 = 33
1.3) calculate z = ( p - 1 ) * ( q - 1 ) = ( 3 - 1 ) * ( 11 - 1 ) = 20
1.4) choose a prime number k, such that k is co-prime to z, i.e, z is not divisible by k. We have several choices for k: 7, 11, 13, 17, 19 (we cannot use 5, because 20 is divisible by 5). Let's pick k=7 (smaller k, "less math").
1.5) So, the numbers n = 33 and k = 7 become the Server's public key.
1.6) Now, still done in advance of any transmission, the Server has to calculate it's secret key. Here is how.
1.7) k * j = 1 ( mod z )
1.8) 7 * j = 1 ( mod 20 )
1.9) ( 7 * j ) / 20 = ?
 with the remainder of 1 (the "?" here means: "something, but don't wory about it"; we are only interested in the remainder). Since we selected (on purpose) to work with small numbers, we can easily conclude that 21 / 20 gives "something" with the remainder of 1. So, 7 * j = 21, and j = 3. This is our secret key. We MUST NOT give this key away.

    Now, after the Server has done the above preparatory calculations in advance, we can begin our message transmission from our Browser to the Server. First, the Browser requests from the Server, the Server's public key, which the Server obliges, i.e., it sends n=33 and k=7 back to the Browser.  Now, we said that the Browser has a Plain message P=14, and it wants to encrypt it, before sending it to the Server. Here is how the encryption happens on the Browser.

Section 2. Encrypting the message
Here is the encryption math that Browser executes.

2.1) P ^ k = E ( mod n ) 
"^" means "to the power of"
P is the Plain message we want to encrypt
n and k are Server's public key (see Section 1)
E is our Encrypted message we want to generate

After plugging in the values, this equation is solved as follows:
2.2) 14 ^ 7 = E ( mod 33 )
This equation in English says: raise 14 to the power of 7, divide this by 33, giving the remainder of E.
2.3) 105413504 / 33 = 3194348.606 (well, I lied when I said that this is "Pencil and Paper" method only. You might want to use a calculator here).
2.4) 3194348 * 33 = 10541348
2.5) E = 105413504 - 10541348 = 20

So, our Encrypted message is E=20.  This is now the value that the Browser is going to send to the Server. When the Server receives this message, it then proceeds to Decrypt it, as follows.

Section 3. Decrypting the Message
Here is the decryption math the Server executes to recover the original Plain text message which the Browser started with.

3.1) E ^ j = P ( mod n)
E is the Encrypted message just received
j is the Server's secret key
P is the Plain message we are trying to recover
n is Server's public key (well part of; remember that Server's public key was calculated in Section 1 as consisting of two numbers: n=33 and k=7).

After plugging in the values:
3.2) 20 ^ 3 = P ( mod 33 )
3.3) 8000 / 33 = ? with the remainder of P.  So to calculate this remainder, we do:
3.4) 8000 / 33 = 242.424242...
3.5) 242 * 33 = 7986
3.6) P = 8000 - 7986 = 14, which is exactly the Plain text message that the Browser started with!

Well that's about it. While we did not discuss the theory behind the formulae involved I hope that you got at least a basic idea of how the public key cryptography using the RSA algorithm works.

Section 4. "Cracking the Code"
The essential requirement of the Public Key Cryptography is that the public and secret keys are mathematically related, but this relationship must be made very hard to determine by an outsider.  As you saw in the preceeding text, everything starts with  p and q, from which we calculated n. The public key consists of two numbers: n and k, where k is calculated from z and z is calculated from p and q. The secret key j, was calculated from k and z and,  as we just stated,  k and z are calculated from p and q. It follows then, that j is also calculated from p and q,which proves that the public and private keys are mathematically related.  So, if an outsider wanted to find the secret key j, by only knowing n, he must break down n into the two prime numbers that were used to produce it (remember that n = p * q). Now, here is the real crux of the bisquit: Decomposing a very large n into p and q is really difficult to do. It is easy with the small numbers that we have used in our demonstration, but try, for example decomposing p into p and q when p has several hundred digits. 


                                                     

========================

Video Lectures

 RSA Algorithm with a solution

---------------------------------------

RSA Algortihm explained 

============================================

Read More

DNS Cache Poisoning - Information Security

      A very popular topic for discussion in "Information Security" :


 Download this whole article as PDF Guide : Download now
                                   
DNS Cache Poisoning


    What is exactly DNS Poisoning?.. to study this we would first require to know little bit about DNS i.e Domain Name System.Firstly, let us have a brief look at DNS  and then move to the main problem


What is Domain Name System?
  In the world of the Internet and TCP/IP, IP addresses are used to route packets from source to destination. A single IP address, for example 203.192.135.234, is not difficult to remember. But trying to learn or track thousands of these addresses, including which server/node is associated with each address, is a daunting task. So instead, we use domain names to refer to systems with which we want to communicate


 Let us take a real world example : 
  When you enter the "Google.com" into the address bar of your browser, the Google page appears. This is because your PC executed a process to resolve Google.com to an IP address. Only by having the IP address is a system able to initiate a session with another system across the Internet. 
   
  In simple terms what I mean to say is :


Whether you try 

   or you try :

both will deliver the same results ... if you try www.google.com then your browser resolves the appropriate ip address for the page by looking up into the DNS table which is just  like an index and then process your request and display the page on your browser.



   Now that we have a good idea how DNS is supposed to work, it’s time to look at how this process can be used to co-opt one or more DNS caches.


What is DNS Cache Poisoning?


    DNS cache poisoning consists of changing or adding records in the resolver caches, either on the client or  the server, so that a DNS query for a domain returns an IP address for an attacker’s domain instead of the intended domain. 


To demonstrate how this might work, let’s step through Figure below


Figure : DNS Cache Poisoning

Step 1: The resolver checks the resolver cache in the workstation’s memory to see if it contains an entry for Farpoint.companyA.com.


Step 2: Having found no entry in the resolver cache, the resolver sends a resolution request to the internal DNS server.


Step 3: When the DNS server receives the request, it first checks to see if it’s authoritative. In this case, it isn’t authoritative for companyA.com. The next action it takes is to check its local cache to see if an entry for Farpoint.companyA.com exists. It doesn’t. So in Step 4 the internal DNS server begins the process of iteratively querying external DNS servers until it either resolves the domain name or it reaches a point at which it’s clear that the domain name entry doesn’t exist.


Step 4: A request is sent to one of the Internet root servers. The root server returns the address of a server authoritative for the .COM Internet space.


Step 5: A request is sent to the authoritative server for .COM. The address of a DNS server authoritative for the companyA.com domain is returned.


Step 6: A request is sent to the authoritative server for companyA.com. This is identical to the standard process for an iterative query – with one exception. A cracker has decided to poison the internal DNS server’s cache. In order to intercept a query and return malicious information, the cracker must know the transaction ID. Once the transaction ID is known, the attacker’s DNS server can respond as the authoritative server for companyA.com.


    Although this would be a simple matter with older DNS software (e.g. BIND 4 and earlier), newer DNS systems have build-in safeguards. In our example, the transaction ID used to identify each query instance is randomized. But figuring out the transaction ID is not impossible. All that’s required is time. To slow the response of the real authoritative server, our cracker uses a botnet to initiate a Denial of Service (DoS) attack. While the authoritative server struggles to deal with the attack, the attacker’s DNS server has time to determine the transaction ID.
      Once the ID is determined, a query response is sent to the internal DNS server. But the IP address for Farpoint.companyA.com in the response is actually the IP address of the attacker’s site. The response is placed into the server’s cache.


Step 7: The rogue IP address for Farpoint is returned to the client resolver.


Step 8: An entry is made in the resolver cache, and a session is initiated with the attacker’s site. At this point, both the workstation’s cache and the internal DNS server’s cache are poisoned. Any workstation on the internal network requesting resolution of Farpoint.companyA.com will receive the rogue address listed in the internal DNS server’s cache. This continues until the entry is deleted.
    Another method used to poison a DNS cache is the use of a recursive query sent by the attacker. The query can force the target server to connect to the authoritative source of the domain in the query. Once connected, rogue information about one or more domains might be sent to the querying server and posted to the server’s cache.
    There are other methods attackers use to poison DNS caches, but the objective is the same. 
    
   Now we’ll explore the consequences of using a poisoned DNS cache


Potential Consequences of Cache Poisoning



Identity Theft
   Once an attacker gets you to his site, he’ll try to trick you into leaving behind information he can use to impersonate you. One way to do this in our first example is to create a site identical to the real Farpoint.companyA.com. When the user connects using the poisoned cache information, she might be fooled into entering information about herself through apparently legitimate requests for her name, social security number, address, etc.


Distribution of Malware
  Another of objective of attackers using cache poisoning is the automatic distribution of malware. Instead of releasing malicious code into the Internet and realizing random results, the use of rogue IP addresses to redirect unsuspecting users to the attacker’s site can be a more focused attack vector. Once a workstation initiates a session with the malicious site, malware is uploaded to the workstation without intervention by or the knowledge of the user.


Dissemination of False Information
   This aspect of pharming is useful to attackers who want to spread self-serving information about an organization. It’s also been used to manipulate stock prices in an attempt to realize a large profit.


Man-in-the-middle Attack
  In this attack type, the workstation initiates a session with the attacker’s server. The attacker’s server initiates a session with the actual target site. All information flowing between the workstation and the genuine site passes through and is intercepted by the cracker’s server. 
    There can be serious consequences when security is an afterthought during the configuration and deployment of DNS servers. The next section provides guidelines that can help prevent cache poisoning.






Explanation of DNS Cache Poisoning

Example of DNS Posioning Attack

Read More