Encrypting Your Laptop Like You Mean It

[labbe5]

https://theintercept.com/2015/04/27/enc ... like-mean/

If you want to encrypt your hard disk and have it truly help protect your data, you shouldn’t just flip it on; you should know the basics of what disk encryption protects, what it doesn’t protect, and how to avoid common mistakes that could let an attacker easily bypass your encryption.

[BarryK]

A good read.

As it says, disk encryption protects you if someone get hold of your computer physically.

I finally decided to tackle this in EasyOS. The latest version, 0.9.4, uses the per-folder encryption available with the ext4 filesystem (also available for f2fs).

When boot from a USB drive for first time, a password is asked for, then the "working partition" is created on the drive, with encrypted folders.

Everything is in those folders, so everything is encrypted.

The downside of course, the password has to be typed in at every bootup, and you have to remember it.

[foxpup]

The downside of course, the password has to be typed in at every bootup, and you have to remember it.

But by typing it that often, it becomes very easy to remember

[ITSMERSH]

Best encryption ever still remains:

- don't save relevant data on the computer's drives...

[BarryK]

This is interesting, it shows the performance hit with the various types of encryption, and with none:

https://www.phoronix.com/scan.php?page= ... -418&num=1

Running EasyOS with the ext4 inbuilt encryption (fscrypt), I don't notice any slowdown. But then I suppose, if an unencrypted app opens in say 1 second, you wouldn't notice if it took say 1.2 seconds.

[rufwoof]

This is interesting, it shows the performance hit with the various types of encryption, and with none:

Part of encryption can (often) involve(s) compression, as compression has the effect of equalising (approximately) the number of occurrences of each character (0..255). For throughput, lz4 is one of the fastest, doesn't compress as tightly as some alternatives, but is lightening fast - and under multi-core it can throughput at ram speeds whilst typically halving the data size due to compression.

Much of those speed tests I suspect reflect such compression.

In other areas of Puppy style, consider whether its more appropriate to wait some during boot to transfer the whole sfs into ram in one go, or to just read on-demand. Often once read in once the code will remain memory bound (cached), such that second/subsequent runs of the same code don't see any differences in speed. Loading on demand saves on memory space, if you don't run gparted for instance during a session then it never gets loaded into ram space, whereas with loads sfs into ram it does take up memory space.

Broadly with puppy style the conclusion I came to was that it is better to have a faster boot time and not load the sfs into ram, and accept slower first run speeds when a program is run for the first time during a session, but generally see comparable load time speeds for subsequent runs. My preferred compression choice is lz4 for its potential ram speed like throughputs, followed by lzo level 1 when lz4 support hadn't been incorporated into the kernel. On older mechanical disks that can make a significant/noticeable difference, less so however with solid state (future more common) devices (and less so also with available ram/memory space - given that the difference between say 400MB and 500MB ram utilisation when 8, 16, 32GB type ram being available is negligible). Similarly with more complex encryption methods, piping a stream through 3 or 4 different encryption algorithms so as to increase security increasingly becomes less negligible under multi-core. Higher/slower encryption however is more preferred as what took 300 years to break a encryption a decade ago might be achieved in minutes under more recent hardware, that could reduce to fractions of seconds in the future, so higher encryption algorithms defer how quickly it becomes viable to break the encryption, excepting quantum computers becoming real world viable. The ultimate is one time pad encryption as that is the only mathematically proven uncrackable providing the random numbers are truly random (you can get reasonably close such as generating 'random' numbers based on disk spin speed, mouse movements ...etc. all being used as part of generation of a random number - that whilst pseudo random, are pretty close to being truly random). Again that is my personal preference, which has the added benefit you don't have to remember a password, but does involve having a "key" that is the same size as the data (in effect one time pad xor's each data byte with a random byte, so only when both the encrypted bytes + random bytes are present can they be xor'd back again to determine the actual data byte). Again provided the data was first compressed so as to have near equal occurrences of all byte counts, then mathematically all possible unencrypted sensible/intelligible outcomes have equal probability such that the real unencrypted content cannot be known with certainty in the absence of any other clues/indications. A four byte encrypted set for instance could just as well be 'Jack', 'John', 'Fred' .. etc as it could be 'them' or 'they' ...etc. And even if you knew that the four bytes corresponded to being Fred, that still would not help with figuring out what the rest of a message might contain (with other encryption methods, having deduced part of the message can be the means to deduce how the algorithm/seed was sourced such that the rest of the message might be figured out).

Giving up some speed and focussing less upon compression and space concerns, to instead focus upon future proofing via good quality encryption is the way-to-go IMO as speed and space issues will fade with time. Having to perhaps use two USB's/SDD's as part of decryption however also has negative elements. Secure provided only one or the other is available/lost, but risk of loss of data if one or the other is corrupted/lost and the bother of having two devices to attach before access is achieved.