Term Paper

Data Inscription Standard

CAP-104

Dept. Name: Lovely Institute of Management (LIM)

Submitted To: Prof. Rishi Chopra

Submitted by:
Harsharan Kaur
Roll No:RTB012A38
MSc CS 1st Sem
Sec:TB012

Data Inscription Standard

Page 1
 CERTIFICATE

This is to certify that the term paper entitled

“Data encryption standard”

Submitted in partial fulfillment of the requirement for the MSc Computer Science to
Lovely Professional University, Phagwara, is a record of bonafide research work carried out by
Harsharan kaur under my supervision and guidance.

Submitted By:

Harsharan Kaur

RTB012A38

MSc CS

Attested

(H.O.D. IT DEPT)

Certified

Faculty Guide

Data Inscription Standard

Page 2
 ACKNOWLEDGEMENT

I would like to thank all those who have encouraged me to complete

this term paper on the topic "Data Encryption Standards". I am grateful to Rishi Sir who
inspired and encouraged me in making the term project successful. I will never forget his
support and words of wisdom. Because these things would serve as a guideline for making my
career bright and bloom.
I am also thankful to Lovely Professional University in providing me the sources which helped
me to complete this project

Harsharan Kaur

Roll#RTB012A38

Reg#1101388

Data Inscription Standard

Page 3
 CONTENT

 Introduction to DES

 General Applications

 History

 Encryption now a days

 Security problems that encryption doesn’t solve

 Advantages

 Data encryption Challenges

 Screenshots and coding

 References

Data Inscription Standard

Page 4
Introduction to Data Encryption
Many times when data is exchanged electronically the privacy of the data is a requirement. The
use of encryption restricts unintended recipients from viewing the data, which are deemed
confidential and potentially dangerous if made known to irresponsible parties. Today,
encryption is the procedure of transforming plain text, data that can be read by anyone, to
ciphertext, data that can only be read by someone with a secret decryption key.A message
before being changed in any way is called plain text. Plain text messages are converted to
ciphertext via some encryption method. A particular such method is called a cryptosystem.

In 1972, the National Bureau of Standards (NBS), a part of the U.S. Department of Commerce,
initiated a program to develop standards for the protection of computer data. The Institute for
Computer Sciences and Technology (ICST), one of the major operating units of the National
Bureau of Standards, had been recently established in response to a 1965 federal law known as
the Brooks Act (PL89-306) that required new standards for improving utilization of computers
by the federal government. Computer security had been identified by an ICST study as one of
the high-priority areas requiring standards if computers were to be effectively used. A set of
guidelines and standards were defined by the ICST that were to be developed as resources
became available in computer security. The guidelines were to include areas such as physical
security, risk management, contingency planning, and security auditing. Guidelines were
adequate in areas not requiring interoperability among various computers. Standards were
required in areas such as encryption, personal authentication, access control, secure data stor-
age, and transmission because they could affect interoperability.

Standards come in different "flavors": basic, interoperability, interface, and implementation.

Data Inscription Standard

Page 5
1. Basic standards (also called 4'standards of good practice") are used to specify

generic functions (services, methods, results) required to achieve a certain set of

common goals. Examples include standards for purity of chemicals, contents of

food products, and in the computer field, structured programming practices.

2. Interoperability standards specify functions and formats so that data transmitted

from one computer can be properly acted on when received by another computer.

The implementation (hardware, firmware, software) or structure (integrated, iso-

lated, interfaced layers) need not be specified in interoperability standards, since

there is no intent of replacing one implementation or structure within a system

with another.

3. Interface standards specify not only the function and format of data crossing the

interface, but also include physical, electrical, and logical specifications sufficient

to replace one implementation (device, program, component) on either side of the

interface with another.

4. Implementation standards not only specify the interfaces, functions, and formats,

but also the structure and the method of implementation. These may be necessary

to assure that secondary characteristics such as speed, reliability, physical secu-

rity, etc. also meet certain needs. Such standards are often used to permit compo-

nent replacement in an overall system.

Data Inscription Standard

Page 6
General Applications

The basic DES algorithm can be used for both data encryption and data authentication.

1. Data Encryption: It is easy to see how the DES may be used to encrypt a 64-bit plaintext input
to a 64-bit ciphertext output, but data are seldom limited to 64 bits. In order to use DES in a
variety of cryptographic applications, four modes of operation were developed: electronic
codebook (ECB); cipher feedback (CFB); cipher block chaining (CBC); and output feedback (OFB)
[26] (Figs. 1-4). Each mode has its advantages and disadvantages. ECB is excellent for encrypting
keys; CFB is typically used for encrypting individual characters; and OFB is often used for
encrypting satellite communications. Both CBC and CFB can be used to authenticate data. These
modes of operation permit the use of DES for interactive terminal to host encryption, crypto-
graphic key encryption for automated key management applications, file encryption, mail
encryption, satellite data encryption, and other applications. In fact, it is extremely difficult, if
not impossible, to find a cryptographic application where the DES cannotbe applied.

Figure 1: Electronic codebook (ECB) mode.

Data Inscription Standard

Page 7
Figure2: Cipher block chaining (CBC) mode.

Data Inscription Standard

Page 8
Data Inscription Standard
Page 9
Data Inscription Standard
Page 10
History of encryption

In its earliest form, people have been attempting to conceal certain information that they
wanted to keep to their own possession by substituting parts of the information with symbols,
numbers and pictures. Ancient Babylonian merchants used intaglio, a piece of flat stone carved
into a collage of images and some writing to identify themselves in trading transactions. Using
this mechanism, they are producing what today we know as 'digital signature.' The public knew
that a particular 'signature' belonged to this trader, but only he had the intaglio to produce that
signature.

Of course, technology today has evolved at such rapid pace that the need to protect
information grows with the lessening reliability of older encryption techniques. Basic modern
encryption is not much different from the ancient civilisations' substitution using symbols.
Translation table, lends itself very well in making a piece of data generally unreadable. However
computers today are much too advanced that translation table is easily broken and thus no
longer viable. Instead encryption today has grown into such specialised field that involve
mathematical, non-linear cryptosystem that even a relatively powerful computers take months
or even years to break the ciphertext.

The origins of DES go back to the early 1970s. In 1972, after concluding a study on the US
government's computer security needs, the US standards body NBS (National Bureau of
Standards) — now named NIST (National Institute of Standards and Technology) — identified a
need for a government-wide standard for encrypting unclassified, sensitive information. [1]
Accordingly, on 15 May 1973, after consulting with the NSA, NBS solicited proposals for a cipher
that would meet rigorous design criteria. None of the submissions, however, turned out to be
suitable. A second request was issued on 27 August 1974. This time, IBM submitted a candidate
which was deemed acceptable — a cipher developed during the period 1973–1974 based on an
earlier algorithm, Horst Feistel's Lucifer cipher. The team at IBM involved in cipher design and
analysis included Feistel, Walter Tuchman, Don Coppersmith, Alan Konheim, Carl Meyer, Mike
Matyas, Roy Adler, Edna Grossman, Bill Notz, Lynn Smith, and Bryant Tuckerman.

NSA's involvement in the design

On 17 March 1975, the proposed DES was published in the Federal Register. Public comments
were requested, and in the following year two open workshops were held to discuss the
proposed standard. There was some criticism from various parties, including from public-key
cryptography pioneers Martin Hellman and Whitfield Diffie, citing a shortened key length and
the mysterious "S-boxes" as evidence of improper interference from the NSA. The suspicion
was that the algorithm had been covertly weakened by the intelligence agency so that they —

Data Inscription Standard

Page 11
but no-one else — could easily read encrypted messages. [2] Alan Konheim (one of the designers
of DES) commented, "We sent the S-boxes off to Washington. They came back and were all
different."[3] The United States Senate Select Committee on Intelligence reviewed the NSA's
actions to determine whether there had been any improper involvement. In the unclassified
summary of their findings, published in 1978, the Committee wrote:

In the development of DES, NSA convinced IBM that a reduced key size was sufficient; indirectly
assisted in the development of the S-box structures; and certified that the final DES algorithm
was, to the best of their knowledge, free from any statistical or mathematical weakness. [4]

However, it also found that

NSA did not tamper with the design of the algorithm in any way. IBM invented and designed
the algorithm, made all pertinent decisions regarding it, and concurred that the agreed upon
key size was more than adequate for all commercial applications for which the DES was
intended.[5]

Another member of the DES team, Walter Tuchman, stated "We developed the DES algorithm
entirely within IBM using IBMers. The NSA did not dictate a single wire!" [6] In contrast, a
declassified NSA book on cryptologic history states:

In 1973 NBS solicited private industry for a data encryption standard (DES). The first offerings
were disappointing, so NSA began working on its own algorithm. Then Howard Rosenblum,
deputy director for research and engineering, discovered that Walter Tuchman of IBM was
working on a modification to Lucifer for general use. NSA gave Tuchman a clearance and
brought him in to work jointly with the Agency on his Lucifer modification." [7]

and

NSA worked closely with IBM to strengthen the algorithm against all except brute force attacks
and to strengthen substitution tables, called S-boxes. Conversely, NSA tried to convince IBM to
reduce the length of the key from 64 to 48 bits. Ultimately they compromised on a 56-bit key. [8]

Some of the suspicions about hidden weaknesses in the S-boxes were allayed in 1990, with the
independent discovery and open publication by Eli Biham and Adi Shamir of differential
cryptanalysis, a general method for breaking block ciphers. The S-boxes of DES were much
more resistant to the attack than if they had been chosen at random, strongly suggesting that
IBM knew about the technique in the 1970s. This was indeed the case; in 1994, Don
Coppersmith published some of the original design criteria for the S-boxes. [9] According to
Steven Levy, IBM Watson researchers discovered differential cryptanalytic attacks in 1974 and
were asked by the NSA to keep the technique secret. [10] Coppersmith explains IBM's secrecy
decision by saying, "that was because [differential cryptanalysis] can be a very powerful tool,

Data Inscription Standard

Page 12
used against many schemes, and there was concern that such information in the public domain
could adversely affect national security." Levy quotes Walter Tuchman: "[t]hey asked us to
stamp all our documents confidential... We actually put a number on each one and locked them
up in safes, because they were considered U.S. government classified. They said do it. So I did
it". Bruce Schneier observed that "It took the academic community two decades to figure out
that the NSA 'tweaks' actually improved the security of DES."

Encryption Now a Days

Industrial espionage among highly competitive businesses often requires that extensive security
measures be put into place. And, those who wish to exercise their personal freedom, outside of
the oppressive nature of governments, may also wish to encrypt certain information to avoid
legalities that entailed possession of such.

With respect to the Internet, there are many types of data and messages that people would
want to be kept secret. Now that commercial trading on the Net is a reality, one of the main
targets of data encryption is credit card numbers. Other information that could otherwise
benefit or educate a group or individual can also be used against such groups or individuals.

Data Inscription Standard

Page 13
Security Problems That Encryption Does Not Solve
While there are many good reasons to encrypt data, there are many reasons not to encrypt
data. Encryption does not solve all security problems, and may make some problems worse.
The following sections describe some misconceptions about encryption of stored data:

 Principle 1: Encryption Does Not Solve Access Control Problems

 Principle 2: Encryption Does Not Protect Against a Malicious Database Administrator

 Principle 3: Encrypting Everything Does Not Make Data Secure

Principle 1: Encryption Does Not Solve Access Control Problems

Most organizations must limit data access to users who must see this data. For example, a
human resources system may limit employees to viewing only their own employment records,
while allowing managers of employees to see the employment records of subordinates. Human
resource specialists may also need to see employee records for multiple employees.

Typically, you can use access control mechanisms to address security policies that limit data
access to those with a need to see it. Oracle Database has provided strong, independently
evaluated access control mechanisms for many years. It enables access control enforcement to
a fine level of granularity through Virtual Private Database.

Because human resource records are considered sensitive information, it is tempting to think
that all information should be encrypted for better security. However, encryption cannot
enforce granular access control, and it may hinder data access. For example, an employee, his
manager, and a human resources clerk may all need to access an employee record. If all
employee data is encrypted, then all three must be able to access the data in unencrypted
form. Therefore, the employee, the manager and the human resources clerk would have to
share the same encryption key to decrypt the data. Encryption would, therefore, not provide
any additional security in the sense of better access control, and the encryption might hinder
the proper or efficient functioning of the application. An additional issue is that it is difficult to
securely transmit and share encryption keys among multiple users of a system.

A basic principle behind encrypting stored data is that it must not interfere with access control.
For example, a user who has the SELECT privilege on emp should not be limited by the
encryption mechanism from seeing all the data he is otherwise allowed to see. Similarly, there
is little benefit to encrypting part of a table with one key and part of a table with another key if
users must see all encrypted data in the table. In this case, encryption adds to the overhead of
decrypting the data before users can read it. If access controls are implemented well, then
encryption adds little additional security within the database itself. A user who has privileges to

Data Inscription Standard

Page 14
access data within the database has no more nor any less privileges as a result of encryption.
Therefore, you should never use encryption to solve access control problems.

Principle 2: Encryption Does Not Protect Against a Malicious Database

Administrator

Some organizations, concerned that a malicious user might gain elevated (database
administrator) privileges by guessing a password, like the idea of encrypting stored data to
protect against this threat. However, the correct solution to this problem is to protect the
database administrator account, and to change default passwords for other privileged
accounts. The easiest way to break into a database is by using a default password for a
privileged account that an administrator allowed to remain unchanged. One example is
SYS/CHANGE_ON_INSTALL.

While there are many destructive things a malicious user can do to a database after gaining the
DBA privilege, encryption will not protect against many of them. Examples include corrupting or
deleting data, exporting user data to the file system to e-mail the data back to himself to run a
password cracker on it, and so on.

Some organizations are concerned that database administrators, typically having all privileges,
are able to see all data in the database. These organizations feel that the database
administrators should administer the database, but should not be able to see the data that the
database contains. Some organizations are also concerned about concentrating so much
privilege in one person, and would prefer to partition the DBA function, or enforce two-person
access rules.

It is tempting to think that encrypting all data (or significant amounts of data) will solve these
problems, but there are better ways to protect against these threats. For example, Oracle
Database supports limited partitioning of DBA privileges. Oracle Database provides native
support for SYSDBA and SYSOPER users. SYSDBA has all privileges, but SYSOPER has a limited
privilege set (such as startup and shutdown of the database).

Furthermore, you can create smaller roles encompassing several system privileges. A jr_dba
role might not include all system privileges, but only those appropriate to a junior database
administrator (such as CREATE TABLE, CREATE USER, and so on).

Oracle Database also enables auditing the actions taken by SYS (or SYS-privileged users) and
storing that audit trail in a secure operating system location. Using this model, a separate
auditor who has root privileges on the operating system can audit all actions by SYS, enabling
the auditor to hold all database administrators accountable for their actions.

See "Auditing SYS Administrative Users" for information about ways to audit database
administrators.

Data Inscription Standard

Page 15
You can also fine-tune the access and control that database administrators have by using Oracle
Database Vault. See Oracle Database Vault Administrator's Guide for more information.

The database administrator function is a trusted position. Even organizations with the most
sensitive data, such as intelligence agencies, do not typically partition the database
administrator function. Instead, they manage their database administrators strongly, because it
is a position of trust. Periodic auditing can help to uncover inappropriate activities.

Encryption of stored data must not interfere with the administration of the database, because
otherwise, larger security issues can result. For example, if by encrypting data you corrupt the
data, then you create a security problem, the data itself cannot be interpreted, and it may not
be recoverable.

You can use encryption to limit the ability of a database administrator or other privileged user
to see data in the database. However, it is not a substitute for managing the database
administrator privileges properly, or for controlling the use of powerful system privileges. If
untrustworthy users have significant privileges, then they can pose multiple threats to an
organization, some of them far more significant than viewing unencrypted credit card numbers.

Principle 3: Encrypting Everything Does Not Make Data Secure

A common error is to think that if encrypting some data strengthens security, then encrypting
everything makes all data secure.

As the discussion of the previous two principles illustrates, encryption does not address access
control issues well, and it is important that encryption not interfere with normal access
controls. Furthermore, encrypting an entire production database means that all data must be
decrypted to be read, updated, or deleted. Encryption is inherently a performance-intensive
operation; encrypting all data will significantly affect performance.

Availability is a key aspect of security. If encrypting data makes data unavailable, or adversely
affects availability by reducing performance, then encrypting everything will create a new
security problem. Availability is also adversely affected by the database being inaccessible when
encryption keys are changed, as good security practices require on a regular basis. When the
keys are to be changed, the database is inaccessible while data is decrypted and reencrypted
with a new key or keys.

There may be advantages to encrypting data stored off-line. For example, an organization may
store backups for a period of 6 months to a year off-line, in a remote location. Of course, the
first line of protection is to secure the facility storing the data, by establishing physical access
controls. Encrypting this data before it is stored may provide additional benefits. Because it is
not being accessed on-line, performance need not be a consideration. While an Oracle
database does not provide this capability, there are vendors who provide encryption services.
Before embarking on large-scale encryption of backup data, organizations considering this

Data Inscription Standard

Page 16
approach should thoroughly test the process. It is essential to verify that data encrypted before
off-line storage can be decrypted and re-imported successfully.

Advantages

EFS technology makes it so that files encrypted by one user cannot be opened by
another user if the latter does not possess appropriate permissions. After encryption is
activated, the file re-mains encrypted in any storage location on the disk, regardless of
where it is moved. Encryption is can be used on any files, including executables.

The user with permission to decrypt a file is able to work with the file like with any
other, without experiencing any restrictions or difficulties. Meanwhile, other users
receive a restricted access notification when they attempt to access the EFS encrypted
file.

This approach is definitely very convenient. The user gets the opportunity to reliably and
quickly (using standard means) limit access to confidential information for other
household members or colleagues who also use the computer.

EFS seems like an all-around winning tool, but this is not the case. Data encrypted using
this technology can be entirely lost, for example during operating system reinstallation.

We should remember that the files on disk are encrypted using the FEK (File Encryption
Key), which is stored in their attributes. FEK is encrypted using the master key, which in
turn is en-crypted using the respective keys of the system users with access to the file.
The user keys themselves are encrypted with the users’ password hashes, and the
password hashes use the SYSKEY security feature.

This chain of encryption, according to EFS developers, should reliably protect data, but
in prac-tice, as explained below, the protection can be ultimately reduced to the good
old login-pass-word combination.

Data Inscription Standard

Page 17
 Thanks to this encryption chain, if the password is lost or reset, or if the operating
system fails or is reinstalled, it becomes impossible to gain access to the EFS-encrypted
files on the drive. Infact, access can be lost irreversibly.

Regular users do not fully understand how EFS works and often pay for it when they lose
their data. Microsoft has issued EFS documentation that explains how it works and the
main issues that may be encountered when encrypting, but these are difficult for
regular users to understand, and few read the documentation before starting to work.

Data Inscription Standard

Page 18
Data Encryption Challenges
In cases where encryption can provide additional security, there are some associated technical
challenges, as described in the following sections:

 Encrypting Indexed Data

 Generating Encryption Keys

 Transmitting Encryption Keys

 Storing Encryption Keys

 Changing Encryption Keys

 Encrypting Binary Large Objects

Encrypting Indexed Data

Special difficulties arise when encrypted data is indexed. For example, suppose a company uses
a national identity number, such as the U.S. Social Security number (SSN), as the employee
number for its employees. The company considers employee numbers to be sensitive data, and,
therefore, wants to encrypt data in the employee_number column of the employees table.
Because employee_number contains unique values, the database designers want to have an
index on it for better performance.

However, if DBMS_CRYPTO or the DBMS_OBFUSCATION_TOOLKIT (or another mechanism) is

used to encrypt data in a column, then an index on that column will also contain encrypted
values. Although an index can be used for equality checking (for example, SELECT * FROM emp
WHERE employee_number = '987654321'), if the index on that column contains encrypted
values, then the index is essentially unusable for any other purpose. You should not encrypt
indexed data.

Oracle recommends that you do not use national identity numbers as unique IDs. Instead, use
the CREATE SEQUENCE statement to generate unique identity numbers. Reasons to avoid using
national identity numbers are as follows:

 There are privacy issues associated with overuse of national identity numbers (for
example, identity theft).

 Sometimes national identity numbers can have duplicates, as with U.S. Social Security
numbers.

Data Inscription Standard

Page 19
Generating Encryption Keys

Encrypted data is only as secure as the key used for encrypting it. An encryption key must be
securely generated using secure cryptographic key generation. Oracle Database provides
support for secure random number generation, with the RANDOMBYTES function of
DBMS_CRYPTO. (This function replaces the capabilities provided by the GetKey procedure of
the earlier DBMS_OBFUSCATION_TOOLKIT.) DBMS_CRYPTO calls the secure random number
generator (RNG) previously certified by RSA Security.

Note:

Do not use the DBMS_RANDOM package. The DBMS_RANDOM package generates pseudo-
random numbers, which, as Randomness Recommendations for Security (RFC-1750) states that
using pseudo-random processes to generate secret quantities can result in pseudo-security.

Be sure to provide the correct number of bytes when you encrypt a key value. For example, you
must provide a 16-byte key for the ENCRYPT_AES128 encryption algorithm.

Transmitting Encryption Keys

If the encryption key is to be passed by the application to the database, then you must encrypt
it. Otherwise, an intruder could get access to the key as it is being transmitted. Network
encryption, such as that provided by Oracle Advanced Security, protects all data in transit from
modification or interception, including cryptographic keys.

Storing Encryption Keys

Storing encryption keys is one of the most important, yet difficult, aspects of encryption. To
recover data encrypted with a symmetric key, the key must be accessible to an authorized
application or user seeking to decrypt the data. At the same time, the key must be inaccessible
to someone who is maliciously trying to access encrypted data that he is not supposed to see.

The options available to a developer are:

 Storing the Encryption Keys in the Database

 Storing the Encryption Keys in the Operating System

 Users Managing Their Own Encryption Keys

 Using Transparent Database Encryption and Tablespace Encryption

Data Inscription Standard

Page 20
Storing the Encryption Keys in the Database

Storing the keys in the database cannot always provide infallible security if you are trying to
protect against the database administrator accessing encrypted data. An all-privileged database
administrator could still access tables containing encryption keys. However, it can often provide
good security against the casual curious user or against someone compromising the database
file on the operating system.

As a trivial example, suppose you create a table (EMP) that contains employee data. You want
to encrypt the employee Social Security number (SSN) stored in one of the columns. You could
encrypt employee SSN using a key that is stored in a separate column. However, anyone with
SELECT access on the entire table could retrieve the encryption key and decrypt the matching
SSN.

While this encryption scheme seems easily defeated, with a little more effort you can create a
solution that is much harder to break. For example, you could encrypt the SSN using a
technique that performs some additional data transformation on the employee_number before
using it to encrypt the SSN. This technique might be as simple as using an XOR operation on the
employee_number and the birth date of the employee to determine the validity of the values.

As additional protection, PL/SQL source code performing encryption can be wrapped, (using the
WRAP utility) which obfuscates (scrambles) the code. The WRAP utility processes an input SQL
file and obfuscates the PL/SQL units in it. For example, the following command uses the
keymanage.sql file as the input:

wrap iname=/mydir/keymanage.sql

A developer can subsequently have a function in the package call the

DBMS_OBFUSCATION_TOOLKIT with the key contained in the wrapped package.

Oracle Database enables you to obfuscate dynamically generated PL/SQL code. The DBMS_DDL
package contains two subprograms that allow you to obfuscate dynamically generated PL/SQL
program units. For example, the following block uses the DBMS_DDL.CREATE_WRAPPED
procedure to wrap dynamically generated PL/SQL code.

BEGIN
......
SYS.DBMS_DDL.CREATE_WRAPPED(function_returning_PLSQL_code());
......
END;

While wrapping is not unbreakable, it makes it harder for an intruder to get access to the
encryption key. Even in cases where a different key is supplied for each encrypted data value,

Data Inscription Standard

Page 21
you should not embed the key value within a package. Instead, wrap the package that performs
the key management (that is, data transformation or padding).

An alternative to wrapping the data is to have a separate table in which to store the encryption
key and to envelope the call to the keys table with a procedure. The key table can be joined to
the data table using a primary key to foreign key relationship. For example, employee_number
is the primary key in the employees table that stores employee information and the encrypted
SSN. The employee_number column is a foreign key to the ssn_keys table that stores the
encryption keys for the employee SSN. The key stored in the ssn_keys table can also be
transformed before use (by using an XOR operation), so the key itself is not stored
unencrypted. If you wrap the procedure, then that can hide the way in which the keys are
transformed before use.

The strengths of this approach are:

 Users who have direct table access cannot see the sensitive data unencrypted, nor can
they retrieve the keys to decrypt the data.

 Access to decrypted data can be controlled through a procedure that selects the
encrypted data, retrieves the decryption key from the key table, and transforms it
before it can be used to decrypt the data.

 The data transformation algorithm is hidden from casual snooping by wrapping the
procedure, which obfuscates the procedure code.

 SELECT access to both the data table and the keys table does not guarantee that the
user with this access can decrypt the data, because the key is transformed before use.

The weakness to this approach is that a user who has SELECT access to both the key table and
the data table, and who can derive the key transformation algorithm, can break the encryption
scheme.

The preceding approach is not infallible, but it is adequate to protect against easy retrieval of
sensitive information stored in clear text.

Storing the Encryption Keys in the Operating System

Storing keys in a flat file in the operating system is another option. Oracle Database enables you
to make callouts from PL/SQL, which you could use to retrieve encryption keys. However, if you
store keys in the operating system and make callouts to it, then your data is only as secure as
the protection on the operating system. If your primary security concern is that the database
can be broken into from the operating system, then storing the keys in the operating system
makes it easier for an intruder to retrieve encrypted data than storing the keys in the database
itself.

Data Inscription Standard

Page 22
Users Managing Their Own Encryption Keys

Having the user supply the key assumes the user will be responsible with the key. Considering
that 40 percent of help desk calls are from users who have forgotten their passwords, you can
see the risks of having users manage encryption keys. In all likelihood, users will either forget an
encryption key, or write the key down, which then creates a security weakness. If a user forgets
an encryption key or leaves the company, then your data is not recoverable.

If you do decide to have user-supplied or user-managed keys, then you must ensure you are
using network encryption so that the key is not passed from the client to the server in the clear.
You also must develop key archive mechanisms, which is also a difficult security problem. Key
archives and backdoors create the security weaknesses that encryption is attempting to solve.

Using Transparent Database Encryption and Tablespace Encryption

Transparent database encryption and tablespace encryption provide secure encryption with
automatic key management for the encrypted tables and tablespaces. If the application
requires protection of sensitive column data stored on the media, then these two types of
encryption are a simple and fast way of achieving this.

Changing Encryption Keys

Prudent security practice dictates that you periodically change encryption keys. For stored data,
this requires periodically unencrypting the data, and reencrypting it with another well-chosen
key. You would most likely change the encryption key while the data is not being accessed,
which creates another challenge. This is especially true for a Web-based application encrypting
credit card numbers, because you do not want to shut down the entire application while you
switch encryption keys.

Encrypting Binary Large Objects

Certain data types require more work to encrypt. For example, Oracle Database supports
storage of binary large objects (BLOBs), which stores very large objects (for example, multiple
gigabytes) in the database. A BLOB can be either stored internally as a column, or stored in an
external file.

Layouts of DES in C++ project:-

Data Inscription Standard

Page 23
Data Inscription Standard
Page 24
Data Inscription Standard
Page 25
Data Inscription Standard
Page 26
Data Inscription Standard
Page 27
Data Inscription Standard
Page 28
 References
www.en.wikipedia.org/wiki
www.answers.com/topic/data-encryption-standard
http://www.laynetworks.com/des.htm
Books:-Cyber Security Economic Strategies and public policy alternative
Michael P. Gallaher, Albert N. Link, Brent Rowe

Data Inscription Standard

Page 29