Number Theory and

Cryptography Assignment

CS-4021
Yash Mograi
M140368CA
MCA SEMESTER III

Cryptography in history is interesting, cryptography in theory is fun, practice is

important. And hard.

GNU Privacy Guard

GnuPG was initially developed by Werner Koch. Version 1.0.0, which was the first
production version, was released on September 7, 1999, almost two years after the first
GnuPG release (version 0.0.0). The German Federal Ministry of Economics and Technology
funded the documentation and the port to Microsoft Windows in 2000. GnuPG is a
complete and free implementation of the OpenPGP standard as defined by RFC4880 (also
known as PGP). PGP stands for Pretty Good Privacy. GnuPG allows to encrypt and sign your
data and communication, features a versatile key management system as well as access
modules for all kinds of public key directories. GnuPG, also known as GPG, is a command
line tool with features for easy integration with other applications.
GnuPG is Free Software (meaning that it respects your freedom). GNU is a recursive
acronym for "GNU's Not Unix!", chosen because GNU's design is Unix-like, but differs from
Unix by being free software and containing no Unix code. It can be freely used, modified and
distributed under the terms of the GNU General Public License. Any one is can modify the
software and use it. Here RFC4880 is the document which was made by Network Working
Group of the Internet Engineering Task Force (IETF) during which specifies OpenPGP
message format. This document is maintained in order to publish all necessary information
needed to develop interoperable applications based on the OpenPGP format. It is not a
step-by-step cookbook for writing an application. It describes only the format and methods
needed to read, check, generate, and write conforming packets crossing any network. It
does not deal with storage and implementation questions. It does, however, discuss
implementation issues necessary to avoid security flaws. OpenPGP software uses a
combination of strong public-key and symmetric cryptography to provide security services
for electronic communications and data storage. These services include confidentiality, key
management, authentication, and digital signatures. This document specifies the message
formats used in OpenPGP.

RFC 4880 OpenPGP

OpenPGP was first created by Phil Zimmermann in 1991. The RFC4880 document provides
information on the message-exchange packet formats used by OpenPGP to provide
encryption, decryption, signing and key management functions. It is a revision of RFC 2440,
OpenPGP Message Format", which itself replaces RFC 1991, "PGP Message Exchange
Formats" [RFC1991] [RFC2440].
OpenPGP provides data integrity services for messages and data files by using these core
technologies:

Digital signatures

Encryption

Compression

Radix-64 conversion

In addition, OpenPGP provides key management and certificate services.

Confidentiality via Encryption

OpenPGP combines symmetric-key encryption and public-key encryption to provide
confidentiality. When made confidential, first the object is encrypted using a
symmetric encryption algorithm. Each symmetric key is used only once, for a single
object. A new "session key" is generated as a random number for each object
(sometimes referred to as a session). Since it is used only once, the session key is
bound to the message and transmitted with it. To protect the key, it is encrypted
with the receiver's public key. The sequence is as follows:
1. The sender creates a message.
2. The sending OpenPGP generates a random number to be used as a
session key for this message only.

3. The session key is encrypted using each recipient's public key. These
"encrypted session keys" start the message.
4. The sending OpenPGP encrypts the message using the session key,
which forms the remainder of the message. Note that the message is
also usually compressed.
5. The receiving OpenPGP decrypts the session key using the recipient's
private key.
6. The receiving OpenPGP decrypts the message using the session key. If
the message was compressed, it will be decompressed.
With symmetric-key encryption, an object may be encrypted with a symmetric key derived
from a passphrase (or other shared secret), or a two-stage mechanism similar to the publickey method described above in which a session key is itself encrypted with a symmetric
algorithm keyed from a shared secret. Both digital signature and confidentiality services
may be applied to the same message. First, a signature is generated for the message and
attached to the message. Then the message plus signature is encrypted using a symmetric
session key. Finally, the session key is encrypted using public-key encryption and prefixed to
the encrypted block.

Authentication via Digital Signature

The digital signature uses a hash code or message digest algorithm,
and a public-key signature algorithm. The sequence is as follows:
1. The sender creates a message.
2. The sending software generates a hash code of the message.
3. The sending software generates a signature from the hash code
using the sender's private key.
4. The binary signature is attached to the message.
5. The receiving software keeps a copy of the message signature.
6. The receiving software generates a new hash code for the received
message and verifies it using the message's signature. If the
verification is successful, the message is accepted as authentic.
4

 Compression
OpenPGP implementations SHOULD compress the message after applying
the signature but before encryption. If an implementation does not implement
compression, its authors should be aware that most OpenPGP messages in
the world are compressed. Thus, it may even be wise for a space-constrained
implementation to implement decompression, but not compression.
Furthermore, compression has the added side effect that some types of
attacks can be thwarted by the fact that slightly altered, compressed
data rarely uncompresses without severe errors. This is hardly rigorous, but it is
operationally useful. These attacks can be rigorously prevented by implementing
and using Modification Detection Codes.

Conversion to Radix -64

OpenPGP's underlying native representation for encrypted messages, signature
certificates, and keys is a stream of arbitrary octets. Some systems only permit the
use of blocks consisting of seven-bit, printable text. For transporting OpenPGP's
native raw binary octets through channels that are not safe to raw binary data, a
printable encoding of these binary octets is needed. OpenPGP provides the
service of converting the raw 8-bit binary octet stream to a stream of printable
ASCII characters, called Radix-64 encoding or ASCII Armor.

User Level features of GPG

GnuPG itself is a command line tool without any graphical stuff. It is the real crypto engine
which can be used directly from a command prompt, from shell scripts or by other
programs. Applications, frontends and browser extensions that support GPG are :
Claws mail an email client with GPG plugin
Enigform a Firefox extension
Enigmail a Mozilla Thunderbird plug-in
FireGPG a Firefox extension (discontinued)
Gpg4win a Windows package with tools and manuals for email and
file encryption
GPGMail an OS X Mail.app plug-in
GPGServices an OS X Services Menu plug-in
GPGTools an OS X package with tools for email and file encryption
(incl. GPGMail, GPG Keychain Access, MacGPG2, GPG Services, ...)
KGPG a KDE graphical frontend for GnuPGM
Cabber a Jabber client
Mutt an email client with PGP/GPG support built-in
Psi (instant messaging client)
WinPT a graphical frontend to GPG for Windows.

User Level Features of GPG

The user features of the GPG are:
1. Key Algorithm In this user can select the type of key the key he or she wants.
The algo parameter in the dump identifies the encryption algorithm associated
with the key packet. The list of required and possible algorithms is listed in the
Constants section of the RFC (RFC4880-9.1). That section states that DSA (for
signing) and Elgamal (for encryption) can be expected to be the most available
across implementations and versions. The length of the key is important. Preferred is
4096 bits, based on the current recommendation from Debian. For e.g.

2. Dates and Expiration The dates are specified in the key certificate as Unix
epochs i.e. number of seconds that have elapsed since 00:00:00 Coordinated
Universal Time. The expires value of 0 means that the key itself has no expiration
date.For e.g.
Unix Epochs
Actual Date obtained from Unix Epochs.

3. Compatibility with the old PGP There are certain difficulties in using GnuPG
to communicate with people who are still using PGP 2.x. First and foremost, GnuPG
does not support the IDEA cipher, which is an essential component of PGP 2.x. This is
a deliberate omission. The IDEA cipher is patented by the Swiss company AscomTech AG. Later provisions were made to ensure compatibility.
4. Importing and generating keys - Public and secret keys are required in order to
use GnuPG for secure email. These keys are stored in two files called public and
secret keyrings. If you are already a user of any version of PGP, you can import your
existing keyrings into GnuPG. To import a public keyring, use the command
gpg --import <keyfile> where <keyfile> denotes the filename of the keyring file. If
this keyring file is not in your currently selected directory, you will need to specify its
full pathname. The same command can be used to import a public key sent to you by
another user of PGP or GnuPG. When importing keys, GnuPG behaves differently
from PGP in at least two respects. First, in its default mode of operation GnuPG will
not import keys which are not self-signed. Second, contrary to what an experienced
PGP user might expect, the simple command "gpg <keyfile>" does not offer the
option of adding any keys to your keyring; it is essential to use the "import"
command as above. A somewhat more complex command is required to import a
secret keyring: gpg --allow-secret-key-import --import <keyfile>Note the use of
double dashes in GnuPG commands, in contrast to PGP, which uses only single
dashes. However, certain GnuPG commands have standard single-letter
abbreviations, which are preceded by only a single dash. For example, you can
obtain a list of all the main commands by typing "gpg --help" or, in abbreviated form,
8

"gpg -h". If you have not previously used any version of PGP, you will need to
generate new keys. To do this, enter the command gpg --gen-key. GnuPG will then
offer a choice of several options. It is recommended that you select the default
option ("DSA and ElGamal") for the key types, unless you have a special reason for
some other choice. To ensure high security for the foreseeable future, you should
choose a reasonably large key size. GnuPG will also ask for your name and e-mail
address, which together form a user ID to identify your key. Even if you already have
an RSA key pair from previous use of PGP, it is still highly desirable to generate new
keys as described above, since RSA keys are deprecated in GnuPG and in some later
versions of PGP.
5. Listing your keys - You can view basic details of any particular key in your public
keyring by typing the command gpg --list-keys <name> where <name> is the user ID
of the key, or (more conveniently) any substring of it which specifies it uniquely.
6. Receiving Encrypted messages - If other users of PGP or GnuPG are to send you
encrypted messages, they must have your public key in their keyrings. If you have
just generated a new key, you can extract it into a file by means of the command
gpg --export -o <keyfile> <name> where <keyfile> is the filename of the output file
into which you want the public key to be extracted, and <name> specifies the key as
described above. You can then send the keyfile to other users who want to
communicate with you.
7. Sending Encrypted messages - Before you can encrypt a message for someone
else, that person's public key must be in your public keyring. If you receive
someone's public key, you can add it to your public keyring by means of the "import"
command described earlier. To encrypt a file for someone, use the command gpg -e r <name> <file> where <name> specifies the user ID of the intended recipient's key,
and <file> is the filename. It is also possible to encrypt a file simultaneously for any
number of multiple recipients by means of a command of the form gpg -e -r
<name1> -r <name2> ... <file> To add a digital signature to an encrypted message,
simply replace the "-e" by "-se" in the encryption command. In this case, GnuPG will
ask for your passphrase for accessing your secret key.
9

Usage Examples:
gpg -se -r Bob file
sign and encrypt for user Bob

gpg clearsign file

make a clear text signature

gpg -sb file

make a detached signature

gpg -u 0x12345678 -sb file

make a detached signature with the key 0x12345678

gpg list-keys user_ID

show keys

gpg fingerprint user_ID

show fingerprint

gpg verify pgpfile

gpg verify sigfile
Verify the signature of the file but do not output the data. The second form is used for
detached signatures, where sigfile is the detached signature (either ASCII armored or binary)
and are the signed data; if this is not given, the name of the file holding the signed data is
constructed by cutting off the extension (".asc" or ".sig") of sigfile or by asking the user for
the filename.

Commands not specific to the function

--version
Print the program version and licensing information. Note that you cannot abbreviate this
command.
10

--help
-h
Print a usage message summarizing the most useful command line options. Note that you
cannot abbreviate this command.

--warranty
Print warranty information.

--dump-options
Print a list of all available options and commands. Note that you cannot abbreviate this
command.

Commands to select the type of operation

--sign
-s
Make a signature. This command may be combined with --encrypt (for a signed and
encrypted message), --symmetric (for a signed and symmetrically encrypted message), or -encrypt and --symmetric together (for a signed message that may be decrypted via a secret
key or a passphrase). The key to be used for signing is chosen by default or can be set with
the --local-user and --default-key options.

--clearsign
Make a clear text signature. The content in a clear text signature is readable without any
special software. OpenPGP software is only needed to verify the signature. Clear text
signatures may modify end-of-line whitespace for platform independence and are not
intended to be reversible. The key to be used for signing is chosen by default or can be set
with the --local-user and --default-key options.

11

--detach-sign
-b
Make a detached signature.

--encrypt
-e
Encrypt data. This option may be combined with --sign (for a signed and encrypted
message), --symmetric (for a message that may be decrypted via a secret key or a
passphrase), or --sign and --symmetric together (for a signed message that may be
decrypted via a secret key or a passphrase).

--symmetric
-c
Encrypt with a symmetric cipher using a passphrase. The default symmetric cipher used is
CAST5, but may be chosen with the --cipher-algo option. This option may be combined with
--sign (for a signed and symmetrically encrypted message), --encrypt (for a message that
may be decrypted via a secret key or a passphrase), or --sign and --encrypt together (for a
signed message that may be decrypted via a secret key or a passphrase).

--store
Store only (make a simple RFC1991 literal data packet).

--decrypt
-d
Decrypt the file given on the command line (or STDIN if no file is specified) and write it to
STDOUT (or the file specified with --output). If the decrypted file is signed, the signature is
also verified. This command differs from the default operation, as it never writes to the
filename which is included in the file and it rejects files which dont begin with an encrypted
message.

12

--verify
Assume that the first argument is a signed file or a detached signature and verify it without
generating any output. With no arguments, the signature packet is read from STDIN. If only
a sigfile is given, it may be a complete signature or a detached signature, in which case the
signed stuff is expected in a file without the ".sig" or ".asc" extension. With more than 1
argument, the first should be a detached signature and the remaining files are the signed
stuff. To read the signed stuff from STDIN, use - as the second filename. For security
reasons a detached signature cannot read the signed material from STDIN without denoting
it in the above way.

--multifile
This modifies certain other commands to accept multiple files for processing on the
command line or read from STDIN with each filename on a separate line. This allows for
many files to be processed at once. --multifile may currently be used along with --verify, -encrypt, and --decrypt. Note that --multifile --verify may not be used with detached
signatures.

--verify-files
Identical to --multifile --verify.

--encrypt-files
Identical to --multifile --encrypt.

--decrypt-files
Identical to --multifile --decrypt.

--list-keys
-k
--list-public-keys
List all keys from the public keyrings, or just the keys given on the command line.

--list-secret-keys
13

-K
List all keys from the secret keyrings, or just the ones given on the command line. A # after
the letters sec means that the secret key is not usable (for example, if it was created via -export-secret-subkeys).

--list-sigs
Same as --list-keys, but the signatures are listed too. This command has the same effect as
using --list-keys with --with-sig-list.

For each signature listed, there are several flags in between the "sig" tag and keyid. These
flags give additional information about each signature. From left to right, they are the
numbers 1-3 for certificate check level (see --ask-cert-level), "L" for a local or nonexportable signature (see --lsign-key), "R" for a nonRevocable signature (see the --edit-key
command "nrsign"), "P" for a signature that contains a policy URL (see --cert-policy-url), "N"
for a signature that contains a notation (see --cert-notation), "X" for an eXpired signature
(see --ask-cert-expire), and the numbers 1-9 or "T" for 10 and above to indicate trust
signature levels (see the --edit-key command "tsign").

--check-sigs
Same as --list-sigs, but the signatures are verified. Note that for performance reasons the
revocation status of a signing key is not shown. This command has the same effect as using -list-keys with --with-sig-check.

The status of the verification is indicated by a flag directly following the "sig" tag (and thus
before the flags described above for --list-sigs). A "!" indicates that the signature has been
successfully verified, a "-" denotes a bad signature and a "%" is used if an error occurred
while checking the signature (e.g. a non supported algorithm).

--locate-keys
Locate the keys given as arguments. This command basically uses the same algorithm as
used when locating keys for encryption or signing and may thus be used to see what keys

14

gpg2 might use. In particular external methods as defined by --auto-key-locate may be used
to locate a key. Only public keys are listed.

--fingerprint
List all keys (or the specified ones) along with their fingerprints. This is the same output as -list-keys but with the additional output of a line with the fingerprint. May also be combined
with --list-sigs or --check-sigs. If this command is given twice, the fingerprints of all
secondary keys are listed too.

--list-packets
List only the sequence of packets. This is mainly useful for debugging.

--card-edit
Present a menu to work with a smartcard. The subcommand "help" provides an overview on
available commands.

--card-status
Show the content of the smart card.

--change-pin
Present a menu to allow changing the PIN of a smartcard. This functionality is also available
as the subcommand "passwd" with the --card-edit command.

--delete-key name
Remove key from the public keyring. In batch mode either --yes is required or the key must
be specified by fingerprint. This is a safeguard against accidental deletion of multiple keys.

--delete-secret-key name
Remove key from the secret keyring. In batch mode the key must be specified by
fingerprint.

15

--delete-secret-and-public-key name
Same as --delete-key, but if a secret key exists, it will be removed first. In batch mode the
key must be specified by fingerprint.

--export
Either export all keys from all keyrings (default keyrings and those registered via option -keyring), or if at least one name is given, those of the given name. The exported keys are
written to STDOUT or to the file given with option --output. Use together with --armor to
mail those keys.

--send-keys key IDs

Similar to --export but sends the keys to a keyserver. Fingerprints may be used instead of
key IDs. Option --keyserver must be used to give the name of this keyserver. Dont send
your complete keyring to a keyserver select only those keys which are new or changed by
you. If no key IDs are given, gpg does nothing.

--export-secret-keys
--export-secret-subkeys
Same as --export, but exports the secret keys instead. The exported keys are written to
STDOUT or to the file given with option --output. This command is often used along with the
option --armor to allow easy printing of the key for paper backup; however the external tool
paperkey does a better job for creating backups on paper. Note that exporting a secret key
can be a security risk if the exported keys are send over an insecure channel.

The second form of the command has the special property to render the secret part of the
primary key useless; this is a GNU extension to OpenPGP and other implementations can
not be expected to successfully import such a key. Its intended use is to generated a full key
with an additional signing subkey on a dedicated machine and then using this command to
export the key without the primary key to the main machine.

16

--import
--fast-import
Import/merge keys. This adds the given keys to the keyring. The fast version is currently just
a synonym.

--recv-keys key IDs

Import the keys with the given key IDs from a keyserver. Option --keyserver must be used to
give the name of this keyserver.

--refresh-keys
Request updates from a keyserver for keys that already exist on the local keyring. This is
useful for updating a key with the latest signatures, user IDs, etc. Calling this with no
arguments will refresh the entire keyring. Option --keyserver must be used to give the name
of the keyserver for all keys that do not have preferred keyservers set (see --keyserveroptions honor-keyserver-url).

--search-keys names
Search the keyserver for the given names. Multiple names given here will be joined together
to create the search string for the keyserver. Option --keyserver must be used to give the
name of this keyserver. Keyservers that support different search methods allow using the
syntax specified in "How to specify a user ID" below. Note that different keyserver types
support different search methods. Currently only LDAP supports them all.

--fetch-keys URIs
Retrieve keys located at the specified URIs. Note that different installations of GnuPG may
support different protocols (HTTP, FTP, LDAP, etc.)

--update-trustdb
Do trust database maintenance. This command iterates over all keys and builds the Web of
Trust. This is an interactive command because it may have to ask for the "ownertrust"
values for keys. The user has to give an estimation of how far she trusts the owner of the
17

displayed key to correctly certify (sign) other keys. GnuPG only asks for the ownertrust value
if it has not yet been assigned to a key. Using the --edit-key menu, the assigned value can be
changed at any time.

--check-trustdb
Do trust database maintenance without user interaction. From time to time the trust
database must be updated so that expired keys or signatures and the resulting changes in
the Web of Trust can be tracked. Normally, GnuPG will calculate when this is required and
do it automatically unless --no-auto-check-trustdb is set. This command can be used to force
a trust database check at any time. The processing is identical to that of --update-trustdb
but it skips keys with a not yet defined "ownertrust".

--export-ownertrust
Send the ownertrust values to STDOUT. This is useful for backup purposes as these values
are the only ones which cant be re-created from a corrupted trustdb.

18

Cryptosystems implemented in GPG

1.

Asymmetric key cryptosystems

1.1. Elgamal
1.2. RSA
1.3. DSA

2.

Symmetric key Cryptosystems

2.1. AES
2.2. IDEA
2.3. 3DES
2.4. Blowfish
2.5. Twofish
2.6. CAST5
2.7. Camellia

3.

Hash Cryptosystems

3.1.1. MD5
3.1.2. SHA-1
3.1.3. RIPE-MD-160
3.1.4. TIGER

19

Asymmetric Key Cryptosystems

The basic idea behind asymmetric key cryptosystems are public keys. Each persons key is
separated into two parts: a public key(pk) for encryption available to everyone and a secret
key(sk) for decryption which is kept secret by the owner. Thus public key cryptography is
also known as asymmetric key cryptography.
Suppose Bob has such a key pair (pk, sk) and Alice wants to encrypt a message m for Bob.
Like everyone else, Alice knows Bobs public key pk. She computes the ciphertext c = E(pk,
m) by applying the encryption function E with Bobs public key pk. Encrypting with a fixed
key pk is denoted by Epk, i.e., Epk(m) := E(pk, m). The encryption scheme can only be secure
if it is practically infeasible to compute m from c = Epk(m).

The encryption function Epk must have the property that the pre-image m of the ciphertext
c = Epk(m) is easy to compute using Bobs secret key sk. Since only Bob knows the secret key,
he is the only one who can decrypt the message. Even Alice, who encrypted the message m,
would not be able to get m from Epk(m) if she lost m. Of course, efficient algorithms must
exist to perform encryption and decryption. The algorithm under the public key
cryptography are Elgamal, RSA and DSA.

20

ElGamal Encryption System

In cryptography, the ElGamal encryption system is an asymmetric key encryption algorithm
for public-key cryptography which is based on the DiffieHellman key exchange. It was
described by Taher Elgamal in 1985. ElGamal encryption is used in the free GNU Privacy
Guard software, recent versions of PGP, and other cryptosystems. The Digital Signature
Algorithm is a variant of the ElGamal signature scheme, which should not be confused with
ElGamal encryption. ElGamal encryption can be defined over any cyclic group G. Its security
depends upon the difficulty of a certain problem in G related to computing discrete
logarithms.

Key Generation
The key generator works as follows:
Alice generates an efficient description of a cyclic group G of order q
with generator g.
Alice chooses an x randomly from {1,.,q-1}
Alice computes h:= gX
Alice publishes h, along with the description of (G,q,g) as her public key. Alice
retains x as her private key, which must be kept secret.

Encryption
The encryption algorithm works as follows: to encrypt a message m to Alice under her
public key (G,q,g,h)
Bob chooses a random y from {1,.,q-1}, then calculates c1:=gy.
Bob calculates the shared secret s :=hy.
Bob maps his secret message m onto an element m of G.
Bob calculates c2 :=m.s.

21

 Bob sends the ciphertext (c1,c2) = (gy,m,hy) to Alice.

Note that one can easily find hy if one knows m. Therefore, a new y is generated for every
message to improve security. For this reason, y is also called an ephemeral key.

Decryption
The decryption algorithm works as follows: to decrypt a ciphertext (c1 , c2) with her
private key x1.
Alice calculates the shared secret s :=c1x.
and then computes m :=c2.s-1 which she then converts back into the plaintext
message m, where s-1 is the inverse of s in the group G. (E.g. modular multiplicative
inverse if G is a subgroup of a multiplicative group of integers modulo n).
The decryption algorithm produces the intended message, since
c2.s-1 = m .hy . (gxy)-1 = m . (gxy) . (gxy)-1 = m

Key Size
Elgamal key size can be of any size (greater than 768 bits) in GnuPG. Longer the key size
stronger is the encryption against brute-force attack.

Security
The security of the scheme depends on the following assumption: it is impossible to
compute gxk (and hence gxk = (gxk)1 and m) from gx and gk, which is called the DiffieHellman problem. An efficient algorithm to compute discrete logarithms would solve the
Diffie-Hellman problem. It is unknown whether the Diffie-Hellman problem is equivalent to
computing discrete logarithms, but it is believed that no efficient algorithm exists for this
problem.

22

RSA
RSA Cryptosystems names after Rivest, Shamir and Adleman is the most famous asymmetric
cryptosystem used worldwide. It was introduced in 1977.

Key Generation
Each user Alice of the RSA cryptosystem has her own public and secret keys. The key
generation algorithm proceeds in three steps:
1. Choose large distinct primes p and q, and compute n = pq.
2. Choose e that is prime to (n). The pair (n, e) is published as the public key.
3. Compute d with ed 1 mod (n). The pair (n, d) is used as the secret key.

Encryption and Decryption

We encrypt messages in {0, . . . , n1}, considered as elements of Zn.
The encryption function is defined by,
E : Zn Zn, x xe
The decryption function is of the same type, and is defined by,
D : Zn Zn, x xd
E and D are bijective maps and inverse to each other: E D = D E = idZn .

Security
An adversary knowing the factors p and q of n also knows (n) = (p 1)(q 1), and then
derives d from the public encryption key e using the extended Euclidean algorithm . Thus,
the security of RSA depends on the difficulty of finding the factors p and q of n, if p and q
23

are large primes. It is widely believed that it is impossible today to factor n by an efficient
algorithm if p and q are sufficiently large. This fact is known as the factoring assumption. An
efficient factoring algorithm would break RSA. It is not proven whether factoring is
necessary to decrypt RSA ciphertexts, but it is also believed that inverting the RSA function
is intractable.

Implementation Details
GPG has a default key size of 2048 bit. It supports key sizes of up to 4096 bit.

24

DSA
In 1991 NIST(National Institute of Standards and Technology) proposed a digital signature
standard (DSS). DSS was intended to become a standard digital signature method for use by
government and financial organizations. The DSS contains the digital signature algorithm
(DSA), which is very similar to ElGamals algorithm.

Key Generation
The keys are generated in a similar way as in ElGamals signature scheme. As above, a prime
p, an element g Zp and an exponent x are chosen. x is kept secret, whereas p, g and y = gx
are published. The difference is that g is not a primitive root in Zp, but an element of order
q, where q is a prime divisor of p1. Moreover, the binary size of q is required to be 160 bits.
To generate a public and a secret key, Alice proceeds as follows:
1. She chooses a 160-bit prime q and a prime p, such that q divides p 1 (p should have
the binary length |p| = 512 + 64t, 0 t 8). She can do this in a way analogous to
the key generation in ElGamals encryption scheme. First, she selects q at random,
and then she looks for a prime p in {2kq + 1, 2(k + 1)q + 1, 2(k + 2)q + 1, . . .}, with k a
randomly chosen number of appropriate size.
2. To get an element g of order q, she selects elements h Zp at random until
g := h(p1)/q [1]. Then g has order q, and it generates the unique cyclic group Gq of
order q in Zp. Note that in Gq elements are computed modulo p and exponents are
computed modulo q.
3. Finally, she chooses an integer x in the range 1 x q 1 at random.
4. (p, q, g, x) is the secret key, and the public key is (p, q, g, y), with y := gx.

25

Signing
Messages m to be signed by DSA must be elements in Zq. The signed message is produced
by Alice using the following steps:
1. She selects a random integer k, 1 k q 1.
2. She sets r := (gk mod p) mod q and s := k1(m + rx) mod q. If s = 0, she returns to step
1, but it is extremely unlikely that this occurs.
3. (m, r, s) is the signed message.

Verification
Bob verifies the signed message (m, r, s) as follows:
1. He verifies that 1 r q 1 and 1 s q 1; if not, then he rejects the signature.
2. He computes the inverse t := s1 of s modulo q and v := ((gmyr)t mod p) mod q,
where y is the public key of Alice.
3. The signature is accepted if v = r; otherwise it is rejected.

Implementation Details
DSA-2048 with SHA-224, -256, -384 or -512.
DSA-3072 with SHA-256, SHA-384 or SHA-512.

26

Symmetric Key Cryptosystems

Symmetric-key encryption provides secrecy when two parties, say Alice and Bob,
communicate. An adversary who intercepts a message should not get any significant
information about its content.
To set up a secure communication channel, Alice and Bob first agree on a key k. They keep
their shared key k secret. Before sending a message m to Bob, Alice encrypts m by using
the encryption algorithm E and the key k. She obtains the ciphertext c = E(k, m) and sends
c to Bob. By using the decryption algorithm D and the same key k, Bob decrypts c to
recover the plaintext m = D(k, c).
We speak of symmetric encryption, because both communication partners use the same key
k for encryption and decryption. The encryption and decryption algorithms E and D are
publicly known. Anyone can decrypt a ciphertext, if he or she knows the key. Thus, the key k
has to be kept secret.
A symmetric-key encryption scheme consists of a map
E: K M C
such that for each k K, the map
Ek: M C, m E(k, m)
is invertible. The elements m M are the plaintexts (also called messages). C is the set of
ciphertexts or cryptograms, the elements k K are the keys.
Ek is called the encryption function with respect to the key k. The inverse function
Dk := Ek 1 is called the decryption function. It is assumed that efficient algorithms to
compute Ek and Dk exist.

27

International Data Encryption Algorithm-IDEA

The International Data Encryption Algorithm (IDEA), originally called Improved Proposed
Encryption Standard (IPES), is a symmetric-key block cipher designed by James Massey of
ETH Zurich and Xuejia Lai and was first described in 1991. The algorithm was intended as a
replacement for the Data Encryption Standard (DES). IDEA is a minor revision of an earlier
cipher, Proposed Encryption Standard (PES).
The block cipher IDEA operates with 64-bit plaintext and cipher text blocks and is controlled
by a 128-bit key. The fundamental innovation in the design of this algorithm is the use of
operations from three different algebraic groups. The substitution boxes and the associated
table lookups used in the block ciphers available to-date have been completely avoided. The
algorithm structure has been chosen such that, with the exception that different key subblocks are used, the encryption process is identical to the decryption process.

Key Generation
The 64-bit plaintext block is partitioned into four 16-bit sub-blocks, since all the algebraic
operations used in the encryption process operate on 16-bit numbers. Another process
produces for each of the encryption rounds, six 16-bit key sub-blocks from the
128-bit key. Since a further four 16-bit key-sub-blocks are required for the subsequent
output transformation, a total of 52 (= 8 x 6 + 4) different 16-bit sub-blocks have to be
generated from the 128-bit key.
The 52 16-bit key sub-blocks which are generated from the 128-bit key are produced as
follows:
1. First, the 128-bit key is partitioned into eight 16-bit sub-blocks which are then
directly used as the first eight key sub-blocks.
2. The 128-bit key is then cyclically shifted to the left by 25 positions, after which the
resulting 128-bit block is again partitioned into eight 16-bit sub-blocks to be directly
used as the next eight key sub-blocks.
28

3. The cyclic shift procedure described above is repeated until all of the required 52 16bit key sub-blocks have been generated.

Encryption
The process consists of eight identical encryption steps (known as encryption rounds)
followed by an output transformation.

In the first encryption round, the first four 16-bit key sub-blocks are combined with two of
the 16-bit plaintext blocks using addition modulo 216, and with the other two plaintext
blocks using multiplication modulo 216 + 1. The results are then processed further as shown
in Figure 1, whereby two more 16-bit key sub-blocks enter the calculation and the third
algebraic group operator, the bit-by-bit exclusive OR, is used. At the end of the first
encryption round four 16-bit values are produced which are used as input to the second
encryption round in a partially changed order. The process described above for round one is
repeated in each of the subsequent 7 encryption rounds using different 16-bit key subblocks for each combination. During the subsequent output transformation, the four 16-bit
values produced at the end of the 8th encryption round are combined with the last four of

29

the 52 key sub-blocks using addition modulo 216 and multiplication modulo 216 + 1 to form
the resulting four 16-bit ciphertext blocks.

Decryption
The computational process used for decryption of the ciphertext is essentially the same as
that used for encryption of the plaintext. The only difference compared with encryption is
that during decryption, different 16-bit key sub-blocks are generated.
More precisely, each of the 52 16-bit key sub-blocks used for decryption is the inverse of the
key sub-block used during encryption in respect of the applied algebraic group operation.
Additionally, the key sub-blocks must be used in the reverse order during decryption in
order to reverse the encryption process.

30

3DES Triple DES

Triple DES (3DES) is the common name for the Triple Data Encryption Algorithm (TDEA or
Triple DEA) symmetric-key block cipher, which applies the Data Encryption Standard (DES)
cipher algorithm three times to each data block. 3DES, is made of three DES algorithms
running together with three independent keys.

Encryption
The DES algorithm takes 56-bit keys and 64-bit plaintext messages as inputs and outputs a
64-bit cryptogram:
DES: {0, 1}56 {0, 1}64 {0, 1}64
If the key k is chosen, we get
DESk: {0, 1}64 {0, 1}64, x DES(k, x)
An encryption with DESk consists of 16 major steps, called rounds. In each of the 16 rounds,
a 48-bit round key ki is used. The 16 round keys k1, . . . , k16 are computed from the 56-bit
key.
In the definition of DES, one of the basic building blocks is a map
f: {0, 1}48 {0, 1}32 {0, 1}32
which transforms a 32-bit message block x with a 48-bit round key . f is composed of a
substitution S and a permutation P:
f(, x) = P(S(E(x) )).
The 32 message bits are extended to 48 bits, x E(x) (some of the 32 bits are used twice),
and XORed with the 48-bit round key . The resulting 48 bits are divided into eight groups of
6 bits, and each group is substituted by 4 bits. Thus, we get 32 bits which are then permuted
by P. The cryptographic strength of the DES function depends on the design of f, especially
on the design of the eight famous S-boxes which handle the eight substitutions.
31

Define for i = 1, . . . , 16
i : {0, 1}32 {0, 1}32 {0, 1}32 {0, 1}32, (x, y) (x f(ki, y), y).
i transforms 64-bit blocks and for this transformation, a 64-bit block is split into two 32-bit
halves x and y. We have
i i(x, y) = i(x f(ki, y), y) = (x f(ki, y) f(ki, y), y) = (x, y).
The DESk function is obtained by composing 1, . . . , 16 and the map
: {0, 1}32 {0, 1}32 {0, 1}32 {0, 1}32, (x, y) (y, x),
which interchanges the left and the right half of a 64-bit block (x, y).
Namely,
DESk: {0, 1}64 {0, 1}64,
DESk(x) := IP1 16 15 . . . 2 1 IP(x).
Here, IP is a publicly known permutation without cryptographic significance.

Decryption
For decryption the keys are simply applied in the reverse order.

Implementation Details
Key size: 56 bit each
Block size: 64 bit

32

CAST
Similar to the Data Encryption Standard and other proposed block ciphers, the CAST
algorithm consists of a series of rounds of substitutions in order to achieve the confusion
and diffusion principles suggested by Shannon.

Encryption
The algorithm encrypts by dividing the
N -bit plaintext input block in half. The right half-block, R1, is transformed by a round
function F and then XORed bit-by-bit to the left half-block, L1. The right and left halves are
then swapped. This is repeated for the number of rounds in the cipher . Consequently, the
algorithm may be viewed as the following iterated operation:
Ri+1=F((Ri, Ki) Li
Li+1= Ri
This format is identical to all so-called DES-like ciphers. The novelty of CAST is the round function F.
The round function is implemented using S-boxes of dimension m x n where n = N/2 and m < n.
The example CAST system presented below uses four 8 x 32 S-boxes to implement a 64bit block
cipher. The inputs to the four S-boxes are determined by XORing a 32bit sub-key Ki to the right halfblock and then dividing the half-block into four 8 bit groups. The 32bit outputs of the four S-boxes
are XORed together to produce the output of the function F . Letting Sj (X) represent the 32bit
output of the j -th S-box given an 8bit input X , the operation of the round function may be
represented by
F(Ri , Ki ) = Sj ( Ri(j) Ki(j) )

where Ri(j) is the j-th byte of Ri and Ki(j) is the j-th byte of Ki.

33

Decryption
For decryption the keys are simply applied in the reverse order.

Implementation Details
Key size: 40 -128 bits in increments of 8 bits
Block size: 64 bit

34

Blowfish
Blowfish is a symmetric block cipher that can be effectively used for encryption of data.
It was designed in 1993 by Bruce Schneier as a fast, free alternative to existing
encryption algorithms.
Blowfish algorithm is a Feistel Network, iterating a simple encryption function 16 times.
The block size is 64 bits, and the key can be any length up to 448 bits. Although there is
a complex initialization phase required before any encryption can take place, the actual
encryption of data is very efficient on large microprocessors.
Blowfish is a variable-length key block cipher. It is suitable for applications where the
key does not change often, like a communications link or an automatic file encryptor.

Encryption
Blowfish has 16 rounds. The input is a 64-bit data element, x.
The P-array consists of 18 32-bit subkeys
1. Divide x into two 32-bit halves: xL, xR.
2. Then, for i = 1 to 16:
a. xL = xL XOR Pi
b. xR = F(xL) XOR xR
c. Swap xL and xR
3. After the sixteenth round, swap xL and xR again to undo the last swap.
4. Then, xR = xR XOR P17 and xL = xL XOR P18.
5. Finally, recombine xL and xR to get the ciphertext.

35

Generating the Subkeys

The subkeys are calculated using the Blowfish algorithm:
1. Initialize first the P-array and then the four S-boxes, in order, with a fixed string.
This string consists of the hexadecimal digits of pi (less the initial 3): P1 =
0x243f6a88, P2 = 0x85a308d3, P3 = 0x13198a2e, P4 = 0x03707344, etc.
2. XOR P1 with the first 32 bits of the key, XOR P2 with the second 32-bits of the
key, and so on for all bits of the key (possibly up to P14). Repeatedly cycle
through the key bits until the entire P-array has been XORed with key bits. (For
every short key, there is at least one equivalent longer key; for example, if A is a
64-bit key, then AA, AAA, etc., are equivalent keys.)
3. Encrypt the all-zero string with the Blowfish algorithm, using the subkeys
described in steps (1) and (2). Replace P1 and P2 with the output of step (3).
4. Encrypt the output of step (3) using the Blowfish algorithm with the modified
subkeys.
5. Replace P3 and P4 with the output of step (5).
6. Continue the process, replacing all entries of the P array, and then all four Sboxes in order, with the output of the continuously changing Blowfish algorithm.

Encryption
Decryption is exactly the same as encryption, except that P1, P2,..., P18 are used in the
reverse order.

Implementation Details
Key size: 128 bits by default. Supports variable key length from 32 - 448 bits.
Block size: 64 bit

36

Advanced Encryption Standard

In January 1997, the National Institute of Standards and Technology started an open
selection process for a new encryption standard the advanced encryption standard, or AES
for short. NIST encouraged parties worldwide to submit proposals for the new standard. The
proposals were required to support a block size of at least 128 bits, and three key sizes of
128, 192 and 256 bits.
Three international AES Candidate Conferences were held, and in October 2000 NIST
selected the Rijndael cipher to be the AES.
Rijndael was developed by J. Daemen and V. Rijmen. It is an iterated block cipher and
supports different block and key sizes. Block and key sizes of 128, 160, 192, 224 and 256 bits
can be combined independently.
The only difference between Rijndael and AES is that AES supports only a subset of
Rijndaels block and key sizes. The AES fixes the block length to 128 bits, and uses the three
key lengths 128, 192 and 256 bits.
Rijndael is an iterated block cipher. The iterations are called rounds. The number of rounds,
which we denote by Nr, depends on the block length and the key length. In each round
except the final round, the same round function is applied, each time with a different round
key. The round function of the final round differs slightly. The round keys key1, . . . , keyNr are
derived from the secret key k by using the key schedule algorithm.

Encryption
byteString Rijndael(byteString plaintextBlock, key)
1. InitState(plaintextBlock, state)
2. AddKey(state, key0)
3. for i 1 to Nr 1 do

37

a. SubBytes(state)
b. ShiftRows(state)
c. MixColumns(state)
d. AddKey(state, keyi)
4. SubBytes(state)
5. ShiftRows(state)
6. AddKey(state, keyNr)
7. return state;

The input and output blocks of the Rijndael algorithm are byte strings of 4Nb bytes. In the
beginning, the state matrix is initialized with the plaintext block. The matrix is filled column
by column. The ciphertext is taken from the state matrix after the last round. Here, the
matrix is read column by column.
All steps of the round function SubBytes, ShiftRows, MixColumns, AddKey are invertible.
Therefore, decrypting with Rijndael means to apply the inverse functions of SubBytes,
ShiftRows, MixColumns and AddKey, in the reverse order.
The Round function. We describe now the steps SubBytes, ShiftRows, MixColumns and
AddKey of the round function. The Rijndael algorithm and its steps are byte-oriented. They
operate on the bytes of the state matrix. In Rijndael, bytes are usually considered as
elements of the finite field F28 with 28 elements, and F28 is constructed as an extension of
the field F2 with 2 elements by using the irreducible polynomial X8 + X4 + X3 + X + 1. Then
adding (which is the same as bitwise XORing) and multiplying bytes means to add and
multiply them as elements of the field F28.
The SubBytes Step. SubBytes is the only non-linear transformation of Rijndael. It substitutes
the bytes of the state matrix byte by byte, by applying the function SRD to each element of
the matrix state. The function SRD is also called the S-box; it does not depend on the key. The
38

same S-box is used for all byte positions. The S-box SRD is composed of two maps, f and g.
First f and then g is applied:
SRD(x) = g f(x) = g(f(x)) (x a byte).
Both maps, f and g, have a simple algebraic description. To understand f, consider a
byte x as an element of the finite field F28. Then f simply maps x to its multiplicative
inverse x1.

To understand g, consider a byte x as a vector of 8 bits or, more precisely, as a vector of

length 8 over the field F2 with 2 elements. Then g is the F2-affine map

composed of a linear map x Ax and a transla on with vector b. The matrix A of the
linear map and b are given by

The S-box SRD operates on each of the state bytes of the state matrix independently. For
a block length of 128 bits, we have:

39

Both maps f and g are invertible. We even have f = f 1. Thus the S-box SRD is invertible
and SRD1 = f 1 g1 = f g1.
The ShiftRows Step. The ShiftRows transformation performs a cyclic left shift of the
rows of the state matrix. The offsets are different for each row and depend on the block
length Nb.

ShiftRows is invertible. The inverse operation is obtained by cyclic right shifts with the
same offsets.
The MixColumns Step. The MixColumns transformation operates on each column of the
state matrix independently. We consider a column a = (a0, a1, a2, a3) as a polynomial
a(X) = a3X3 + a2X2 + a1X + a0 of degree 3, with coefficients in F28.
Then MixColumns transforms a column a by multiplying it with the fixed
polynomial
c(X) := 03 X3 + 01 X2 + 01 X + 02
and taking the residue of the product modulo X4 + 1:
a(X) a(X) c(X) mod (X4 + 1).

40

The coefficients of c are elements of F28. Hence, they are represented as bytes, and a
byte is given by two hexadecimal digits, as usual.
The transformations of MixColumns, multiplying by c(X) and taking the residue modulo
X4 + 1, are F28-linear maps. Hence MixColumns is a linear map of vectors of length 4
over F28. It is given by the following 4 4-matrix over F28:

Again, bytes are represented by two hexadecimal digits.

The polynomial c(X) is relatively prime to X4 + 1. Therefore c(X) is a unit modulo
X4 + 1. Its inverse is
d(X) = 0B X3 + 0D X2 + 09 X + 0E,
i.e., c(X)d(X) mod (X4+1) = 1. This implies that MixColumns is invertible. The inverse
operation is to multiply each column of the state matrix by d(X) modulo X4 + 1.
AddKey. The operation AddKey is the only operation in Rijndael that depends on the
secret key k, which is shared by the communication partners.
It adds a round key to the intermediate result state. The round keys are derived from
the secret key k by applying the key schedule algorithm, which is described in the next
section. Round keys are bit strings and, as the intermediate results state, they have
block length, i.e., each round key is a sequence of Nb words. AddKey simply bitwise
XORs the state with the roundkey to get the new value of state:
(state, roundkey) state roundkey.
Since we arrange state as a matrix, a round key is also represented as a round key
matrix of bytes with 4 rows and Nb columns. Each of the Nb words of the round key
41

yields a column. Then the corresponding entries of the state matrix and the round key
matrix are bitwise XORed by AddKey to get the new state matrix. Note that bitwise
XORing two bytes means to add two elements of the field F28.
AddKey is invertible. It is inverse to itself. To invert it, you simply apply AddKey a
second time with the same round key. The Key Schedule. The secret key k consists of Nk
4-byte-words. The Rijndael algorithm needs a round key for each round and one round
key for the initial key addition. Thus we have to generate Nr + 1 round keys (as before,
Nr is the number of rounds). A round key consists of Nb words. If we concatenate all the
round keys, we get a string of Nb(Nr +1) words. We call this string the expanded key.
The expanded key is derived from the secret key k by the key expansion procedure. The
round keys
key0, key1, key2, . . . , keyNr
are then selected from the expanded key ExpKey: key0 consists of the firs Nb words of
ExpKey, key1 consists of the next Nb words of ExpKey, and so on.
To explain the key expansion procedure, we use functions fj, defined for multiples j of
Nk, and a function g. All these functions map words (x0, x1, x2, x3), which each consist of
4 bytes, to words.
g simply applies the S-box SRD to each byte:
(x0, x1, x2, x3) (SRD(x0),SRD(x1),SRD(x2),SRD(x3)).

If j is a multiple of Nk, i.e., j 0 mod Nk, we define fj by

We can now define ExpKey:

42

We have for Nk 6:

If Nk > 6, we have:

Operation modes
Electronic Codebook Mode. The electronic code book mode is the straightforward mode.
The encryption is deterministic identical plaintext blocks result in identical ciphertext
blocks. The encryption works like a codebook. Each block of m is encrypted independently
of the other blocks. Transmission bit errors in a single ciphertext block affect the decryption
only of that block.
In this mode, we have r = n. The electronic codebook mode is implemented by the following
algorithm:
bitString ecbEncrypt(bitString m)
1. divide m into m1 . . . ml
2. for i 1 to l do
a. ci Ek(mi).
3. return c1 . . . cl
43

For decryption, the same algorithm can be used with the decryption function E1k in place
of Ek
Cipher-Block Chaining Mode. In this mode, we have r = n. Encryption in the cipher-block
chaining mode is implemented by the following algorithm:
bitString cbcEncrypt(bitString m)
1. select c0 {0, 1}n at random
2. divide m into m1 . . . ml
3. for i 1 to l do
a. ci Ek(mi ci1)
4. return c0c1 . . . cl
Decryption in cipher-block chaining mode is implemented by the following algorithm:
bitString cbcDecrypt(bitString c)
1. divide c into c0c1 . . . cl
2. for i 1 to l do
a. mi Ek 1(ci) ci1
3. return m1 . . . ml
The cryptogram c = c0c1 . . . cl has one block more than the plaintext.
The initial value c0 needs not be secret, but its integrity must be guaranteed in order to
decrypt c1 correctly.
Cipher Feedback Mode. Let lsbl denote the l least significant (rightmost) bits of a bit string,
msbl the l most significant (leftmost) bits of a bit string, and let || denote the concatenation
of bit strings.
In the cipher feedback mode, we have 1 r n.Let x1 {0,1}n be a randomly chosen initial
value. The cipher feedback mode is implemented by the following algorithm:

44

bitString cfbEnCrypt(bitString m, x1)

1. divide m into m1 . . . ml
2. for i 1 to l do
a. ci mi msbr(Ek(xi))
3. xi+1 lsbnr(xi)||ci
4. return c1 . . . cl
Output Feedback Mode. As in the cipher feedback mode, we have 1 r n.
Let x1 {0, 1}n be a randomly chosen initial value. The output feedback mode is
implemented by the following algorithm:
bitString ofbEnCrypt(bitString m, x1)
1. divide m into m1 . . . ml
2. for i 1 to l do
a. ci mi msbr(Ek(xi))
b. xi+1 Ek(xi)
3. return c1 . . . cl
For decryption, the same algorithm can be used.

Implementation Details
Key sizes: 128, 192, 256 bit
All modes of operation are implemented.

45

TwoFish
In cryptography, Twofish is a symmetric key block cipher with a block size of 128 bits and
key sizes up to 256 bits. It was one of the five finalists of the Advanced Encryption Standard
contest, but it was not selected for standardization. Twofish is related to the earlier block
cipher Blowfish.

Encryption
The basis of the Twofish encryption algorithm is the Feistel structure with 16 rounds and
additional whitening of the input and output.
Before the encryption begins the plaintext is prepared to be encrypted by dividing it into
four 32-bit words. After that they are whitened by XOR-ing them with four key words. This is
followed by sixteen rounds.
1. The two words on the left are used as input to the g functions after the rotation by 8
bits of one of them.
2. The g function consists of four byte-wide key-dependent S-boxes, followed by a
linear mixing step based on an MDS matrix.
3. The results of the two g functions are combined using a Pseudo-Hadamard
Transform (PHT), and two keywords are added.
4. One of the words on the right is rotated by 1 bit and then both of them are XORed in
to the results on the left.
5. The left and right halves are then swapped for the next round.
6. After 16 rounds, the swap of the last round is reversed, and the four words are
XORed with four more key words to produce the ciphertext.

46

The Key-dependent S-boxes: The S-boxes are one of the key design elements of Twofish.
These S-boxes have the following characteristics:
1. They are different one from another.
2. Each is defined with two, three, or four bytes of key material.

47

3. The four S-boxes output four bytes.

4. As they are dependent on half of the key there should be few or no pairs of keys that
result in the same S-boxes.
5. A small change of even 1 bit in the key should lead to extremely different S-boxes.
6. A few or none keys should cause the S-boxes resulted to be weak, which means
that they might have high-probability differential or linear characteristics or even an
simple algebraic representation.
The MDS Matrix: The MDS Matrix is used as the main diffusion mechanism for the four
bytes outputted by the four S-boxes. This is realized by multiplying this output with the MDS
Matrix, which has the following properties:
1. A change in any input byte is guaranteed to change all four output bytes.
2. A change in two input bytes is guaranteed to change at least three output bytes.
3. Preserves the number of bytes changed even after the rotation in the round function
has fixed coefficients.
4. For software implementation the multiplication is implemented using four lookup
tables each containing 256 32-bit words, so that the coefficients used in the matrix
do not affect performance.
5. Twofish does not use the inverse of this matrix for decryption.
6. No row of the matrix is a rotation of another row or column of the matrix.
7. It maximizes the minimum binary Hamming weight of the output differences over all
single-byte input differences.
Pseudo-Hadamard Transformation(PHT): This operation was chosen to produce a fast and
efficient operation on the Pentium CPU family using the LEA(load effective address)
opcodes.

48

To optimize the performance of Twofish a version of the code used for encryption and
decryption can be compiled for any given key and then insert the round subkeys as
constant values in LEA opcodes in the instruction stream.
The alternative to using the PHTs would have been to use eight key dependent S-boxes
instead of four and an 8-by-8 MDS matrix instead of a 4-by-4 one. Although this would have
been easier to analyze and would have had nicer properties, PHTs have been chosen
because the alternative would have been much slower in all implementations of the Twofish
and would not be worth it.
Given two inputs, a and b, the 32-bit PHT is defined as:
a = a + b mod 232
b = a + 2b mod 232

Implementation Details
Key sizes: 128, 192 or 256 bits
Block sizes: 128 bits

49

Camellia
Camellia is a symmetric key block cipher with a block size of 128 bits and key sizes of 128,
192 and 256 bits. It was jointly developed by Mitsubishi and NTT of Japan.
Camellia is a Feistel cipher with either 18 rounds (when using 128-bit keys) or 24 rounds
(when using 192 or 256-bit keys). Every six rounds, a logical transformation layer is applied:
the so-called "FL-function" or its inverse. Camellia uses four 8 8-bit S-boxes with input and
output affine transformations and logical operations. The cipher also uses input and output
key whitening. The diffusion layer uses a linear transformation based on a matrix with a
branch number of 5.

Encryption
In order to encrypt data blocks, one have to create a few helper variables and then subkeys,
based on secret key bits. Each subkey is 64-bit long.
At first, one should calculate two variables of size of 128 bits (KL and KR) and four variables
of size of 64 bits (KLL, KLR, KRL and KRR). The following equations describe connections
between those variables:
KLL = 64 left bits of KL
KLR = 64 right bits of KL
KRL = 64 left bits of KR
KRR = 64 right bits of KR
The rest of connections should be determined based on the length of the secret key K.
For the 128-bit long key:
KL = K
KR = 0
50

For the 192-bit long key:

KL = 128 left bits of K
KRL = 64 right bits of K
KRR = ~ KRR (negation of bits)
For the 256-bit long key:
KL = 128 left bits of K
KR = 128 right bits of K
Then, it is possible to calculate two new helper variables: KA and KB, based on the previous
ones. They are both 128-bit long. KB is nonzero if and only if the secret key consists of 192 or
256 bits. While creating KA and KB one should use six help constant values, which are
referred to as i.
At the end, based on four 128-bit long just created variables KL, KR, KA and KB, one should
compute all secret subkeys of size of 64 bits: ki, kwi and kli. Subkeys are used in all the steps
during encryption and decryption in the Camellia algorithm.

Implementation Details
Key sizes: 128, 192 or 256 bits
Block sizes: 128 bits
Rounds: 18 or 24

51

Hash Cryptosystems
A hash function is a function that takes as input an arbitrarily long string of bits (called a
message) and outputs a bit string of a fixed length n. Mathematically, a hash function is a
function:
h: {0, 1} {0, 1}n, m h(m).
The length n of the output is typically between 128 and 512 bits.
A cryptographic hash function must be a one-way function: Given a value y {0, 1}n, it is
computationally infeasible to find an m with h(m) = y.
They are also useful in cryptography. A cryptographic hash function allows one to easily
verify that some input data maps to a given hash value, but if the input data is unknown, it is
deliberately difficult to reconstruct it (or equivalent alternatives) by knowing the stored
hash value. This is used for assuring integrity of transmitted data, and is the building block
for HMACs, which provide message authentication.

52

MD5
The MD5 message-digest algorithm is a widely used cryptographic hash function producing
a 128-bit (16-byte) hash value, typically expressed in text format as a 32 digit hexadecimal
number. MD5 has been utilized in a wide variety of cryptographic applications, and is also
commonly used to verify data integrity. MD5 was designed by Ronald Rivest in 1991 to
replace an earlier hash function, MD4.
In 1996 a flaw was found in the design of MD5. While it was not deemed a fatal weakness at
the time, cryptographers began recommending the use of other algorithms, such as SHA-1
which has since been found to be vulnerable as well. In 2004 it was shown that MD5 is not
collision resistant. As such, MD5 is not suitable for applications like SSL certificates or digital
signatures that rely on this property for digital security. Also in 2004 more serious flaws
were discovered in MD5, making further use of the algorithm for security purposes
questionable; specifically, a group of researchers described how to create a pair of files that
share the same MD5 checksum. Further advances were made in breaking MD5 in 2005,
2006, and 2007. In December 2008, a group of researchers used this technique to fake SSL
certificate validity. As of 2010, the CMU Software Engineering Institute considers MD5
"cryptographically broken and unsuitable for further use".

Algorithm
1. Add padding bits behind the input message
This step is to elongate the initial message and make its length be congruent to 448
mod 512. First, a single bit 1 is appended to the message. Then, a series of 0 bits
are appended so that
Length(the padded message) 448 mod 512
For example, suppose the initial message has 1000 bits. Then this step will add 1 bit
1 and 471 bits 0. As another example, consider a message with just 448 bits.
Since the algorithm doesnt check whether the initial length is congruent to 448 mod

53

512, one bit 1 and 511 bits 0 will be appended to the message. Therefore, the
padding bits length is at least one and at most 512.

2. Add a 64-bit binary-string which is the representation of the messages length.

The 64-bit binary-string shouldnt be regarded as first 64 bits of the initial message. It
is indeed the binary representation of the length of the initial message. For example,
suppose the message is 1000bits long. Its 64-bit binary representation would be
x00000000000003E8. If the message is very long, greater than 264, only the lower 64
bits of its binary representation are used.
3. Initialize four 32-bit values
These four 32-bit variables would be used to compute the message digest. We
denote them by A, B, C, D. Their initial values are:
A = 0x67452301
B = 0xEFCDAB89
C = 0x98BADCFE
D = 0x10325376
4. Compress every 512-bit block
5. Generate the 128-bit output
There are four rounds and sixteen steps in each round.

54

SHA1 - Secure Hash Algorithm 1

In cryptography, SHA-1 (Secure Hash Algorithm 1) is a cryptographic hash function designed
by the United States National Security Agency and is a U.S. Federal Information Processing
Standard published by the United States NIST. SHA-1 produces a 160-bit (20-byte) hash
value known as a message digest. A SHA-1 hash value is typically rendered as a hexadecimal
number, 40 digits long.

Algorithm
Padding: Given an m-bit message, a single bit 1 is appended as the m + 1th bit and then
(448 (m + 1)) mod 512 (between 0 and 511) zero bits are appended.
As a result, the message becomes 64-bit short of being a multiple of 512 bits long.
Merkle-Damgard Strengthening: Append the length: A 64-bit representation of the original
length of m is appended, making the result a multiple of 512 bits long.
Division into Blocks: The result is divided into 512-bit blocks, denoted by M1, M2, . . . , M
The internal state of SHA-1 is composed of five 32-bit words A, B, C, D and E, used to keep
the 160-bit chaining value hi
Initialization: The initial value (h0) is (in hexadecimal):
A = 67452301x
B = EFCDAB89x
C = 98BADCFEx
D = 10325476x
E = C3D2E1F0x .

55

Compression: For each block, the compression function

hi = H(hi1, Mi)
is applied on the previous value of hi1 = (A, B, C, D, E) and the message block.
Output: The hash value is the 160-bit value
h = (A, B, C, D, E).
1. Divide Mi into 16 32-bit words: W0, W1, W2, . . . , W15.
2. for t = 16 to 79 compute
a. Wt = (Wt3 Wt8 Wt14 Wt16) 1
3. Set (A0, B0, C0, D0, E0) hi1.
4. For t = 0 to 79 do
a. T = At 5 + ft (Bt, Ct, Dt) + Et+ Wt+ Kt
b. Et+t = Dt
c. Dt+1 = Ct
d. Ct+1 = Bt 30
e. Bt+1 = At
f. At+1 = T
5. Output A = A0 + A80, B = B0 + B80, C = C0 + C80, D = D0 + D80, and E = E0 + E80 (modulo
232).

The function ft and the values Kt used above are:

0 t 19: ft (X, Y , Z) = XY (X)Z; Kt = 5A827999
20 t 39: ft (X, Y , Z) = X Y Z; Kt = 6ED9EBA1

56

40 t 59: ft (X, Y , Z) = XY XZ YZ; Kt = 8F1BBCDC

60 t 79: ft (X, Y , Z) = X Y Z; Kt = CA62C1D6

57

RIPEMD-160
RIPEMD (RACE Integrity Primitives Evaluation Message Digest) is a family of cryptographic
hash functions developed in Leuven, Belgium, by Hans Dobbertin, Antoon Bosselaers and
Bart Preneel at the COSIC research group at the Katholieke Universiteit Leuven, and first
published in 1996. RIPEMD was based upon the design principles used in MD4, and is similar
in performance to the more popular SHA-1.

Algorithm
Operations in one step. A := (A + f (B,C,D) + X + K)<<s + E and C := C<<10. Here <<s denotes
cyclic shift (rotation) over s positions.

Ordering of the message words. Take the following permutation p:

Further define the permutation by setting (i) = 9i + 5 (mod 16). The order of the message
words is then given by the following table:

Boolean functions. Define the following Boolean functions:

58

These Boolean functions are applied as follows:

Shifts. For both lines we take the following shifts:

Constants. Take the integer parts of the following numbers:

59

SHA-256,384,512,224
SHA-256 operates in the manner of MD4, MD5, and SHA-1: The message to be hashed is
first
1. padded with its length in such a way that the result is a multiple of 512 bits long, and
then
2. parsed in to 512-bit message blo cks M (1) , M (2) ,, M (N) .
The message blocks are processed one at a time: Beginning with a fixed initial hash value
H(0) , sequentially compute
H (i) = H (i-1) + CM(i) (H (i-1) );
where C is the SHA-256 c ompression function and + means word-wise mod 232 addition.
H(N) is the hash of M .

Description of SHA-256
The SHA-256 compression function op erates on a 512-bit message block and a 256-bit
intermediate hash value. It is essentially a 256-bit block cipher algorithm which encrypts the
in termediate hash value using the message block as key . All of these operators act on 32bit words.
60

The initial hash value H(0) is the following sequence of 32-bit words (which are obtained by
taking the fractional parts of the square ro ots of the first eight primes):

Description of SHA-512
The SHA-512 compression function op erates on a 1024-bit message block and a 512-bit
intermediate hash value. It is essentially a 512-bit block cipher algorithm which encrypts the
in termediate hash value using the message block as key . All of these operators act on 64bit words.
The initial hash value H(0) is the following sequence of 32-bit words (which are obtained by
taking the fractional parts of the square ro ots of the first eight primes):

61

SHA-224 and SHA-384 are simply truncated versions of 256 and 512, computed with different initial
values.

62

TIGER
Tiger is a cryptographic hash function designed by Ross Anderson and Eli Biham in 1995 for
efficiency on 64-bit platforms. The size of a Tiger hash value is 192 bits. Truncated versions
(known as Tiger/128 and Tiger/160) can be used for compatibility with protocols assuming a
particular hash size. Unlike the SHA-2 family, no distinguishing initialization values are
defined; they are simply prefixes of the full Tiger/192 hash value.
Tiger2 is a variant where the message is padded by first appending a byte with the
hexadecimal value of 0x80 as in MD4, MD5 and SHA, rather than with the hexadecimal
value of 0x01 as in the case of Tiger. The two variants are otherwise identical.
Algorithm
Tiger is designed using the nearly universal Merkle-Damgrd paradigm. The one-way
compression function operates on 64-bit words, maintaining 3 words of state and
processing 8 words of data. There are 24 rounds, using a combination of operation mixing
with XOR and addition/subtraction, rotates, and S-box lookups, and a fairly intricate key
scheduling algorithm for deriving 24 round keys from the 8 input words.
Although fast in software, Tiger's large S-boxes (4 S-boxes, each with 256 64-bit entries
totals 8 KiB) make implementations in hardware or small microcontrollers difficult.
Examples
192-bit (24-byte) Tiger hashes are represented as 48 hexadecimal digits in little-endian byte order. The
following demonstrates a 43-byte ASCII input and the corresponding Tiger hashes:

Tiger("The quick brown fox jumps over the lazy dog") =

6d12a41e72e644f017b6f0e2f7b44c6285f06dd5d2c5b075

Tiger2("The quick brown fox jumps over the lazy dog") =

976abff8062a2e9dcea3a1ace966ed9c19cb85558b4976d8

63

Even a small change in the message will (with overwhelming probability) result in a completely different
hash, e.g. changing d to c:

Tiger("The quick brown fox jumps over the lazy cog") =

a8f04b0f7201a0d728101c9d26525b31764a3493fcd8458f

Tiger2("The quick brown fox jumps over the lazy cog") =

09c11330283a27efb51930aa7dc1ec624ff738a8d9bdd3df

The hash of the zero-length string is:

Tiger("") =
3293ac630c13f0245f92bbb1766e16167a4e58492dde73f3

Tiger2("") =
4441be75f6018773c206c22745374b924aa8313fef919f41

64

Compression Techniques
The GNU privacy guard supports the following compression algorithms:
1. ZIP
2. ZLIB
3. ZLIB2

1. ZIP is an archive file format that supports lossless data compression. A .ZIP file may
contain one or more files or directories that may have been compressed. The .ZIP file
format permits a number of compression algorithms, though DEFLATE is the most
common. This format was originally created in 1989 by Phil Katz, and was first
implemented in PKWARE, Inc.'s PKZIP utility, as a replacement for the
previous ARC compression format by Thom Henderson. The .ZIP format is now
supported by many software utilities other than PKZIP. Microsoft has included builtin .ZIP support (under the name "compressed folders") in versions of Microsoft
Windows since 1998.
2. ZLIB is a software library used for data compression. zlib was written by Jean-Loup
Gailly and Mark Adler and is an abstraction of the DEFLATE compression algorithm
used in their gzip file compression program. zlib is also a crucial component of many
software platforms including Linux, Mac OS X, and iOS. It has also been used in
gaming consoles such as the PlayStation 4, PlayStation 3, Wii U, Wii, Xbox One and
Xbox 360.The first public version of zlib, 0.9, was released on 1 May 1995 and was
originally intended for use with the libpng image library. It is free software,
distributed under the zlib license.

65

Flaws in GnuPG
False positive signature verification in GnuPG
Posted on Wed Feb 15 08:49:25 CET 2006 by Werner Koch.
Impact:
Signature verification of detached signatures does not work, thus
modified versions of signature protected files may not be detected. All versions of
gnupg prior to 1.4.2.1 are affected if they are used in certain unattended operation
modes. There is no problem using GnuPG in an interactive way because GnuPG won't
print any signature status at all; i.e. no "Good signature". Scripts and applications
using gpg or gpgv with the --status-fd option and properly parsing this output are not
affected. Applications using the GPGME library are not affected. The GnuPG versions
1.9 are not affected unless the currently deprecated gpg part has been enabled.

Solution:
Update GnuPG as soon as possible to version 1.4.2.1

GnuPG's ElGamal signing keys compromised

Posted on Thu Nov 27 09:29:51 CET 2003 by Werner Koch. Phong Nguyen identified a
severe bug in the way GnuPG creates and uses ElGamal keys for signing.
Impact:
All ElGamal sign+encrypt keys (type 20) generated with GnuPG 1.0.2 or later must be
considered compromised. Keys generated and used only with prior versions might still
be safe but should ideally be revoked too. Note that even if an ElGamal sign+encrypt
key was generated before GnuPG 1.0.2, using that key in GnuPG 1.0.2 or later to issue
signatures will still compromise the key.

66

Solution :
Do not use *ElGamal sign+encrypt keys (type 20)*. Revoke all those keys immediately.
Consider all material signed or encrypted with such a key as compromised.Forthcoming
GnuPG versions will remove the ability to create such keys and the ability create
ElGamal signatures.

GnuPG does not detect injection of unsigned data

Posted on Thu Mar 9 19:53:40 CET 2006 by Werner Koch.
Impact :
Signature verification of non-detached signatures may give a positive result but when
extracting the signed data, this data may be prepended or appended with extra data
not covered by the signature. Thus it is possible for an attacker to take any signed
message and inject extra arbitrary data. Detached signatures (a separate signature file)
are not affected. All versions of GnupPG prior to 1.4.2.2 are affected. Scripts and
applications using gpg to verify the integrity of data are affected. This includes
applications using the GPGME library.
Solution:
Update GnuPG as soon as possible to version 1.4.2.2.

67

Man in the Middle Attack- MITM

In cryptography and computer security, a man-in-the-middle attack (often abbreviated to
MITM, MitM, MIM, MiM or MITMA) is an attack where the attacker secretly relays and
possibly alters the communication between two parties who believe they are directly
communicating with each other. Man-in-the-middle attacks can be thought about through a
chess analogy. Mallory, who barely knows how to play chess, claims that she can play two
grandmasters simultaneously and either win one game or draw both. She waits for the first
grandmaster to make a move and then makes this same move against the second
grandmaster. When the second grandmaster responds, Mallory makes the same play
against the first. She plays the entire game this way and cannot lose using this strategy
unless she runs into difficulty with time because of the slight delay between relaying moves.
A man-in-the-middle attack is a similar strategy and can be used against many cryptographic
protocols. One example of man-in-the-middle attacks is active eavesdropping, in which the
attacker makes independent connections with the victims and relays messages between
them to make them believe they are talking directly to each other over a private connection,
when in fact the entire conversation is controlled by the attacker. The attacker must be able
to intercept all relevant messages passing between the two victims and inject new ones.
This is straightforward in many circumstances; for example, an attacker within reception
range of an unencrypted Wi-Fi wireless access point, can insert himself as a man-in-themiddle.

Receiver
Sender

Man in the Middle

68

As an attack that aims at circumventing mutual authentication, or lack thereof, a man-inthe-middle attack can succeed only when the attacker can impersonate each endpoint to
their satisfaction as expected from the legitimate other end. Most cryptographic protocols
include some form of endpoint authentication specifically to prevent MITM attacks. For
example, TLS can authenticate one or both parties using a mutually trusted certification
authority.
For e.g.
Suppose Alice wishes to communicate with Bob. Meanwhile, Mallory wishes to intercept the
conversation to eavesdrop and optionally deliver a false message to Bob.
First, Alice asks Bob for his public key. If Bob sends his public key to Alice, but Mallory is able
to intercept it, a man-in-the-middle attack can begin. Mallory sends a forged message to
Alice that claims to be from Bob, but instead includes Mallory's public key.
Alice, believing this public key to be Bob's, encrypts her message with Mallory's key and
sends the enciphered message back to Bob. Mallory again intercepts, deciphers the
message using her private key, possibly alters it if she wants, and re-enciphers it using the
public key Bob originally sent to Alice. When Bob receives the newly enciphered message,
he believes it came from Alice.
Alice sends a message to Bob, which is intercepted by Mallory:
Alice "Hi Bob, it's Alice. Give me your key."

Mallory

Bob

Mallory relays this message to Bob; Bob cannot tell it is not really from Alice:
Alice

Mallory "Hi Bob, it's Alice. Give me your key."

Bob

Bob responds with his encryption key:

Alice

Mallory

[Bob's key] Bob

Mallory replaces Bob's key with her own, and relays this to Alice, claiming that it is Bob's
key:
Alice

[Mallory's key] Mallory

Bob
69

Alice encrypts a message with what she believes to be Bob's key, thinking that only Bob can
read it:
Alice "Meet me at the bus stop!" [encrypted with Mallory's key]

Mallory

Bob

However, because it was actually encrypted with Mallory's key, Mallory can decrypt it, read
it, modify it (if desired), re-encrypt with Bob's key, and forward it to Bob:
Alice

Mallory "Meet me in the windowless van on 22nd Ave!" [encrypted with Bob's key]
Bob

Bob thinks that this message is a secure communication from Alice.

70

Different attacks
Local Area Network

ARP Poisoning Address Resolution Protocol Poisoning

DNS Spoofing Domain name system spoofing

STP mangling Spanning tree protocol

Port Stealing

From Local to Remote (Through a gateway)

ARP Poisoning Address Resolution Protocol Poisoning

DNS spoofing Domain name system Poisoning

DHCP spoofing Dynamic Host Configuration Protocol Spoofing

ICMP redirection - Internet Control Message Protocol

IRDP spoofing ICMP Internet Router Discovery Protocol

Route mangling

Remote

DNS poisoning

Traffic tunnelling

Route mangling

71

Common Solutions
All cryptographic systems that are secure against MITM attacks require an additional
exchange or transmission of information over some kind of secure channel. Many key
agreement methods have been developed, with different security requirements for the
secure channel. Interlock Protocol attempts to address this but it was earlier found to be
broken.
Various defenses against MITM attacks use authentication techniques that include:
1. DNSSEC: Secure DNS extensions
2. Public key infrastructures: Transport Layer Security is an example of implementing
public key infrastructure over Transmission Control Protocol. This is used to prevent
Man-in-the-middle attack over a secured HTTP connection on internet. Client and
Server exchange PKI certificates issued and verified by a common certificate
authority.
3. PKI mutual authentication: The main defense in a PKI scenario is mutual
authentication. In this case applications from both client and server mutually
validates their certificates issued by a common root certificate authority. Virtual
Private Networks do mutual authentication before sending data over the created
secure tunnel, however mutual authentication over internet for HTTP connections
are seldom enforced.
4. Certificate pinning
5. A recorded media attestment (assuming that the user's identity can be recognized
from the recording), which can either be:
6. A verbal communication of a shared value for each session (as in ZRTP)
7. An audio/visual communication of the public key hash (which can be easily
distributed via PKI)

72

8. Stronger mutual authentication, such as:

Secret keys (which are usually high information entropy secrets, and thus
more secure), or

Passwords (which are usually low information entropy secrets, and thus less
secure)

9. Latency examination, such as with long cryptographic hash function calculations that
lead into tens of seconds; if both parties take 20 seconds normally, and the
calculation takes 60 seconds to reach each party, this can indicate a third party.
10. Second (secure) channel verification
11. Testing is being carried out on deleting compromised certificates from issuing
authorities on the actual computers and compromised certificates are being
exported to sandbox area before removal for analysis.
The integrity of public keys must generally be assured in some manner, but need not be
secret. Passwords and shared secret keys have the additional secrecy requirement.
Public keys can be verified by a certificate authority, whose public key is distributed
through a secure channel (for example, with a web browser or OS installation). Public
keys can also be verified by a web of trust that distributes public keys through a secure
channel (for example by face-to-face meetings).

73

References
1.

Hans Delfs, Helmut Knebl: Introduction to Cryptography Principles and

Applications, Second Edition, Springer.

2.

RIPEMD-160: A Strengthened Version of RIPEMD: Hans Dobbertin,

Antoon Bosselaers, Bart Preneel, (18 April 1996)

3.

Hash Functions MD5 and SHA1: Orr Dunkelman

4.

Twofish Encryption Algorithm: Horatiu Paul Stancu

5.

International Data Encryption Algorithm: How-Shen Chang

6.

Wikipedia: en.wikipedia.org

7.

Google Images: images.google.com

8.

GNU Privacy Guard: www.gnupg.org

9.

https://en.wikipedia.org/wiki/Man-in-the-middle_attack

10.

RFC4880 OPENPGP http://www.ietf.org/rfc/rfc4880.txt

11.

Man in the middle - https://en.wikipedia.org/wiki/Man-in-the-middle_attack

74