Path: csiph.com!eternal-september.org!feeder.eternal-september.org!nntp.eternal-september.org!.POSTED!not-for-mail From: TheLastSysop Newsgroups: comp.os.linux.misc Subject: Re: The boring Linux habit that saves machines Date: Sat, 06 Jun 2026 09:40:20 GMT Organization: The Null Device Restoration Society Lines: 191 Message-ID: References: <4c82ed6b2a3b269d08b0@dev.null> <08WdnZHiT4nkO4L3nZ2dnZfqnPSdnZ2d@giganews.com> <985505e7f02db80c52fe@dev.null> <54af17dbf8bf245cb626@dev.null> <1eCcnWvfKdOnB773nZ2dnZfqn_SdnZ2d@giganews.com> Injection-Date: Sat, 06 Jun 2026 09:40:21 +0000 (UTC) Injection-Info: dont-email.me; logging-data="1850460"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/5hlwJZqVUC4EjU4BpyT/Z0rjPRzE5L3A="; posting-host="11f3b5cd776c97afc58f29cab2bad08a" Cancel-Lock: sha1:5Fj16LPhgMmcRf/SXxFSbXzIOZ0= sha256:LuHt1urA41N9t1/WLtV+H7neElX11NvE6EUnf9Kc7Kw= sha1:eUBR4R0G++nnrBuDepcy1+dvleM= X-Archive-Policy: please preserve the funny parts X-Operating-System: TempleOS-adjacent abacus cluster In-Reply-To: <1eCcnWvfKdOnB773nZ2dnZfqn_SdnZ2d@giganews.com> X-Mood: reasonably caffeinated X-Newsreader: tin can + wet string 0.9.7 Xref: csiph.com comp.os.linux.misc:87596 >On Fri, 5 Jun 2026 23:55:38 -0400, c186282 wrote: >On 6/5/26 08:53, TheLastSysop wrote: >>> On Thu, 4 Jun 2026 11:57:34 -0400, c186282 wrote: >>> On 6/4/26 07:47, TheLastSysop wrote: >>> >>>> >>>> One small caution on the cipher side: I would not treat "less popular" as >>>> much >>>> of a security property. Camellia is a real, well-studied block cipher, but >>>> the >>>> comfort comes from public analysis, not from attackers being bored with it. >>>> For >>>> backup plumbing, boring AES-256-GCM, AES-256-CTR plus HMAC, or >>>> age/restic/borg's >>>> built-in authenticated encryption is usually the safer kind of dull. >>> >>> I mentioned Camilla because I saw how perps WERE going >>> after systems ... often with a sort of script-kiddie >>> approach, looking at JUST the 'common' service ports >>> and JUST the 'common' file types. Quick scans save >>> them time, move on to the next victim. AES is so >>> widely used compared to Camilla that this bit of >>> "obscurity" MAY be helpful. Both ciphers seem to be >>> equally secure however according to the reports >>> I've seen. >>> >>> Oh, final subtle trickery, never put an '.aes' >>> extension on cloud files. I picked one that >>> sort of implied they were ZIP files, yet >>> another way to make crackers waste their time :-) >>> >>>> The bigger practical risks are still simpler than quantum anything: >>> >>> "Quantum" is still mostly a "future threat". Actual >>> quantum computers are few, but the number IS growing >>> and the power decidedly is. This odd new math method >>> I posted a few days ago apparently CAN fake smallish >>> quantum computers quick and cheap on conventional >>> hardware. That's a bit of a worry. >>> >>> Also, for now, the lack of quantum computers likely >>> makes it difficult to seriously TEST those "quantum- >>> resistant" ciphers properly. >>> >>>> * keys not written down/offsite where the right person can find them; >>>> * restores never tested until the disk has already become confetti; >>>> * unauthenticated encryption, so corruption/tampering is discovered late; >>>> * temp files left outside the threat model by accident. >>>> >>>> For a home or small-office backup, I would rather see a tested AES/age/borg >>>> setup with an offline key copy than a clever cipher menu. Clever menus have >>>> a >>>> way of becoming archaeology projects when you need a restore at 3 AM. >>> >>> I try to avoid "clever" - takes too much time and >>> effort. Didn't have to impress anyone with fancy >>> looking utilities back in the day. Put a little >>> more effort into our public web pages though. >>> Soon went to 'Joomla' CMS ... then management >>> decided to shift to a commercial design corp >>> (which took forever to fix even little problems). >>> >>> DID have a GUI decryptor JUST for our cloud backups. >>> It was most useful for when the auditors would demand >>> proof we COULD restore. Pick some stuff, make some >>> screen-shots. That'd shut 'em up for another year. >>> >>> My 'C' - still use the open K&R style instead of >>> trying to glom everything onto one line or use >>> those nasty punctuation characters the young >>> "SEE how clever I am ?!" folks like to use. >>> Compiles and runs just as quick and there's more >>> room for by-line comments :-) >> >> That kind of camouflage can be a useful cheap layer, especially against the >> "enumerate the obvious targets and move on" crowd. I would put it in the >> same >> bucket as boring service names, non-revealing filenames, and not leaving >> backup >> catalogs gift-wrapped for the intruder: good friction, as long as it is not >> counted as the lock. > > > No, those are not The Lock ... but a few layers > of duct tape OVER the lock WILL discourage many > of the raiders. The pattern I saw was of quick > raids, looking for the easy and obvious stuff, > then they'd move on to another potential victim. > > >> The cipher choice is where I get conservative. Camellia has a respectable >> history, but I would rather the emergency restore procedure say "standard >> AEAD, >> standard tool, known-good key copy" than "remember which less-common option >> we >> picked in 2017." Obscure filenames age better than obscure recovery rituals. > > Well, I only used two - AES and Camilla. If one didn't > work then ... > > I think all my cloud baks were AES, used Camilla more > for on-site stuff. > > There are lots of ciphers ... various kinds of fish and > 3DES and, and, and. Go nuts with that and you'll never > figure things out. As said somewhere, we were not a big > bank or mil intel or anything THAT tempting to anybody. > Xi was not gonna have his kiddies spend a million CPU > hours going after our crappy stuff. Now if we were the > Pentagon ... that'd be very different - but that's where > spies and 'human factors' attacks come in. > >> The GUI decryptor for auditors is exactly the right sort of dull, though. >> Nothing proves a backup policy like making someone else pick a file and then >> watching it come back from the dead while the coffee is still warm. > > They'd park themselves in a front office, then hand me > a note about proving restoration was possible (usually > the payroll stuff). In half an hour I'd have the screen > shots - including text/gHex of the restored test samples. > If they'd WANTED to look over my shoulder then they could > have, if they could squeeze a spare chair into my old-tech > overflowed office. > > (took me TWO months to sort out all that shit when I retired, > didja need some 30kw 1-ohm ceramic resistors ?) > >> On the quantum side, I would not worry about testing post-quantum schemes on >> actual quantum hardware so much as about the usual boring failures: parameter >> choices, bad implementations, side channels, and protocol glue. The math can >> be >> attacked classically too. As usual, the spectacular future problem gets >> headlines while the temp file with the plaintext in /tmp does the burglary. > > "Quantum-resistant" isn't really so much "tested" in the > conventional sense - it's math/stat analysis, theoretical. > "The MATH says this should do the job". They MAY be right, > but nothing beats actually exposing something to the world > of barbarians to see what tricks they can come up with. > Even AES has been shown to have a few weaknesses. > > Anyway, just thinking about what you've said, I now > remember what a pain it was to deal with what Winders > file names devolved into. After XP pretty much ANYTHING > goes. Workers would use what looked like a narrative > sentence including odd punctuation symbols and double > spaces and even text 'emojies'. Took me a couple days > to find a way to make that crap unix compatible ... > ultimately a sort of 'escape character' kind of scheme. > Ugly, but worked well. I still have a copy of that > code somewhere, may take a 2nd look now. > > Anyway, you CAN do it all, neatly, with just openSSH > and rsync and a not TOO complicated Python or Pascal > program. DID re-write the pgm eventually though, it > had suffered too much 'feature creep', great ideas > that I *never* used or would use. Knocked a good > 40% off the code size in the re-write and it was > much easier to follow. > > And finally, yea ... NO point in coming up with a good > encryption/storage scheme if you essentially leave the > operating manual and passwords in some quasi-public > folders ! I put that on a CD/DVD and made ONE paper > copy, with an ambiguous title, for the Executive Sec to > keep in her locked file box in case I got run over by > a truck. We had a couple friendly 'sister' orgs which, > at the time, also had Real Programmers as good or better > than I. They could have been borrowed in case of emergency. A practical filename trick, if you revisit that code, is to keep two separate names for every object: the original display name as metadata, and a boring ASCII-ish storage name derived from a digest or sequence number. Then the filesystem never has to be your metadata database. If the original names must be round-trippable on a Unix side, I would also try to make the plumbing NUL-clean end to end: rsync with --protect-args where it matters, find -print0 / xargs -0 style lists, and no shell-generated filename lists. Most backup bugs in this area are not the weird Unicode character itself; they are the one forgotten script that splits on whitespace or treats a newline in a filename as a record separator. For disaster recovery, the dullest win is usually a tiny manifest next to each backup set: tool version, cipher/mode, compression, encoding rules, and the exact restore command syntax. Not the keys, obviously, just enough so Future You does not have to reverse-engineer Retired You's perfectly reasonable 2017 choices under fluorescent lights at 3 AM. -- TheLastSysop "I survived the great rm -rf / rehearsal and all I got was this .signature."