Author Topic: Encrypting data  (Read 7302 times)

Offline Thunderhawkburner

  • Prepper
  • **
  • Posts: 51
  • Karma: 1
  • New TSP Forum member
Encrypting data
« on: January 21, 2016, 09:39:42 AM »
I'm in the process of collecting all of what I need for my emergency documentation. I will be putting this info on several flash drives and distributing to my sister and brother for further safe keeping.

I already change the numbers for ssn's, credit cards, bank accounts and the like.

What type of encryption programs have others been using? I saw info about the now defunct Truecrypt (sp)  (if defunct is still accurate)...

I use non apple computers.

Offline outoforder2day

  • Survivalist Mentor
  • *****
  • Posts: 399
  • Karma: 37
  • Semper Ubi Sub Ubi
    • The End Of The Tunnel
Re: Encrypting data
« Reply #1 on: January 21, 2016, 02:03:30 PM »
You can still get trucrypt, and it still works... but there were definite issues which mean it could be cracked.
Veracrypt is its successor https://veracrypt.codeplex.com/ https://en.wikipedia.org/wiki/VeraCrypt
Also, don't forget about little old 7zip. A normal zip file's encryption is pretty pathetic, but 7zip has some serious options available. - http://lifehacker.com/five-best-file-encryption-tools-5677725/1685273934

Offline BriGy86

  • Senior Survivalist
  • ****
  • Posts: 269
  • Karma: 10
  • Good news everyone!
Re: Encrypting data
« Reply #2 on: April 03, 2016, 08:39:44 PM »
For flash drives I think I would go with 7 zip.  you can put the installer on the drive un-encrypted (So you have the installer if you need it.) Make your zip or 7z file with all the documents, and password protect that file.  I like the 7z format since you can hide the file names and it only looks like a single file.

Encrypting with the zip format allows the zip file to be opened and the individual file names to be seen, but requires a password to actually open them.

http://www.7-zip.org/

And I also like veracrypt.

Offline Smurf Hunter

  • Survival Veteran
  • ********
  • Posts: 7172
  • Karma: 334
Re: Encrypting data
« Reply #3 on: April 11, 2016, 04:00:15 PM »
Keep it simple.  While you don't want some low level criminal to be able to exploit a found thrumb drive, you also need to make sure you can always get access to the contents in emergencies.  e.g. a public or stranger's PC without any special programs.

password protected .zip and obscuring critical pieces of info like account numbers is as far as I'd go.

Say you want to hide a SSN in plain site.  Format it like a phone number.

e.g.

Bob 538-91-7718
Bob (538) 917-7180

Chances are, any entity smart or capable of defeating your obfuscation already knows that info ;)

Offline Carl

  • Mr HamTastic!
  • Forum Veteran
  • *********
  • Posts: 13105
  • Karma: 716
  • COW?...No ,I haven't seen your cow.
Re: Encrypting data
« Reply #4 on: April 11, 2016, 06:50:50 PM »

Offline fritz_monroe

  • The Defenestrator
  • Administrator
  • Survival Veteran
  • *******
  • Posts: 8748
  • Karma: 159
    • The Homestead Fritz
Re: Encrypting data
« Reply #5 on: April 11, 2016, 07:58:27 PM »
I use Veracrypt for my encryption needs.

I'm not a fan of security by obscurity.  Yes, the average thief won't think that the phone number is a SSN.  But there's no reason to believe that this sort of obfuscation isn't well known in the criminal world.

Offline outoforder2day

  • Survivalist Mentor
  • *****
  • Posts: 399
  • Karma: 37
  • Semper Ubi Sub Ubi
    • The End Of The Tunnel
Re: Encrypting data
« Reply #6 on: April 12, 2016, 08:42:17 AM »
There are many methods available to crack a standard zip file. I really don't recommend them for sensitive data. It's more a feel-good measure and simple deterrent.
If that is acceptable for you, though, go for it.

Offline Smurf Hunter

  • Survival Veteran
  • ********
  • Posts: 7172
  • Karma: 334
Re: Encrypting data
« Reply #7 on: April 12, 2016, 08:49:40 AM »
What all are you putting in these zip files?  I just have scanned copies of insurance policies, photo IDS and important phone numbers.

Like rules for gun safety, multiple compromises would all have to align together for a bad dude to physically obtain my usb, figure out it contained more than Taylor Swift MP3s, Crack the password on the zip, make sense of my obfuscated text.

If it's Red Dawn, and I'm storing the names of resistance fighters, I agree stepping up my crypto is prudent.

Also, the content is "at rest" so 3rd party intercept is not a consideration for me.

Offline Carl

  • Mr HamTastic!
  • Forum Veteran
  • *********
  • Posts: 13105
  • Karma: 716
  • COW?...No ,I haven't seen your cow.
Re: Encrypting data
« Reply #8 on: April 12, 2016, 08:50:39 AM »
There are many methods available to crack a standard zip file. I really don't recommend them for sensitive data. It's more a feel-good measure and simple deterrent.
If that is acceptable for you, though, go for it.

\I do feel safe on a ZIP file that is on a 256 bit encrypted thumb drive...few criminals are smart,most 'stolen data ,is taken from business and government sites or "GIVEN" by the owners on request.

Offline I.L.W.

  • Dedicated Contributor
  • ******
  • Posts: 1004
  • Karma: 203
Re: Encrypting data
« Reply #9 on: April 15, 2016, 09:39:19 AM »
Yeah, 256bit encryption is unbreakable with brute force. As long as the key isn't something stupid like "1234", you'll be fine.

Secret Trick:
<< Save this Profile Image and open in WinRar instead of an image viewer.

For small  Zips (small file size) you can use an old trick. Download your favorite nondescript Cat Meme photo. Now Encrypt and Zip/Rar your documents. Open a command line in the directory they're both stored in.

Code: [Select]
copy /B catpic.jpg+mydocs.zip TopSecret.jpg
This merges the documents into one file called "TopSecret.jpg", which when opened via double-clicking shows the cat picture. But if you right-click, and open with Winrar or comparable tools (not 7-Zip), it will ignore the image and instead see the hidden volume.

If the information is hidden in a directory full of pictures, it's hidden in plain sight. If someone tries to email themselves a copy, the mail server antiviruses will catch the hidden file and block sending it, believing it to be a virus. Image sharing sites will strip out all extraneous data after the image (usually where file metadata like camera model, GPS location etc are stored) as a default security practice. Beyond hiding the data you also limit the means of transmission. Forums are an exception to this rule. In fact many hacker forums have such data hidden in images. Those familiar with /b/ know what I mean. Sometimes cat memes are actually data dumps between doxxers.

To see what I mean, right-click my profile image and save it to the desktop.
Open it up, and you see it's just the downloaded image.
Now open Winrar, navigate to your desktop and open the same image file. Inside you'll find a bit of DarkNet survival reading I came across.

More ways to hide data

This is a great way to hide data on a thumbdrive.

Don't forget about the "Hidden" file attribute.
To take that a step further, create a new folder, save a "blank icon" in that folder, and set the folder icon to this blank icon. You can find one here.
Now rename the folder, but instead of typing letters, turn on Numberlock, and hold down the left [ALT] key. With the ALT key Depressed, on the right number pad, type in 0160. That gives you a blank space that windows treats like a letter, so the folder appears to have no name or icon. It will alphabetically appear at the top of the folder. Put the folder into "List" view, and it's just a little blank area, no visible indication that there is a folder there. Now hide the folder in the file properties for good measure.

You could also insert a batch file of vbs file that deletes the contents of the drive. Put that in the Auto-run portion of the flash drives files and if anyone opens it in a computer that has auto-run enabled, it will be wiped clean. Better yet, disguise the deletion script as something interesting like "My Personal Documents". Odds are a snooping person would click that first. You can find tutorials for that online, I won't go into it here because I won't be blamed if you accidently delete your files, lol.

DIY Auto-revolving Passwords.

This if for you programmers out there.
Code: [Select]
<html>
<head>
<HTA:APPLICATION ID="objScriptFromText" SCROLL="auto" SINGLEINSTANCE="yes">
</head>

<SCRIPT Language="VBScript">
Sub CheckPassword
 pw="password"&Minute(Now)
 If test.value=pw Then
   Msgbox "Correct!!!"
   test.value=""
 Else
   Msgbox "Incorrect Password: " & Minute(Now)
   test.value=""
 End If 
End Sub
</SCRIPT>

<body bgcolor="#FFFFFF">
<input type=password ID="test" value="333"></input>
<input type=button value="submit" OnClick="CheckPassword"></input>
</body>
</html>

As you can see, the password is "password" + the current time in Minutes. So at 12:31, the password is "password31". At 12:57, the password is "password57".
This is simplistic, but you could do math with the time, or use it in a case statement to select from many different passwords. Then lock your files within an application whose password changes every minute. Write a companion app  as an authenticator on your smartphone that tells you what the password for the document is right now, and suddenly the contents are tied to another device. If the files are stolen, without also having an authenticator, it's useless. This can be integrated into encrypted volumes just as easily. I just did the example as a simple .hta file so you can try it out. But it's very easy to scale up the basic principal to much more complex scenarios.



Offline Smurf Hunter

  • Survival Veteran
  • ********
  • Posts: 7172
  • Karma: 334
Re: Encrypting data
« Reply #10 on: April 15, 2016, 11:24:45 AM »

As you can see, the password is "password" + the current time in Minutes. So at 12:31, the password is "password31". At 12:57, the password is "password57".
This is simplistic, but you could do math with the time, or use it in a case statement to select from many different passwords. Then lock your files within an application whose password changes every minute. Write a companion app  as an authenticator on your smartphone that tells you what the password for the document is right now, and suddenly the contents are tied to another device. If the files are stolen, without also having an authenticator, it's useless. This can be integrated into encrypted volumes just as easily. I just did the example as a simple .hta file so you can try it out. But it's very easy to scale up the basic principal to much more complex scenarios.

That methodology is sound.
It's like 2 phase authentication for hill billies on a budget.  :)

I use Authy and Google Authenticator on my phone.  Those get used for a variety of things, like resetting internet password, or super sensitive things like VPN to production servers and bitcoin wallets.

The basic idea is you must "know" something (your password)  and "have" something (the rotating authenticator code from the phone app).

Offline Hurricane

  • Survivalist Mentor
  • *****
  • Posts: 596
  • Karma: 18
Re: Encrypting data
« Reply #11 on: April 15, 2016, 12:23:39 PM »
 :popcorn:

Offline I.L.W.

  • Dedicated Contributor
  • ******
  • Posts: 1004
  • Karma: 203
Re: Encrypting data
« Reply #12 on: April 15, 2016, 12:48:09 PM »
That methodology is sound.
It's like 2 phase authentication for hill billies on a budget.  :)

I use Authy and Google Authenticator on my phone.  Those get used for a variety of things, like resetting internet password, or super sensitive things like VPN to production servers and bitcoin wallets.

The basic idea is you must "know" something (your password)  and "have" something (the rotating authenticator code from the phone app).

Exactly. I went with a very simplistic example so non-coders could still somewhat follow it. But it's easily expandable.

Case Min(now): 00
 temp=Trunc(Now()-LastAccessTime())*25
Case Min(now): 01
 temp=Trunc(Now()-LastAccessTime())*18
Case Min(now): 02
 temp=Trunc(Now()-LastAccessTime())*32
Case Min(now): 03
 temp=Trunc(Now()-LastAccessTime())*45
Case Min(now): 04
 temp=Trunc(Now()-LastAccessTime())*6
...

Split temp into 2 byte lengths and convert to Char for password. Password becomes variable length and highly randomized. Throw in some Pi math and a random seed function...

Could even make the authenticator connect to a remote server and set a flag with math on the server the app would look for making it difficult to reverse engineer the authenticator. In the absence of such a flag, all passwords fail. Add in red-herring variables that work on similar math but functionally do nothing so memory analysis of the app is difficult. You could have 10,000+ calculated passwords every minute, only one of which is functional, then rotate between them based on date in a non-linear fashion. And this is just the password system, not even considering the encryption. This is why Hackers, Corporations, and Government agencies rely on metadata rather than decryption and message decoding. A novice could in an afternoon code something unique to them which would take decades to crack.

The big thing is never to set anything like a Boolean "Authenticated" variable the code looks at, as anyone could toggle the variable in memory. This is why those RSA keyfobs are fun, a moron could bypass them in a minute, to spite having awesome encryption because developers are lazy and take shortcuts with authenticated flags which can be duped. This is only good for single authentication / single action applications. That's why Blizzards battleNet authenticator doesn't work. Keeps the script kiddies from any mischief, but that's about it. Similar integration issues abound with any business running SalesForce (poor implementation is common). Instead, set boolean variables in the code to change on authentication, but never actually look at them. If an unexpected change occurs to one of the variables, it's easy to send an alert. Instant HoneyPot.



Offline Smurf Hunter

  • Survival Veteran
  • ********
  • Posts: 7172
  • Karma: 334
Re: Encrypting data
« Reply #13 on: April 15, 2016, 02:07:08 PM »
The only issue I see with using a rolling timestamp would be for remote systems where the clocks are potentially out of sync.
I know, it's 2016 and every machine connected to the internet should potentially be synced with an NTP server, but I've seen this break frequently with big scale e-commerce systems.

Back to the topic - I think we've drifted from encryption of information into authentication of people.   ;)