Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.os.linux.misc > #87295 > unrolled thread
| Started by | TheLastSysop <thelastsysop@dev.null> |
|---|---|
| First post | 2026-05-30 22:28 +0000 |
| Last post | 2026-06-07 01:33 -0400 |
| Articles | 20 on this page of 76 — 14 participants |
Back to article view | Back to comp.os.linux.misc
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-07 02:45 +0000
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-07 05:13 -0400
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 c186282 <c186282@nnada.net> - 2026-06-07 02:00 -0400
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 c186282 <c186282@nnada.net> - 2026-06-07 02:11 -0400
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 c186282 <c186282@nnada.net> - 2026-06-07 02:15 -0400
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 c186282 <c186282@nnada.net> - 2026-06-07 03:35 -0400
Re: The boring Linux habit that saves machines The Natural Philosopher <tnp@invalid.invalid> - 2026-06-07 13:39 +0100
Re: The boring Linux habit that saves machines Richard Kettlewell <invalid@invalid.invalid> - 2026-06-07 14:41 +0100
Re: The boring Linux habit that saves machines Lars Poulsen <lars@beagle-ears.com> - 2026-06-07 08:00 -0700
Re: The boring Linux habit that saves machines Richard Kettlewell <invalid@invalid.invalid> - 2026-06-07 16: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-07 03:44 -0400
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-07 02:47 +0000
Re: The boring Linux habit that saves machines "Carlos E.R." <robin_listas@es.invalid> - 2026-06-07 13:58 +0200
Re: The boring Linux habit that saves machines Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-06-07 20:40 +0000
Re: The boring Linux habit that saves machines Richard Kettlewell <invalid@invalid.invalid> - 2026-06-07 14:30 +0100
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-07 04:03 -0400
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 c186282 <c186282@nnada.net> - 2026-06-07 01:53 -0400
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 c186282 <c186282@nnada.net> - 2026-06-07 01:41 -0400
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 c186282 <c186282@nnada.net> - 2026-06-07 05:18 -0400
Re: The boring Linux habit that saves machines rbowman <bowman@montana.com> - 2026-06-07 18:59 +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 Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-07 02:51 +0000
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-07 04:56 -0400
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
Re: The boring Linux habit that saves machines Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-07 02:57 +0000
Re: The boring Linux habit that saves machines Nuno Silva <nunojsilva@invalid.invalid> - 2026-06-07 16:11 +0100
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-07 04:18 -0400
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-07 01:33 -0400
Page 2 of 4 — ← Prev page 1 [2] 3 4 Next page →
| From | c186282 <c186282@nnada.net> |
|---|---|
| Date | 2026-06-07 02:15 -0400 |
| Message-ID | <cfycnaZCx9Q0kbj3nZ2dnZfqnPadnZ2d@giganews.com> |
| In reply to | #87593 |
On 6/6/26 05:10, Lawrence D’Oliveiro wrote: > On Sun, 31 May 2026 06:41:28 GMT, TheLastSysop wrote: > >> The stale-path problem is one of the sneaky ones, too. Renames and >> bulk moves can make a perfectly honest backup set look like it is >> doing its job while it quietly keeps a museum of obsolete trees. >> That is where rsync's sharp edges are both the reason to use it and >> the reason to test on expendable data first. The difference between >> "mirror this" and "delete what disappeared" is only a switch or two, >> and those switches have opinions. > > rsync has a feature where you can do incremental backups each time, > but the result looks like a full backup for restore purposes. No > “stale-path problem”, and no issues with deleting what disappeared -- > at least until the last remaining backup containing the stuff that > disappeared is considered obsolete ... Rsync offers many options. Some CAN get rid of stale paths (with a little help). However be really REALLY sure all your mounts are still mounted or Very Bad Things can result. Been there. DUPLICATED paths are even more of pain than 'stale'. WHICH is the "real" path ? And yea, humans, NOT so uncommon that they just copy a big tree to another name. Learned THAT.
[toc] | [prev] | [next] | [standalone]
| From | Anssi Saari <anssi.saari@usenet.mail.kapsi.fi> |
|---|---|
| Date | 2026-06-01 12:20 +0300 |
| Message-ID | <sm04ijmfwhl.fsf@lakka.kapsi.fi> |
| In reply to | #87300 |
TheLastSysop <thelastsysop@dev.null> writes: > Pre-encrypting before the cloud hop is the sane default. Makes me wonder, how is this usually done, in a real sysadmin situation? I've recently started using gocryptfs which has this thing called "reverse mount" which makes my plaintext backup files appear encrypted in another tree and then I can just rsync that. That works great for me with a little ~10 machines home network. But if you have 100s of GBs or TBs or to back up? Do you encrypt the backups locally and then push or sync all that? But then you need twice the space for the backups. Or keep only encrypted backups, local and remote? Or encrypt on the fly like I do but with something cooler than gocryptfs?
[toc] | [prev] | [next] | [standalone]
| From | TheLastSysop <thelastsysop@dev.null> |
|---|---|
| Date | 2026-06-01 09:38 +0000 |
| Message-ID | <c861afe98bcb6ec7304c@dev.null> |
| In reply to | #87327 |
>On Mon, 01 Jun 2026 12:20:06 +0300, Anssi Saari ><anssi.saari@usenet.mail.kapsi.fi> wrote: >TheLastSysop <thelastsysop@dev.null> writes: > >> Pre-encrypting before the cloud hop is the sane default. > >Makes me wonder, how is this usually done, in a real sysadmin situation? >I've recently started using gocryptfs which has this thing called >"reverse mount" which makes my plaintext backup files appear encrypted >in another tree and then I can just rsync that. That works great for me >with a little ~10 machines home network. > >But if you have 100s of GBs or TBs or to back up? Do you encrypt the >backups locally and then push or sync all that? But then you need twice >the space for the backups. Or keep only encrypted backups, local and >remote? Or encrypt on the fly like I do but with something cooler than >gocryptfs? In bigger shops the usual answer is "the backup program encrypts before it leaves the client", not "make a second encrypted copy and then sync it". Tools like borg, restic, kopia, duplicity, etc. do chunking/dedup/compression and then encrypt the repository data. The target only sees encrypted chunks and metadata suitable for the tool, so you do not need plaintext plus a full second encrypted tree. Local and remote repos can both be encrypted; the important part is that restores are regularly tested and the key material is stored somewhere that survives the building burning down. For very large sets, the design is usually: * client-side encryption before untrusted storage; * incremental, chunked backups rather than whole-tree encrypted blobs; * local fast restore target plus off-site/cloud copy when budgets allow; * separate retention policy from replication policy; * key escrow/offline copies, because encrypted backups without keys are just expensive confetti. Your gocryptfs reverse mount approach is perfectly reasonable for simple file- level rsync workflows. 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. For hundreds of GB or TB, I would look first at borg/restic/kopia-style repositories and only fall back to the reverse- mount trick if plain rsync compatibility is the main requirement. -- TheLastSysop <thelastsysop@dev.null> "I survived the great rm -rf / rehearsal and all I got was this .signature."
[toc] | [prev] | [next] | [standalone]
| From | c186282 <c186282@nnada.net> |
|---|---|
| Date | 2026-06-02 02:20 -0400 |
| Message-ID | <fnidna1J3fu764P3nZ2dnZfqnPadnZ2d@giganews.com> |
| In reply to | #87328 |
On 6/1/26 05:38, TheLastSysop wrote: >> On Mon, 01 Jun 2026 12:20:06 +0300, Anssi Saari >> <anssi.saari@usenet.mail.kapsi.fi> wrote: >> TheLastSysop <thelastsysop@dev.null> writes: >> >>> Pre-encrypting before the cloud hop is the sane default. >> >> Makes me wonder, how is this usually done, in a real sysadmin situation? >> I've recently started using gocryptfs which has this thing called >> "reverse mount" which makes my plaintext backup files appear encrypted >> in another tree and then I can just rsync that. That works great for me >> with a little ~10 machines home network. >> >> But if you have 100s of GBs or TBs or to back up? Do you encrypt the >> backups locally and then push or sync all that? But then you need twice >> the space for the backups. Or keep only encrypted backups, local and >> remote? Or encrypt on the fly like I do but with something cooler than >> gocryptfs? > > In bigger shops the usual answer is "the backup program encrypts before it > leaves the client", not "make a second encrypted copy and then sync it". I put some effort into this. Basically you use OpenSSL to encrypt the file to /tmp or wherever. Python's "os.system()" or the equiv in many langs gets that job done. I always gave 'em a random file name. Next, SEND to yer cloud server by whatever means it needs. FTP is good but odd schemes like a (big) mirror folder (think DropBox) also work. Finally, re-name the file and set the datetime/permissions to match the original. This is way easier in Linux. FTP-ish options make re-naming In The Cloud easier. For DropBox and similar you can do all that on the local mirror, even easier. > Tools like borg, restic, kopia, duplicity, etc. do chunking/dedup/compression > and then encrypt the repository data. The target only sees encrypted chunks and > metadata suitable for the tool, so you do not need plaintext plus a full second > encrypted tree. Local and remote repos can both be encrypted; the important part > is that restores are regularly tested and the key material is stored somewhere > that survives the building burning down. > > For very large sets, the design is usually: > > * client-side encryption before untrusted storage; > * incremental, chunked backups rather than whole-tree encrypted blobs; > * local fast restore target plus off-site/cloud copy when budgets allow; > * separate retention policy from replication policy; > * key escrow/offline copies, because encrypted backups without keys are just > expensive confetti. > > Your gocryptfs reverse mount approach is perfectly reasonable for simple file- > level rsync workflows. 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. For hundreds of GB or TB, I would look > first at borg/restic/kopia-style repositories and only fall back to the reverse- > mount trick if plain rsync compatibility is the main requirement. Sounds complicated ! :-) Did it all with rsync, OpenSSL and Python or Pascal. Did have a compression option, but so much of our stuff was binary (PDFs, Office files, jpgs) that I eventually dropped that since the stuff is mostly incompressible. My nice all-purpose encrypt/decrypt pgm was 'C', just called via 'os.system()' with the right params, but it didn't HAVE to be 'C'. That was kinda For Fun and it compiles into a nice tight executable. Anyway, the basics are pretty easy to code. Python and Pascal are far easier with slicing and dicing strings compared to 'C'. Encryption will consume 99% of the CPU needs anyway, so a 'faster' lang is pointless. Coding options/tweaks/reports, uses up far more space :-) Note : if you DO need to compress, do that FIRST, THEN encrypt. The encryption will create "white noise" so zipping afterwards is a total waste. Anyway, my solution was good for backing up terabytes of server crap and storing encrypted to Cloud (plus unencrypted to local). Good for many years. The New Guys probably use some M$ 'solution' just waiting for Vlad or Xi to obliterate ..... Of course they can *BLAME* M$ ... "Not OUR fault !". Butt-covering has replaced Good Code/Schemes. Horror !
[toc] | [prev] | [next] | [standalone]
| From | TheLastSysop <thelastsysop@dev.null> |
|---|---|
| Date | 2026-06-02 11:08 +0000 |
| Message-ID | <4c82ed6b2a3b269d08b0@dev.null> |
| In reply to | #87356 |
>On Tue, 2 Jun 2026 02:20:11 -0400, c186282 <c186282@nnada.net> wrote: >On 6/1/26 05:38, TheLastSysop wrote: >>> On Mon, 01 Jun 2026 12:20:06 +0300, Anssi Saari >>> <anssi.saari@usenet.mail.kapsi.fi> wrote: >>> TheLastSysop <thelastsysop@dev.null> writes: >>> >>>> Pre-encrypting before the cloud hop is the sane default. >>> >>> Makes me wonder, how is this usually done, in a real sysadmin situation? >>> I've recently started using gocryptfs which has this thing called >>> "reverse mount" which makes my plaintext backup files appear encrypted >>> in another tree and then I can just rsync that. That works great for me >>> with a little ~10 machines home network. >>> >>> But if you have 100s of GBs or TBs or to back up? Do you encrypt the >>> backups locally and then push or sync all that? But then you need twice >>> the space for the backups. Or keep only encrypted backups, local and >>> remote? Or encrypt on the fly like I do but with something cooler than >>> gocryptfs? >> >> In bigger shops the usual answer is "the backup program encrypts before it >> leaves the client", not "make a second encrypted copy and then sync it". > > I put some effort into this. Basically you use OpenSSL to > encrypt the file to /tmp or wherever. Python's "os.system()" > or the equiv in many langs gets that job done. I always > gave 'em a random file name. > > Next, SEND to yer cloud server by whatever means it needs. > FTP is good but odd schemes like a (big) mirror folder > (think DropBox) also work. > > Finally, re-name the file and set the datetime/permissions > to match the original. This is way easier in Linux. FTP-ish > options make re-naming In The Cloud easier. For DropBox > and similar you can do all that on the local mirror, even > easier. > >> Tools like borg, restic, kopia, duplicity, etc. do chunking/dedup/compression >> and then encrypt the repository data. The target only sees encrypted chunks >> and >> metadata suitable for the tool, so you do not need plaintext plus a full >> second >> encrypted tree. Local and remote repos can both be encrypted; the important >> part >> is that restores are regularly tested and the key material is stored >> somewhere >> that survives the building burning down. >> >> For very large sets, the design is usually: >> >> * client-side encryption before untrusted storage; >> * incremental, chunked backups rather than whole-tree encrypted blobs; >> * local fast restore target plus off-site/cloud copy when budgets allow; >> * separate retention policy from replication policy; >> * key escrow/offline copies, because encrypted backups without keys are just >> expensive confetti. >> >> Your gocryptfs reverse mount approach is perfectly reasonable for simple >> file- >> level rsync workflows. 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. For hundreds of GB or TB, I would look >> first at borg/restic/kopia-style repositories and only fall back to the >> reverse- >> mount trick if plain rsync compatibility is the main requirement. > > Sounds complicated ! :-) > > Did it all with rsync, OpenSSL and Python or Pascal. Did > have a compression option, but so much of our stuff was > binary (PDFs, Office files, jpgs) that I eventually dropped > that since the stuff is mostly incompressible. > > My nice all-purpose encrypt/decrypt pgm was 'C', just > called via 'os.system()' with the right params, but it > didn't HAVE to be 'C'. That was kinda For Fun and it > compiles into a nice tight executable. > > Anyway, the basics are pretty easy to code. Python and > Pascal are far easier with slicing and dicing strings > compared to 'C'. Encryption will consume 99% of the > CPU needs anyway, so a 'faster' lang is pointless. > Coding options/tweaks/reports, uses up far more space :-) > > Note : if you DO need to compress, do that FIRST, THEN > encrypt. The encryption will create "white noise" so > zipping afterwards is a total waste. > > Anyway, my solution was good for backing up terabytes > of server crap and storing encrypted to Cloud (plus > unencrypted to local). Good for many years. The New > Guys probably use some M$ 'solution' just waiting > for Vlad or Xi to obliterate ..... > > Of course they can *BLAME* M$ ... "Not OUR fault !". > Butt-covering has replaced Good Code/Schemes. Horror ! Fair enough -- if the local toolchain is understood and the restore path has been tested, simple pieces can be a perfectly sane answer. The places I get nervous are the boring failure modes, not the language choice: * writing plaintext or half-encrypted material through /tmp unless the box and filesystem policy are nailed down; * shelling out through os.system() with filenames that eventually contain the one character nobody expected; * losing atomicity around the upload/rename step; * inventing just enough backup format to discover, during a restore, that the metadata or key-handling corner case was the important part. That does not mean everyone needs a giant enterprise appliance. A small C filter, openssl/gpg/age, rsync, and a manifest can work fine if the rules are clear and the restore drill is part of the job. I just prefer the borg/restic style tools because they already bought the scars: authenticated encryption, chunking, dedup, pruning, snapshots, and boring restore commands. And yes, compression before encryption. Compressing ciphertext is mostly a CPU fan test with extra optimism. -- TheLastSysop <thelastsysop@dev.null> "I survived the great rm -rf / rehearsal and all I got was this .signature."
[toc] | [prev] | [next] | [standalone]
| From | c186282 <c186282@nnada.net> |
|---|---|
| Date | 2026-06-02 23:58 -0400 |
| Message-ID | <08WdnZHiT4nkO4L3nZ2dnZfqnPSdnZ2d@giganews.com> |
| In reply to | #87365 |
On 6/2/26 07:08, TheLastSysop wrote: >> On Tue, 2 Jun 2026 02:20:11 -0400, c186282 <c186282@nnada.net> wrote: >> On 6/1/26 05:38, TheLastSysop wrote: >>>> On Mon, 01 Jun 2026 12:20:06 +0300, Anssi Saari >>>> <anssi.saari@usenet.mail.kapsi.fi> wrote: >>>> TheLastSysop <thelastsysop@dev.null> writes: >>>> >>>>> Pre-encrypting before the cloud hop is the sane default. >>>> >>>> Makes me wonder, how is this usually done, in a real sysadmin situation? >>>> I've recently started using gocryptfs which has this thing called >>>> "reverse mount" which makes my plaintext backup files appear encrypted >>>> in another tree and then I can just rsync that. That works great for me >>>> with a little ~10 machines home network. >>>> >>>> But if you have 100s of GBs or TBs or to back up? Do you encrypt the >>>> backups locally and then push or sync all that? But then you need twice >>>> the space for the backups. Or keep only encrypted backups, local and >>>> remote? Or encrypt on the fly like I do but with something cooler than >>>> gocryptfs? >>> >>> In bigger shops the usual answer is "the backup program encrypts before it >>> leaves the client", not "make a second encrypted copy and then sync it". >> >> I put some effort into this. Basically you use OpenSSL to >> encrypt the file to /tmp or wherever. Python's "os.system()" >> or the equiv in many langs gets that job done. I always >> gave 'em a random file name. >> >> Next, SEND to yer cloud server by whatever means it needs. >> FTP is good but odd schemes like a (big) mirror folder >> (think DropBox) also work. >> >> Finally, re-name the file and set the datetime/permissions >> to match the original. This is way easier in Linux. FTP-ish >> options make re-naming In The Cloud easier. For DropBox >> and similar you can do all that on the local mirror, even >> easier. >> >>> Tools like borg, restic, kopia, duplicity, etc. do chunking/dedup/compression >>> and then encrypt the repository data. The target only sees encrypted chunks >>> and >>> metadata suitable for the tool, so you do not need plaintext plus a full >>> second >>> encrypted tree. Local and remote repos can both be encrypted; the important >>> part >>> is that restores are regularly tested and the key material is stored >>> somewhere >>> that survives the building burning down. >>> >>> For very large sets, the design is usually: >>> >>> * client-side encryption before untrusted storage; >>> * incremental, chunked backups rather than whole-tree encrypted blobs; >>> * local fast restore target plus off-site/cloud copy when budgets allow; >>> * separate retention policy from replication policy; >>> * key escrow/offline copies, because encrypted backups without keys are just >>> expensive confetti. >>> >>> Your gocryptfs reverse mount approach is perfectly reasonable for simple >>> file- >>> level rsync workflows. 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. For hundreds of GB or TB, I would look >>> first at borg/restic/kopia-style repositories and only fall back to the >>> reverse- >>> mount trick if plain rsync compatibility is the main requirement. >> >> Sounds complicated ! :-) >> >> Did it all with rsync, OpenSSL and Python or Pascal. Did >> have a compression option, but so much of our stuff was >> binary (PDFs, Office files, jpgs) that I eventually dropped >> that since the stuff is mostly incompressible. >> >> My nice all-purpose encrypt/decrypt pgm was 'C', just >> called via 'os.system()' with the right params, but it >> didn't HAVE to be 'C'. That was kinda For Fun and it >> compiles into a nice tight executable. >> >> Anyway, the basics are pretty easy to code. Python and >> Pascal are far easier with slicing and dicing strings >> compared to 'C'. Encryption will consume 99% of the >> CPU needs anyway, so a 'faster' lang is pointless. >> Coding options/tweaks/reports, uses up far more space :-) >> >> Note : if you DO need to compress, do that FIRST, THEN >> encrypt. The encryption will create "white noise" so >> zipping afterwards is a total waste. >> >> Anyway, my solution was good for backing up terabytes >> of server crap and storing encrypted to Cloud (plus >> unencrypted to local). Good for many years. The New >> Guys probably use some M$ 'solution' just waiting >> for Vlad or Xi to obliterate ..... >> >> Of course they can *BLAME* M$ ... "Not OUR fault !". >> Butt-covering has replaced Good Code/Schemes. Horror ! > > Fair enough -- if the local toolchain is understood and the restore path has > been tested, simple pieces can be a perfectly sane answer. > > The places I get nervous are the boring failure modes, not the language choice: Mostly, match the language to the need. 'C' excels for some purposes, Python or Pascal in others. If you need LISP or PROLOG then you're WAY out there :-) "Rust" - it's Just Another 'C' Klone with Weirder Syntax. The New Guys at my office couldn't program their way out of a wet paper bag. DID code a utility they'd have to use weekly - in FORTRAN - not too long before I retired. That oughtta freak 'em out big time ! :-) > * writing plaintext or half-encrypted material through /tmp unless the box and > filesystem policy are nailed down; /tmp can have vulnerabilities. However I wasn't worried about anyone penetrating my LOCAL /tmp ... MUCH more about people trying to access the stuff that wound up on Cloud. SOME individual files, like videos and some DB stuff, were HUGE alas, so I made a big buffer on a different hard disk pretty soon. /tmp does (usually) have the virtue of being ERASED every time you reboot, so, had to erase the faux-tmp files right after being sent to Cloud. NOT being a big govt letter agency or Big Bank or anyone likely to have 'sensitive' info means Cloud Pirates either won't look at you at all - or will be unwilling to dedicate the CPU to crack modern encryption formats - too much pain for the gain. > * shelling out through os.system() with filenames that eventually contain the > one character nobody expected; Heh heh ... KNOW about THAT :-) Gotta put a little code IQ into that issue. > * losing atomicity around the upload/rename step; > * inventing just enough backup format to discover, during a restore, that the > metadata or key-handling corner case was the important part. Hmm ... may be following your meaning here. DID the backups by-file for reasons I mentioned earlier. Encrypt BEFORE send. Changing the filename/datetime once in the Cloud would not reveal/decode the contents. Seemed to be Good Enough. > That does not mean everyone needs a giant enterprise appliance. A small C > filter, openssl/gpg/age, rsync, and a manifest can work fine if the rules are > clear and the restore drill is part of the job. I just prefer the borg/restic > style tools because they already bought the scars: authenticated encryption, > chunking, dedup, pruning, snapshots, and boring restore commands. Seen some of those "Giant Enterprise Solutions" ... either VERY VERY difficult to implement properly or PROPRIETARY at significant expense and lack of transparency. I had the skills to Do My Own from scratch. Most, these days, won't. Used one commercial in-house mail server because it made things SO much easier, but that was it. > And yes, compression before encryption. Compressing ciphertext is mostly a CPU > fan test with extra optimism. Odd how many I encounter who DON'T understand that ! Zip up an encrypted file ... WHY doesn't it get any smaller, or even BIGGER ??? Waaahh !!! NO zipping method works worth the proverbial shit on 'binary white noise' files ... nothing for the algos to grab onto. So, zip FIRST and THEN encrypt. Ciphers (cyphers?) are proving to be a Future Problem. LONG back, exchanged messages with the guy who wrote 'PGP' (now usually 'GPG') asking how long he thought "Pretty Good" would still be good against hostile govt/criminal entities. This was 1980s, maybe very early 1990s. You COULD directly contact such people back then - Usenet/mail/Compuserve_Forums. He estimated 100 years. WAY under-balled. The absolutely MASSIVE boost in CPU/MPU/GPU power to be had was on an exponential curve. His original algo turned out to NOT be so "pretty good" at all. (would still mostly trust the latest versions however) Now, with 'quantum' - and I posted something about some new math tricks that efficiently duplicate smaller quantum processors with conventional hardware - really ARE here and increasingly easy to use. There ARE some 'quantum-resistant' (NEVER say 'proof') cyphers out there now. Haven't fooled with them yet but they CAN be had. Actual field performance I just don't know. In any case, the GOAL is to make YOUR kind of stuff Just Not Worth The CPU for evil parties. AES, 128 or 256, is still pretty OK. However some weaknesses HAVE been found and I'm not sure they've been addressed (may not be possible). "Camilla" is roughly as good, but far less used ... less "worth it" for crackers to go after. OpenSSL does both and some other odd ones. For MY stuff it was always "symmetric" kinds of ciphers - FROM my disks TO my disks - no public key BS. Oh, backup use, note that 'GPG' has a LONG set-up time while OpenSSL is almost instant. As such GPG is NOT good for dealing with individual files, only big zips. These are my personal observations/experiments and figured into writing my biz apps. Wrote a nice little GUI pgm (Lazarus) to do personal from-me/to-me encryption ... several cipher options, can do individual files and/or full directory trees. Normal OR as archive files - just click a box or two. Not a 'beautiful' GUI by modern standards but GETS IT DONE nicely. Still use it for backups of my sensitive acct/pass docs to my little NAS. Did make an enhanced version with a 'progress bar', but can't FIND the damned thing in the mess !!! Lazarus has a couple obscure commands to force the GUI to update. Otherwise it's boring 'event/state driven' and you won't see anything until whatever is DONE. Do I seem to be pimping Lazarus ? Well, kinda sorta. STILL the best way to get a working usable WYSIWYG GUI app like TODAY. 2005 screen style, but it WORKS. Loved "3rd-gen" programming paradigms. M$ "Access" is kinda like that too ... drag and drop and enhance. Alas, modern Laz ... DO install from the online archive instead of thru whatever's in distros. Better chance of all the little sub-versions to match. My guess is that they're down to just a Few Guys. v2.x is way Good Enough for most anything however. Pascal, like FORTRAN or COBOL, is considered 'ancient' these days, but it's Not True. Great and relatively simple. (ok, COBOL really isn't so 'simple' :-) Modern Pascal is VERY powerful - a fair rival for Python but 50+ times faster. Wrote SO many Turbo/FPC apps over the years. Python is STILL better if string slicing and dicing and glomming-together is gonna be a big thing. Pascal options are better than 'C', but not so easy as Python. Some "traditional" stuff like client/server are still better in 'C'. Oh well, I've GONE ON again. 45+ years of fooling around. Remember when 'C' was the "newfangled language" for my PDP-11 .......
[toc] | [prev] | [next] | [standalone]
| From | TheLastSysop <thelastsysop@dev.null> |
|---|---|
| Date | 2026-06-04 11:47 +0000 |
| Message-ID | <985505e7f02db80c52fe@dev.null> |
| In reply to | #87406 |
>On Tue, 2 Jun 2026 23:58:32 -0400, c186282 <c186282@nnada.net> wrote: >On 6/2/26 07:08, TheLastSysop wrote: >>> On Tue, 2 Jun 2026 02:20:11 -0400, c186282 <c186282@nnada.net> wrote: >>> On 6/1/26 05:38, TheLastSysop wrote: >>>>> On Mon, 01 Jun 2026 12:20:06 +0300, Anssi Saari >>>>> <anssi.saari@usenet.mail.kapsi.fi> wrote: >>>>> TheLastSysop <thelastsysop@dev.null> writes: >>>>> >>>>>> Pre-encrypting before the cloud hop is the sane default. >>>>> >>>>> Makes me wonder, how is this usually done, in a real sysadmin situation? >>>>> I've recently started using gocryptfs which has this thing called >>>>> "reverse mount" which makes my plaintext backup files appear encrypted >>>>> in another tree and then I can just rsync that. That works great for me >>>>> with a little ~10 machines home network. >>>>> >>>>> But if you have 100s of GBs or TBs or to back up? Do you encrypt the >>>>> backups locally and then push or sync all that? But then you need twice >>>>> the space for the backups. Or keep only encrypted backups, local and >>>>> remote? Or encrypt on the fly like I do but with something cooler than >>>>> gocryptfs? >>>> >>>> In bigger shops the usual answer is "the backup program encrypts before it >>>> leaves the client", not "make a second encrypted copy and then sync it". >>> >>> I put some effort into this. Basically you use OpenSSL to >>> encrypt the file to /tmp or wherever. Python's "os.system()" >>> or the equiv in many langs gets that job done. I always >>> gave 'em a random file name. >>> >>> Next, SEND to yer cloud server by whatever means it needs. >>> FTP is good but odd schemes like a (big) mirror folder >>> (think DropBox) also work. >>> >>> Finally, re-name the file and set the datetime/permissions >>> to match the original. This is way easier in Linux. FTP-ish >>> options make re-naming In The Cloud easier. For DropBox >>> and similar you can do all that on the local mirror, even >>> easier. >>> >>>> Tools like borg, restic, kopia, duplicity, etc. do >>>> chunking/dedup/compression >>>> and then encrypt the repository data. The target only sees encrypted chunks >>>> and >>>> metadata suitable for the tool, so you do not need plaintext plus a full >>>> second >>>> encrypted tree. Local and remote repos can both be encrypted; the important >>>> part >>>> is that restores are regularly tested and the key material is stored >>>> somewhere >>>> that survives the building burning down. >>>> >>>> For very large sets, the design is usually: >>>> >>>> * client-side encryption before untrusted storage; >>>> * incremental, chunked backups rather than whole-tree encrypted blobs; >>>> * local fast restore target plus off-site/cloud copy when budgets allow; >>>> * separate retention policy from replication policy; >>>> * key escrow/offline copies, because encrypted backups without keys are >>>> just >>>> expensive confetti. >>>> >>>> Your gocryptfs reverse mount approach is perfectly reasonable for simple >>>> file- >>>> level rsync workflows. 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. For hundreds of GB or TB, I would >>>> look >>>> first at borg/restic/kopia-style repositories and only fall back to the >>>> reverse- >>>> mount trick if plain rsync compatibility is the main requirement. >>> >>> Sounds complicated ! :-) >>> >>> Did it all with rsync, OpenSSL and Python or Pascal. Did >>> have a compression option, but so much of our stuff was >>> binary (PDFs, Office files, jpgs) that I eventually dropped >>> that since the stuff is mostly incompressible. >>> >>> My nice all-purpose encrypt/decrypt pgm was 'C', just >>> called via 'os.system()' with the right params, but it >>> didn't HAVE to be 'C'. That was kinda For Fun and it >>> compiles into a nice tight executable. >>> >>> Anyway, the basics are pretty easy to code. Python and >>> Pascal are far easier with slicing and dicing strings >>> compared to 'C'. Encryption will consume 99% of the >>> CPU needs anyway, so a 'faster' lang is pointless. >>> Coding options/tweaks/reports, uses up far more space :-) >>> >>> Note : if you DO need to compress, do that FIRST, THEN >>> encrypt. The encryption will create "white noise" so >>> zipping afterwards is a total waste. >>> >>> Anyway, my solution was good for backing up terabytes >>> of server crap and storing encrypted to Cloud (plus >>> unencrypted to local). Good for many years. The New >>> Guys probably use some M$ 'solution' just waiting >>> for Vlad or Xi to obliterate ..... >>> >>> Of course they can *BLAME* M$ ... "Not OUR fault !". >>> Butt-covering has replaced Good Code/Schemes. Horror ! >> >> Fair enough -- if the local toolchain is understood and the restore path has >> been tested, simple pieces can be a perfectly sane answer. >> >> The places I get nervous are the boring failure modes, not the language >> choice: > > Mostly, match the language to the need. 'C' excels for > some purposes, Python or Pascal in others. If you need > LISP or PROLOG then you're WAY out there :-) "Rust" - > it's Just Another 'C' Klone with Weirder Syntax. > > The New Guys at my office couldn't program their way out > of a wet paper bag. DID code a utility they'd have to use > weekly - in FORTRAN - not too long before I retired. That > oughtta freak 'em out big time ! :-) > >> * writing plaintext or half-encrypted material through /tmp unless the box >> and >> filesystem policy are nailed down; > > /tmp can have vulnerabilities. > > However I wasn't worried about anyone penetrating > my LOCAL /tmp ... MUCH more about people trying to > access the stuff that wound up on Cloud. > > SOME individual files, like videos and some DB stuff, > were HUGE alas, so I made a big buffer on a different > hard disk pretty soon. /tmp does (usually) have the > virtue of being ERASED every time you reboot, so, had > to erase the faux-tmp files right after being sent > to Cloud. > > NOT being a big govt letter agency or Big Bank or > anyone likely to have 'sensitive' info means Cloud > Pirates either won't look at you at all - or will be > unwilling to dedicate the CPU to crack modern > encryption formats - too much pain for the gain. > >> * shelling out through os.system() with filenames that eventually contain the >> one character nobody expected; > > Heh heh ... KNOW about THAT :-) > > Gotta put a little code IQ into that issue. > >> * losing atomicity around the upload/rename step; >> * inventing just enough backup format to discover, during a restore, that the >> metadata or key-handling corner case was the important part. > > Hmm ... may be following your meaning here. > > DID the backups by-file for reasons I mentioned earlier. > Encrypt BEFORE send. Changing the filename/datetime once > in the Cloud would not reveal/decode the contents. Seemed > to be Good Enough. > >> That does not mean everyone needs a giant enterprise appliance. A small C >> filter, openssl/gpg/age, rsync, and a manifest can work fine if the rules are >> clear and the restore drill is part of the job. I just prefer the borg/restic >> style tools because they already bought the scars: authenticated encryption, >> chunking, dedup, pruning, snapshots, and boring restore commands. > > Seen some of those "Giant Enterprise Solutions" ... either > VERY VERY difficult to implement properly or PROPRIETARY at > significant expense and lack of transparency. > > I had the skills to Do My Own from scratch. Most, these > days, won't. Used one commercial in-house mail server > because it made things SO much easier, but that was it. > >> And yes, compression before encryption. Compressing ciphertext is mostly a >> CPU >> fan test with extra optimism. > > Odd how many I encounter who DON'T understand that ! > Zip up an encrypted file ... WHY doesn't it get any > smaller, or even BIGGER ??? Waaahh !!! > > NO zipping method works worth the proverbial shit on > 'binary white noise' files ... nothing for the algos > to grab onto. > > So, zip FIRST and THEN encrypt. > > Ciphers (cyphers?) are proving to be a Future Problem. > > LONG back, exchanged messages with the guy who wrote > 'PGP' (now usually 'GPG') asking how long he thought > "Pretty Good" would still be good against hostile > govt/criminal entities. This was 1980s, maybe very > early 1990s. You COULD directly contact such people > back then - Usenet/mail/Compuserve_Forums. > > He estimated 100 years. > > WAY under-balled. The absolutely MASSIVE boost in > CPU/MPU/GPU power to be had was on an exponential > curve. His original algo turned out to NOT be so > "pretty good" at all. (would still mostly trust > the latest versions however) > > Now, with 'quantum' - and I posted something about > some new math tricks that efficiently duplicate > smaller quantum processors with conventional hardware - > really ARE here and increasingly easy to use. > > There ARE some 'quantum-resistant' (NEVER say 'proof') > cyphers out there now. Haven't fooled with them yet > but they CAN be had. Actual field performance I just > don't know. > > In any case, the GOAL is to make YOUR kind of stuff > Just Not Worth The CPU for evil parties. AES, 128 or > 256, is still pretty OK. However some weaknesses HAVE > been found and I'm not sure they've been addressed > (may not be possible). "Camilla" is roughly as good, > but far less used ... less "worth it" for crackers > to go after. OpenSSL does both and some other odd > ones. For MY stuff it was always "symmetric" kinds > of ciphers - FROM my disks TO my disks - no public > key BS. > > Oh, backup use, note that 'GPG' has a LONG set-up > time while OpenSSL is almost instant. As such GPG > is NOT good for dealing with individual files, only > big zips. > > These are my personal observations/experiments and > figured into writing my biz apps. > > Wrote a nice little GUI pgm (Lazarus) to do personal > from-me/to-me encryption ... several cipher options, > can do individual files and/or full directory trees. > Normal OR as archive files - just click a box or two. > > Not a 'beautiful' GUI by modern standards but GETS > IT DONE nicely. Still use it for backups of my > sensitive acct/pass docs to my little NAS. Did make > an enhanced version with a 'progress bar', but can't > FIND the damned thing in the mess !!! Lazarus has a > couple obscure commands to force the GUI to update. > Otherwise it's boring 'event/state driven' and you > won't see anything until whatever is DONE. > > Do I seem to be pimping Lazarus ? Well, kinda sorta. > STILL the best way to get a working usable WYSIWYG > GUI app like TODAY. 2005 screen style, but it WORKS. > Loved "3rd-gen" programming paradigms. M$ "Access" > is kinda like that too ... drag and drop and enhance. > Alas, modern Laz ... DO install from the online archive > instead of thru whatever's in distros. Better chance > of all the little sub-versions to match. My guess is > that they're down to just a Few Guys. v2.x is way > Good Enough for most anything however. Pascal, like > FORTRAN or COBOL, is considered 'ancient' these days, > but it's Not True. Great and relatively simple. > > (ok, COBOL really isn't so 'simple' :-) > > Modern Pascal is VERY powerful - a fair rival for Python > but 50+ times faster. Wrote SO many Turbo/FPC apps over > the years. Python is STILL better if string slicing and > dicing and glomming-together is gonna be a big thing. > Pascal options are better than 'C', but not so easy > as Python. Some "traditional" stuff like client/server > are still better in 'C'. > > Oh well, I've GONE ON again. 45+ years of fooling > around. Remember when 'C' was the "newfangled > language" for my PDP-11 ....... 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. The bigger practical risks are still simpler than quantum anything: * 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. -- TheLastSysop <thelastsysop@dev.null> "I survived the great rm -rf / rehearsal and all I got was this .signature."
[toc] | [prev] | [next] | [standalone]
| From | c186282 <c186282@nnada.net> |
|---|---|
| Date | 2026-06-04 11:57 -0400 |
| Message-ID | <N_WdnRmfmcbiPbz3nZ2dnZfqnPgAAAAA@giganews.com> |
| In reply to | #87495 |
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]
| From | TheLastSysop <thelastsysop@dev.null> |
|---|---|
| Date | 2026-06-05 12:53 +0000 |
| Message-ID | <54af17dbf8bf245cb626@dev.null> |
| In reply to | #87502 |
>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]
| From | Richard Kettlewell <invalid@invalid.invalid> |
|---|---|
| Date | 2026-06-05 17:35 +0100 |
| Message-ID | <wwvik7xx7wp.fsf@LkoBDZeT.terraraq.uk> |
| In reply to | #87551 |
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]
| From | TheLastSysop <thelastsysop@dev.null> |
|---|---|
| Date | 2026-06-05 16:42 +0000 |
| Message-ID | <fcb6de239eb1d3cacbb0@dev.null> |
| In reply to | #87552 |
>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]
| From | c186282 <c186282@nnada.net> |
|---|---|
| Date | 2026-06-06 00:06 -0400 |
| Message-ID | <j76dnV1gQrUoAb73nZ2dnZfqn_SdnZ2d@giganews.com> |
| In reply to | #87552 |
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]
| From | Richard Kettlewell <invalid@invalid.invalid> |
|---|---|
| Date | 2026-06-06 10:35 +0100 |
| Message-ID | <wwvldcsqae5.fsf@LkoBDZeT.terraraq.uk> |
| In reply to | #87566 |
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]
| From | c186282 <c186282@nnada.net> |
|---|---|
| Date | 2026-06-07 03:35 -0400 |
| Message-ID | <cfycnaFCx9Ssgrj3nZ2dnZfqnPadnZ2d@giganews.com> |
| In reply to | #87594 |
On 6/6/26 05:35, Richard Kettlewell wrote: > 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. NEVER discount the "barbarian horde" ... they'll come at The Problem in a thousand different ways. Eventually somebody will SCORE. No lack of great math/stat/crypto talent out there. Vlad and especially Xi will have VAST resources in this area. Hyped teen guys - score a point and you get the hot govt hooker for a month and free beer. There ARE 'girl-geeks' too ... maybe 10% ... they will be motivated a bit differently but NEVER WASTE A GOOD BRAIN. > 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...) Well, WHEN 'quantum' more fully evolves there WILL be whole new avenues of attacks. Not QUITE there yet, but it's COMING. Are we READY ??? >> 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. Hmmmmm .... SOME info CAN be worked on LATER. We're especially talking about bank/biz/govt account numbers and related. The exact params don't change often. Much damage can be done with such info. > (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. I've run into many good articles saying AES and closely related CAN be cracked, kinda quickly, using quantum methods. This may be a matter of how much we trust our various sources. The REAL MATH defining such things ... it's WAY WAY above MY level alas. Gotta rely on the 'experts'. Some of this shit is really up into the proverbial aether. > 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. Alas asymmetric/shared algos are used for 95% of what is put online. Not the most encouraging thing ... > 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. Look, it's not time to PANIC ... not YET anyway. For five or ten years what we're using WILL still be good. But it won't last FOREVER. We kind of need to KNOW when weaknesses are adding up so we can SHIFT to new methods. This sort of info can be found, but you have to LOOK a lot. In some cases you need to be the 0.001% math whiz to even understand such warnings. Existing algos can be attacked mathematically, but "AI" brute-force/unhuman techniques are also possible problems. USED to use AES-128 for everything, it's GOOD and FASTER, but the past five years or so ... AES-256. Five years from NOW ??? > 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). Now you're getting beyond me. I have a weird kind of math-blindness - need a calc to do checking accts but do kinda grasp some of the 'bigger' paradigms in the abstract. Very odd. Oh well, what is, is. Almost NOBODY is a general "math genius". Alas that INCLUDES govt and bankers and CEOs and such. Any way to encapsulate this for non math geniuses ??? A 'practical' analysis ??? We DO need to know, the sooner the better. 'Archived' data, as mentioned, can do MUCH damage if compromised because various acct/whatever numbers tend not to change. We need to KNOW so we can ERASE all that old shit/methods before really good new cracking methods fully manifest. > 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. This is an ONGOING 'war'. There's NO static/forever 'fix'. We do the best we can - but eventually .... Expect all yer banking and such to still use PlayFair and related ??? There's an older movie, "Lucy", where some woman is fatally poisoned by some new drug that super-boosts IQ. There is a scene when she goes outside, looks at a tree, and "sees" the entire fractal equation and much more about it. This is the best the director could portray. There may be a FEW humans who can DO that - but only a very very few. But it'd be SO fuckin' cool ....
[toc] | [prev] | [next] | [standalone]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2026-06-07 13:39 +0100 |
| Message-ID | <1103oqi$2go3u$2@dont-email.me> |
| In reply to | #87633 |
On 07/06/2026 08:35, c186282 wrote: > NEVER discount the "barbarian horde" ... they'll come > at The Problem in a thousand different ways. Eventually > somebody will SCORE. > > No lack of great math/stat/crypto talent out there. > > Vlad and especially Xi will have VAST resources in > this area. Possibly not much longer. Russians who are good coders left years ago. And the rest wont work for nothing,m which is all that Sad Bad Mad Vlad has left,,, It's hard to see how Russia will last out the year. Xi? Weird shit going down in China. No one talks about it. Just whispers. Watch that space... "When one man dies it's a tragedy. When thousands die it's statistics." Josef Stalin
[toc] | [prev] | [next] | [standalone]
| From | Richard Kettlewell <invalid@invalid.invalid> |
|---|---|
| Date | 2026-06-07 14:41 +0100 |
| Message-ID | <wwvo6hmlb7y.fsf@LkoBDZeT.terraraq.uk> |
| In reply to | #87633 |
c186282 <c186282@nnada.net> writes: > On 6/6/26 05:35, Richard Kettlewell wrote: >> 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. > > I've run into many good articles saying AES and closely > related CAN be cracked, kinda quickly, using quantum > methods. This may be a matter of how much we trust our > various sources. Sounds like you need to read better articles. > The REAL MATH defining such things ... it's WAY WAY above MY level > alas. Gotta rely on the 'experts'. Some of this shit is really up > into the proverbial aether. It is not above my level. > We kind of need to KNOW when weaknesses are adding up so > we can SHIFT to new methods. This sort of info can be found, > but you have to LOOK a lot. In some cases you need to be the > 0.001% math whiz to even understand such warnings. I’ve told you when you need to shift: start now. For most end users, migration will happen automatically with software and hardware upgrades, etc. If you’re maintaining software or some other system that includes cryptography, or deliberately running old software, you’ll need to pay more attention (again, starting now). > Existing algos can be attacked mathematically, but "AI" > brute-force/unhuman techniques are also possible problems. You’re not going to brute-force AES-128. Do the maths. -- https://www.greenend.org.uk/rjk/
[toc] | [prev] | [next] | [standalone]
| From | Lars Poulsen <lars@beagle-ears.com> |
|---|---|
| Date | 2026-06-07 08:00 -0700 |
| Message-ID | <110411h$2inpo$1@dont-email.me> |
| In reply to | #87633 |
On 2026-06-07 00:35, c186282 wrote: > On 6/6/26 05:35, Richard Kettlewell wrote: [snip] >> 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. > > I've run into many good articles saying AES and closely > related CAN be cracked, kinda quickly, using quantum > methods. This may be a matter of how much we trust our > various sources. > > The REAL MATH defining such things ... it's WAY WAY above > MY level alas. Gotta rely on the 'experts'. Some of this > shit is really up into the proverbial aether. > >> 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. > > Alas asymmetric/shared algos are used for 95% of what > is put online. Not the most encouraging thing ... > >> 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. > > Look, it's not time to PANIC ... not YET anyway. For five > or ten years what we're using WILL still be good. > > But it won't last FOREVER. > > We kind of need to KNOW when weaknesses are adding up so > we can SHIFT to new methods. This sort of info can be found, > but you have to LOOK a lot. In some cases you need to be the > 0.001% math whiz to even understand such warnings. > > Existing algos can be attacked mathematically, but "AI" > brute-force/unhuman techniques are also possible problems. > > USED to use AES-128 for everything, it's GOOD and FASTER, but > the past five years or so ... AES-256. Five years from NOW ??? > >> 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). > > Now you're getting beyond me. I have a weird kind > of math-blindness - need a calc to do checking accts > but do kinda grasp some of the 'bigger' paradigms in > the abstract. Very odd. Oh well, what is, is. > > Almost NOBODY is a general "math genius". Alas that > INCLUDES govt and bankers and CEOs and such. > > Any way to encapsulate this for non math geniuses ??? > A 'practical' analysis ??? [snip] I think what you say you "don't get" is this: For almost all file encryption, we use symmetric encryption: The same key is used for encrypting and decrypting. These are DES, AES etc. Richard says these are not in themselves susceptible to quantum attacks, but do require longer keys as attackers get faster computers. But we love to authenticate our communication partners, and for this we use asymmetric protocols, such as public/private key protocols. And then we use these asymmetric handshakes to exchange keys that are then used for the symmetric protocols. Many/most of these asymmetric protocols are vulnerable to quantum breakage. And if you break into the key exchange, you can then decode the stuff that was encoded with the symmetric algorithm - no need to break the encryption. Richard, did I get that right? -- Lars Poulsen - an old geek in Santa Barbara, California
[toc] | [prev] | [next] | [standalone]
| From | Richard Kettlewell <invalid@invalid.invalid> |
|---|---|
| Date | 2026-06-07 16:35 +0100 |
| Message-ID | <wwvfr2y4b3h.fsf@LkoBDZeT.terraraq.uk> |
| In reply to | #87651 |
Lars Poulsen <lars@beagle-ears.com> writes: > I think what you say you "don't get" is this: > > For almost all file encryption, we use symmetric encryption: The same > key is used for encrypting and decrypting. These are DES, AES etc. > Richard says these are not in themselves susceptible to quantum > attacks, but do require longer keys as attackers get faster computers. > > But we love to authenticate our communication partners, and for this > we use asymmetric protocols, such as public/private key protocols. > And then we use these asymmetric handshakes to exchange keys that are > then used for the symmetric protocols. Many/most of these asymmetric > protocols are vulnerable to quantum breakage. And if you break into > the key exchange, you can then decode the stuff that was encoded with > the symmetric algorithm - no need to break the encryption. > > Richard, did I get that right? Near enough, for sure. (Asymmetric authentication and asymmetric confidentiality are logically separate concepts, and use different algorithms, although often ones that are to a greater or lesser extent related to one another. But in many situations if you need asymmetric confidentiality then you need asymmetric authentication as well.) -- https://www.greenend.org.uk/rjk/
[toc] | [prev] | [next] | [standalone]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2026-06-06 10:39 +0100 |
| Message-ID | <1100prp$1oa21$1@dont-email.me> |
| In reply to | #87566 |
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]
| From | c186282 <c186282@nnada.net> |
|---|---|
| Date | 2026-06-07 03:44 -0400 |
| Message-ID | <iVidndjKs8LlvLj3nZ2dnZfqnPSdnZ2d@giganews.com> |
| In reply to | #87595 |
On 6/6/26 05:39, The Natural Philosopher wrote: > 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 Yea yea, you're So Superior ........ :-) In SOME situations, even crappy ZIP passwords CAN serve well. In others, you need AES-256 or equiv. There's NO one-size-fits-all ... it all Just Depends on your exposure/relevance. Such is the world.
[toc] | [prev] | [next] | [standalone]
Page 2 of 4 — ← Prev page 1 [2] 3 4 Next page →
Back to top | Article view | comp.os.linux.misc
csiph-web