Aaron Toponce

I noticed there's no mention of quantum-resistant crypto. Looking around, it looks like this is the rational [1]. This sort of feels like a hand-wave. > Quantum computing does give us some far more efficient algorithms that classical computing cannot achieve, but even then, 256-bits still remains outside of the practical realm of mythical quantum computing when brute force searching. [1] https://pthree.org/2016/06/19/the-physics-of-brute-force/

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).

Not sure if it's still relevant (article is quite old after all), but does [1] still hold true in regards to /boot on ZFS on linux, even with zfsbootmenu? What kind of issues can I expect? Is there a newer/better knowledgebase compared to the one on pthree.org? I'm guessing the newness/missing features of zfsbootmenu is in regards to beadm [2]? [1] https://pthree.org/2013/01/03/zfs-administration-part-xvii-best-practi… [2] https://vermaden.files.wordpress.com/2018/11/nluug-zfs-boot-environmen…

Mutt/Neomutt is great once you got over the initial trauma of the keybinds and configuring the config plus theme. Except when it comes to HTML e-mail which is a lot more common that I'd like it to be. For a more up-to-date guide on how to use GPG for your e-mail password [1] [1] https://pthree.org/2012/01/07/encrypted-mutt-imap-smtp-passwords/

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-…

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-s…

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-sh…

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…

FreeBSD's Handbook on ZFS [0] and Aaron Toponce's articles [1] were what helped me the most when getting started with ZFS [0] https://docs.freebsd.org/en/books/handbook/zfs/ [1] https://pthree.org/2012/04/17/install-zfs-on-debian-gnulinux/

Base64 is just another translation with very basic rules, you can even do it by hand [^1]. How hard would it be for an LLM to convert a string to binary? That's just a lookup table. How hard would it be to remove all spaces and add spaces every 6 bits? And convert that to letters. That's a lookup table again. [1]: https://pthree.org/2011/04/06/convert-text-to-base-64-by-hand/

> and see if I started to be able to recognize the randomart images in the way the manual implies I'd be able to, and it turns out it worked! How computationally expensive is it to generate a key with randomart that kinda-resembles a known randomart? I've always ignored randomart since I always assumed it's easy to get a close-enough "collision". EDIT: algorithm explained here https://pthree.org/2013/05/30/openssh-keys-and-the-drunken-bishop/

Under some circumstances, this can be true on Linux: https://pthree.org/2014/07/21/the-linux-random-number-generator/ (see "input pool")

Unless some crazy physics breakthrough happens, bruteforcing even 128 bits is physically impossible: https://pthree.org/2016/06/19/the-physics-of-brute-force/

Google Authenticator implements TOTP, which is actually a very simple standard: https://pthree.org/2014/04/15/time-based-one-time-passwords-how-it-wor… If you can extract the private key, you can transfer it to another phone or device. On Android, AndOTP is open source (available on F-Droid) and allows encrypted backups. As for Google Authenticator, I don't think you can create backups.

> Dropping support for file systems outside ext4. One of my machines uses Linux on ZFS Well if you're using ZFS you can create a zvol for your dropbox folder and format it in ext4 and it'll work: https://pthree.org/2012/12/21/zfs-administration-part-xiv-zvols/

https://pthree.org/2012/12/14/zfs-administration-part-ix-copy-on-write… Here is a good one I've used.

"As alluded to above, this does introduce a separate challenge with multi-file consistency. The team took an interesting approach here. The index file points to the location of the root of the page graph and free space map in each page cache file. When persisting a multi-file transaction, all page cache files are flushed to disk before the index file." That sounds familiar: https://pthree.org/2012/12/14/zfs-administration-part-ix-copy-on-write…

An RTL-SDR [0] commodity hardware device paired with rtl-entropy [1] seems to have great potential for filling this need. It has some nice write-ups [2][3][4] and ongoing development. 0: http://www.rtl-sdr.com 1: https://github.com/pwarren/rtl-entropy 2: http://blog.cros13.net/2014/08/cheap-entropy-using-your-rtl-sdr-as.htm… 3: https://pthree.org/2015/06/16/hardware-rng-through-an-rtl-sdr-dongle/ 4: http://blog.krisk.org/2013/12/high-quality-entropy.html

Unless he is talking about scrubbing and self-healing? In which case, the same thing still applies -- all releases do this as far as I know. See: https://pthree.org/2012/12/11/zfs-administration-part-vi-scrub-and-res…

Scary scenarios regarding "faulty ram destroys volume" can be found in various places, e.g., https://pthree.org/2013/12/10/zfs-administration-appendix-c-why-you-sh… However, for a refutation of this scenario see XorNot's comment (and perhaps the surrounding discussion) at https://news.ycombinator.com/item?id=8294434

Here is a well balanced explanation why ECC-RAM. That being said, if the RAM is the weakest link it doesn't matter what underlying FS is used. https://pthree.org/2013/12/10/zfs-administration-appendix-c-why-you-sh… In my experience 16GB is only needed if you want to run Deduplication.

This is a myth started by someone who did not understand how filesystems work. You are wrong. Don't spread potentially dangerous maladvice on the internet when you have no idea what you're talking about. The official ZFS documentation[1] tells you to use ECC Ram and why. The first google hit for "zfs ecc ram"[2] further elaborates on the risks of using ZFS without ECC memory. [1] https://pthree.org/2013/12/10/zfs-administration-appendix-c-why-you-sh… [2] http://louwrentius.com/please-use-zfs-with-ecc-memory.html

Yes it does or I don't understand that: http://louwrentius.com/please-use-zfs-with-ecc-memory.html https://pthree.org/2013/12/10/zfs-administration-appendix-c-why-you-sh… Always fun to post on HN and getting downvoted ;o

If you are looking at playing around with ZFS on Linux, be sure to check out Aaron Toponce's awesome series of articles, entitled "Install ZFS on Debian GNU/Linux" [1]. I have also done a two part screencast about using ZFS on Linux [2], part two will be released later today. [1] https://pthree.org/2012/04/17/install-zfs-on-debian-gnulinux/ [2] https://sysadmincasts.com/episodes/35-zfs-on-linux-part-1-of-2

/dev/urandom on Linux only has an internal state of 1024 bits [1] As Python's Mersenne Twister is seeded with urandom... [1] https://pthree.org/2014/07/21/the-linux-random-number-generator/

I'm looking for any algorithms among those you listed that is considered weak. http://en.wikipedia.org/wiki/Triple_DES#Security - ok, that has chosen plaintext weaknesses. I don't see much information on CAST5 aka CAST128, can someone chime in with its current status? I suppose you could encrypt an image using ECB. Would PGP allow this kind of broken configuration? http://pthree.org/2012/02/17/ecb-vs-cbc-encryption/

I'd very much like an invite, too. Especially after reading a bit about the background, and stumbling on this link on the front page:) http://pthree.org/2013/05/30/openssh-keys-and-the-drunken-bishop/

> But you seem to claim that it isn't sound, which also isn't possible without an audit. That's not quite true, right? If encryption was successfully broken, then you wouldn't need an audit. Even if it wasn't broken, there's still things like this: http://pthree.org/2012/02/17/ecb-vs-cbc-encryption/

zsh can do that. eg. http://pthree.org/2009/03/28/add-vim-editing-mode-to-your-zsh-prompt/ that was the first link on a ddg search. there were other articles. https://duckduckgo.com/?q=zsh+vi+mode+prompt

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-m… 22222 MH/J is the…