M S RAMAIAH INSTITUTE OF TECHNOLOGY

(Autonomous Institute affiliated to VTU)

Department of Computer Science and Engineering
Bangalore

Computer Network Security

Non-CIE Component

Rithvik S Shetty - 1MS18CS100

Tharun E - 1MS18CS127
Prashanth S - 1MS18CS096
T Sai Chandu - 1MS18CS125
 Table of Contents

Experiment Experiment
Number
1 Demonstration of CRYPTOOL (which covers all the algorithms)

2 RSA algorithm

3 public key cryptography RSA to create digital signatures

4 Diffie Hellman Secret Key Exchange Algorithm

5 Key management operations

6 network troubleshooting, analysis-wireshark tool

7 security scanner-NMap tool

8 Intrusion Detection System- Snort tool

9 vulnerability scanning-Nessus
 EXPERIMENT NO 1

Aim: CRYPTOOL

CrypTool implements more than 300 algorithms. Users can adjust these with their own parameters.
The graphical interface, online documentation, analytic tools and algorithms of CrypTool introduce
users to the field of cryptography. Classical ciphers are available alongside asymmetric
cryptography including RSA, elliptic curve cryptography, digital signatures,homomorphic
encryption, and Diffie–Hellman key exchange, many of which are visualized by animations.
In this lab they need to demonstrate the following Algorithms.
● Triple DES with CBC mode and Weak DES keys
● Testing Different Modes in Symmetric Ciphers
● Implement DES and AES ciphers.
● Investigate Properties of Modes in DES and AES
● RSA Encryption and Factorization Attacks
● Attack on RSA encryption with short RSA modulus
● Short Message RSA Attacks and Padding
● RSA Timing Attacks
● Hash generation and sensitivity of hash functions to plaintext modifications
● Hash Function
● Digital Signature Visualization
● RSA Signature
● Attack on Digital Signature/Hash Collision
● Digital Signature
 EXPERIMENT NO 2
Aim: To implement RSA algorithm to achieve confidentiality

Theory:

Public-key cryptography refers to a cryptographic system requiring two separate keys, one to lock
or encrypt the plaintext, and one to unlock or decrypt the ciphertext. Neither key will do both
functions. One of these keys is published or public and the other is kept private. If the
lock/encryption key is the one published then the system enables private communication from the
public to the unlocking key's owner. If the unlock/decryption key is the one published then the
system serves as a signature verifier of documents locked by the owner of the private key. This
cryptographic approach uses asymmetric key algorithms such as RSA, hence the more general name
of "asymmetric key cryptography". Some of these algorithms have the public key/private key
property; that is, neither key is derivable from knowledge of the other; not all asymmetric key
algorithms do. Those with this property are particularly useful and have been widely deployed, and
are the source of the commonly used name.
Although unrelated, the key pair is mathematically linked. The public key is used to transform a
message into an unreadable form, decryptable only by using the (different but matching) private key.
By publishing the public key, the key producer empowers anyone who gets a copy of the public key
to produce messages only s/he can read—because only the key producer has a copy of the private
key (required for decryption). When someone wants to send a secure message to the creator of those
keys, the sender encrypts it (i.e., transforms it into an unreadable form) using the intended recipient's
public key; to decrypt the message, the recipient uses the private key. No one else, including the
sender, can do so.
RSA

RSA involves a public key and a private key. The public key can be known to everyone and is used
for encrypting messages. Messages encrypted with the public key can only be decrypted using the
private key. The keys for the RSA algorithm are generated the following way:

1. Choose two distinct prime numbers p and q.

2. For security purposes, the integers p and q should be chosen at random, and should be
of similar bit-length.
3. Compute n = pq.
▪ n is used as the modulus for both the public and private keys
4. Compute φ(n) = (p-1)(q-1), where φ is Euler's totient function.
5. Choose an integer e such that 1 < e < φ(n) and greatest common divisor of (e, φ(n)) =
1; i.e., e and φ(n) are co prime.
▪e is released as the public key exponent.
6. Determine d as:

i.e., d is the multiplicative inverse of e mod φ(n).

 The public key consists of the modulus n and the public (or encryption) exponent e. The private
key consists of the modulus n and the private (or decryption) exponent d which must be kept
secret.
Encryption

Alice transmits her public key to Bob and keeps the private key secret. Bob then wishes
to send message M to Alice.
He first turns M into an integer m, such that by using an agreed-upon reversible
protocol known as a padding scheme. He then computes the ciphertext corresponding to

.
This can be done quickly using the method of exponentiation by squaring. Bob then
transmits to Alice.
Note that at least nine values of m will yield a cipher text c equal to m but this is very
unlikely to occur in practice.
Decryption
Alice can recover from by using her private key exponent via computing

.
Students are required to implement the logic in Turbo C++ or JAVA.

Java code:
import java.math.*;
import java.util.*;

public class RSA {

public static void main(String args[])

{

int p, q, n, z, d = 0, e, i;

// The number to be encrypted and decrypted

int msg = 12;
double c;
 BigInteger msgback;
// 1st prime number p
p = 3;
// 2nd prime number q
q = 11;
n = p * q;
z = (p - 1) * (q - 1);
System.out.println("the value of z = " + z);
for (e = 2; e < z; e++) {
// e is for public key exponent
if (gcd(e, z) == 1) {
break;
}
}
System.out.println("the value of e = " + e);
for (i = 0; i <= 9; i++) {
int x = 1 + (i * z);
// d is for private key exponent
if (x % e == 0) {
d = x / e;
break;
}
}
System.out.println("the value of d = " + d); c = (Math.pow(msg, e)) % n;
System.out.println("Encrypted message is : " + c);
// converting int value of n to BigInteger
BigInteger N = BigInteger.valueOf(n);
// converting float value of c to BigInteger
BigInteger C = BigDecimal.valueOf(c).toBigInteger(); msgback = (C.pow(d)).mod(N);
System.out.println("Decrypted message is : "
+ msgback);
}
static int gcd(int e, int z)
{
if (e == 0) return z;
else
return gcd(z % e, e);
}
}
Conclusion:

The features of public key cryptography and RSA logic are studied..
 EXPERIMENT NO 3
Aim: To implement public key cryptography RSA to create digital signatures

Theory:

Public-key cryptography refers to a cryptographic system requiring two separate keys, one
to lock or encrypt the plaintext, and one to unlock or decrypt the ciphertext. Neither key will do both
functions. One of these keys is published or public and the other is kept private. If the
lock/encryption key is the one published then the system enables private communication from the
public to the unlocking key's owner. If the unlock/decryption key is the one published then the
system serves as a signature verifier of documents locked by the owner of the private key. This
cryptographic approach uses asymmetric key algorithms such as RSA, hence the more general name
of "asymmetric key cryptography". Some of these algorithms have the public key/private key
property; that is, neither key is derivable from knowledge of the other; not all asymmetric key
algorithms do. Those with this property are particularly useful and have been widely deployed, and
are the source of the commonly used name.
Although unrelated, the key pair is mathematically linked. The public key is used to transform a
message into an unreadable form, decryptable only by using the (different but matching) private key.
By publishing the public key, the key producer empowers anyone who gets a copy of the public key
to produce messages only s/he can read—because only the key producer has a copy of the private
key (required for decryption). When someone wants to send a secure message to the creator of those
keys, the sender encrypts it (i.e., transforms it into an unreadable form) using the intended recipient's
public key; to decrypt the message, the recipient uses the private key. No one else, including the
sender, can do so.

RSA

RSA involves a public key and a private key. The public key can be known to everyone and is used
for encrypting messages. Messages encrypted with the public key can only be decrypted using the
private key. The keys for the RSA algorithm are generated the following way:

7. Choose two distinct prime numbers p and q.

8. For security purposes, the integers p and q should be chosen at random, and should be
of similar bit-length.
9. Compute n = pq.
▪ n is used as the modulus for both the public and private
keys 10.Compute φ(n) = (p-1)(q-1), where φ is Euler's totient
function.
11. Choose an integer e such that 1 < e < φ(n) and greatest common divisor of (e, φ(n)) =
1; i.e., e and φ(n) are coprime.
 ▪e is released as the public key
exponent. 12.Determine d as:
 i.e., d is the multiplicative inverse of e mod φ(n).
The public key consists of the modulus n and the public (or encryption) exponent e. The private
key consists of the modulus n and the private (or decryption) exponent d which must be kept
secret.
Encryption (Creating Digital Signature)
To create a digital signature Alice has to encrypt the message using her private key.If the private
key of Alice is d then, M d mod N gives the cipher text which is the digital signature of Alice.

Decryption (Verifying Signature)

Bob can verify the signature of Alice by decrypting the signed message using Alice’s public

key. Ce mod N

Students are required to implement the logic in Turbo C++ or JAVA.

import java.security.KeyPair;
import java.security.KeyPairGenerator;
import java.security.PrivateKey;
import java.security.Signature;
import java.util.Scanner;

public class CreatingDigitalSignature {

public static void main(String args[]) throws Exception {
//Accepting text from user
Scanner sc = new Scanner(System.in);
System.out.println("Enter some text");
String msg = sc.nextLine();

//Creating KeyPair generator object

KeyPairGenerator keyPairGen =
KeyPairGenerator.getInstance("RSA");
 //Initializing the key pair generator
keyPairGen.initialize(2048);

//Generate the pair of keys

KeyPair pair = keyPairGen.generateKeyPair();

//Getting the private key from the key pair

PrivateKey privKey = pair.getPrivate();

//Creating a Signature object

Signature sign = Signature.getInstance("SHA256withRSA");

//Initialize the signature

sign.initSign(privKey);
byte[] bytes = "msg".getBytes();

//Adding data to the signature

sign.update(bytes);

//Calculating the signature

byte[] signature = sign.sign();

//Printing the signature

System.out.println("Digital signature for given text: "+new
String(signature, "UTF8"));

}
}
Conclusion:

The features of public key cryptography to create digital signatures are done.
 EXPERIMENT NO 4
Aim: To implement Diffie Hellman Secret Key Exchange Algorithm.

Theory:

The Diffie Hellman key exchange algorithm uses asymmetric key principles for the distribution of
symmetric keys to both parties in a communication network. Key distribution is an important aspect
of conventional algorithms and the entire safety is dependent on the distribution of the key using a
secured channel. Diffie Hellman utilizes the public & private key of asymmetric key cryptography
to exchange the secret key.

Before going in depth of Diffie Hellman Algorithm,we define primitive root of a prime number 'p'
as one whose powers generate all the integers from 1 to p-1, i.e. if 'a' is the primitive root of a prime
no 'p', then,
a mod p , a2 mod p , a 3 mod p, ap-1 mod p generate all distinct integers from 1 to (p-1) in
some permutation.

The steps for Diffie Hellman key exchange algorithm are:

Step 1 : GLOBAL PUBLIC ELEMENTS

Select any prime no : 'q'
Calculate the primitive root of q : 'a' such that a<q

Step 2 : ASYMMETRIC KEY GENERATION BY USER 'A'

Select a random number as the private key XA where XA < q
Calculate the public key Y A where Y A = aX mod q

Step 3 : KEY GENERATION BY USER 'B'

Select a random number as the private key XB where XB < q
Calculate the public key Y B where Y B = aX mod q

Step 4 : Exchange the values of public key between A & B

Step 5 : SYMMETRIC KEY (K) GENERATION BY USER 'A'

K= Y X mod q

Step 6 : SYMMETRIC KEY (K) GENERATION BY USER 'B'

K= Y X mod q

It can be easily proved that the key K generated by this algorithm by both parties are the same.
Students are required to implement the logic in Turbo C++ or Java.

Java code:
public class GFG{

// Power function to return value of a ^ b mod P

private static long power(long a, long b, long p)

if (b == 1)

return a;

else

return (((long)Math.pow(a, b)) % p);

// Driver code

public static void main(String[] args)

long P, G, x, a, y, b, ka, kb;

// Both the persons will be agreed upon the

// public keys G and P

// A prime number P is taken

P = 23;

System.out.println("The value of P:" + P);

// A primitive root for P, G is taken
G = 9;

System.out.println("The value of G:" + G);

// Alice will choose the private key a

// a is the chosen private key

a = 4;

System.out.println("The private key a for Alice:" + a);

// Gets the generated key

x = power(G, a, P);

// Bob will choose the private key b

// b is the chosen private key

b = 3;

System.out.println("The private key b for Bob:" + b);

// Gets the generated key

y = power(G, b, P);

// Generating the secret key after the exchange

// of keys

ka = power(y, a, P); // Secret key for Alice

kb = power(x, b, P); // Secret key for Bob

System.out.println("Secret key for the Alice is:" + ka);

System.out.println("Secret key for the Bob is:" + kb);

}}
 Conclusion:

The Diffie Hellman Secret Key Exchange algorithm is studied.

 EXPERIMENT NO 5

Key management operations

Aim: Distribution of secret keys without and with key distribution center between two users

Theory:

In implementation, this approach must address the following issues: –

Assuming that A is the initiator of a session-key request to KDC, when A receives a response
from KDC, how can A be sure that the sending party for the response is indeed the KDC?
Assuming that A is the initiator of a communication link with B, how does B know that some
other party is not masquerading as A?
How does A know that the response received from B is indeed from B and not from someone
else masquerading as B?
What should be the lifetime of the session key acquired by A for communicating with B?

Assumptions: A party named A wants to establish a secure communication link with another party B. Both
the parties A and B, respectively, possess master keys KA and KB , for communicating privately with a key
distribution center (KDC). The exchange of messages is shown graphically in Figure 1.1, followed by
details of the key distribution Protocol.

Now A engages in the following protocol:

● Using KA, A sends a request to KDC for a session key intended specifically for communicating
with B.
● The message sent by A to KDC includes A′s network address (IDA), B′s network address  (IDB ),
and a unique session identifier N1. The message sent by A to KDC can be expressed in shorthand
by E(KA, [IDA, IDB , N1]). 

where E(., .) stands for encryption of the second-argument data block with a key
that is in the first argument.

● KDC responds to A with a message encrypted using the key KA. The various components of this
message are
FIG. 1.1: A most important element of this exchange is that the message (information)
that party A receives back from the Key Distribution Center can only be read by party B.

1. The session-key IS that A can use for communicating with B.

2. The original message received from A, including the unique session identifier N1 used by A. This is
to allow A to match the response received from KDC with the request sent. Note that A may be
trying to establish multiple simultaneous sessions with B.
3. A “packet” of information meant for A to be sent to B. This packet of information, encrypted using
B′s master key KB includes, again, the session key KS , and A′s identifier IDA. (Note that A cannot
look inside this packet because A does not have access to B′s master key KB .

● The message that KDC sends back to A can be expressed as

E(KA, [KS , IDA, IDB , N1, E(KB , [KS , IDA])]). 
● Using the master key KA, A decrypts the message received from KDC. Because only A and KDC
have access to the master key KA, A is certain that the message received is indeed from KDC.
● A keeps the session key KS and sends the packet intended for B to B. This message is sent to B
unencrypted by A. But note that it was previously encrypted by KDC using B′s master key KB .
Therefore, this first contact from A to B is protected from eavesdropping.
● B decrypts the message received from A using the master key KB . B compares the IDA in the
decrypted message with the sender identifier associated with the message received from A. By
matching the two, B makes certain that no one is masquerading as A.
● B now has the session key for communicating securely with A.
● Using the session key KS , B sends back to A an unique session identifier N2. A responds back with
N2+1, using, of course, the same session key KS . This way B knows that it did not receive a first
contact from A that A is no longer interested in. This is also a protection against a “replay” attack.

● A replay attack is a form of network attack in which a third party E eavesdrops on the
communications between A and B. Let us say that E intercepts the first-contact message that B
received from A. Now the question is: Would E be able to pose as B during a subsequent attempt by
A to initiate a session with B? Let us assume that E has somehow gotten hold of B′s master key KB
.

● The message sent by B back to A can be expressed as  E(KS , N2) and A′s response back to B as
E(KS , N2+1).
 EXPERIMENT NO 6
Aim: To study the Sniffing tool: Wireshark.

Theory:

Wireshark is a free and open-source packet analyzer. It is used for network troubleshooting,
analysis, software and communications protocol development, and education. Wireshark is very
similar to tcpdump, but has a graphical front-end, plus some integrated sorting and filtering options.
Wireshark allows the user to put the network interfaces that support promiscuous mode into that
mode, in order to see all traffic visible on that interface, not just traffic addressed to one of the
interface's configured addresses and broadcast/multicast traffic. However, when capturing with a
packet analyzer in promiscuous mode on a port on a network switch, not all of the traffic traveling
through the switch will necessarily be sent to the port on which the capture is being done, so
capturing in promiscuous mode will not necessarily be sufficient to see all traffic on the
network. Port mirroring or various network taps extend capture to any point on the net; simple
passive taps are extremely resistant to malware tampering.
Students are required to capture packets using Wireshark and packets are analyzed.
Conclusion:
Wire shark tool as a packet analyser is studied.
 EXPERIMENT NO 7

Aim: To study the NMap tool and familiarize with various options

Theory:
Nmap (Network Mapper) is a security scanner originally written by Gordon Lyon (also known by
his pseudonym Fyodor Vaskovich) used to discover hosts and services on a computer network, thus
creating a "map" of the network. To accomplish its goal, Nmap sends specially crafted packets to the
target host and then analyzes the responses. Unlike many simple port scanners that just send packets
at some predefined constant rate, Nmap accounts for the network conditions
(latency fluctuations, network congestion, the target interference with the scan) during the run. Also,
owing to the large and active user community providing feedback and contributing to its features,
Nmap has been able to extend its discovery capabilities beyond simply figuring out whether a host is
up or down and which ports are open and closed; it can determine the operating system of the target,
names and versions of the listening services, estimated uptime, type of device, and presence of
a firewall.
Nmap features include:

▪ Host Discovery – Identifying hosts on a network. For example, listing the hosts which
respond to pings or have a particular port open.
▪ Port Scanning – Enumerating the open ports on one or more target hosts.
▪ Version Detection – Interrogating listening network services listening on remote devices to
determine the application name and version number.
▪ OS Detection – Remotely determining the operating system and some hardware characteristics
of network devices.
Basic commands working in Nmap

▪ For target specifications: nmap <target’s URL or IP with spaces between them>
▪ For OS detection: nmap -O <target-host's URL or IP>
▪ For version detection: nmap -sV <target-host's URL or IP>
Conclusion:

NMap Port scanner is studied with its various commands.

 EXPERIMENT NO: 8
Aim: To study Intrusion Detection System: Snort

Theory:

An intrusion detection system (IDS) is a device or software application that monitors network and/or
system activities for malicious activities or policy violations and produces reports to a Management
Station. Some systems may attempt to stop an intrusion attempt but this is neither required nor
expected of a monitoring system. Intrusion detection and prevention systems (IDPS) are primarily
focused on identifying possible incidents, logging information about them, and reporting attempts. In
addition, organizations use IDPSes for other purposes, such as identifying problems with security
policies, documenting existing threats, and deterring individuals from violating security
policies.ISSUes have become a necessary addition to the security infrastructure of nearly every
organization.

Snort:

Snort is a lightweight network intrusion detection system, capable of performing real-time traffic
analysis and packet logging on IP networks. It can perform protocol analysis, content
searching/matching and can be used to detect a variety of attacks and probes, such as buffer
overflows, stealth port scans, CGI attacks, SMB probes, OS fingerprinting attempts, and much more.
Conclusion: Various types of Intrusion detection systems are studied and as case study snort
features are studied.
EXPERIMENT NO: 9 -
Vulnerability Scanning Using
Nessus

Aim:

In this lab we will explore vulnerability scanning using an open source tool called Nessus. This tool
is already installed in your Linux VMware image. You will need to install the Windows client on
your Host O/S and then use it to scan your Windows Machine.

SOFTWARE REQUIREMENTS:

nessuswx-1.4.5d.zip

REFERENCES:

1. http://www.nessus.com (Nessus)

Procedure:

Part 1 – Installing Nessus Client on the Windows Host

1. Point your browser to: http://Linux_IP_ADDRESS

2. Download the nessuswx-1.4.5d.zip file by clicking on “Windows Remote Console” and

extract it to the desktop of your host machine.

3. The NessusWX.exe file is the executable that we will be using.

Part 2 – Connecting from the Windows client to the Linux nessus server.

1. In the Windows host start the NessusWX client.

2. Click on the Communications window and select connect

3. In the name field type the IP address of the Linux guest machine that is running the nessus server.

4. Select the radio button labeled, “Authentication by password.”

5. Use the following credentials to connect (click save password):

a. Username: root

b. Password: nessus

6. Click on the connect button.

7. You will be prompted about a New Server Certificate, click the Accept & Save button.

8. Click on the Session menu and select New

9. Give the session a name and click the create button.

10. Add a target(s). This could be the address of your Linux guest, Windows Host and/or
Windows host computer.

11. Click on the Plugins tab and check the “Use session-specific plugin set” checkbox.

12. Click on the Select plugins button

13. Select the Enable Non-DoS button

14. Select the No button for the warning box.

15. Click the Close Button

16. Click the OK Button

17. Right click on the session icon that you created and select the Execute option.

18. Click the Execute button.

19. After the scan has finished click the close button.

20. Click on the view button to view the report(s).

21. Save one of your reports to a pdf file and print it out to hand in with the lab.
 REPORT

Nessus_Tutorial
Report generated by Nessus™ Sun, 09 Jan 2022 12:41:58 IST
 TABLE OF CONTENTS

Hosts Executive Summary

• 192.168.0.102.......................................................................................................................................................4
Hosts Executive Summary
 192.168.0.213

0 0 1 0 32
CRITICAL HIGH MEDIUM LOW INFO

Vulnerabilities Total: 33
SEVERIT CVSS PLUGIN NAME
Y V3.0

MEDIUM 6.4 51192 SSL Certificate Cannot Be Trusted

INFO N/A 12634 Authenticated Check : OS Name and Installed Package Enumeration

INFO N/A 45590 Common Platform Enumeration (CPE)

INFO N/A 55472 Device Hostname

INFO N/A 54615 Device Type

INFO N/A 25203 Enumerate IPv4 Interfaces via SSH

INFO N/A 25202 Enumerate IPv6 Interfaces via SSH

INFO N/A 33276 Enumerate MAC Addresses via SSH

INFO N/A 35716 Ethernet Card Manufacturer Detection

INFO N/A 86420 Ethernet MAC Addresses

INFO N/A 10107 HTTP Server Type and Version

INFO N/A 12053 Host Fully Qualified Domain Name (FQDN) Resolution

INFO N/A 24260 HyperText Transfer Protocol (HTTP) Information

INFO N/A 19506 Nessus Scan Information

INFO N/A 10147 Nessus Server Detection

INFO N/A 64582 Netstat Connection Information

INFO N/A 14272 Netstat Portscanner (SSH)

INFO N/A 11936 OS Identification

INFO N/A 97993 OS Identification and Installed Software Enumeration over SSH v2 (Using
New SSH Library)

INFO N/A 110695 OS Security Patch Assessment Checks Not Supported

INFO N/A 117886 OS Security Patch Assessment Not Available

INFO N/A 45405 Reachable IPv6 address

INFO N/A 56984 SSL / TLS Versions Supported

INFO N/A 10863 SSL Certificate Information

INFO N/A 70544 SSL Cipher Block Chaining Cipher Suites Supported

INFO N/A 21643 SSL Cipher Suites Supported

INFO N/A 57041 SSL Perfect Forward Secrecy Cipher Suites Supported

INFO N/A 22964 Service Detection

INFO N/A 42822 Strict Transport Security (STS) Detection

INFO N/A 136318 TLS Version 1.2 Protocol Detection

INFO N/A 138330 TLS Version 1.3 Protocol Detection

INFO N/A 56468 Time of Last System Startup

INFO N/A 20301 VMware ESX/GSX Server detection