1. Numerical Cryptography As a More Efficient Method of Data Disclosure and Accessibility
Emeka Ikpeazu, Jr., St. Andrew’s School, Boca Raton, Fl
Abstract: Cryptography is a very important way of encoding data. Companies are
looking for people who can improve the security of their systems. The RSA and PGP
cryptography programs utilize various algorithms for encryption and decryption, both of which
are multivariable algorithms each with its own inverse that allows one to decrypt from the
encryption algorithm, and vice versa. My approach was to develop my own algorithm while
simultaneously avoiding any complexity. The program required heavy use of the American
Standard Code for Information Interchange, or ASCII, table. The irony of algorithmic
cryptography as an efficient program is that it is rather easy to decipher, provided that the hacker
knows that knows the multivariable inverses of the encryption and decryption methods. This
numerical cryptography program, though simpler, is harder to decipher via the “brute-force”
method; in fact, the program is essentially impervious to any brute-force attack. The encrypted
message in the program will appear as a bunch of random numbers only to be decrypted by the
input of a set password. The program could ultimately work for all priorities of data as higher
priority data would be simply numbers and harder to crack and low priority data would be
hindered from a hopefully more complex and frequently changing password.
Mentor: Prof. Gary F. Pollice

2. Numerical Cryptography As a More Efficient Method of Data Disclosure and Accessibility
Executive Summary:
The development of my program began with the simple question of whether or not it
necessitated the algorithmic nature that most programs possess. What really propelled me to do
this project was my discovering a way to decipher codes from numbers, and vice versa. Once I
figured this out, I sought to expand on this method.
The program begins with an exposition of the algorithms of the PGP program and their
efficacy. This was made up of five methods: one that finds the prime a factor of a message in the
form of a very large number, one that encrypts the message, one that decrypts the message, one
that cracks the message, and one that finds a number given to the recipient of the message that is
used to decrypt the message. Those methods were able to decipher numbers and algorithmically
encrypt them, but I wanted to apply that concept to Strings, text variables that are represented by
characters.
It turned out that each character has an integer representation of three characters, meaning
that one could numerically encrypt a message by taking a String and returning the integer
representation of its characters in successive order. The numerical decryption of series of
numbers could be achieved by continuously taking the character that corresponded to the integer
value of the last three characters of the String and making it the first character of an empty
String. This would ultimately return the original message.
While this may seem rather easy to do, it is better than the algorithmic encoders and
decoders in that the decrypted data is not revealed to a user unless the user types in the correct
password. Unlike the algorithms before, the password needed to decrypt the message cannot be
acquired by any algorithm, thus ensuring privacy of information and other data.

3. Why?
Security is an important issue that constantly confronts this country. Security codes are
very interesting topics in regards to the safety of a system as large as a country or as small as a
household. The other day an article was published that talked about how the U.S. is lagging
behind when it comes to the strength of our IT security. There is no doubt that cyber-attacks are
becoming more frequent. The massive shift to electronic information is probably the primary
catalyst for the increase in cyber-attacks. In May 2009, the Government Accountability Office
made a total of twenty-four recommendations for cyber-security; however, only two were
implemented. The potential of destruction for cyber-security breaches and privacy attacks is
heavily underestimated. Terrorists are starting to take up arms against other nations and
cyberspace is the “primary realm.”
One of the most outstanding breakthroughs in computer science in the area of encryption
and decryption came in 1993 when Cryptography Research, Advanced Wireless Technologies,
and EFF (Electronic Frontier Foundation) made the DES, the Data Encryption Standard. The
DES algorithm randomly generated a 64-bit key made up of a series of 56 “0”s and “1”s. The
other 8-bits are used for the detection of error. The algorithm allows for over 72 quadrillion
keys; however, companies that use the program are still advised to frequently change keys in
order to greatly reduce the risk of brute-force breaches. The algorithm was still able to find an
encryption key after 56 hours of searching at 90 billion keys per second. This powerful
algorithm is the most widely distributed encryption algorithm, protecting financial transactions
and private information.
The reason for which the U.S. is lagging behind is that it is not fortifying the primary
target of these security attacks, the information infrastructure. The information infrastructure is

4. important for housing the instructions for the carrying out of secret operations. Advancements in
encryption and decryption could help solve the problem of the information and privacy breaches.
What was to be tested and evaluated was the Pretty Good Privacy (PGP) program for encryption
and decryption; moreover the results of the tests of the PGP program were to be compared to the
results of the program I made. The PGP program utilizes an asymmetric-key encryption system
in which the sender wants to send an encrypted message to the “recipient,” so the sender gets his
public key (containing integer variables z and n) from recipient’s website. The sender also has
his plaintext message, m. The sender encrypts his plaintext message, m, into ciphertext, c, with
the following equation:
c = m^n % z,
Where the symbol “%” is the modulus division function,
c is message in ciphertext,
m is the original message,
n is the encryption key,
and z is the public key which is a very large number that is the product of two prime
integer variables p and q.
The sender then sends his encrypted message over the Internet to the recipient. The
recipient receives the encrypted message, c, and turns it back into the original plaintext with the
equation:
m = c^s % z,
where s is the private key of the recipient.
What is to be verified is the whether the method can actually encrypt a message of alpha-
numerical characters rather than extraordinarily large integers. There is a way that one can do

5. this. Java allows the programmer to cast a char variable as an integer according to its American
Standard Code for Information Interchange, or ASCII, equivalent in the decimal number system.
For example, the char “a” would have decimal integer equivalent of 097. With this convenience,
a simple message can be changed into a series of numbers or a very large integer m. The
asymmetric-key encryption program relies on the properties exhibited by prime numbers. For
example, one of the prime factors of 133 is 7; by dividing 133 by 7 we can find another factor
which is 19. The same thing works for the message; the computer will start at 3 (all numbers are
divisible by one and two is both an even and prime number) and search until it finds the variable
s such that m % s = 0. With this, one can not only decrypt the message but one can also encrypt
the message as the product of two prime numbers. The research is very important because
foreign causes of national security breaches are becoming more sophisticated and using PGP is a
good way of encrypted private messages and data because the keys are only available to the
recipient. The PGP program is a very good and rather simple way for programmers to encrypt
both data and messages, provided that the messages are strictly in the form of numbers.
How?
The first step was to implement import java.math.BigInteger package. This class is
specialized in dealing with very large integers that exceed 232
-1 or fall below -232
-1 but
BigIntegers can also have a value as small as 1 or 4. In order to initialize a BigInteger one must
name it as an object and put the integer in parentheses as so:
public static BigInteger three = new BigInteger ("3");
The first method in the class was called FindPrimeFactor; in this method was this
for-loop created to find the two prime factors:

6. for (BigInteger p = three; p.compareTo(z.divide(two)) < 0; p = p.add(one))
That is, the value to which BigInteger p is initialized is 3. The condition of the for-loop is
p.compareTo(z.divide(two)) < 0
where p is less than half of the public key z. While the aforementioned condition is being
met, p is being incremented by 1. Inside the for-loop is the if-statement:
{
if (z.mod(p).equals(zero)) {
return p;
The function of the if-statement is to find a number that divides z. If the loop does not
find a factor of z, the loop will just return z. For the second and third methods: Encrypt and
Decrypt, the modPow method of the BigInteger class was the only function used. The modPow
method returns a BigInteger whose value is (thisexponent
% m). The function of Encrypt simply
returns m.modPow(n,z). The function of Decrypt simply returns c.modPow(s,z).
The professor showed me how to create the method by which I could find the private key
of the recipient. The method was called findS took the form of the Extended Euclidean
Algorithm in order to compute the private key of the recipient. This method took to BigInteger
parameters z and n. What had to be invented was another integer variable theta. The theta
variable was equal to (p-1)*(q-1). The next step was a very complex function such that:
for (BigInteger s = three; s.compareTo(new BigInteger("9999999")) < 0; s =
s.add(one)).
Like the first method, this method also contained a nested if statement inside the for-loop.
If (n*s) % theta equaled one then the method would return s otherwise the method would return
zero; the use of 9,999,999 was just as a hypothetical limit.

7. The method Crack carried out the same function as Decrypt except in a different way.
The method takes three parameters c, z, and n and sets a BigInteger s equal to the result of findS.
The method, however, was different from Decrypt in that the method did not “know” the value
of s, the variable denoting the private key of the recipient by which the recipient may decrypt the
message.
The two methods of my program were a bit more complex. The first method that was
implemented was the StringToBigInteger method. The professor was a great assistance with this
one. This method was the one that was to encrypt a character-composed message m into a
number made of three digit numbers for each character as corresponding to the ASCII table
(American Standard Code for Information Interchange). The method consisted of a for-loop that
traversed every character of an input string and converted each one into a three character decimal
equivalent. This method returned a BigInteger, result, as the ASCII equivalent of every
character in the string was multiplied by a constant bi1000, which equaled 1,000, and then added
to the ASCII value of the subsequent character(s) and then multiplied by 1,000. For example,
the String “hello” would return a value of 104101108108111 where the ASCII value of “h”,
equaling 104, would be multiplied by 1000 and then added to ASCII value of the next character
“e,” which equals 101. The value of result would then become 104,101; it would then be
multiplied by 1,000 and have its value increased by the ASCII value of “l” which is 108. This
process would repeat until the method traversed the entire string.
The second method, which was the hardest by far, was the BigIntegerToString method.
There were two ways I went about creating this method, the first way being very clumsy and
cumbersome. Having found no way to convert a three digit integer to the character to which it
corresponded, I unsuccessfully went about creating the method by positing an array of all the

8. printing characters of the ASCII table called ASCII. A variable String IntMessage was String
version of the BigInteger result. Then, two courses of action follow depending on what the first
character of IntMessage is. If the first number is a “1,” x an integer parameter in this case, will
partition IntMessage into substrings, each of which has three numbers. In the loop,
for (int x = (IntMessage.length()% 3 - 3) % 3; x < IntMessage.length(); x+=3)
x is being incremented by three and then being established as arguments for the substrings of
IntMessage as in the substring-to-integer conversion
int n = Integer.parseInt(IntMessage.substring(Math.max(x, 0), x + 3));)).
In order to nullify the possibility of the initialization of x in the for-loop being less than zero, the
Math.max(int a, int b) method made it so the that the parametric indices of the substring would
be at least zero or x and partition the String into divisions of three characters.
A variable n becomes this integer for each three-digit substring of IntMessage. Quite
interestingly, message, an empty String variable, is having the elements of ASCII continuously
added. Unlike the real ASCII table, ASCII has its elements, all the printing characters, start at 0;
the ASCII table has them start at 32. For the loop, the empty String message was changed by the
continuous addition of certain elements in the array as in the return statement:
message.concat(ASCII [n - 32]).
For example, the char variable a would have an ASCII value of 97, but its position in the array is
represented as ASCII [(97)-32], the sixty-fifth variable of the ASCII array.
Since the index of the characters in ASCII is 32 less than that of those in the ASCII table,
the method’s output was simply message.
The second part of the method was a case made for strings whose first character has an
ASCII value of less than 100. The conditional statement of this case was:

9. else if (IntMessage.length()%3!=0)
In this case, the length of the result variable as a String is examined to see whether it is a
multiple of three. This is because the ASCII value of every character is a three-digit number
with numbers less than 100 starting with 0; however, if the first character of the IntMessage
String was less 100 that means the 0 would have been excluded and then the first character of the
String would have just had its two numbers left and all the characters that followed would have
their three. If this were the case the number of characters in the String which denotes the length
would not have been a multiple of three. In this case, mess, the variable that was supposed to be
returned by this method, was initialized to the first character of the array and the for-loop would
do the rest of the job in adding onto said character in a similar fashion as the case before where
message=ASCII[Integer.parseInt(IntMessage.substring(0,2))-32].
The function of the for-loop was not much different than that of the for-loop of the previous case.
The only difference was that the variable x was initialized to
((IntMessage.length()-2)% 3 - 3) % 3) as the String’s first two characters initialized to
message.
The String mess is concatenated with the continuous addition of
ASCII [r-32].
Then the method returns message.
The repeated variations of way of computing Strings from numbers were futile.
However, Stack Overflow, a question-and-answer website for computer programming, became
of great assistance the second time around when it came to my attempts to make a method that
could turn the ASCII value of a String back into the original String. One user helped by

10. suggesting a method where a variable t is initialized to 1000 and a StringBuilder n. A while loop
was then imposed as long as result did not equal zero then. Under the conditions of the while
loop, result was to undergo a modulus division that would end up taking the last three digits of
result, casting them collectively as a single char variable corresponding to the ASCII table, and
inserting the variable into the “zeroth” index of the null StringBuilder object n. After each
iteration of the loop, result would be divided by 1000 in that
result=result.divide(t)
This process would be continuously repeated until result equaled zero. Then the method would
return
result.toString().
The many methods we used for making this entire class were entirely listed on the Oracle
website for the directory of Java applications and various imports. The Scanner package allowed
for user inputs and the IOException allowed for the possibility of an exception to be thrown. In
order to avoid difficulty, I let the BigInteger class encompass every numerical variable in the
program. The StringToBigInteger method was written by the professor. Most of the methods
that invoked Strings came from the Java Methods textbook. The Hello World! Computer
Programming for Kids and Other Beginners and the Java for Dummies books helped
tremendously in the creation of the intricate for-loops. Some of the other parts of the code that
assisted me came from the Stack Overflow website.
Findings:
The test of the Encrypt method took three parameters message, n, and z which equaled
3895, 4, 13493, respectively. The z variable was the product of two other variables p and q,

11. which, in this case, equaled 103 and 131, respectively. All the variables of the Encrypt method
were plugged into this formula:
c = m^n % z
c = (3,895)4
% 13,493
c = 4867
The Decrypt method took the parameters c, z, and s which equaled 4867, 13,493, 149,
respectively. The result of this method was the plaintext message which was to be returned by
the equation:
m=c^s%z
As expected, the method returned m as equaling 3895.
The Crack method returned the same thing as Decrypt, 3985. This method, however,
took what was returned by the findS method and applied that in the same fashion as the Decrypt
method did for s.
Although I was able to successfully create the StringToBigInteger method, my initial
conceptualization of method would go about was like this:
public static int StringToInt(String myString) {
int sum = 0;
int len = myString.length();
int i = 3*(len-1);
for (int j = 0; j < len; j++)
for (j = 0; j < len; i-=3)
sum += ((int) myString.charAt(j))*Math.pow(10,i);
return sum;

12. The first for-loop traverses the entire String. The integer variable i is supposed to make it
so that the String actually has an integer value. For example, the String "hello" would have a
value of 104,101,108,108,111 104 is "h", 101 is "e", 108 is "l", and 111 is "o". The reason that i
= (3*myString.length()-3) or 3*(len-1) is because for the first ASCII value of the String to be in
its proper place, the integer value of the first character of the String, in this case "h", must be
multiplied by 10 to the 3*(len-1) (which is 12 as len = 5) and be but in the place of 1012. As the
loop goes to the next character, i is decremented by 3 so the 101 corresponding to "e" would be
in the place of 109 and so on. The integer variable sum becomes bigger according to the
respective position and value of each ASCII equivalent of every character in the String and then
is returned. This method, however, failed, contradicting the predictions of how it would
function.
The first of the methods of my program, the one which the professor helped write,
worked perfectly. The StringToBigInteger method was carried out by the function of the for-
loop:
for (int i = 0; i < myString.length(); i++) {
BigInteger nextCharValue = new BigInteger("" + (int)myString.charAt(i)); // integer
value of the next character
result = result.multiply(bi1000);
result = result.add(nextCharValue);
}
return result;
The test of the method took in the String “abc” and returned 97,098,099.

13. There were a myriad of problems when it came to the BigIntegerToString method. There
were runtime errors repeatedly for each time the method was tested. There were also many
problems with certain lines of code that were written. Variations of the same idea, the idea of
printing from an array with all the printing characters of the ASCII table, were used of no avail.
However, what was unnecessary was the implementation of the entire ASCII table as an array.
The method given to me by the user from Stack Overflow was a success. The input String “ab”
returned result as 97098 and the BigIntegerToString method returned the String “ab” as
predicted.
In the main method of the programs all the methods worked. However, I provided two
options by which one could test the program. In both, there was an integer variable called
choice; choice was a number, 1 or 2, that was input by the user when prompted to either run a
large integer through the PGP program or to numerically encrypt and/or decrypt an input String.
If choice equals one, the message is returned as having been run through the FindPrimeFactor,
Encrypt, Decrypt, findS, and Crack methods. If choice equals two, the user is prompted to enter
an input String that would then be changed into a BigInteger. Afterwards, the user is asked to set
a String variable called password and then there is another prompt to type the password as
originally set. If the user, or another, can type it correctly the result of the BigIntegerToString
method, the method that shows the message decrypted, is returned. If the user does not type the
password correctly, the user is denied access which is denoted by the code:
System.out.println(“Your access to the decrypted data is denied.”).

14. Illustrations:
When the all of the code was complete, the success of my program could then be tested as a
whole.
The screenshot above is an illustration of some of the problems that were associated with the
BigIntegerToString method. The reference in the second line is to the eighty-fourth line of code
where I made message = ASCII [Integer.parseInt(IntMessage.substring(0,2))-32]. The third line
is referring to the dysfunctionality of the BigIntegerToString method in my main method.
The results of the algorithmically cryptographic programs were not successful on all counts as I
thought they would be. The Crack method, in particular, had the most problems associated with
it. Below is the running of the algorithmic methods.

15. What is supposed to be shown below the result of the Decrypt method is the result of the Crack
method although it is the same as that of the Decrypt method. What is more is that the
termination button (the red square inside a square) has not faded as instantly as it is supposed to
have—and in roughly no time at all. When the result of the method was evinced the result of the
Crack method was 1, not matching the output of the Decrypt method. Moreover, the findS
method that was supposed to give me the private key of the recipient was off for some reason or
another also, having given the value of s as 0. Below is the partial screen shot of the Crack and
findS methods.
However, it turns out that there was no error in my code. The Crack method is totally dependent
on the results of the findS method. In this case, the findS method was impossible by any means.
The for-loop of the method was supposed to make a BigInteger theta which was the product of
(103-1) and (131-1), equaling 13260. Since n equaled four and was being multiplied by s in
order to see whether 13260 modulus (n*s) equaled one, the only option for the findS method was
zero because such conditions were impossible. One can never add 1 to theta and get a multiple
of four because, in this case, theta was a multiple of four. Since the result of the findS method
equaled zero, the Crack method could not work as it utilized the algorithm:
Decrypt(c, z, s)

16. where c equaled 4867,
z equaled 4,
and s equaled 0.
What was to be returned was (48670
)%4 which is the same as 1%4. The only possible result had
to be 1. The methods I wrote for the numerical encryption worked, though they took many trials
and errors.
The numbers in brackets represent the variable choice if a user presses “2,” the user is prompted
to enter any String message and it’s numerically encrypted representation is returned below. The
user is then prompted to enter a password.

17. If the password does not match the original password the user is denied access to the program.
However, if the password is right the user is given the original data.
Excluding runtime errors, the possibility of the code going wrong is essentially nullified.
Moreover, it is necessarily impossible to algorithmically acquire the password of the person who
encrypted the password in the first place, so using “brute-force” is completely futile.
Discussion:

18. Numerical cryptography augurs well for cyber-security in the future. The data is
encrypted only to the person who has not already put in the password or has put in the wrong
password. The good things that can result from this are numerous; data can stay safer no matter
the priority. One can literally make an encryption but a password that is even more complex that
the data itself. However, this is not the case for the PGP program was the private key of the
recipient is at risk of being uncovered making it all the more important to conceal the private key
of the recipient.
The most important part of the program is the fact that it differs from the conventional
algorithm in that it takes in numbers and Strings. Another issue that could arise is that even of
the PGP algorithm would take in the ASCII value of the Strings that are represented there is no
guarantee that it could be encrypted as theorized. For example, the String “At noon” has an
ASCII value of 6511632110111111110. If n were to equal 2, and z were to equal 85 as p and q
equal 17 and 5, respectively, the encrypted ciphertext message would be 50. The recipient would
have to labor to find a private key that decrypts the data. The user would have to find a number
s that satisfies the equation:
6511632110111111110 = 50
s
% 85
Given the parameters, the findS method would inevitably return zero, the Crack zero, and the
Decrypt method one, using zero as the value of s returned by the findS method. Even if this
message could be encrypted the sender would have to find a public key n and two prime numbers
p and q whose product is the value of the public key z. Not to mention all of these must be able
to be correctly valued to allow an integer s to be useful in the Decrypt method.

19. The numerical program does its job in facilitating the securing of data and other private
information. Although the program is rather simple, it is can go a long way, being of great use
by companies and governmental organizations. The program, at least, brings a new perspective
of how people secure valuable data. The functional value of the program is definitely unique
from the PGP, but the program’s efficiency is one of its most important aspects. The time is
virtually nothing to encrypt, decrypt, and compare passwords but in the case of the PGP
program, it literally took two whole minutes for the findS value to return zero and make the
Crack method return one. To put this in perspective, a second of runtime searching covers 256
permutations and then the exponent is added to log2N, where N is the number of seconds; in this
case N = 120. This means that in order to finally return zero the findS method went through roughly 134
quadrillion calculations before it reached its conclusion. With this program, less time is wasted and the
number of calculations is decreased. Time really is of the essence when it comes to cyber-security as two
minutes could easily be the difference between a breach and a successful storage of data.
Conclusions:
There is much to be taken from this program; it is a much better way of securing data,
accessing data, and making data more easily accessible. The results of the computer program
have definitely met the standard to be taken seriously and maximized in every possible way. The
method was faster, easier, simpler, and more reliable than a good number of other algorithms
and/or methods. The method’s best success, I believe, came from the fact that it was faster.
Efficiency was the number one goal of the program and that goal was fulfilled.
In terms of future applications, this computer program can, at the very least serve as an
archetype on which companies, businesses, and other institutions can expand. It has the potential

20. to be used by even more computer scientists and those of relevant fields to heighten the security
of their information databases. As far as future experiments are concerned one could make it so
that there is an interface in which multiple users are taken into consideration. To each user
would be a unique password and no user would know another one’s password. It could even be
possible that every user in the interface of the program could collectively decrypt high-priority
data by individually contributing his/her password. Other possibilities including running the
encrypted data through randomly generated algorithms in order ensure greater security.
Had I been given a little bit more time, I would try to ensure that the password String was
not visible so that it would appear more professional than prototypic. I would also try to see if I
could run the decrypted code through an algorithm that arranges the digits in the most arbitrary
of ways, like a method that encrypts the encrypted. Again, these are just ways to make sure the
security of the data is optimally maintained.
What is still unanswered is whether the data is only in the form of textual input. Now it
is even possible that files can now be stored as alpha-numerical representations of any base. It
would be very interesting to see how one could apply this method or something similar, to object
files such as .mp3, .ppt, or .php. If this is possible, then one could theoretically encrypt and
decrypt a WAV file that could only be opened by the input of a recorded sound that would
actually function as the password. One could apply the concept to a file that is to be decrypted
by input of fingerprint or a hair follicle whose genome is computationally sequenced in a matter
of seconds. Whatever may result from this program, it will be this program that laid the
foundation as the original prototype.

21. Works Cited
1. Burd, Barry A. Java for Dummies. Hoboken, NJ: Wiley, 2007. Print.
2. "FIPS 46-2 - (DES), Data Encryption Standard." Information Technology Laboratory
Homepage. Federal Information Processing Standards Publications, 30 Dec. 1993. Web. 26 Aug.
2011. <http://www.itl.nist.gov/fipspubs/fip46-2.htm>.
3. Litvin, Gary, and Maria Litvin. Java Methods A&AB, AP Edition. Andover: Skylight, 2006.
Print.
4. "Overview (Java 2 Platform SE V1.4.2)." Automatic Redirection. Oracle, 2003. Web. 06 Aug.
2011.
<http://download.oracle.com/javase/1.4.2/docs/api/overview-summary.html>.
5. Rashid, Fahmida Y. "U.S. Officials Tell Congress the Country Lags in Fortifying IT Security -
Security - News & Reviews - EWeek.com." Technology News, Tech Product Reviews, Research
and Enterprise Analysis - News & Reviews - EWeek.com. EWeek, 26 July 2011. Web. 29 July
2011. <http://www.eweek.com/c/a/Security/US-Officials-Tell-Congress-the-Country-Lags-in-
Fortifying-IT-Security-669334/>.
6. "Record Breaking DES Key Search Completed." Cryptography Research a Division of
Rambus. Cryptography Research, 2011. Web. 26 Aug. 2011.
<http://www.cryptography.com/technology/applied-research/research-efforts/des-key-
search.html>.
7. Sande, Warren, and Carter Sande. Hello World! Computer Programming for Kids and Other
Beginners. Greenwich, CT: Manning, 2009. Print.
8. Vijayan, Jaikumar. "Take Cyberthreats Seriously, Says Counterterrorism Expert -
Computerworld." Computerworld - IT News, Features, Blogs, Tech Reviews, Career Advice. 03
Aug. 2011. Web. 03 Aug. 2011.
<http://www.computerworld.com/s/article/9218844/Take_cyberthreats_seriously_says_counterte
rrorism_expert?taxonomyId=82>.
9. Yannakogeorgos, Panayotis A. "Promises and Pitfalls of the National Strategy to Secure
Cyberspace." Project on National Security Reform. Web. 05 Aug. 2011.
<http://www.pnsr.org/web/page/956/sectionid/579/pagelevel/3/interior.asp>.