Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Sun 26 Apr 2015, 04:19
All times are UTC - 4
 Forum index » House Training » HOWTO ( Solutions )
Secure Sensitive data with Peazip Encryption and Camouflage
Moderators: Flash, Ian, JohnMurga
Post new topic   Reply to topic View previous topic :: View next topic
Page 1 of 1 [10 Posts]  
Author Message
mikeslr


Joined: 16 Jun 2008
Posts: 916
Location: Union New Jersey USA

PostPosted: Wed 17 Dec 2014, 10:04    Post subject:  Secure Sensitive data with Peazip Encryption and Camouflage  

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.”

What, peazip can encrypt files? Well, the pet The Asterisk created can. And the gtk-version runs on Slacko 5.6. Banksy, which I've been playing with, is based on that version. You can get The Asterick's pet here: http://www.silverdollarsolutions.com/PuppyLinux/asterisk/PeaZip/5.1.0/. I don't know what the other “addl_formats” and “unace_plugins” pets there do. I'll have to google some more. But what the Peazip pet does without those additions is
(1) offer a choice of compression techniques –but only 7z, pea, and Zip* enable encryption;
(2) offer a number of encryption techniques, including AES256;
(3) let you select by high-lighting any number of files and folders, name the archive to be created, and
(4) by clicking a little “encryption” radio button before creating the archive type in the password to be associated with it.

Later, you can move or copy the encrypted archive elsewhere. I created one with a “zip” ending. When I tried to open it with 7Zip, it ran and grumbled and spat out
files and folders with the same names as those in the archive, but devoid of the content.

*Arc supposedly enables encryption, but attempting to create arc files generated errors. Pea seems like a good choice. The icon of the archive generated looks like a binary, with, however, the suffix “.pea” added to its name. Xarchiver can't open it; in fact, unless set to show even non-supported files, won't even see it. 7Zip couldn't open it, even after typing the password. My password had only 6 alphanumericals. Bcrypt complained that the password was too short. How often are laziness and a poor memory an asset? Peazip, of course, opened it.

So it might pay to give boring names to the files and folders you want to protect. In fact, why even provide a glaring hint that you're trying to protect anything. If you're feeling even a little ambitious, you can rename the archive by deleting its “.pea” ending. Then, not even peazip will open it – until you restore its suffix.

Perhaps I shouldn't have recently watched a documentary on how camouflage and misdirection helped the Normandy Invasion succeed. I particularly liked the blow-up tanks which were part of the make believe army being “assembled to invade Pas de Calais”.

Peazip, IIRC, shows up on the Utility Submenu with a “Peazip” Icon and a tool tip that it's an archiving application. But that's information to help humans. Operating systems don't care. So I renamed

/usr/share/applications/peazip.desktop to

/usr/share/applications/Anti-alias-pixel-fix.desktop

and changed the arguments in that file to:

[Desktop Entry]
Encoding=UTF-8
Name=Anti-alias-pixel-fix
GenericName=Anti-alias-pixel-fix
Comment=adjust pixelation on some computers
Exec=peazip*
Icon=/usr/share/icons/hicolor/48x48/apps/icon.png**
Type=Application
Categories=X-Desktop;X-Desktop-appearance;


* This is a call to the binary. Browsing thru folders of The Asterisk's pet, decompressed, I found that binary and could change its name. Peazip would open. But I didn't test it. There were also symlinks to binaries and scripts which included the name pea –such as pealauncher. Things got broken when I attempted to change those names. I'll leave such additional misdirection to someone who better understand the workings of Peazip.

** I deleted the peazip.png which had appeared at the location specified in this argument. While the “icon” icon appeared on the menu, once the application started the folder appearing on the taskbar had the peazip image. A thorough search of folders and files within, “now”, Anti-alias-pixel-fix's structure failed to reveal where it came from.

The Asterisk's Peazip pet –or at least my camouflaged version which I had converted to an SFS-- ran on Slackos and Ubuntu based Pups, including Tahr and LxTahrPup. But not Lupu. If you do a wellminded search, http://wellminded.net63.net/ you'll find instructions for running Peazip on Lupu, Racy and Wary. Carolina, has a version available from its repo.

I'm a great fan of vicmz's Openbox + Lxpanel and employ it whenever possible. But it has one small weakness: sometimes applications don't show up on its menu. That was the case with my camouflaged peazip.sfs. Switching the same Pups to use JWM as window-manager menu entries appeared.

A camouflaged peazip may be of significant value to banksy. Its intended purpose is to provide a secure OS for online banking and economic activities. Designed to run from a CD/DVD without a SaveFile so that you always boot into a pristine OS. It provides an easy --even noob-friendly remaster to create your personalized CD/DVD. But it can be run from a USB-Key. Access to storage media, while possible, has been concealed. If I'm traveling, I'm far more likely to carry a USB-Key than a CD. And I may want to take with me sensitive data, or create records of transactions containing sensitive data while on the road. Peazip –especially a camoflaged version-- can provide the ability to easily encrypt that data and store it on my USB-Key.

Leaving me with the question: Am I more likely to remember peazip's secret identity, or –if I delete the .desktop file, thus eliminating any menu entry-- that I can open it by typing “peazip” --without the quotes-- in a terminal?

mikesLr
Circumcised peazip archive.png
 Description   Camoflaged peazip archive
 Filesize   3.88 KB
 Viewed   376 Time(s)

Circumcised peazip archive.png

Back to top
View user's profile Send private message 
mikeslr


Joined: 16 Jun 2008
Posts: 916
Location: Union New Jersey USA

PostPosted: Mon 06 Apr 2015, 12:15    Post subject: Encrypt SaveFile/Folder with Peazip
Subject description: Possible -- but not necessary
 

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.php?p=838904#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

Last edited by mikeslr on Tue 07 Apr 2015, 12:55; edited 4 times in total
Back to top
View user's profile Send private message 
greengeek

Joined: 20 Jul 2010
Posts: 3019
Location: New Zealand

PostPosted: Mon 06 Apr 2015, 15:03    Post subject:  

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.
Back to top
View user's profile Send private message 
mikeslr


Joined: 16 Jun 2008
Posts: 916
Location: Union New Jersey USA

PostPosted: Mon 06 Apr 2015, 21:03    Post subject: Renaming peazip files  

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. Embarassed
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. Rolling Eyes Twisted Evil

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
Back to top
View user's profile Send private message 
jafadmin

Joined: 19 Mar 2009
Posts: 479

PostPosted: Tue 07 Apr 2015, 14:35    Post subject:  

Worth reading:
https://en.wikipedia.org/wiki/Security_through_obscurity

.
Back to top
View user's profile Send private message 
headfound


Joined: 24 Jun 2006
Posts: 353
Location: England

PostPosted: Tue 07 Apr 2015, 17:49    Post subject:  

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.

_________________
Download a better Computer Smile
Puppy Linux Song
altern8life
Back to top
View user's profile Send private message Visit poster's website 
jafadmin

Joined: 19 Mar 2009
Posts: 479

PostPosted: Tue 07 Apr 2015, 19:16    Post subject:  

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.
Back to top
View user's profile Send private message 
greengeek

Joined: 20 Jul 2010
Posts: 3019
Location: New Zealand

PostPosted: Wed 08 Apr 2015, 03:46    Post subject:  

jafadmin wrote:
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.
Back to top
View user's profile Send private message 
jafadmin

Joined: 19 Mar 2009
Posts: 479

PostPosted: Wed 08 Apr 2015, 12:38    Post subject:  

greengeek wrote:
jafadmin wrote:
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 Wink
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.
Back to top
View user's profile Send private message 
greengeek

Joined: 20 Jul 2010
Posts: 3019
Location: New Zealand

PostPosted: Wed 08 Apr 2015, 14:05    Post subject:  

jafadmin wrote:
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 Smile

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.
Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 1 of 1 [10 Posts]  
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » House Training » HOWTO ( Solutions )
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.1092s ][ Queries: 12 (0.0049s) ][ GZIP on ]