Aaron Toponce

For a great primer on ZFS (on Linux) in general there's this website[1] by Aaron Toponce that is very well laid out. Specifically see the section on snapshots & clones, as well as sending/receiving. Also don't forget that you can make a ZFS pool out of any block device, this includes normal files mounted as a loop device! So a great way to experiment w/ learning how to manage a ZFS pool is to just create a few sparse files, add them to a pool, and just start messing around with it. (For actual production pools though always put ZFS as close to the actual disks as possible.)

What's really cool about serialized snapshots is that once native encryption support lands in ZFSonLinux you'll be able to send encrypted volumes over the wire. The data blocks don't have to be decrypted to be serialized or checked for integrity, so you don't even need the decryption key to do incremental sends! You can send your backups to an untrusted remote pool that never has to have knowledge of the decryption key!

(You can also serialize snapshots to files, which is useful for say writing them to detachable media to sneakernet them. If you want to do incremental sends though the receiver does have to be an actual zpool.)

Some other helpful hints would be using something like `mbuffer`[2] on the sender & receiver. This is handy for spinning rust pools, so that your disks don't have to wait on the network before seeking to the next blocks to be sent.

Also ZFS lets you delegate permissions so you…

I did the math myself at one point, but I lost the link. However, here's a reference for the same kind of thing:

https://pthree.org/2016/06/19/the-physics-of-brute-force/

The total energy output of a supernova is enough to count up to 2^220, making a lot of generous (invalid) assumptions. You'd need 2^36 supernovas to just count up to 2^256, never mind actually running SHA256. At minimum.

There are circa 2^38 stars in the Milky Way, and they're not going to all go supernova. Add in the actual cost of compute and it just isn't happening, not in this galaxy.

For 128-bit crypto we can look at a more earthly calculation. Using the same math as that article, but at room temperature, and taking the total solar irradiance on the Earth as an energy source, it would take this long to count up to 128 bits (calculated using Google):

((2^128) * (1.38064852 * ((10^(−16)) (ergs / K))) * (298 K)) / ((1361 (W / (m^2))) * (pi * (radius of Earth^2))) =
8.04911615 seconds

Definitely more on the plausible side, but we're already moving away from 128-bit crypto and there's a staggering number of generous assumptions being made here; we aren't going to be getting thermodynamically ideal computers using a significant fraction of the total solar irradiance on the Earth any time soon.

Just to give you an idea of how far away we are from that, looking at actual SHA256 calculations:

https://www.iea.org/data-and-statistics/charts/efficiency-of-bitcoin-mining-hardware

22222 MH/J is the…

Here's the first example I could find.

https://pthree.org/2014/04/01/protect-against-bit-rot-with-parchive/

Basically, you take a normal TAR file and creates external parity files that can be used to recover data in the case of bitrot. Something like this would have been great to have on a few data files I had to retrieve from tape that ended up with a bit flip somewhere in the network > disk > tape > disk process.

However, it doesn't look like the program is maintained anymore...

http://parchive.sourceforge.net/

> DISCLAIMER: This project web space is not actively mantained and is presented here for archive purposes. However some project members still montior the project mailings lists if you have questions. (sic)

The last release was in 2004 (Wikipedia says it was active until 2015, but I don't see that).

Zpool is a great feature. On top of the dozen(s) of amazing features in ZFS. The problem is, and ZFS admits this: If you don't run ECC ram Zpool can "accidentally" your whole hard drive (bit of a joke there, it can corrupt your drive as it attempts to correct bit rot that never happened).

This happens a lot more often then we really care to think about. (Ram corruption)

For most day-to-day linux users who are just using standard consumer desktop/laptops they don't have this protection. And ZFS can do more harm then good.

References:

https://pthree.org/2013/12/10/zfs-administration-appendix-c-why-you-should-use-ecc-ram/

Although this depends very much on the particular form of key you are using.

Password encrypted SSH keys were getting a single round of MD5 for the longest time. This was fixed initially only for Ed25519 keys, to use bcrypt(5), which is still not fantastic, but a hell of a lot better than md5(1).

Newer OpenSSH (v6.5 and later) has a new file format and allows specifying an arbitrary bcrypt complexity regardless of the key type. Look for your private key file to start with;

-----BEGIN OPENSSH PRIVATE KEY-----

[1] - https://pthree.org/2014/12/08/super-size-the-strength-of-your-openssh-private-keys/

Well, in the case of SSDs, every byte counts. But no, that's not my concern. My concern is installing a binary I have no intention of using. It's solid security best practices to only install what you need, and leave the rest out.

Also, I don't have a "fundamental misunderstanding of NTP". I've blogged about it quite a bit:

https://pthree.org/2013/11/05/real-life-ntp/

https://pthree.org/2013/10/13/ntp-drift-file/

https://pthree.org/2013/10/12/new-public-ntp-server/

http://transmission.xmission.com/2014/05/28/building-a-stratum-1-ntp-server-with-a-raspberry-pi