File	Date	Author	Commit
tests	2014-01-24	Peter Schaefer	[2f71bc] Version 0.6. Added "experimental" mode ("x").
.gitignore	2014-01-18	Peter Schaefer	[31f9e4] v0.3 - repeat file feature, cyclic key feature
cloudture.cpp	2014-02-01	Peter Schaefer	[ad3b3b] fixed stdin/stdout thanks to zlib
compile.sh	2014-01-15	Peter Schaefer	[631262] v0.1
example.sh	2014-01-23	Peter Schaefer	[d941b1] WIP towards v0.6 - better parameter parsing, al...
readme.txt	2014-02-01	Peter Schaefer	[ad3b3b] fixed stdin/stdout thanks to zlib
test.sh	2014-01-21	Peter Schaefer	[c64b32] Forgot to commit and push v0.4. Includes WIP v0.5.

Read Me

Why CLOUDTURE?

The news has made us aware that the intelligence services are storing 
huge amounts of data. The question is, how can we make good use of this 
huge storage capacity?

I suggest to use the real, possibly subliminal, message as the key to 
encode your "secret" messages, with the full expectation that if the 
attacker uses enough resources, he will be able to read the "secret" 
message, IF HE HAS STORED THE KEY IN HIS DATABASES.
You could, for example, use a copy of the movie "1984" as the source 
for keys, to transmit the message that too much surveillance is a bad 
thing.
To make sure that e.g. the entire movie is stored eventually, the 
program allows you to specify an offset into the key source. Because 
that is the suggested use, the encryption method is simple, yet 
effective if used correctly.

A file encoded with:

cloudture.exe -m test.txt -o 581px-Paracoroniceras.jpg 1337 -of encoded.txt

will be decoded with:

cloudture.exe -m encoded.txt -o 581px-Paracoroniceras.jpg 1337 -of decoded.txt

The options trigger checks on the value or existence of up to two 
parameters, position and repeat:
-m	a message, no position and no repeat
-c	a chunk, no repeat
-k	a key, is repeated two times by default
-o	a one-time-pad, is repeated one time, i.e. not at all
-f	a file, use it without any checks

-of is followed by the name of the output file

For encoding, the program uses a most basic function, xor. This function
is safe if the keystream is truly random, and the keystream be 
transferred safely to the recipient. It also means that the encoded 
message always has the same length as the message. This is a potential 
weakness - if it concerns you, pad your message with random data if you 
can.

Since the program does not distinguish between message, encoded message 
and (truncated) one-time.pads, it is possible that the encoded message 
actually is shorther than the message. Please check the length of the 
output. In some modes, the program will detect such a situation.

Traditional encryption allows an attacker only to read the entire 
message or nothing at all. The xor encryption method used here allows 
an attacker to decode part of the message if he has part of the 
keystream. On the good site, if you use one-timed pads as long as the 
message, the attacker cannot brute-force the message by scanning the 
entire key space.

Another weakness is that common file types start with a magic number or 
code, like e.g. GIF98a. This might allow an attacker to detect the file
type or read the first words of the encoded file. The same is true if 
you use an uncompressed executable as the key - it will often contain 
predictible sequences and long areas with zeroes. The program uses an 
encryption method which is very susceptible to this.

Maximum offset is currently at 2GB, this is the maximum file size.

New feature since v0.3: You may now choose to repeat a file.

The main problem adressed here is that for big files, the start and end 
position of the key file will be unlikely to be chosen randomly as the 
start of the actual key sequence used.

This does decrease the safety of the encrytion if the key file is 
smaller than the message file, but it also allows you to encrypt 
messages larger than the key file, and works better with the suggested 
hidden purpose of cloudture to store the key source file in the 
databases of the attacker.

You may specify the starting position in the file as "random". You then 
must provide a source for randomness to the program. Since v0.5, you 
must specify the name of the random data stream with random=filename.
Since any pseudo-random-generator has potential weaknesses, it is left
up to you to choose one. On unixoid system, there may exist /dev/random 
or /dev/urandom for such a purpose.

cloudture.exe -m msg.txt -o 1984.mp4 random=/dev/random 1 -of encoded.txt

Repeating file data since v0.3 is  a standard feature.
You have to specify "random=filename" with a number following, like 
in "random=/dev/random 3", which means the file will be repeated 3 
times. If you do not specify a number, the default number of repeats 
will be two. If the message file (including repeats), which is 
identified by not having random start position, is smaller than 
(or equal) than the key file (including repeats), then the random 
position selection will simulate a cyclic randomness, where every 
position is as likely as the other, even for start and final position 
of the key file.

If you want the old v0.2 behavior, please specify "offset position" as 
"0 1" for the message file and "random=/dev/random 1" for the key file.

When completing the file merge, the program will output the starting 
positions in the files, which you will need to note down to have the 
full key information needed for decoding. This behaviour can be
controlled using environment flags, see further below.

A file encoded with:

cloudture.exe -m test.txt -o 581px-Paracoroniceras.jpg 1337 -of encoded.txt

will be decoded with:

cloudture.exe -m encoded.txt -o 581px-Paracoroniceras.jpg 1337 -of decoded.txt

Since version 0.4, you may specify negative offsets, if cyclic mode is 
being triggered.

Since v0.5, if you specify random=/dev/random on Windows/MinGW, then if 
MinGW fails to open /dev/random, windows functions CryptAcquireContext 
and CryptGenRandom will be used. I guess I need to move to linux .. ..

You may now set the "quiet" flag in the program's environment:

	cloudtureflags=q
	export cloudtureflags

You may now set the "h0" and "h1" flags in the program's environment.
This will cause the program to output the command to decode file 0 or 1,
or both, as in the example below:

	cloudtureflags=qh0h1
	export cloudtureflags

There is now an automated test named tests/verify.sh, which uses these 
features.

LICENSE: GPLv2, GPLv3 or later, BSD
VERSION 0.7

This program has been built and tested on Windows/mingw, YMMV.
As you can read above, while there is a way to use it safely, using 
actual one-time-pads, this is not the suggested use.

compile.sh is for building, test.sh for running a few test cases.

PLEASE TEST THIS!
The code has gotten more complex with more features, there might be 
some cases that are not treated correctly.

CURRENTLY EXPERIMENTAL FEATURES
They are only available if you set "x" for experimental flag.

For any input file, you may specify "stdin", which makes the program 
read from stdin:

For the output file, you may specify "stdout", which will output the 
result, which you then can pipe to another program.

Example: if you want to type in random characters and send the result to 
stdut, do:

cloudture.exe x -m msg.txt -c 1984.mp4 random=stdin -of stdout > encoded.txt

and then type in a few random characters and press [enter].

[NOTE] The program cannot read from files named "stdin" or "stdout".

[NOTE] The stdin/stdout feature was broken in 0.6, fixed in 0.7 for 
windows-like systems and might be moved from experimental to normal 
mode in 0.8.