Secure Sensitive data with Peazip Encryption and Camouflage

[mikeslr]

I'm not particularly concerned about security. But there is some information on my computers I would rather have remain private.

I always keep most of my files in uncompressed folders on my hard-drive rather than within the confining space of a compressed SaveFile. Theoretically, the information in those files could be swooped up by the dragnet-bots criminal organizations and governments cast into the internet. But the most likely way for the horse to get out of the barn is for my USB-Key to fall out of my shirt pocket. Even a curious tech-savy teenager could, with a little googling, could obtain a free ride: Enter encryption.

I'm lazy and have the memory of a seize. I want something simple: something I could password-protect, with a good chance that I'll remember the password. After all, I'm not guarding the Nation's secrets. Just trying to frustrate some random teenager or fall prey to a dragnet.

A couple of hours of trying unsuccessfully to create an encrypted folder using Truecrypt convinced me either it was broken or I was. So I did what I always do: “When at first you don't succeed, google for something else.

[mikeslr]

Hi All,

On a different thread it was asked if it was possible to encrypt an entire USB-Key. Well it is. But then you won't be able to boot into it: at least not until you decrypt it which will require employing a different OS on a different USB-Key or otherwise.

First off, before mikeb bites my head off, I don't urge you to do the following; or even utilize the procedure I set out in my previous post. Frankly, I think it sufficient --if you have a good reason to keep sensitive data on a drive-- that it just be kept in an encrypted folder.

The question of how many security mechanisms you employ involves a trade-off: the time required vs. the increasingly infinitesimal advantage gained. Satisfaction for one person may be paranoia for another.

As I see it, the main goal is to protect sensitive data. Who cares if someone else acquires a Puppy Linux operating system. After all, it's open source and freely available.

All the above having been said, suppose your level of satisfaction were only obtainable if you were able to carry around a USB-Key with your SaveFile encrypted. [I do not recommend SaveFolders if a Pup is to be employed in an environment where the protection afforded by firewalls is questionable. In the absence of a firewall, any hacker could read the data within a SaveFolder even if you haven't loaded that data into ram]. Here's how you could accomplish that.

1. Follow the steps set forth in the prior post to create a camouflaged version of peazip. Go one step further. While your renaming files, rename the bin and script files which include the letters "pea". It turns out that wasn't as hard to do as I had anticipated. Do not include a desktop file creating a Menu entry. The purpose of this Step 1 is to entirely* conceal the existence of peazip so that only you know it's there and by what name to invoke it: the peazip bin -renamed, for example, jdlq, is buried among other bins; only you will know that you can invoke peazip by typing jdlq in a terminal; someone else having acquired your USB-Key won't even know that you've had any reason to include an encryption application, or be able to find it without spending the time to invoke every executable via a terminal until peazip is started.
* This doesn't appear to be possible. See the part of http://murga-linux.com/puppy/viewtopic. ... 904#838904 following the bolded text "Edit: after changing names>".
1a. Delete /root/.peazip if it exists.
2. Remaster your Pup.
3. Create a SaveFile/Folder and install into it everything you would want on your functioning Pup. Repeat Step 1a. Save.
4. Boot into your Pup using the boot parameter pfix=ram.
5. Invoke peazip and encrypt your SaveFile/Folder. If your USB-Key is seen as sdc1, your SaveFile/Folder will be seen as something like /mnt/sdc1/puppysave-xxx(.sfs). [If using a SaveFolder, there won't be an ".sfs" suffix]. Delete the boot parameter pfix=ram. [This assumes you only have one Pup of that derivation on your USB-Key and that no Pup of that derivation exists on the computer you've plugged into].
6. Use the "renaming" procedure discussed in the previous post to delete ".pea" from your encrypted SaveFile/Folder. Anyone examining the contents of the USB-Key will see the file. But unless they know the renaming trick it will be of no use to them.
6a. [Untested] I think you can also rename the puppysave-xxx.sfs part of puppysave-xxx.sfs,pea. But if you do so, you'll have to remember at least the puppysave & sfs parts when you want to change it back.
7. You or anyone else booting into the Pup will only "see" a Pup without a SaveFile/or Folder.
8. Rename your encrypted SaveFile/Folder to add back the ".pea" sufffix and Invoke peazip to decrypt your SaveFile/Folder.
9. Reboot. You Pup will now load your SaveFile/Folder. Before shutting down, delete the SaveFile/Folder, leaving only its encrypted version. The next time you, or anyone else, boots into this Pup, you or they will be at Step 6.
10. If, while at Step 9, you've added any data or applications to your SaveFile/Folder, reboot using the parameter pfix=ram; change the name of your SaveFile/Folder and then invoke peazip to encrypt it. (Step 5).
11. Caution. Test any encrypted SaveFile/Folder before deleting the un-encrypted version to make certain, at least, that you will actually be able to recover the data when you want it. To test, create a folder two layers below the root of your USB-key and move your un-encrypted SaveFile/Folder into it. Then decrypt your encrypted SaveFile/Folder and boot into it.

To each his/her own.

mikesLr

[greengeek]

Just had a tinker with this - I renamed peazip bin file, but doing this still leaves other files and directories such as /usr/local/share/peazip and also the hidden /root/.peazip directory so it does still leave a degree of visibility of the method being used to encypt.

Renaming peazip and leaving it out of the menu will be of some benefit, but its going to be hard to truly hide it.

[mikeslr]

Hi greengeek,

The peazip I was able to man-handle was version (I think) 5.10 which may have been slightly different than the one you sent me, and I assume worked with. Edit: Now that I think about it, after renaming things I didn't check to see if the application worked.

Regarding both, the hidden /root/.peazip folder is only created when/after you open peazip. It's used to retain bookmarks and a config file which will open peazip to the last directory you used. Neither are necessary. In banksy, in a Pup without a SaveFile/Folder, and in a Pup re-using an encrypted SaveFile/Folder --if you don't run peazip before creating the SaveFile/Folder-- it will not be preserved. If using an encrypted SaveFile/Folder as setup in my prior post, the user will have to delete any /root/.peazip folder before rebooting to perform either Steps 2 or 10. [Above post edited. Nice catch greengeek].

The peazip I worked with had 2 folders under /usr: the first was "local" and the second "share," The share folder had the Puppy standard /application/...desktop; with its icon argument pointing to an icon in /share/icons.
The Local folder had within it 2 folders: bin and peazip. The peazip folder contained an executable named peazip, and a folder named "res" containing executables named pea and pealauncher. The bin folder only contained symlinks to the those three executables.
It was possible to first change the name of the peazip executable, the peazip folder, then the names of the executables within it and then create new symlinks in the bin folder, deleting the old.

I'll play around with the version you sent me and see if things break if I change names.

Edit: after changing names>

mikeslr: "I'll play around with the version you sent me and see if things break if I change names."

Things break. All things break.
Peazip, the application, is built using modules. At least one of the necessary modules is pealauncher. Peazip, the executable located at /usr/local/share/peazip, is more-or-less a GUI. In order to compress or encrypt files it "calls" the pealauncher module. If the pealauncher module is renamed, peazip --the executable-- can't find it. Neither compression nor encryption can take place.

It has occurred to me that it may be possible to compile the peazip executable so that it would look for pealauncher by a different name. But that's speculation as I don't compile. But it also occurred to me that, even if it would work, doing so would add a significant amount of work/inconvenience for very little gain in security.

Pealauncher is an executable which can be started by itself. However, by itself --that is not called via the peazip executable-- it can do nothing. The executable, pea, also can be started directly. Except for its routines to securely delete files, pea does not significantly enhance the peazip application. Theoretically, it could be renamed or entirely deleted.

Conclusion: The presence of peazip, the application, can not be entirely concealed as pealauncher can not be renamed. While renaming peazip, the executable, would make the running of pealauncher by opening it directly of no immediate value, the presence of pealauncher on the system could provide a clue that an encrypted folder might be found somewhere on the disk.

mikesLr

[jafadmin]

Worth reading:
https://en.wikipedia.org/wiki/Security_ ... _obscurity

.

[headfound]

Interesting tutorial!
I've always used the portable peazip straight from the developers - extract to a folder and run it there. If you keep it on a removable drive or hidden deep in some directory chances are no one will know.

[jafadmin]

Simply because I have an extreme distrust for "security through obscurity", I'll post this link to a rox addon for encrypting directories. (AES128 & 256)

http://www.smokey01.com/pets/FolderEnc-1.0.pet

It adds right-click menu items to encrypt, decrypt, open, and close.

This is a "security through design" solution. This is a standard install on all my puppy implementations.

[greengeek]

It adds right-click menu items to encrypt, decrypt, open, and close. This is a "security through design" solution. This is a standard install on all my puppy implementations.

Hi jaf - why do you feel this is more secure than hiding an encrypted folder somewhere? You don't think it's a bit obvious to have an encrypted folder in plain sight?

Maybe we could encrpyt a directory with a hidden peazip, then hide the directory, then right click it and encrypt it with FolderEnc. Or vice versa. Maybe I'll add both options to my pup.

[jafadmin]

It adds right-click menu items to encrypt, decrypt, open, and close. This is a "security through design" solution. This is a standard install on all my puppy implementations.

Hi jaf - why do you feel this is more secure than hiding an encrypted folder somewhere? You don't think it's a bit obvious to have an encrypted folder in plain sight?

Maybe we could encrpyt a directory with a hidden peazip, then hide the directory, then right click it and encrypt it with FolderEnc. Or vice versa. Maybe I'll add both options to my pup.

The utility does hide the encrypted folder and leaves a visible empty folder of the same name when closed. I personally don't care if it is visible. It doesn't make any difference from a security perspective. No one is going to break AES256 encryption.

My reason for advocating it's use is that it is crazy easy to use.

Protips
1) ALWAYS USE A STRONG PASSPHRASE.
2) Create the encrypted folder first, then add stuff to it, rather than encrypting an existing folder full of files. Otherwise, someone using file recovery software can find the un-encrypted versions that existed before they were encrypted.

I made a file deletion utility called "afo" that will securely delete files/directories here, so they can't be recovered.

[greengeek]

I made a file deletion utility called "afo" that will securely delete files/directories here, so they can't be recovered.

Excellent work - your results in lab testing Bcrypt are very valuable information. And quite concerning. Another example of the erroneous concept that Linux is safe and reliable as a result of "many eyes" scrutinising the code.

I feel reluctant to use permanent file deletion utilities (or any kind of dd for that matter) as I don't trust myself to choose the right partition/file

Thanks for the link to afo - it would make sense to use such a tool before selling a PC, memory card, camera with inbuilt memory, or any other device that contains a hard drive or flash.

[greengeek]

Protips
1) ALWAYS USE A STRONG PASSPHRASE..

Lets assume that I don't want to use a strong passphrase - maybe because I have had a stroke and know that I can't remember a difficult passphrase - what option would be best for me to create a "locked up" directory containing my personal information??

Do you know of any software that can ask me a specific "security question" that identifies me from a personal event i have experienced in my past?

I know online security interfaces are capable of this, but I would like an offline method that gives me a degree of security without remembering a strong password - because i KNOW for a fact I am going to forget that passphrase and have to write it down.

Many older people have clear memories of their childhood or teenage years, but no memory at all of the bank password they agreed to last week.

I want to find an interface (to peazip or similar) that relies on MYSELF determining the question (and answer) to a security question that only I have experienced and have a memory of...

[mikeslr]

PeaZip for Linux x86 7.0.0 runs flawlessly under dpup-stretch 7.5. From previous experience I expect it should run other 32-bit puppies. Just download and extract the archive. It's executable --oddly placed-- is /usr/share/Peazip. Left-Click to start.

Perhaps someone else can figure out how to manage creation and extractions of archives using the menu. The GUI provides a window onto which you just 'drag and drop' files/folders to be zipped and unzipped, below which are boxes to do more such as entering passwords.

You can find it here, https://www.peazip.org/peazip-linux-x86.html

Will have to test more to see if "camouflaging" discussed in 1st post still works.

[rufwoof]

Many file formats have magic numbers (of varying lengths). gzip for instance has 1f 8b

xxd somegzipfile.gz

will display the byte values (i.e. first two bytes of file content).

tar up a folder, gzip compress that tarball to a filename of mytar.gz ... and running

printf "\xff\xfb" 1<> mytar.gz
mv mytar.gz my.mp3

will replace the .gz magic number (file signature) with that of a mp3 files signature and renaming the file to match completes the pretence. gzip will then refuse to un zip that file because it doesn't look like a .gz file, neither the file name nor magic code match that of it being a .gz file. But equally mp3 will tend to fail to play that mp3 file correctly - as it isn't a mp3 file content, even though its file name and magic code suggest it is a mp3 file.

To restore, revert the magic number back to gzip

printf "\x1f\x8b" 1<> my.mp3

and rename

mv my.mp3 mytar.gz

and the compressed tarball is back to as before.

Alternatively windows bmp might be used as the disguise (magic code 42 4d) ... or whatever.

It's best to use compressed files as the source, as otherwise frequency analysis (counting the number of occurrences of each byte value in the file) can be revealing. Compression has the tendency to equalise the number of occurrences of all byte values.

Be mindful however that forensics will often look for discrepancies and attempted hiding/encryption attracts interest/focus. If a system has specifically used encrypting/hiding, then what was attempted to be hidden can be of greater interest compared to whatever was left open/clear text. If a mp3 doesn't actually play as a mp3 then that file could be scrutinised, run through shift/rotation and frequency analysis etc. to attempt to discover hidden content. And in some countries that could lead you into great difficulties where they refuse to release you until you have disclosed the content/method of hiding, which is fine if there is a real hidden content involved, not so good if there is none (you cannot disclose the 'key' because there isn't one, but they wont release you in their belief there is a key).

Another factor to keep in mind is that today's 'impossible' to break ciphers may become trivial to break in the future. In 8 bit days encryption that would have taken centuries to brute force using 'current technology' can nowadays be broken in seconds. One time pad based encryption is future proof as when correctly applied there is no pointers as to one out of all possible solutions (clear text) being the more probable compared to all other possible solutions. With other methods the probability of one solution being the most likely actual correct solution is more apparent.

If you internationally travel, not storing any encrypted/hidden content on whatever devices you carry is generally the better choice. Data can traverse international borders electronically. If you use one time pads for encryption then the two halves need to be brought together in order to reveal the clear text content. So the 'key' is the two separate locations that the two halves are independently stored/retrieved-from. Best also not to use the same communications paths to retrieve those, otherwise anyone monitoring the data flows could have visibility of both halves. Those channels/tunnels should also use secure encryption, ssh for instance rather than open ftp/whatever. A combination of phone and laptop for instance.

In short, using even small amounts of non-standard encrypting/hiding on a device could be a significant risk. More so if even just one file within the entire system doesn't work/view as it seemingly should.

[rufwoof]

Below are notes dragged out of my archives, so I've not formatted them, just pasted them straight into a CODE box.

One Time Pad (OTP) encryption involves a key the same size as the file being encrypted. Fundamentally it just involves a xor method where a file of random bytes is created, such as by running dd if=/dev/urandom of=keyfile bs=1 count=40000 ... assuming the file to be encrypted is 40000 bytes, and then xor those two files to create the 'pad' file (also 40000 bytes).

In the lower half of this post http://murga-linux.com/puppy/viewtopic. ... 83#1045383 I've posted the C code for a reasonably quick xor program. There's little in the way of validation etc included in that program as I mostly call/run it from scripts and I do the validations in the script.

Once you've created a OTP encrypted file (Pad and random bytes (key) file), you need both of those (xor them) to decrypt. Without both, the P or key files are useless.

There is a trick however you can use with OTP to encrypt two messages and have different keys all encrypted within the same single file. So if someone is aware that you have a encrypted file and forced you to reveal the key/content, you can be selective as to which key you give them and when run it will reveal the content/data associated to that key. It looks like it all worked/decrypted as expected ... however with a second key a entirely different content is revealed.

That's called Deniable Encryption and my notes as per the following outline how that works.

Code: Select all

Deniable Encryption using XOR/One Time Pad.


A and B are the same filesize clear text files with different clear
text contents.

If we A+B (+ here and throughout signifies XOR, which in mathematical
papers is typically written as a + encased within a circle) we generate
a output of cipher C.

Now if we XOR A+C we get the clear text for B; Or if we XOR B+C we get
the clear text for A. 

B+C->A
A+C->B

i.e. given B and C (or A and C), then we derrive both sets of clear
texts A and B

We could have some fun with that. For instance we might set clear text
to be "Man U will win their game tomorrow." being recorded in B. On the
basis that we'll reveal how to decrypt that encrypted message (B and
C files) the next day after the event. In A however we might record a
clear text message of "Man U will lose their game tomorrow" Note here
the exclusion of a full stop in the clear text message, so that compares
in length to the clear text B message length (one says "win" the other 
says "lose", so a 1 character difference is compensated by the addition
of a full stop). With One Time Pad encryption the message and keys are
of the same size, so the introduction of another message into the set
also requires that to be of the same size.

The next day, after Man U actually lost, we release a decryption script
that runs B+C which produces A as its output.

Had however Man U won then the decryption script we release performs
B+C to produce A, and then we A+C (we could have just said look at the
content of B).

Such deception however stands out a mile, its all too easily apparent
as to what was being done. If however we add in additional layers then
we can totally obscure the trick ...

Note that the following encryption mechanism would consist of two keys
named Primary key and Secondary key. Primary key P would be used in the
decryption of cipher text to the true message Mt, it is named primary
because the true message Mt cannot be retrieved without it. Similarly
Secondary key S will be used in generation of fake message M f from
the cipher text C. The sizes of both the keys P and S would be same as
the size of above messages. Take an important note that only Primary
key is user defined but the Secondary key would be generated by the
algorithm.

Encryption involves ...

Mt = true message
Mf = false message
Md = Mt+Mf  ... see Notes (make a backup copy of Mf before running this)
C = Md+P
S = C+Mf

C is shared. S is the key that leads to the dishonest output.
P is the Primary key that leads to the honest output.


Dishonest decryption ...

Mf = C+S

which produces Mf


For honest decryption ...

Mf = C+S
Md = C+P
Mt = Md+Mf
which produces Mt


So generally we release C (Ciphered/encrypted), and can release S
(secondary 'key') that yields the dishonest result. Or we can release
both sets of Primary (P) and Secondary (S) keys in order that the
honest message is revealed. Generally if someone has a copy of C
and under duress obliges us to release the key, then we release the
S key to them ... and they get to see the dishonest deciphered content.
Only when we actually want to reveal the honest content do we release
both S and P. P is in effect the key to enable visibility of the 
honest content. However if an adversary is known to have both C and P,
then we should not release S to them. C and P alone will reveal just
garbage, where you might declare that clearly that key (P) does not go
with that C.


Properties

From the above algorithm a few observations can be made. Notice that
the true message Mt is independent from the fake message Mf. So Mt
cannot be obtained with just the possession of a single key. The
algorithm requires the presence of Mf and Md followed by an XOR
operation of both, to retrieve the true message Mt .

Furthermore, it is mathematically impossible to prove that the cipher
text C has more than one message. Since the cipher text is obtained
using XOR function it may have infinite sets of data each with
corresponding key.

If an adversary somehow gets hold of S and is able to generate the
fake message Mf, there is no way they will know that another message
Md can be retrieved from the cipher text C without the P.

If the coercer possesses the true key P, and the cipher text C, they
can neither prove nor derive that the cipher text contains the true
message Mt. They only find garbage data Md. Apart from this if the
adversary possess P, C and Md they still cannot derive Mf and S by any
mathematically computational way.


Notes

Note that the C program that we use to XOR two files is coded such
that it overwrites the input file with the output (XOR'd) data. We
designed it that way so that its more efficient on disk/ram space.

xor A B will for instance have A containing the original A content
xor'd with the B data content. That generally works well, however the
only place where that is awkward in the above is for the 'Encryption'
stage where we

Md = Mt+Mf
C = Md+P
S = C+Mf

and use Mf twice. So before running the Md=Mt+Mf run we should make
a copy of Mf so that is available in the S=C+Mf step.

Fundamentally, decrypting the true message is initially the exact same as decrypting the fake message, with the addition of using that fake message xor'd with P to extract the true message.

Note also that P, a random set of bytes (key) sized to the same size as the message(s), could alternatively be a much shorter recursive algorithm, perhaps a random number generator algorithm where a password is used to seed that random number generator (pseudo random - so the same seed yields the same sequence of 'random' bytes). Or a hash function such as

Code: Select all

#!/bin/ash

P="letmein"
targetsize=40000  # If our message file(s) were 40,000 bytes

cnt=0
if [ -f P ]; then 
	rm P
fi
while [ $cnt -lt $targetsize ]; do
	P=`echo "$P" | md5sum`
	# use md5sum of P and use the 2nd for 30 characters of that
	# as part of the total P file content and as the input to 
	# the next md5sum calculation
	P=${P:2:30}
	echo -n "$P" >>P
	cnt=$((cnt+30))
done

.. that is less than 400 bytes but that can generate a P file of any target size. It is however rather slow. A C program runs much quicker - for instance ...

Code: Select all

#include <stdlib.h>
#include <stdio.h>

int main(int argc, char *argv[])
{
    int j, r, nloops;
    unsigned int seed;

   if (argc != 3) {
        fprintf(stderr, "Usage: %s <seed> <nloops>\n", argv[0]);
        exit(EXIT_FAILURE);
   }

   seed = atoi(argv[1]);
   nloops = atoi(argv[2]);

   srand(seed);
   for (j = 0; j < nloops; j++) {
        r =  rand();
        fputc(r & 255,stdout);
   }

   exit(EXIT_SUCCESS);
}

saved as hash.c and compiled (devx sfs loaded) using gcc hash.c -o hash, builds to a 8K binary and produces random data at around 25MB/sec. Accepts a unsigned int seed, i.e. numbers 0 up to around 4 billion (9 full/any digits prefixed with a 0..4 digit). A very basic example, where in practice the actual algorithm/code used to generate the (repeated sequence when the same seed is used) might be made much more complex. The algorithm is in effect part of the 'secret' so a number of seeds or modifiers (skipping/reversing bytes ..etc.), make it more secure.

Returning to OTP, a nice feature of not using two keys S and P is that its easier to remember that the shorter hash function such as the above is the tool to access the true text, rather than having two keys of the same size (S and P) that could become mixed up with each other.

Summary

Code: Select all

Encrypt

	Required Files
	
		Mt = true message
		Mf = false message
		P = random bytes file
		(all three must be the same size (P can be larger))
	
	Algorithm
	
		Md = Mt+Mf  
		C = Md+P
		S = C+Mf


Decrypt Fake

	Required Files
	
		C
		S
	
	Algorithm
	
		Mf = C+S


Decrypt Actual

	Required Files
	
		C
		S
		P
	
	Algorithm 
	
		Mf = C+S
		Md = C+P
		Mt = Md+Mf
		
	Basically, to decrypt real - decrypt fake first, then use
	that fake clear text message XOR'd with P to decrypt the real