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 Thu 28 Jul 2016, 06:41
All times are UTC - 4
 Forum index » Advanced Topics » Additional Software (PETs, n' stuff) » Security/Privacy
pcrypt
Post new topic   Reply to topic View previous topic :: View next topic
Page 1 of 1 [13 Posts]  
Author Message
rufwoof


Joined: 24 Feb 2014
Posts: 1413
Location: UK

PostPosted: Fri 15 Jan 2016, 23:19    Post subject:  pcrypt
Subject description: File encrypt using one time pad (keysize = filesize)
 

pcrypt single file encryption. pcrypt generates a one time keyfile that is the same size as the message (file) using /dev/urandom sourced random data. /dev/urandom utilises hardware/environment to induce randomness - in effect purely random. For truly random keys One Time Pad encryption (with keysize = message size) is proven uncrackable.

SFS located here http://murga-linux.com/puppy/viewtopic.php?p=881776#881776

Puppy's small size makes it great for running purely in ram. If you store .fck (encrypted) file/data on a remote server (cloud - such as googledrive) and keep the associated .key file on a USB, then you can download the file (into ram) and decrypt that (using the key on the USB) and work on the file ... and then re-encrypt and upload the revised version to the cloud (and replace the old key with the new one on the USB) ... all without any decrypted data being recorded on your local laptop/PC. Once powered off the ram is cleared such that if the laptop is stolen your data is not available to the thief.

The .key file is useless without the associated .fck (encrypted data) file. The .fck file is useless without the associated .key file. And run in ram no cache of the unencrypted data remains available once powered down.

Each file has its own unique key (one time pad), and you don't have to worry about remembering passwords. The only downside is that each file takes up twice the amount of disk space, one for the encrypted data, the other for the key - however more modern hardware usually have copious amounts of disk space.
Back to top
View user's profile Send private message 
rufwoof


Joined: 24 Feb 2014
Posts: 1413
Location: UK

PostPosted: Sun 17 Jan 2016, 12:23    Post subject:  

https://www.cloudcracker.com/ - for a fee offer a online cloud service that brute force crack attacks the following

WPA/WPA2
NTLM
SHA-512
MD5
MS-CHAPV2 (PPTP/WPA2-E)

pcrypt is resilient to such brute force attacks as some other meaningful output (decrypt) is just a likely as the actual unencrypted message. Given the universe of meaningful outcomes, the actual original content remains cloaked even if there was sufficient power/time to decipher all possibilities.

The downside of having to store key files has the benefit that you don't have to think up and remember passwords (which can lead to duplication (same password used to access multiple files/content)). With a unique key per file, even in the unlikely event that was cracked (extremely unlikely) that doesn't help in cracking any other files (as there's a single unique key for each file).
Back to top
View user's profile Send private message 
slavvo67

Joined: 12 Oct 2012
Posts: 1076
Location: The other Mr. 305

PostPosted: Thu 28 Jan 2016, 21:28    Post subject:  

I like this idea. It'll have to wait until the weekend but I look forward to trying.....
Back to top
View user's profile Send private message 
bruno

Joined: 08 Mar 2012
Posts: 83
Location: Belgium

PostPosted: Fri 29 Jan 2016, 09:48    Post subject: pcrypt otp  

Rufwoof, thanks for this great little utility, it works great on tahrpup605.
What would be even greater, is if you would make some gui so that OTP can be used with puppy as a way to communicate, that is: first create the one time pads, share them with your correspondent when you meet in person, and then later when you are in different locations, communicate encrypted by using those pads.
That would combine the unbreakable security of OTP encrypted communication, with the convenience of puppy.
Back to top
View user's profile Send private message 
rufwoof


Joined: 24 Feb 2014
Posts: 1413
Location: UK

PostPosted: Wed 03 Feb 2016, 18:51    Post subject:  

Its quite useful when you have a confidential document/spreadsheet that you'd hate for others to see (financial accounts etc.). Keep one of the encrypted pair on googledrive or wherever, so no one with access to that can see it, and the key even on your laptop alone without that other half is pretty useless, so if your laptop is lost/stolen the spreadsheet is confidential/secret - unless of course they figure out your googledrive or wherever account login/password.

To open the spreadsheet pull the .fck file down from google to be alonside the .key file, click and the spreadsheets available to work on/use. When done encrypt again and upload the .fck to google, leave the .key as-is and its secure again. A nice aspect is that you don't even have to remember or think up a password (and each file is in effect secured by its own unique uncrackable password).

I now have mine set up in DebianDog Jessie to be a desktop icon that I can drag/drop a file onto which removes the original and creates the .fck and .key files. I've also associated .fck files to pcrypt so when the two files are alongside each other I can left click the .fck file and both the .fck and .key files are replaced by the unencrypted file.
Back to top
View user's profile Send private message 
slavvo67

Joined: 12 Oct 2012
Posts: 1076
Location: The other Mr. 305

PostPosted: Sat 06 Feb 2016, 19:35    Post subject:  

I am able to use it in terminal, however I am getting an error with the gui. /usr/lib/gtkdialog/xml_info No such file or directory (line 77)

Same with xml_button-icon and xml_scalegrip. This is on Barry's QU 6.21 32 bit.

Also, do you know what kind of encryption it is using?

Thank you,

Slavvo67
Back to top
View user's profile Send private message 
rufwoof


Joined: 24 Feb 2014
Posts: 1413
Location: UK

PostPosted: Fri 12 Feb 2016, 21:27    Post subject:  

slavvo67 wrote:
I am able to use it in terminal, however I am getting an error with the gui. /usr/lib/gtkdialog/xml_info No such file or directory (line 77)

Same with xml_button-icon and xml_scalegrip. This is on Barry's QU 6.21 32 bit.

Also, do you know what kind of encryption it is using?

Thank you,

Slavvo67

Sorry Slavvo only noticed your posting just now.

The GUI no longer works for me either since I've moved over to DebianDog-Jessie. I just use the pcrypt binary alone now. Have it as a desktop icon so I can drag/drop onto that and have a file association to pcrypt for .fck files, so a right click open with pcrypt and the file is decrypted assuming the .key file is in the same directory.

Uses a key that's generated from /dev/urandom, where the key file is as long as the message (file being encrypted). The two are XOR'd. One time pad style - where provided the key file is truly random its the only proven uncrackable choice.

Typically I work on a confidential spreadsheet and once edits are complete I drag the saved file to the desktop pcrypt which creates a .fck and .key files. .fck can then be uploaded to googledrive or wherever, .key file retained securely (USB perhaps). When it comes to work on the spreadsheet again, download the .fck file from googledrive, move the .key file from USB to the same directory as the downloaded file, right click the .fck file and select open with pcrypt. ..... Repeat as required (new unique key for each saved version). Googledrive content is safe (encrypted content that's useless without the .key file), if laptop is stolen but USB is safe then the content remains safe (even if they have access to your googledrive account) and the content is recoverable even without the laptop. Loose the USB or if it stops working and your totally stuffed. Consequently I've been looking into RAID mirroring of USB's (two USB's connected via a USB hub where saving results in two copies, one copy on each of the two USB's). For now I'm still doing that copy of the key file to two USB's manually.

I run Linux in ram only, so there's no prospect of unencrypted recovery from the filesystem. If you run a full install/disk puppy/linux then if the laptop is stolen conceptually deleted files could be recovered/restored.
Back to top
View user's profile Send private message 
6502coder


Joined: 23 Mar 2009
Posts: 276
Location: Western United States

PostPosted: Tue 16 Feb 2016, 20:44    Post subject:  

Just a couple of suggestions for options that might be useful in certain situations.

1. An option to NOT delete remove the original plaintext file after encryption. Bcrypt has this option.

2. An option to send the decrypted text to stdout, instead of to a file. This would allow sending the decrypt down a pipe, for example to "grep" or to "less", with the additional security that you never have the decrypted plaintext sitting on the hard disk or flash drive.
Back to top
View user's profile Send private message 
rufwoof


Joined: 24 Feb 2014
Posts: 1413
Location: UK

PostPosted: Tue 16 Feb 2016, 21:22    Post subject:  

Useful suggestions. But just to clarify I wrote pcrypt for my own purposes ... which it fulfills and accordingly I won't be posting updates/changes/extensions. The C source code is included and can be modified/recompiled as deemed to be appropriate for your own needs.

I have been considering adding some changes for myself, such as including a secure delete of the original unencrypted file and adding a secure hdparm -r0 /dev/sdb and hdparm -r1 /dev/sdb type toggle to switch the USB from being read only to read/write as part of key file storage. Primarily with a view to storing more stuff (docs etc) in the Cloud so that if a virus does implement a disk encryption type payload then the USB's are less prone to being ransomed (original keys and encrypted cloud data providing the unencrypted data/docs content unimpeded by any virus). As part of that I'd include the writing of keys to two USB's simultaneously for better hardware (USB) failure protection (had been considering using RAID mirroring, but easier to provide that duplication functionality in code). If automated cloud transfer is also implemented then obviously it all becomes rather personal/specific and no longer appropriate for general application. Hence I don't want to have to maintain two different versions, one for others, one for myself.
Back to top
View user's profile Send private message 
slavvo67

Joined: 12 Oct 2012
Posts: 1076
Location: The other Mr. 305

PostPosted: Tue 16 Feb 2016, 23:06    Post subject:  

Well, I like this project quite a bit so I hope you do enhance what you made and share it with the community. Pcrypt should live on and seems to be a quality security alternative. As you suggested in my PM, I've attached a link to your Pcrypt with a YAD wrapper. This places a desktop icon (a little red chili) which provides 4 options: Encrypt 1 file, Decrypt 1 file, Encrypt a directory, Decrypt a directory. The directory options simply use a for loop so the individual files still receive individual keys.

https://drive.google.com/file/d/0B672gIlbo7iVN1RQZ2pOTUQtZjg/view?usp=sharing
Back to top
View user's profile Send private message 
slavvo67

Joined: 12 Oct 2012
Posts: 1076
Location: The other Mr. 305

PostPosted: Sat 12 Mar 2016, 01:00    Post subject:  

I was thinking that changing the name of the file (hiding the name) before encrypt would be another interesting step in the encryption process. Converting the true file name back upon decryption. Idea
Back to top
View user's profile Send private message 
6502coder


Joined: 23 Mar 2009
Posts: 276
Location: Western United States

PostPosted: Wed 16 Mar 2016, 01:24    Post subject: using bogus file names
Subject description: changing filenames to make their contents less obvious
 

slavvo67 wrote:
I was thinking that changing the name of the file (hiding the name) before encrypt would be another interesting step in the encryption process. Converting the true file name back upon decryption. Idea

This is a good idea and one that I use myself sometimes.
But if you are encrypting LOTS of files, how do you keep track of what their original names were?
How do you know which file is which when the names no longer tell you what's in them? Confused
Back to top
View user's profile Send private message 
slavvo67

Joined: 12 Oct 2012
Posts: 1076
Location: The other Mr. 305

PostPosted: Wed 16 Mar 2016, 21:46    Post subject:  

Well, my thought is upon name change, having a file that would cross reference the old file name against the new file name. Maybe a front-end gui that would call the file by its original name vs the encrypted name. Of course, if you blow up your Quirky or other puppy save, all is lost. Laughing
Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 1 of 1 [13 Posts]  
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Advanced Topics » Additional Software (PETs, n' stuff) » Security/Privacy
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.0545s ][ Queries: 11 (0.0035s) ][ GZIP on ]