[Back to Home Page]
www.RomanBlack.com
The ELK Theory - Unbreakable Encryption!
This is my ELK Theory, a simple method to ensure totally unbreakable
encryption
Roman Black - Nov 2005 - web Aug 2006 - updated Feb 2008
Opening Note!
After releasing this in Aug 2006 I copped a few negative emails from
academics etc who believed I was trying to take credit for the entire
notion of substitution ciphers or the very old "one time pad" which is
indeed the basis of my work here. I was well aware of the old fashioned
encryption systems having used them in my childhood but my sloppy writing
had led some people to a false understanding of my point, even though it
seemed obvious to me with terms like "going back to a grass-roots system"
etc.
So I have re-written the below text to simplify my point; that
a return to a grass roots system can still be worthwhile even today,
it DOES produce totally unbreakable encryption on interception
and I have further emphasised the main focus of the original article
which was 2 basic real-world implementations of an excessively large
keyword. Hopefully even the "academically challenged" will understand
this time...
What is it?
ELK stands for "Excessive Length Keyword" and is a practical system using
modern equipment for encrypting data, messages, etc to a form that is totally
and absolutely unbreakable if the data is intercepted.
How it works
Unbreakable encryption sounds like wishful thinking. In reality it is
fairly easy, and many of the earliest forms of codes were themselves
unbreakable.
Going back to a grass-roots system, it is in fact very easy to encrypt
things that can NEVER be decrypted unless the key is owned.
This is a basic fact of encryption that no amount of supercomputing
can break - unlike the majority of popular encryption systems etc in
use today that CAN be broken.
The simplified ELK theory
Excessive Length Keyword or ELK
is my term and applies not only to the
basic encryption type (where the encryption key is at least as long
as the data string; ie "one time pad") but also applies to systems of
use of the keyword; as in using one very long keyword that can be
pre-distributed and then used in segments by all users etc.
Below is shown a very crude example of encryption, stripped to the
bare bones. Given that A=1, B=2 etc the message is added to the repeated
keyword (bead), and the result is the encrypted message. The encrypted
data can easily be broken by "brute force" ie trying all possible sizes
and variants of keyword.
Now see the second example above. This is the same message, the same
simple additive math, but this example demonstrates that anytime the
keyword is as long (or longer) than the message it becomes impossible
to break the encryption.
This is a mechanical certainty, the return to a grass roots system where
it is simply not possible to break the encryption as there are an infinite
number of possible (equally valid) solutions.
With this principle utilised, it no longer matters how sophisticated
the math scrambling is. In fact it becomes unimportant. The message is
already unbreakable so increasing the level of math is meaningless.
The reason that grass-roots system like this are no longer used
are the problems of key distribution (always a hurdle) and in generation
of a pure random key (that cannot itself be predicted or broken).
So is it practical?
Now I know that people who have formal encryption training will think
that this system is of limited value. Modern encryption systems are
heavily based on ideals like public and private key encryption and
the encryption's ability to be incorporated into networking protocols.
These things are important for the majority of modern encryption uses,
because the internet purchasing systems and banking systems work that way.
But my work with ELK systems was never intended for those applications.
An ELK system has its greatest value in sending data that is absolutely
impossible to decrypt if that data is intercepted - where issues like
key distribution etc are less important.
Fortunately the very same modern computing power that allows very fast
crunching of numbers and storage and transmission of very large data
strings also facilitates the use (or return) or a primitive grass-roots
system. My goals with this page are to promote and encourage thought
about these encrytion systems in totality and encourage real world use
with some simple software tools I am providing for free.
Two practical systems
Split ELK.
In this system the data is encrypted using a randomly generated,
single-use only ELK sequence.
Then the data is sent by one source, and the ELK is sent by another
source. These two equal size packages are each impossible to decrypt,
the ELK parcel cannot be broken as it contains no data, the data
parcel cannot be broken as it is ELK encrypted and there is no
possible way of reproducing the random ELK.
Both parcels are indistinguishable by themselves, and under an entropy
test each will appear as a perfect random string. There is total
security from decryption unless of course someone can intercept and
posess BOTH parcels.
Multiple ELK.
With multiple ELK the ELK must exist at 2 (or more) locations.
The sender encrypts the data using the ELK. The data parcel is
sent by itself. If the data parcel is intercepted it is
unbreakable because the random ELK is unknown. The person who
receives the data parcel also has a copy of the ELK,
and uses the ELK to decrypt the data. Obviously there can be
more than 2 users within a Multiple ELK system.
Since the ELK cannot ever be re-used for another data parcel,
a practical system would be where the ELK is much larger than a
data parcel, so sequential data parcels can be sent, each one
using the next portion of the ELK that has not previously been
used.
This becomes practical as the mass ELK can first be distributed
to all users, then many data parcels can be sent before it is needed
to discard the ELK and redistribute the next ELK. One requirement
might be to include a simple "index" number with each data parcel
telling where to match it to the right part of the much larger
ELK file.
Another refinement would be for each user to have their own
allocated segment of the ELK to use for their own sending. This
would eliminate the possibility of two messages being sent at the same
time by two different users both using the same overlapping section of
the ELK. For example, with two users, one could do all their
encrypting/sending from the first half of the ELK, the other user
does their encrypting/sending from the second half. This avoids
overlap without requiring a larger ELK.
Implementing these systems
To implement Split ELK all that is required is a source of random
characters to make the ELK, and a very simple character adder software
to encrypt the data file.
For Multiple ELK a longer ELK can be generated first and
distributed first to all users. Then smaller data parcels can be
encrypted and sent using a simple character adder software. The
encrypter software needs to be able to keep track of the index so
it avoids re-using any part of the ELK.
Software tools
One day when I get bored I will code these up. If anyone else wants
to create these software tools or similar please feel free. Also
I encourage anyone with ideas on better implementing these systems
or ideas about new systems please contact me.
A good random stream generator.
Now done! I have recently developed a good Random Number Generator
algorithm that produces very good random data and software to do it;
"Black-RNG" here.
Addition encrypter.
This is an easy one, all it needs to do is open two files, one is the
data stream and one is the ELK stream. Then add each character (byte)
from stream1 to stream2 and write the result (encrypted) data to a new
file. A nice feature would be to save an index number to the hard drive
to allow use of multiple messages from one long ELK. (Work in progress)
Subtraction decrypter.
Same as above but in reverse. Probably easiest to include both these
functions in one software package. A way to enter or store/recall
an index number.
A real-time random stream generator.
This could generate a random stream direct from a music CD, and manage
an index number so it is useful for Multiple ELK. If implemented properly
all each user would need is a copy of the same music CD in their
music collection. The CD could be inserted when a new message arrives,
and once set to the new index could decrypt the new message.
No copy of the ELK is stored or kept on the PC. Seems to have
possibilites, may be worth further investigation...
Future additions
This page is a work in progress. I have more encryption stuff
to add to this page at a later date.
- end -
[Back to Home Page]