Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.misc > #87596

Re: The boring Linux habit that saves machines

Show key headers only | View raw

>On Fri, 5 Jun 2026 23:55:38 -0400, c186282 <c186282@nnada.net> wrote:
>On 6/5/26 08:53, TheLastSysop wrote:
>>> On Thu, 4 Jun 2026 11:57:34 -0400, c186282 <c186282@nnada.net> 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 <thelastsysop@dev.null>
"I survived the great rm -rf / rehearsal and all I got was this .signature."

Back to comp.os.linux.misc | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

The boring Linux habit that saves machines TheLastSysop <thelastsysop@dev.null> - 2026-05-30 22:28 +0000
  Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-05-30 23:51 -0400
    Re: The boring Linux habit that saves machines TheLastSysop <thelastsysop@dev.null> - 2026-05-31 04:23 +0000
      Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-05-31 02:26 -0400
        Re: The boring Linux habit that saves machines TheLastSysop <thelastsysop@dev.null> - 2026-05-31 06:41 +0000
          Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-05-31 03:37 -0400
            Re: The boring Linux habit that saves machines TheLastSysop <thelastsysop@dev.null> - 2026-05-31 07:46 +0000
              Re: The boring Linux habit that saves machines Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-06 08:55 +0000
                Re: The boring Linux habit that saves machines "Carlos E.R." <robin_listas@es.invalid> - 2026-06-06 12:07 +0200
                Re: The boring Linux habit that saves machines TheLastSysop <thelastsysop@dev.null> - 2026-06-06 10:14 +0000
                Re: The boring Linux habit that saves machines "Carlos E.R." <robin_listas@es.invalid> - 2026-06-06 13:06 +0200
                Re: The boring Linux habit that saves machines TheLastSysop <thelastsysop@dev.null> - 2026-06-06 11:12 +0000
                Re: The boring Linux habit that saves machines Rich <rich@example.invalid> - 2026-06-06 18:30 +0000
                Re: The boring Linux habit that saves machines "Carlos E.R." <robin_listas@es.invalid> - 2026-06-06 20:49 +0200
          Re: The boring Linux habit that saves machines Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-06 09:07 +0000
          Re: The boring Linux habit that saves machines Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-06 09:10 +0000
      Re: The boring Linux habit that saves machines Anssi Saari <anssi.saari@usenet.mail.kapsi.fi> - 2026-06-01 12:20 +0300
        Re: The boring Linux habit that saves machines TheLastSysop <thelastsysop@dev.null> - 2026-06-01 09:38 +0000
          Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-02 02:20 -0400
            Re: The boring Linux habit that saves machines TheLastSysop <thelastsysop@dev.null> - 2026-06-02 11:08 +0000
              Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-02 23:58 -0400
                Re: The boring Linux habit that saves machines TheLastSysop <thelastsysop@dev.null> - 2026-06-04 11:47 +0000
                Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-04 11:57 -0400
                Re: The boring Linux habit that saves machines TheLastSysop <thelastsysop@dev.null> - 2026-06-05 12:53 +0000
                Re: The boring Linux habit that saves machines Richard Kettlewell <invalid@invalid.invalid> - 2026-06-05 17:35 +0100
                Re: The boring Linux habit that saves machines TheLastSysop <thelastsysop@dev.null> - 2026-06-05 16:42 +0000
                Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-06 00:06 -0400
                Re: The boring Linux habit that saves machines Richard Kettlewell <invalid@invalid.invalid> - 2026-06-06 10:35 +0100
                Re: The boring Linux habit that saves machines The Natural Philosopher <tnp@invalid.invalid> - 2026-06-06 10:39 +0100
                Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-05 23:55 -0400
                Re: The boring Linux habit that saves machines TheLastSysop <thelastsysop@dev.null> - 2026-06-06 09:40 +0000
                Re: The boring Linux habit that saves machines Rich <rich@example.invalid> - 2026-06-06 18:42 +0000
              Re: The boring Linux habit that saves machines Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-06 08:53 +0000
          Re: The boring Linux habit that saves machines Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-06 08:52 +0000
      Re: The boring Linux habit that saves machines Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-06 06:41 +0000
        Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-06 03:07 -0400
          Re: The boring Linux habit that saves machines "Carlos E.R." <robin_listas@es.invalid> - 2026-06-06 13:28 +0200
          Re: The boring Linux habit that saves machines rbowman <bowman@montana.com> - 2026-06-06 19:16 +0000
        Re: The boring Linux habit that saves machines TheLastSysop <thelastsysop@dev.null> - 2026-06-06 09:40 +0000
  Re: The boring Linux habit that saves machines "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2026-05-31 16:43 +0800
    Re: The boring Linux habit that saves machines TheLastSysop <thelastsysop@dev.null> - 2026-05-31 08:48 +0000
    Re: The boring Linux habit that saves machines Stéphane CARPENTIER <sc@fiat-linux.fr> - 2026-05-31 10:16 +0000
      Re: The boring Linux habit that saves machines TheLastSysop <thelastsysop@dev.null> - 2026-05-31 10:22 +0000
  Re: The boring Linux habit that saves machines Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-06 06:38 +0000
    Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-06 03:04 -0400
      Re: The boring Linux habit that saves machines "Carlos E.R." <robin_listas@es.invalid> - 2026-06-06 13:32 +0200
        Re: The boring Linux habit that saves machines TheLastSysop <thelastsysop@dev.null> - 2026-06-06 11:34 +0000
          Re: The boring Linux habit that saves machines "Carlos E.R." <robin_listas@es.invalid> - 2026-06-06 14:01 +0200
    Re: The boring Linux habit that saves machines Nuno Silva <nunojsilva@invalid.invalid> - 2026-06-06 09:17 +0100
      Re: The boring Linux habit that saves machines TheLastSysop <thelastsysop@dev.null> - 2026-06-06 09:40 +0000

csiph-web