Full-disk encryption Puppy for regular user (Solved)

[rufwoof]

It sources random (key) data from /dev/urandom, so creating on another platform would be subject to that 'device' being available i.e. Linux. For decoding it uses byte size processing (XOR) so could be compiled to extract on other platforms. The C code would need to be changed/compiled to reflect that though.

[rufwoof]

In some countries you can be held in custody until you reveal your passwords. In which case obvious encryption is totally negated. Worse still is if something looks like its encrypted but actually isn't then you could get trapped into a prolonged situation where they think you are intentionally refusing to reveal a password where in reality you don't even know of any password for what they are referring. "OK we'll put you back into custody for another couple of weeks and then take you back into court to ask yet again what the password is for xyz".

Rather than in-your-face encryption, blatantly obvious that encryption is being used, disguised encryption could be the better choice. If you are obviously using encryption for anything, then they may find things that look to fit the bill, but that you haven't declared the password for. You do however have to take steps to deeply disguise that intentional encryption is being used, no clear text scripts for instance to do the opening/closing. Along with plausible deniability - where the likes of a potentially encrypted file isn't actually a encrypted file but instead is something else.

Fundamentally anything without a MAGIC code that contains seemingly random data might be considered as potentially being a encrypted storage. The likes of xor based encryption can have its frequencies inspected (by xor'ing with itself shifted and repeated). If both the data and key aren't normalised to have around the same number of occurrences of all bytes then that can reveal partial content, enough to give clues as to the content or method used for encryption.

In short, securing data using encryption could be a greater risk than not. Even if heavily disguised, forensic analysis could indicate, perhaps falsely, that encrypted content might be being hidden. Better to perhaps not use encryption at all other than 'standard' encryption methods (as contained in browsers etc.), and instead retrieve secure data from a secure server via a secure link as/when needed rather than physically crossing borders with encrypted content included within your laptop/device.

[James186282]

One Time Pad encryption for puppy?!?! Congrats to you and thanks for doing this. I was pondering the onetimeness of a large random file. For true randomness I believe there was some project that recorded static and sender and receiver were supplied the same file. Each encypted file ate away part of the static noise random file so it was never used twice. Anyway your project is great and am glad someone else is doing this.

I know there are some tools to verify random number generation but can't think of the names of them off the top of my head. It would be interesting to see if Puppy's random number generator is truly random.

[rufwoof]

Basically /dev/random and /dev/urandom are both sourced with pretty much real world 'random' entropy (activities) from bootup, but where as that entropy is eaten at a faster rate than being added can result in /dev/random blocking ... so you end up with as good as 'open' encryption (zeros loaded into your 'random' buffer. Whilst urandom resorts to pseudo random, so at least the buffer content looks like random content).

Good enough for most except the more extreme cases. As the amount of entropy before hitting the limit is also random, so any potential 'key' that opened ineligible clear text could still be considered as having randomly occurred as equally any other possible ineligible clear text.

I did have a play with merging 'random' sources, such as using a simple/short key ... a entered 'password/string' and then md5 that to produce a 16 byte sequence and then using random choices of a substring formation from that as the 'string' into the next md5 16 byte sequence ... etc. ... and then randomly selecting to use random numbers of bytes from either that stream or the (potential) pseudo /dev/urandom stream. But that did lead to longer encoding times. Not really worth it IMO. If you did need that sort of level of security then you wouldn't be running a Puppy.

My pcrypt as-is doesn't compress the input, its assumed that's already been done, and compression is important as that normalises the data (approximately equal number of occurrences of all bytes 0..255) which is important as otherwise Xor'ing with itself and shift/repeat can yield frequency counts that could indicate/reveal part of the content.

A cautionary note is that if you use encryption then that could lead to more problems than not having used encryption. Cross some international borders for instance and if its apparent you are familiar with i.e. are using encryption outside of what a conventional off-shelf program might do, then that could result in inspection indicating potential encrypted content, that isn't actually encrypted content (random looking data content). Which could lead to you being detained in custody until such times that you reveal the password/method. They believe you are intentionally not disclosing a password for something where no actual password exists. Maybe taking you back into court every couple of weeks, keeping you in custody between times, for something they believe you are withholding, but aren't. https://en.wikipedia.org/wiki/Key_disclosure_law

I guess its best not to travel internationally with electronics that could land you in a trapped position, which includes smart phones, usb's/DVD's etc.. And instead rent/buy/use/dispose such electronics internally within each country. Have a ssh private key written down on paper and you could enter that into a rented/bought device and electronically transfer data/OS across boundaries in a secure manner (assuming the hardware was trustworthy).