INFOSEC : Theoretical vs Practical Security

Over the last year or so I have been wondering just how effective simple
encryption can be in regards to law enforcement. We know that the National
Security Agency has a top notch collection of scientists and mathematicians,
as well as having a ridiculous amount of computing power. What I often
wonder is just how much access the rest of the Intelligence Community
has to that resource.

For
example, let's say I use a simple transposition and substitution cipher
to encrypt some text files. During the course of time some law enforcement
personnel knock on my door and confiscate all of my equipment. As they
go through the data, they find several files that are encrypted.

With
this they can probably state something about having encrypted data on
my system as well as cryptographic software and how this obviously means
that I'm doing something bad. However, what if I don't cooperate and they
have to find another way to get that data decrypted?

Now
the conspiracy buffs state that all they have to do is email the NSA a
copy of the file. In a couple of days they get the decrypted file back.
Although it only takes the NSA several minutes to crack the encryption,
they delay it to make it look good.

Now
this seems all fine and dandy, but to my knowledge this has never happened
and I doubt that it ever will happen. So what does the local law enforcement
do? They could contact the FBI. There is only one problem, when have you
heard of the FBI breaking any encryption? I haven't heard of any. Now
mind you, this is after they have stated that this case involves a million
plus dollars, relates to espionage activity of Secret or better data or
is of a high profile case (such as defacement of a major web site.)

Now
what does the local law enforcement do? Talk to a professor at the local
university? Or maybe hire somebody for their in-house crypto department?
Neither of which seems to be a viable solution. So it seems they are out
of luck.

Which
leads me to this question, how much effort is really needed to make information
practically secure? Sure there have been cases where a hacker has used
the resources of 50+ workstations to brute force a - yes ONE - key, but
just how many local police departments have this kind of computing power?

So
all this would suggest that a simple text cipher is sufficient to annoy
law enforcement and possibly even a number a Intelligence Agencies. This
is assuming, of course, that they can find the data. This brings me to my second point: if they can't find it, they can't break it.

Hiding the data

There
are many ways of hiding data, all of which have advantages and disadvantages.
Two possible ways consist of using the least significant bit in an audio
or visual file. I don't recall the numbers, but you can store a reasonable
amount of information on a PhotoCD that is full of high-res images. The
disadvantage is just how obvious it is. Say your a hard-core programmer.
What, may I ask, are you doing with 10 PhotoCDs full of high-res images?
True you can put porn on them to help disguise it, though it would go
over a lot better if you were a graphic artist. The same for audio.

Another
possibility is to simply append that file onto an existing, working binary.
I have done this and the file works just fine and as long as you pick
a file that isn't well known it will be that much harder to guess which
file. If /bin/ls is 384k bytes, an observant investigator is going to
know something's up.

Finding the data

One
issue that you have to keep in mind is that computer forensic people have
utilities that will read all ASCII data from the drive. This will mean
if you have some text files appended to a binary they are going to catch
on real quick. So what to do? Since you already wrote a quick C program
to append the data, why not add a little code to do some bit shifting?
All the code has to do is make the data look non-ASCII.

The
Agencies

The
purpose of this paper is to generate questions. Such as, just how secure
is secure? All Agencies, Departments and Bureaus have many factors against
them. Inter-agency politics, internal politics, laws, red tape, financial
constraints and lack of knowledgeable people are some. Though the latter
is quickly being filled. The strength of such agencies, such as the FBI,
isn't technical it is shear size. They can assign a hundred or two hundred
agents to gather information. From all the hotel registries in a 100 mile
radius to sifting through 3 tons of sand. Then input all that information
into a computer for data mining.

Sure
certain Agencies have the technical prowess to design, build and maintain
a project such as Echelon, but how often does that Agency use those skills
to help run-of-the-mill criminal cases? Do they have liaison officers
sitting quietly in the background of every field office nudging the law
enforcement personnel in the right direction? Or do they exist only in
high security towns that aren't on any map quietly building and dissecting
domestic and foreign electronic signals?

The problem

Whether
or not I will find the answer to these questions isn't what I'm interested
in accomplishing. What I wish to accomplish is for others to think about
the problem, the problem of communication between Agencies and Departments.
I have been told that we had all the information necessary to know that
Perl Harbor was going to be bombed, but that information was scattered among many different Departments. Out of the after math OSS and then the
CIA were created for just such a reason. I don't think size is as important
as communication. Look at Unix. The Unix philosophy is to create small
programs that emphasize communication both to the user and to each other.
This creates a flexible and therefore powerful system that has lasted
for several decades. We cannot say the same thing about NT.

Conclusion

I
kind of ran through this topic. I hope that this has given you a slightly
different picture of what's around you. Stereotypes are helpful to a degree,
but they can be misleading as well. Above all remember, never underestimate
your opponent.

Appendix
A: Cryptography

Books:

"Secrets
of Making and Breaking Codes" by Hamilton Nickels ISBN 0-8065-1563-5

A
cute little book that covers a lot of basic cryptographic systems all
of which are text based.

"Applied
Cryptography" by Bruce Schneier ISBN 0-471-59756-2

Now
available in a 2nd edition, an encyclopedia on the topic. From protocols
to algorithms in C code, a must for you bookshelf.

Appendix
B: Text ciphers

Ok,
so you got some text ciphers going, now what? May I suggest your friends
uuencode and uudecode? A simple way to get binary data into and out of
a text cipher.

You
might be asking, aren't text ciphers really easy to break? It depends.
First, if your cryptanalysing English text then you have a lot of things
going for you. If your analyzing binary data your not guaranteed to have
the letters 't' and 'h' together most of the time. Nor the 'i before e'
rule.

Now
if you happen to be enciphering text data, one idea is to make sure that
the output is compliant with uudecode. Now you convert it into binary.
This adds another layer to the problem. Add a false header and footer
with an incorrect extension and you have an unreadable Word file. Just
because it says Word in the header doesn't mean the contents have to be.

Appendix
C: A Simple Cipher, An Idea

An
idea for a simple cipher is this: take a binary file, uuencode it. Take
that and reverse each line (or every other line.) Make sure you strip
the 'M's out then add them to the output lines. Uudecode it and you have
a scrambled binary. The benefit to this approach is that you don't have
any incriminating evidence around, namely the cryptographic software.

Appendix D: Steganography

Steganography
is the study of hiding the data. You know the old trick of cutting out
holes in a piece of paper, then placing that over another printed piece.
then you read the letters that show through? Same thing. The idea is that
if they can't find it, they can't use it.

-
Silere Praeses

1.)
OsReview
: Mandrake Linux 7.0 Deluxe -
L33tdawg

2.)
Setting up
a DHCP server (Part 1) -
L33tdawg

3.)
Basic
Networking Guide -
Haven

4.)
How
To HaX0r1z3 your Toaster -
[SANiTY]

5.)
INFOSEC:
Theoretical vs. Practical Security
- Silere Praeses

6.)
Hop Box
- A telephone relay proposal -
Silere Praeses

7.)
Crippling
Windows -
xearthed