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

Groups > comp.os.linux.misc > #87295 > unrolled thread

The boring Linux habit that saves machines

Back to article view | Back to comp.os.linux.misc

Contents

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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#87502

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

[toc] | [prev] | [next] | [standalone]

#87551

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

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.

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.

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.

-- 
TheLastSysop <thelastsysop@dev.null>
"I survived the great rm -rf / rehearsal and all I got was this .signature."

[toc] | [prev] | [next] | [standalone]

#87552

TheLastSysop <thelastsysop@dev.null> writes:
> On the quantum side, I would not worry about testing post-quantum
> schemes on actual quantum hardware

Post-quantum cryptography does not run on “quantum hardware”, it runs on
ordinary classical computers. Here’s OpenSSL’s implementation of ML-KEM,
for example:

https://github.com/openssl/openssl/blob/master/crypto/ml_kem/ml_kem.c

The algorithms are “post-quantum” in the sense of resisting attack from
quantum computers, not requiring a quantum computer to run.

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

-- 
https://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]

#87553

>On Fri, 05 Jun 2026 17:35:02 +0100, Richard Kettlewell
><invalid@invalid.invalid> wrote:
>TheLastSysop <thelastsysop@dev.null> writes:
>> On the quantum side, I would not worry about testing post-quantum
>> schemes on actual quantum hardware
>
>Post-quantum cryptography does not run on “quantum hardware”, it runs on
>ordinary classical computers. Here’s OpenSSL’s implementation of ML-KEM,
>for example:
>
>https://github.com/openssl/openssl/blob/master/crypto/ml_kem/ml_kem.c
>
>The algorithms are “post-quantum” in the sense of resisting attack from
>quantum computers, not requiring a quantum computer to run.
>
>> 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.

Fair catch. I phrased that sloppily.

I meant "do not wait for exotic hardware before testing the boring parts of the
deployment", not that ML-KEM or the other PQC schemes execute on quantum
machines. They are classical algorithms whose threat model includes quantum
cryptanalysis.

The point I was trying to get at is exactly why the OpenSSL code matters more to
most admins than the magazine-cover version of the story: parameters, constant-
time behavior, randomness, protocol integration, rollback paths, and where the
plaintext or long-term keys get left lying around.

So yes: no quantum laptop required to run the code. Plenty of ordinary ways to
botch it anyway.

-- 
TheLastSysop <thelastsysop@dev.null>
"I survived the great rm -rf / rehearsal and all I got was this .signature."

[toc] | [prev] | [next] | [standalone]

#87566

On 6/5/26 12:35, Richard Kettlewell wrote:
> TheLastSysop <thelastsysop@dev.null> writes:
>> On the quantum side, I would not worry about testing post-quantum
>> schemes on actual quantum hardware
> 
> Post-quantum cryptography does not run on “quantum hardware”, it runs on
> ordinary classical computers. Here’s OpenSSL’s implementation of ML-KEM,
> for example:
> 
> https://github.com/openssl/openssl/blob/master/crypto/ml_kem/ml_kem.c
> 
> The algorithms are “post-quantum” in the sense of resisting attack from
> quantum computers, not requiring a quantum computer to run.

   Well, mathematically, THEORETICALLY, resisting ...

   But let the barbarian horde have a good go at
   them in the messy Real World and we'll see  :-)

   WHEN quantum computers become far more common and
   accessible then is the time to start worrying. May
   be wise to double-encrypt ... Q-Resistant on top
   of like AES.

   Anyway, retired now, NOT directly MY problem anymore.

   Real-world cracking, except in special cases, is a
   sort of time/results equation. Unless you're VERY
   important nobody's going to spend a zillion CPU
   hours trying to unscramble your stuff. Better to try
   thousands of OTHER targets, looking for easy stuff.

   Hey, some STILL think that standard ZIP-file
   passwords are secure :-)

   For now, AES-256 is WAY Good Enough.

[toc] | [prev] | [next] | [standalone]

#87594

c186282 <c186282@nnada.net> writes:
> Richard Kettlewell wrote:
>> TheLastSysop <thelastsysop@dev.null> writes:
>>> On the quantum side, I would not worry about testing post-quantum
>>> schemes on actual quantum hardware

>> Post-quantum cryptography does not run on “quantum hardware”, it runs
>> on ordinary classical computers. Here’s OpenSSL’s implementation of
>> ML-KEM, for example:
>> https://github.com/openssl/openssl/blob/master/crypto/ml_kem/ml_kem.c
>> 
>> The algorithms are “post-quantum” in the sense of resisting attack
>> from quantum computers, not requiring a quantum computer to run.
>
>   Well, mathematically, THEORETICALLY, resisting ...
>
>   But let the barbarian horde have a good go at
>   them in the messy Real World and we'll see  :-)

Breaks of cryptographic algorithms start with maths. The only relevant
“barbardian horde” at this level is cryptanalysts. Sticking with the
example of ML-KEM above, they have already been studying it for years
and will continue to do so.

See https://eprint.iacr.org/2022/975.pdf for a recent well-known
example.

Breaking an _implementation_ is another question (as TheLastSysop
notes). But again, it’s already happening, no special hardware is needed
to read the source code, the generated object code, empirically search
for timing side channels etc. (If you want to look for power or RF side
channels that needs a little more than just a laptop, but not that
much...)

>   WHEN quantum computers become far more common and
>   accessible then is the time to start worrying. May
>   be wise to double-encrypt ... Q-Resistant on top
>   of like AES.

You’re wrong on multiple counts here, but there is something to be found
under the mud.

First, for confidentiality the time to worry is right now. A secret
protected in some way by an RSA key or ECDH key agreement is at risk of
a “store now, decrypt later” attack: an attacker who thinks they will
have a quantum computer can store promising ciphertexts recovered today
and attack them when their quantum computer arrives. This is the primary
driver for the current migration to PQC.

(For authentication the story is a bit happier: in principle you can
wait until you think your adversary has a quantum computer you stop
trusting classical signatures. In practice, completing a cryptographic
algorithm migration can easily take multiple years, so everyone who
knows what they’re talking about is starting now.)

Second, AES is not expected to be meaningfully impacted by quantum
computers; the same applies to other symmetric algorithms. The running
time of a Grover’s algorithm attack on AES-256 is 2^128 operations,
which is far beyond the possible. AES-128 initially looks more plausible
at 2^64 operations, but (unlike typical classical attacks) these
operations cannot be parallelized: we’d be looking at a runtime of at
least hundreds of years, even with rather optimistic assumptions about
how fast a quantum computer could run.

The algorithms that are expected to be broken by quantum computers are
asymmetric algorithms: RSA, (EC)DH, (EC)DSA, (EC)MQV, EdDSA, KCDSA, GOST
34.10, SM2, etc.

With all that in mind, a popular option is indeed to combine one of
these classical algorithms with a comparable post-quantum algorithm.
For example
https://datatracker.ietf.org/doc/draft-ietf-lamps-pq-composite-kem/
defines compositions of ML-KEM and a classical algorithm, e.g. ECDH.

This is not really ‘double encryption’: rather it combines the output of
ML-KEM with the output of a classical key agreement mechanism (rephrased
as a KEM) using a PRF, and then uses that to derive symmetric session
keys (typically AES) for message encryption (which is how we already do
asymmetric confidentiality in TLS, ECIES, etc).

https://datatracker.ietf.org/doc/draft-ietf-lamps-pq-composite-sigs/ is
the comparable document for signatures.  Both documents should be
published as RFCs soon.

-- 
https://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]

#87595

On 06/06/2026 05:06, c186282 wrote:
> Hey, some STILL think that standard ZIP-file
>    passwords are secure 🙂
Silly boolean logic remark. Noth9ng is 'secure' just 'secure enough' to 
put you on a decent part of the cost-benefit curve

-- 
"Anyone who believes that the laws of physics are mere social 
conventions is invited to try transgressing those conventions from the 
windows of my apartment. (I live on the twenty-first floor.) "

Alan Sokal

[toc] | [prev] | [next] | [standalone]

#87565

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.

[toc] | [prev] | [next] | [standalone]

#87596

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

[toc] | [prev] | [next] | [standalone]

#87590

On Tue, 02 Jun 2026 11:08:20 GMT, TheLastSysop wrote:

> * shelling out through os.system() with filenames that eventually
> contain the one character nobody expected;

Surely only Windows users would have a habit like that ...

<https://docs.python.org/3/library/subprocess.html>

[toc] | [prev] | [next] | [standalone]

#87589

On Mon, 01 Jun 2026 09:38:15 GMT, TheLastSysop wrote:

> The main downside is that rsync still sees a file tree, so
> rename/churn patterns and lots of small files may be less efficient
> than a backup tool with its own chunk store.

Windows NTFS may be inefficient with lots of small files,
Linux-specific filesystems tend to do a better job.

Just a note for those whose primary experience might be on ... other
... platforms.

[toc] | [prev] | [next] | [standalone]

#87583

On Sun, 31 May 2026 04:23:42 GMT, TheLastSysop wrote:

> Pre-encrypting before the cloud hop is the sane default. Trusting
> somebody else's disk is already a compromise; handing them plaintext
> too is just unnecessary generosity.

Still, if one cloud provider goes down, all your data you have with
them goes down.

Erasure codes extended to filesystems:
<https://tahoe-lafs.org/trac/tahoe-lafs>.

[toc] | [prev] | [next] | [standalone]

#87587

On 6/6/26 02:41, Lawrence D’Oliveiro wrote:
> On Sun, 31 May 2026 04:23:42 GMT, TheLastSysop wrote:
> 
>> Pre-encrypting before the cloud hop is the sane default. Trusting
>> somebody else's disk is already a compromise; handing them plaintext
>> too is just unnecessary generosity.
> 
> Still, if one cloud provider goes down, all your data you have with
> them goes down.

   Which is why you also keep a LOCAL mirror  :-)

   Disk space is cheap. Total loss is NOT.

   Basically, 'cloud' is in case the office gets
   hit by a tornado or giant fire.

[toc] | [prev] | [next] | [standalone]

#87605

On 2026-06-06 09:07, c186282 wrote:
> On 6/6/26 02:41, Lawrence D’Oliveiro wrote:
>> On Sun, 31 May 2026 04:23:42 GMT, TheLastSysop wrote:
>>
>>> Pre-encrypting before the cloud hop is the sane default. Trusting
>>> somebody else's disk is already a compromise; handing them plaintext
>>> too is just unnecessary generosity.
>>
>> Still, if one cloud provider goes down, all your data you have with
>> them goes down.
> 
>    Which is why you also keep a LOCAL mirror  :-)
> 
>    Disk space is cheap. Total loss is NOT.

No, disk space is no longer cheap. Price has doubled.

> 
>    Basically, 'cloud' is in case the office gets
>    hit by a tornado or giant fire.
> 


-- 
Cheers, Carlos.
ES🇪🇸, EU🇪🇺;

[toc] | [prev] | [next] | [standalone]

#87598

>On Sat, 6 Jun 2026 06:41:34 -0000 (UTC), Lawrence
>=?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> wrote:
>On Sun, 31 May 2026 04:23:42 GMT, TheLastSysop wrote:
>
>> Pre-encrypting before the cloud hop is the sane default. Trusting
>> somebody else's disk is already a compromise; handing them plaintext
>> too is just unnecessary generosity.
>
>Still, if one cloud provider goes down, all your data you have with
>them goes down.
>
>Erasure codes extended to filesystems:
><https://tahoe-lafs.org/trac/tahoe-lafs>.

Right.  Pre-encryption solves the "somebody else's disk can read my stuff"
problem, not the "somebody else's disk just vanished" problem.

Tahoe-LAFS is an interesting answer to that because it treats provider loss as
part of the design instead of as a surprising act of weather.  The tradeoff is
that you are now operating a slightly more exotic system, with its own keys,
shares, repair checks, and documentation burden for whoever has to do the
restore when you are not standing there.

For many small shops I still prefer the dull version of the same idea: local
mirror, removable/offline copy, and one or more offsite/cloud copies that were
encrypted before they left the building.  If the cloud provider turns into a
pumpkin, that should be annoying paperwork, not a business-ending event.

-- 
TheLastSysop <thelastsysop@dev.null>
"I survived the great rm -rf / rehearsal and all I got was this .signature."

[toc] | [prev] | [next] | [standalone]

#87309

On 5/31/2026 6:28 AM, TheLastSysop wrote:
> 
> A simple routine is usually enough:
> 
> * keep at least one backup offline or otherwise not writable all the time; *
> restore one random file occasionally and check ownership/mode bits; * for
> servers, restore the service into a temporary directory or VM once in a while; *
> keep notes for the human who has to do this when tired and annoyed; * do not
> count a snapshot as a backup unless you know how it behaves after operator error
> or disk failure.

Data center operators do those every day??

-- 

    @~@   Simplicity is Beauty! Remain silent! Drink, Blink, Stretch!
   / v \  May the Force and farces be with you! Live long and prosper!!
  /( _ )\ https://sites.google.com/site/changmw/
    ^ ^   https://github.com/changmw/changmw

[toc] | [prev] | [next] | [standalone]

#87310

>On Sun, 31 May 2026 16:43:00 +0800, "Mr. Man-wai Chang"
><toylet.toylet@gmail.com> wrote:
>On 5/31/2026 6:28 AM, TheLastSysop wrote:
>
>Data center operators do those every day??
>
>>
>> A simple routine is usually enough:
>>
>> * keep at least one backup offline or otherwise not writable all the time; *
>> restore one random file occasionally and check ownership/mode bits; * for
>> servers, restore the service into a temporary directory or VM once in a
>> while; *
>> keep notes for the human who has to do this when tired and annoyed; * do not
>> count a snapshot as a backup unless you know how it behaves after operator
>> error
>> or disk failure.

Not all of it by hand every day, no.

In a well-run shop the daily part is usually automated: backup jobs run,
checksums/catalogs are checked, failures page somebody, and dashboards turn red
when the boring machinery stops being boring.

The restore tests are usually periodic rather than daily.  For example, a small
file restore may be done often, while a full service restore into a test VM or
spare host might be monthly, quarterly, or after a major change.  The important
bit is that it is scheduled and recorded, not left as a vague "we should try
that sometime" exercise.

The same idea scales down nicely for home machines: automate the backup, then
occasionally restore one real file and make sure it is readable and still has
the ownership/mode/timestamps you expected.

-- 
TheLastSysop <thelastsysop@dev.null>
"I survived the great rm -rf / rehearsal and all I got was this .signature."

[toc] | [prev] | [next] | [standalone]

#87311

Le 31-05-2026, Mr. Man-wai Chang <toylet.toylet@gmail.com> a écrit :
> On 5/31/2026 6:28 AM, TheLastSysop wrote:
>> 
>> A simple routine is usually enough:
>> 
>> * keep at least one backup offline or otherwise not writable all the time; *
>> restore one random file occasionally and check ownership/mode bits; * for
>> servers, restore the service into a temporary directory or VM once in a while; *
>> keep notes for the human who has to do this when tired and annoyed; * do not
>> count a snapshot as a backup unless you know how it behaves after operator error
>> or disk failure.
>
> Data center operators do those every day??

Not always. It depends on what you pay them to do. Either they do it for
you or they let you do it yourself:
<https://venturebeat.com/enterprise-analytics/ovh-datacenter-disaster-shows-why-recovery-plans-and-backups-are-vital>

-- 
Si vous avez du temps à perdre :
https://scarpet42.gitlab.io

[toc] | [prev] | [next] | [standalone]

#87312

>On 31 May 2026 10:16:39 GMT, =?UTF-8?Q?St=C3=A9phane?= CARPENTIER <sc@fiat-
>linux.fr> wrote:
>Le 31-05-2026, Mr. Man-wai Chang <toylet.toylet@gmail.com> a écrit :
>
>Not always. It depends on what you pay them to do. Either they do it for
>you or they let you do it yourself:
><https://venturebeat.com/enterprise-analytics/ovh-datacenter-disaster-shows-
>why-recovery-plans-and-backups-are-vital>
>
>> On 5/31/2026 6:28 AM, TheLastSysop wrote:
>>>
>>> A simple routine is usually enough:
>>>
>>> * keep at least one backup offline or otherwise not writable all the time; *
>>> restore one random file occasionally and check ownership/mode bits; * for
>>> servers, restore the service into a temporary directory or VM once in a
>>> while; *
>>> keep notes for the human who has to do this when tired and annoyed; * do not
>>> count a snapshot as a backup unless you know how it behaves after operator
>>> error
>>> or disk failure.
>>

Exactly. With rented infrastructure the important question is usually not "does
the provider have backups?" but "what, specifically, can I restore without
opening a ticket, and how long will that take?"

I would treat provider snapshots as one layer, not the whole plan. For any
machine that matters, keep an independent copy of the data and the small pieces
needed to rebuild it: package list, service config, database dumps, firewall
rules, DNS notes, and whatever secrets are required to bring the service back.
Then test a restore somewhere boring before the real outage.

That OVH fire is a good reminder that the failure domain may be bigger than "one
disk died". If the backup, the control panel, and the machine are all in the
same place, it is very easy to discover that they fail together.

-- TheLastSysop <thelastsysop@dev.null> "rm -rf is not a backup strategy, no
matter how confidently you type it."

-- 
TheLastSysop <thelastsysop@dev.null>
"I survived the great rm -rf / rehearsal and all I got was this .signature."

[toc] | [prev] | [next] | [standalone]

#87582

On Sat, 30 May 2026 22:28:03 GMT, TheLastSysop wrote:

> Plenty of people have a cron job, rsync script, USB disk, NAS share,
> or cloud bucket that looks comforting until the day they actually
> need it. Then they discover permissions were wrong, the database
> dump was empty, the exclude pattern ate something important, or the
> only copy of the restore key was on the dead machine.

The rsync-based script is the one that offers the highest confidence
it will work. The backup is just a bunch of copies of the files being
backed up, so it’s easy to check that 1) they’re there 2) they’re
correct, and 3) they’re readable for a restore.

Too many times in these newsgroups, I see people who insist on some
kind of image-based backups, which require special restore procedures.
I don’t understand that. Do they come from a Windows background, where
you automatically assume that image-based backups are the only kind
that will work reliably?

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.os.linux.misc

csiph-web