In general everyday usage, Cryptography is the act or art of writing in secret characters. In technical jargon it may be defined as the science of using mathematics to encrypt and decrypt data.
Cryptanalysis is the study of how to compromise (defeat) cryptographic mechanisms. It is the science of cracking code, decoding secrets, violating authentication schemes, and generally breaking cryptographic protocols.
Cryptology is the discipline of cryptography and cryptanalysis combined. Cryptology is the branch of mathematics that studies the mathematical foundations of cryptographic methods.
Encryption transforms data into nearly impossible form to read without the appropriate knowledge (e.g., a key). Its purpose is to ensure privacy by keeping information hidden from anyone for whom it is not intended.
A method of encryption and decryption is called a cipher.
Hash Functions (Digest algorithms)
Cryptographic hash functions are used in various contexts, for example to compute the message digest when making a digital signature. A hash function compresses the bits of a message to a fixed-size hash value to distribute the possible messages evenly among the possible hash values. A cryptographic hash function does this in a way that makes it extremely difficult to come up with a message that would hash to a particular hash value. Below are some examples of the best-known and most widely used hash functions.
a) - SHA-1 (Secure Hash Algorithm) -This is a cryptographic hash algorithm published by the United States Government. It produces a 160 bit hash value from an arbitrary length string. It is considered to be very good.
b)- MD5 (Message Digest Algorithm 5) - is a cryptographic hash algorithm developed at RSA Laboratories. It can be used to hash an arbitrary length byte string into a 128 bit value.
It describes a step-by-step problem-solving procedure, especially an established, recursive computational procedure for solving a problem in a finite number of steps. Technically, an algorithm must reach a result after a finite number of steps. The efficiency of an algorithm can be measured as the number of elementary steps it takes to solve the problem. There are two classes of key-based algorithms. They are:
a) -- Symmetric Encryption Algorithms (secret-key)
Symmetric algorithms use the same key for encryption and decryption (or the decryption key is easily derived from the encryption key). Secret key algorithms use the same key for both encryption and decryption (or one is easily derivable from the other). This is the more straightforward approach to data encryption, it is mathematically less complicated than public-key cryptography. Symmetric algorithms can be divided into stream ciphers and block ciphers. Stream ciphers can encrypt a single bit of plaintext at a time, whereas block ciphers take several bits (typically 64 bits in modern ciphers), and encrypt them as a single unit. Symmetric algorithms are much faster to execute on a computer than asymmetric ones.
Examples of symmetric algorithms are: AES, 3DES, Blowfish, CAST5, IDEA and Twofish.
b) -- Asymmetric algorithms (Public-key algorithms)
Asymmetric algorithms on the other hand use a different key for encryption and decryption, and the decryption key cannot be derived from the encryption key. Asymmetric ciphers permit the encryption key to be public, allowing anyone to encrypt with the key, whereas only the proper recipient (who knows the decryption key) can decrypt the message. The encryption key is also called the public key, and the decryption key is the private or secret key.
RSA is probably the best-known asymmetric encryption algorithm.
A digital signature binds a document to the owner of a particular key.
The digital signature of a document is a piece of information based on both the document and the signer's private key. It is typically created through a hash function and a private signing function (encrypting with the signer's private key). A digital signature is a small amount of data created using some secret key, and a public key that can be used to verify that the signature was generated using the corresponding private key.
Several methods for making and verifying digital signatures are freely available, but the RSA public-key algorithm is the most widely known.
Cryptography works on many levels. On one level you have algorithms, such as block ciphers and public key cryptosystems. Building upon these, you obtain protocols, and upon protocols, you find applications (or other protocols). Below is a list of typical everyday applications that use cryptographic protocols. These protocols are built on lower level cryptographic algorithms.
i.) Domain Name Server Security (DNSSEC)
This is a protocol for secure distributed name services. It is currently available as an Internet Draft.
ii.) Secure Socket Layer (SSL)
SSL is one of the two protocols used for secure WWW connections (the other is SHTTP). WWW security has become necessary as increasing amounts of sensitive information, such as credit card numbers, are transmitted over the Internet.
iii.) Secure Hypertext Transfer Protocol (SHTTP)
This is another protocol for providing more security for WWW transactions.
iv.) E-Mail security and related services
GnuPG - The GNU Privacy Guard - complies with the proposed OpenPGP Internet standard described in RFC2440.
v.) SSH2 Protocol
This protocol is versatile for the needs of the internet, and is currently used in the SSH2 software. The protocol is used to secure terminal sessions and TCP connections.
The following exercises examine two applications that use cryptographic protocols - GnuPG and OpenSSH.
GnuPG (GNU Privacy Guard) is a set of programs for public key encryption and digital signatures. The tools can be used to encrypt data and to create digital signatures. It also includes an advanced key management facility. GnuPG uses public-key cryptography to enable users to communicate securely.
Perform the following exercises as a regular user. e.g. user ying
Ensure that the GnuPG package is installed on your system. Type:
[ying@serverXYying]$rpm-qgnupg
gnupg-*.*
If it isn’t, get the superuser to install it.
List and make a note of all the hidden directories in your home directory.
List the keys you currently have in your keyring. Type:
[ying@serverXYying]$gpg--list-keys
Note
You shouldn’t have any keys in your key-ring yet. But the above command will also help create a default environment to enable you create a new key-pair successfully the first time.
Lab task:
List the hidden directories in your home directory again. What is the name of the new directory added?
Use the gpg program to create your new key-pairs. Type:
At the prompt for the type of key you want to create, accept the default, i.e.(DSA and ElGamal). Type 1
Warning
Option (1) will create two key-pairs for you. The DSA key-pair will be the primary key pair - for making digital signatures and a subordinate ELGamel key pair for data encryption.
You will create an ELG-E key size of 1024. Accept the default again at the prompt below:
The whole point of all this encrypting, signing and decrypting business is because people wish to communicate with one another - but they also wish to do so in as secure a manner as possible.
With that said - the perhaps not to so obvious has to be stated:
You must exchange public keys to communicate with other people using a public-key-based cryptosystem.
Or at least make your public key available in any publicly accessible place (billboards, web pages, key servers, radio, T.V, SPAMMING via e-mail ..etc)
Creating and verifying signatures uses the public/private key pair, which differs from encryption and decryption. Using the private key of the signer to create a signature, facilitates verification using the corresponding public key.
Create a file named “secret-file.txt” with the text “Hello All” in it. Type:
[ying@serverXYying]$echo"Hello All">secret1.txt
Use cat to view the contents of the file. Use the file command to see the kind of file it is.
Now sign the file with your digital signature. Type:
[ying@serverXYying]$gpg-ssecret1.txt
Input your passphrase when prompted.
The above command will create another file “secret1.txt.gpg” which is compressed and has a signature attached to it. Run the “file” command on the file to check this. View the file with cat
Check the signature on the signed “secret1.txt.gpg” file. Type:
[ying@serverXYying]$gpg--verifysecret1.txt.gpg
gpg:SignaturemadeThu16Oct200307:29:37AMPDTusingDSAkeyID1D12E484
gpg:Goodsignaturefrom"Ying Yang (my test) <ying@serverXY>"
Create another file secret2.txt with the text “ Hello All” in it.
Sign the secret2.txt file, but let the file be ASCII armored this time. Type:
[ying@serverXYying]$gpg-sasecret2.txt
An ASCII armored file called “secret2.txt.asc” will be created in your pwd.
Use the cat command to view the contents of the ASCII armored file created for you above.
Create another file called “secret3.txt” with the text “hello dude” in it. Type:
[ying@serverXYyingecho"hello dude">secret3.txt
Append your signature to the body of the file you created above. Type:
[ying@serverXYying]$gpg--clearsignsecret3.txt
This will create an uncompressed file (secret3.txt.asc) that is wrapped in your ASCII-armored signature.
Write down the command to verify the file's signature created for you.
Open up the file to view its contents with any pager.
Question
Can you read the text you entered into the file?
Read Before Continuing
Ensure that your partner has performed all of “Exercises 1, 2, and 3” above before you continue to Exercise 4 below.
If you don't have a partner, log off user Ying's account and log into the system as the user "me."
Then repeat the whole of "Exercises 1, 2, and 3" as the user "me."
You may then perform exercise 4 below. Replace all references to the user Ying at "serverPR" with user "me" at ServerXY (i.e. your localhost).
You can use either user "me@serverXY" or user "ying@serverPR" as your partner in the next exercise.
While logged into the system as the user ying, create a file called encrypt-sec.txt. Type:
[ying@serverXYying]$echo"hello">encrypt-sec.txt
Ensure you can read the contents of the file using cat.
Encrypt the file encrypt-sec.txt, such that only the user “me” can view the file. i.e. you will encrypt it using me@serverXY’s public key ( which you now have in your key-ring). Type:
The file you encrypted above was meant for me@serverXY.
Try to decrypt the file. Type:
[ying@serverXYying]$gpg--decryptencrypt-sec.txt.gpg
gpg:encryptedwith1024-bitELG-Ekey,IDFD20DBF1,created2003-10-16
"Me Mao (my test) <me@serverXY>"
gpg:decryptionfailed:secretkeynotavailable
Have we learned any valuable lesson here?
Make the encrypted file you created available to the correct owner and have them run the above command to decrypt the file. Were they more successful in decrypting the file.
Note
Be very careful when decrypting binary files ( e.g. programs) because after successfully decrypting a file gpg will attempt to send the file's contents to standard output.
Make a habit of using the command below instead when decrypting files:
OpenSSH is OpenBSD's SSH (Secure SHell) protocol implementation.
It is a FREE version of the SSH protocol suite of network connectivity tools. OpenSSH encrypts all traffic (including passwords) to effectively eliminate eavesdropping, connection hijacking, and other network-level attacks. Additionally, OpenSSH provides a plethora of secure tunneling capabilities, as well as a variety of authentication methods.
It helps to provide secure encrypted communications between two untrusted hosts over an insecure network (such as the internet).
It includes both the server-side components and the client-side suite of programs.
The server side includes the secure shell daemon (sshd). sshd is the daemon that listens for connections from clients.
It forks a new daemon for each incoming connection. The forked daemons handle key exchange, encryption, authentication, command execution, and data exchange. According to sshd’s man page, sshd works as follows:
The OpenSSH SSH daemon supports SSH protocol 2 only. Each host has a host-specific key, used to identify the host. Whenever a client connects, the daemon responds with its public host key. The client compares the host key against its database to verify that it has not changed. Forward security is provided through a Diffie-Hellman key agreement. This key agreement results in a shared session key. The rest of the session is encrypted using a symmetric cipher.
The client selects the encryption algorithm from those offered by the server. Additionally, session integrity is provided through a cryptographic message authentication code (hmac-md5, hmac-sha1, umac-64, umac-128, hmac-sha2-256 or hmac-sha2-512).
Finally, the server and the client enter an authentication dialog. The client tries to authenticate itself using host-based authentication, public key authentication, GSSAPI authentication, challenge-response authentication, or password authentication.
The SSH2 protocol implemented in OpenSSH is standardized by the “IETF secsh” working group.
The client's suite of programs includes ssh. This is a program used for logging into remote systems and can also be used for executing commands on remote systems.
Most Linux systems out of the box already have the OpenSSH server configured and running with some defaults. The configuration file for sshd typically resides under /etc/ssh/ and is named sshd_config.
Open up the SSH server’s configuration file with any pager and study it. Type:
[root@serverXYroot]# less /etc/ssh/sshd_config
Note
sshd_config is a rather odd configuration file. Unlike other Linux config files - comments (#) in the sshd_config file denotes the options' default values. (i.e. comments represents already compiled-in defaults.)
Your SSH server already has host keys that it uses. Those keys were generated when your system was first installed. In this exercise, you will learn how to create host-type keys for your server, but you wont use the keys.
Ensure you are still logged in as the user me on serverXY.
Create a directory under your home directory called myimport and cd to the directory.
Use scp to copy over all the files under the “/home/me/myexport/” directory on the remote serverPR.
(the dot "." at the end of the command is important). Type:
Use ls -alR command to view a listing of the contents of the 2 previous steps. Type:
[me@localhost~myimport]# ls -al ying_home_directory_on_serverPR/
Question
Provide a brief explanation for the output of the ls -alR command? Explain for example why you seem to have duplicates of the these files .bash_history, .bashrc ...
Every user who wants to use SSH with RSA or DSA authentication needs a pair of public and private keys. The ssh-keygen program can be used to create these keys ( just as it was used earlier when you created new host keys for your system)
Tip
One main difference between host and user keys is that it is highly recommended to protect user keys with a passphrase. The passphrase is a password used for encrypting the [plain text] private key.
The public is stored in a file with the same file name as the private key but with the extension “.pub” appended to it. There is no easy way to recover a lost passphrase. A new key must be generated if the passphrase is lost or forgotten.
To create user public/private authentication keys¶
Log into your local machine as the user ying.
Run the ssh-keygen program to create a “dsa” type key with the default length. Type:
After successful completion, you'll see a message stating that your identification and public keys have been saved under the /home/ying/.ssh/ directory.
cd to your ~/.ssh/ directory. List the files in the directory.
What is the ssh-keygen command to view the fingerprint of your keys?
Use the cat command to view the contents of your public-key file (i.e. ~/.ssh/id_dsa.pub).
a. cat he contents of your dsa public-key file, and pipe/send ( | ) the output to the ssh ying@serverPR
b. run the command “cd ~/.ssh && cat - >> authorized_keys && chmod 600 authorized_keys” as the user ying on serverPR.
Note
The purpose of the previous complicated looking command is to copy and append the contents of your public-key file to the “/home/ying/.ssh/authorized_keys” on serverPR and give it the correct permissions.
Tip
You can use the ssh-copy-id utility to easily and more gracefully setup public/private key authentication between systems. ssh-copy-id is a script that uses ssh to log into a remote machine (presumably initially using a login password.
It assembles a list of one or more fingerprints (as described below) and tries to log in with each key, to see if any of them are already installed. It then assembles a list of those that failed to log in, and using ssh, enables logins with those keys on the remote system. By default it adds the keys by appending them to the remote user's ~/.ssh/authorized_keys (creating the file, and directory, if necessary).
After you have added your public-key to the authorized_keys file on the remote system. Attempt to login to serverPR as ying via ssh. Type:
Notice that, you are being prompted for your passphrase this time instead of the user password. Enter the passphrase you created earlier when you created your keys.
After successfully logging into serverPR; Log back out.
According to the man page - ssh-agent is a program to hold private keys used for public key authentication (RSA, DSA, ECDSA, Ed25519). The idea is that ssh-agent is started at the beginning of a user or login session, and all other windows or programs are started as clients to the ssh-agent program. Through the use of environment variables the agent can be located and automatically used for authentication when logging into other machines using ssh.
In this exercise you will learn how to configure the agent so that you wont have to type in your passphrase every time you want to connect to another system using public-key authentication.
Ensure you are logged into your local system as the user ying.
Type in the command below:
[ying@localhost~]$eval`ssh-agent`
Agentpid6354
Take note of the value of the process ID (PID) of the agent in your output.
Run the ssh-add program to list the fingerprints of all [public/private] identities currently represented by the agent. Type:
Now as the user ying, try connecting remotely to serverPR and run a simple test command.
Assuming you've done everything correctly till this point regarding setting up and storing the relevant keys, has done correctly till this point you should NOT be prompted for a password or passphrase. Type:
[ying@serverXY.ssh]$sshserverPR'ls /tmp'
If you are done and no longer in need of the services of the ssh-agent or you simply want to revert back to key based authentication you can delete all the [private/public] identities from the agent. Type: