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 125 — 15 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 c186282 <c186282@nnada.net> - 2026-06-08 00:04 -0400
Re: The boring Linux habit that saves machines The Natural Philosopher <tnp@invalid.invalid> - 2026-06-08 09:34 +0100
Re: The boring Linux habit that saves machines Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-06-08 18:08 +0000
Re: The boring Linux habit that saves machines The Natural Philosopher <tnp@invalid.invalid> - 2026-06-08 21:24 +0100
Re: The boring Linux habit that saves machines rbowman <bowman@montana.com> - 2026-06-09 01:46 +0000
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-09 03:09 -0400
Re: The boring Linux habit that saves machines The Natural Philosopher <tnp@invalid.invalid> - 2026-06-09 11:17 +0100
Re: The boring Linux habit that saves machines rbowman <bowman@montana.com> - 2026-06-09 18:28 +0000
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-09 02:54 -0400
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-09 01:27 -0400
Re: The boring Linux habit that saves machines "Carlos E.R." <robin_listas@es.invalid> - 2026-06-09 10:57 +0200
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 Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-07 23:48 +0000
Re: The boring Linux habit that saves machines Nuno Silva <nunojsilva@invalid.invalid> - 2026-06-08 00:53 +0100
Re: The boring Linux habit that saves machines Richard Kettlewell <invalid@invalid.invalid> - 2026-06-08 08:26 +0100
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-08 23:06 -0400
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-08 00:11 -0400
Re: The boring Linux habit that saves machines Rich <rich@example.invalid> - 2026-06-09 17:42 +0000
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 Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-07 23:39 +0000
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-07 23:00 -0400
Re: The boring Linux habit that saves machines Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-06-08 04:36 +0000
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-08 02:30 -0400
Re: The boring Linux habit that saves machines The Natural Philosopher <tnp@invalid.invalid> - 2026-06-08 09:19 +0100
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-08 23:53 -0400
Re: The boring Linux habit that saves machines rbowman <bowman@montana.com> - 2026-06-08 14:23 +0000
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-09 02:28 -0400
Re: The boring Linux habit that saves machines rbowman <bowman@montana.com> - 2026-06-09 18:24 +0000
Re: The boring Linux habit that saves machines Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-06-08 18:08 +0000
Re: The boring Linux habit that saves machines "Carlos E.R." <robin_listas@es.invalid> - 2026-06-08 22:42 +0200
Re: The boring Linux habit that saves machines Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-09 00:45 +0000
Re: The boring Linux habit that saves machines rbowman <bowman@montana.com> - 2026-06-09 01:44 +0000
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-09 03:08 -0400
Re: The boring Linux habit that saves machines "Carlos E.R." <robin_listas@es.invalid> - 2026-06-09 11:07 +0200
Re: The boring Linux habit that saves machines Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-06-09 18:31 +0000
Re: The boring Linux habit that saves machines Nuno Silva <nunojsilva@invalid.invalid> - 2026-06-08 09:54 +0100
Re: The boring Linux habit that saves machines Eric Pozharski <apple.universe@posteo.net> - 2026-06-08 21:46 +0000
Re: The boring Linux habit that saves machines Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-09 04:50 +0000
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-09 03:16 -0400
Re: The boring Linux habit that saves machines Richard Kettlewell <invalid@invalid.invalid> - 2026-06-09 08:49 +0100
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-09 01:48 -0400
Re: The boring Linux habit that saves machines "Carlos E.R." <robin_listas@es.invalid> - 2026-06-09 11:11 +0200
Re: The boring Linux habit that saves machines Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-06-09 18:31 +0000
Re: The boring Linux habit that saves machines rbowman <bowman@montana.com> - 2026-06-08 14:12 +0000
Re: The boring Linux habit that saves machines Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-06-08 18:08 +0000
Re: The boring Linux habit that saves machines rbowman <bowman@montana.com> - 2026-06-09 01:30 +0000
Re: The boring Linux habit that saves machines "Carlos E.R." <robin_listas@es.invalid> - 2026-06-09 11:15 +0200
Re: The boring Linux habit that saves machines Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-06-09 18:31 +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 23:38 -0400
Re: The boring Linux habit that saves machines The Natural Philosopher <tnp@invalid.invalid> - 2026-06-08 09:22 +0100
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-09 00:28 -0400
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 3 of 7 — ← Prev page 1 2 [3] 4 5 6 7 Next page →
| From | rbowman <bowman@montana.com> |
|---|---|
| Date | 2026-06-09 01:46 +0000 |
| Message-ID | <n8p9jqF8q2vU6@mid.individual.net> |
| In reply to | #87701 |
On Mon, 08 Jun 2026 18:08:10 GMT, Charlie Gibbs wrote: > I thought it was Netanyahu that bought him. > Oh well, same day, different war... Bibi's shabbas goy is getting uppity these days and thinks he can tell Bibi what to do. Interesting days ahead.
[toc] | [prev] | [next] | [standalone]
| From | c186282 <c186282@nnada.net> |
|---|---|
| Date | 2026-06-09 03:09 -0400 |
| Message-ID | <zOCcnVFzd4itIbr3nZ2dnZfqn_cAAAAA@giganews.com> |
| In reply to | #87709 |
On 6/8/26 21:46, rbowman wrote: > On Mon, 08 Jun 2026 18:08:10 GMT, Charlie Gibbs wrote: > >> I thought it was Netanyahu that bought him. >> Oh well, same day, different war... > > Bibi's shabbas goy is getting uppity these days and thinks he can tell > Bibi what to do. Interesting days ahead. Wow ... TDS even here .........
[toc] | [prev] | [next] | [standalone]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2026-06-09 11:17 +0100 |
| Message-ID | <1108p7r$3t5ug$2@dont-email.me> |
| In reply to | #87727 |
On 09/06/2026 08:09, c186282 wrote: > On 6/8/26 21:46, rbowman wrote: >> On Mon, 08 Jun 2026 18:08:10 GMT, Charlie Gibbs wrote: >> >>> I thought it was Netanyahu that bought him. >>> Oh well, same day, different war... >> >> Bibi's shabbas goy is getting uppity these days and thinks he can tell >> Bibi what to do. Interesting days ahead. > > Wow ... TDS even here ......... > It's everywhere. Mostly in the White House. -- New Socialism consists essentially in being seen to have your heart in the right place whilst your head is in the clouds and your hand is in someone else's pocket.
[toc] | [prev] | [next] | [standalone]
| From | rbowman <bowman@montana.com> |
|---|---|
| Date | 2026-06-09 18:28 +0000 |
| Message-ID | <n8r4adFbsbqU2@mid.individual.net> |
| In reply to | #87727 |
On Tue, 9 Jun 2026 03:09:27 -0400, c186282 wrote: > On 6/8/26 21:46, rbowman wrote: >> On Mon, 08 Jun 2026 18:08:10 GMT, Charlie Gibbs wrote: >> >>> I thought it was Netanyahu that bought him. >>> Oh well, same day, different war... >> >> Bibi's shabbas goy is getting uppity these days and thinks he can tell >> Bibi what to do. Interesting days ahead. > > Wow ... TDS even here ......... No, but I didn't drink the Kool-Aid either.
[toc] | [prev] | [next] | [standalone]
| From | c186282 <c186282@nnada.net> |
|---|---|
| Date | 2026-06-09 02:54 -0400 |
| Message-ID | <zOCcnVdzd4hRJbr3nZ2dnZfqn_ednZ2d@giganews.com> |
| In reply to | #87701 |
On 6/8/26 14:08, Charlie Gibbs wrote: > On 2026-06-08, The Natural Philosopher <tnp@invalid.invalid> wrote: > >> "If you want the root passwords, they are all written down on post-it >> notes behind the receptionist. If you want to bypass the firewall, just >> use one of the direct dial in modems the employees use on their PCs to >> enable them to work from home" > > The movie "War Games" dealt with these things. Although it had > technical holes you could drive a truck through, the protagonist > pulling out a desk's writing leaf to reveal a sheet of passwords > was good for a laugh, and the most realistic part of the movie. > > I wouldn't have minded having his 9600-bps acoustic coupler, though. HAVE one ! :-) Though it's more reliable at 2400. Gotta dig into The Heap more often. Have an Apple-II, with its DOS - but haven't fired up the thing since forever. The floppy may have gone bad by now alas. Now WHERE is my ZX-81 ??? >> At some stage someone is going to realise also, that rather than a 4GW >> nuclear plant driving a $10 billion AI data centres, it might actually >> be cheaper to employ a human. > > Yes, but not nearly as much fun. Besides, what would the little people > do with all that electricity? Cook meals? > >> The Russians already did that when they bought Donald Trump... > > I thought it was Netanyahu that bought him. > Oh well, same day, different war... Ignore the Vast Konspiracy Theorists. Didja know that reptillian space aliens are BREEDING with hot co-ed girls ? :-)
[toc] | [prev] | [next] | [standalone]
| From | c186282 <c186282@nnada.net> |
|---|---|
| Date | 2026-06-09 01:27 -0400 |
| Message-ID | <zOCcnVtzd4jOObr3nZ2dnZfqn_ednZ2d@giganews.com> |
| In reply to | #87691 |
On 6/8/26 04:34, The Natural Philosopher wrote: > On 08/06/2026 05:04, c186282 wrote: >> On 6/7/26 09:41, Richard Kettlewell wrote: > >> >>>> 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. >> >> Well, good. We need math geniuses. >> >> Note that almost no one are math geniuses. >> > But Richard in fact IS. And he has spent his life immersed in these > concepts. As said, VERY GOOD. We NEED a few like him. SOME programming stuff really does hinge on VERY complex math - encryption especially. >>> You’re not going to brute-force AES-128. Do the maths. >> >> It's not so much "brute force" ... it's inherent >> little flaws in the algo - according to my sources. >> Reduces the need for "brute". >> > Well maybe. Arguably Enigma wasn't 'brute forced' either.. STRICTLY, no. Bad comm officers were the ultimate key to Enigma. It provided the extra needed to kind of zoom in on the problem. "Pure", kind of random, attack methods hadn't yielded much until then. >> But, so far, no "easy" cracks - just such 'time savers'. >> AES and related should be "good enough" for at least five >> more years. >> >> But, AFTER that, how much of YOUR important info will be >> in accessible AES-encrypted archive files somewhere ? >> Do they change all your banking/ID/investment numbers >> every year ? It's that "data tail" that worries me. >> Being "old" nobody will guard it so well. >> > > I cannot recall anyone ever 'cracking' any password or encryption I have > used personally YOUR stuff, PERSONALLY ... But what about yer bank, yer govt, your 'welfare' institution ??? MIGHT still have all those old recs in DES or similar ..... It's armor - but with your butt exposed. > Most hacks are way simpler. > > "If you want the root passwords, they are all written down on post-it > notes behind the receptionist. If you want to bypass the firewall, just > use one of the direct dial in modems the employees use on their PCs to > enable them to work from home" "Human Factors" are the MOST vulnerable. Plenty of IDIOT humans in the mix too. TRIED to sensitize them ... with FAIR success. Kinda trained them to "smell a rat" and then they'd bounce it to me ... and I'd dissect/research. IF I found some bad stuff I'd send them a congrats - and a two or three para simple description of WHY it was bad. No lecturing, nothing esp abstract. This seemed to work best. > At some stage someone is going to realise also, that rather than a 4GW > nuclear plant driving a $10 billion AI data centres, it might actually > be cheaper to employ a human. True - but don't tell 'em that right NOW :-) > The Russians already did that when they bought Donald Trump... Sorry, Vlad doesn't own Donald. Don't mistake 'diplomatic language' for actual deception and such. Trump WILL flatter Vlad, right up until some recruited agent sticks a knife in Vlad's back. This is how it's DONE. Ah, 'human factors' ... one of my favorite cases was when a sec got an invoice for a large amount of concrete. We DID use concrete - but got it from a dusty place a few miles up the road. The bill was into five figures. Fortunately our place was just small enough so one person could shout down the hall "Do we remember buying a whole bunch of concrete last month ???" The alleged supplier was in AUSTRALIA - a legit mining-supply company. We were USA. If you wanted giant drills and ore carts on tracks, they were yer go-to. Found the LINK was to a blank page on their web site that just bounced you back to their main page so it'd look legit. Evil people may have PUT it there, but it was probably just a link they FOUND by poking around, a 'placeholder' page. The actual dest for payment ... SEEMED to be eastern Europe, likely Romania, as best I could tell. All this took me a couple of HOURS. Wrote it up as simple and concise as possible, mentioned the 'clues'. The employee was happy she spotted this, good psych reinforcement, got mentioned at the next weekly dept meeting so other would become more wise. SOME places PUNISH employees that screw up on things like this. Sorry, 99.999% of the pop could NOT do the kind of research I did - involving deep reading of HTML+ files looking for Evil. Punish employees for stuff well above their pay grade and they just WON'T REPORT such stuff any more. Management/IT becomes The Enemy. Bounce them and then you have to Start Over with a new, naive, worker. No net improvement. Of course management can ALWAYS blame it on that low-wage worker .... that's how biz politics works. Disgusting ! "THEY did it ! We FIRED them ! We're clean now !!!". Things started drifting more towards "disgusting" my last year. Put in my notice. NOT unhappy about that.
[toc] | [prev] | [next] | [standalone]
| From | "Carlos E.R." <robin_listas@es.invalid> |
|---|---|
| Date | 2026-06-09 10:57 +0200 |
| Message-ID | <651lfmxelh.ln2@Telcontar.valinor> |
| In reply to | #87719 |
On 2026-06-09 07:27, c186282 wrote: > On 6/8/26 04:34, The Natural Philosopher wrote: >> On 08/06/2026 05:04, c186282 wrote: >>> On 6/7/26 09:41, Richard Kettlewell wrote: ... >> At some stage someone is going to realise also, that rather than a 4GW >> nuclear plant driving a $10 billion AI data centres, it might actually >> be cheaper to employ a human. > > True - but don't tell 'em that right NOW :-) > >> The Russians already did that when they bought Donald Trump... > > Sorry, Vlad doesn't own Donald. Don't mistake 'diplomatic > language' for actual deception and such. Trump WILL flatter > Vlad, right up until some recruited agent sticks a knife in > Vlad's back. This is how it's DONE. > > Ah, 'human factors' ... one of my favorite cases was when > a sec got an invoice for a large amount of concrete. We > DID use concrete - but got it from a dusty place a few > miles up the road. The bill was into five figures. > > Fortunately our place was just small enough so one person > could shout down the hall "Do we remember buying a whole > bunch of concrete last month ???" > > The alleged supplier was in AUSTRALIA - a legit mining-supply > company. We were USA. If you wanted giant drills and ore carts > on tracks, they were yer go-to. > > Found the LINK was to a blank page on their web site that > just bounced you back to their main page so it'd look legit. > Evil people may have PUT it there, but it was probably just > a link they FOUND by poking around, a 'placeholder' page. > > The actual dest for payment ... SEEMED to be eastern Europe, > likely Romania, as best I could tell. All this took me a > couple of HOURS. > > Wrote it up as simple and concise as possible, mentioned > the 'clues'. The employee was happy she spotted this, good > psych reinforcement, got mentioned at the next weekly > dept meeting so other would become more wise. > > SOME places PUNISH employees that screw up on things like > this. Sorry, 99.999% of the pop could NOT do the kind of > research I did - involving deep reading of HTML+ files > looking for Evil. Punish employees for stuff well above > their pay grade and they just WON'T REPORT such stuff > any more. Management/IT becomes The Enemy. Bounce them and > then you have to Start Over with a new, naive, worker. > No net improvement. Very sensible what you did. > > Of course management can ALWAYS blame it on that low-wage > worker .... that's how biz politics works. Disgusting ! > "THEY did it ! We FIRED them ! We're clean now !!!". > > Things started drifting more towards "disgusting" my last > year. Put in my notice. NOT unhappy about that. > -- Cheers, Carlos. ES🇪🇸, EU🇪🇺;
[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 | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-06-07 23:48 +0000 |
| Message-ID | <1104vvp$2rlf4$8@dont-email.me> |
| In reply to | #87651 |
On Sun, 7 Jun 2026 08:00:01 -0700, Lars Poulsen wrote: > For almost all file encryption, we use symmetric encryption: The > same key is used for encrypting and decrypting. These are DES, AES > etc. I hate the use of “symmetric” for this usage. I originally learned that “symmetric” applied to schemes where the encryption and decryption algorithms were one and the same. The main example is XOR-based encryption: apply XOR with a key once to encrypt, apply it again with the same key to decrypt. The one where the two algorithms are different, but share a common key, is called “secret-key” encryption. A “secret” is not something that you must never tell anyone: instead, it is something that should only be disclosed to trusted partners (like the peer you’re communicating with). Otherwise you couldn’t have concepts such as “shared-secret authentication”, could you? > 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. You know why? Why not use the public/private key protocols directly, for the entire communication? It’s because they’re about a thousand times slower than secret-key protocols, that’s why. Just not practical for high-volume use. > 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. But the key exchange uses a separate protocol, e.g. the one known as “Diffie-Hellman”. Cracking of those is an entirely separate matter from cracking private/public key encryption itself. Has any “quantum” weakness been demonstrated in Diffie-Hellman? Not that I’ve heard of.
[toc] | [prev] | [next] | [standalone]
| From | Nuno Silva <nunojsilva@invalid.invalid> |
|---|---|
| Date | 2026-06-08 00:53 +0100 |
| Message-ID | <11050ah$2rflv$1@dont-email.me> |
| In reply to | #87664 |
On 2026-06-08, Lawrence D’Oliveiro wrote: > On Sun, 7 Jun 2026 08:00:01 -0700, Lars Poulsen wrote: > >> For almost all file encryption, we use symmetric encryption: The >> same key is used for encrypting and decrypting. These are DES, AES >> etc. > > I hate the use of “symmetric” for this usage. I originally learned > that “symmetric” applied to schemes where the encryption and > decryption algorithms were one and the same. The main example is > XOR-based encryption: apply XOR with a key once to encrypt, apply it > again with the same key to decrypt. > > The one where the two algorithms are different, but share a common > key, is called “secret-key” encryption. A “secret” is not something > that you must never tell anyone: instead, it is something that should > only be disclosed to trusted partners (like the peer you’re > communicating with). Otherwise you couldn’t have concepts such as > “shared-secret authentication”, could you? This really goes counter what I've learned, symmetric and asymmetric applying to whether the secret is shared or not. If I'm understanding correctly, by your definition, RSA would be symmetric? -- Nuno Silva
[toc] | [prev] | [next] | [standalone]
| From | Richard Kettlewell <invalid@invalid.invalid> |
|---|---|
| Date | 2026-06-08 08:26 +0100 |
| Message-ID | <wwvtsrdv6ft.fsf@LkoBDZeT.terraraq.uk> |
| In reply to | #87664 |
Lawrence D’Oliveiro <ldo@nz.invalid> writes: > Lars Poulsen wrote: > >> For almost all file encryption, we use symmetric encryption: The >> same key is used for encrypting and decrypting. These are DES, AES >> etc. > > I hate the use of “symmetric” for this usage. The usage is completely standard, you’ll have to get used to it. >> 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. > > But the key exchange uses a separate protocol, e.g. the one known as > “Diffie-Hellman”. Cracking of those is an entirely separate matter > from cracking private/public key encryption itself. Has any “quantum” > weakness been demonstrated in Diffie-Hellman? Not that I’ve heard of. Yes, Diffie-Hellman is vulnerable to a quantum computer. -- https://www.greenend.org.uk/rjk/
[toc] | [prev] | [next] | [standalone]
| From | c186282 <c186282@nnada.net> |
|---|---|
| Date | 2026-06-08 23:06 -0400 |
| Message-ID | <zOCcnVlzd4ipHrr3nZ2dnZfqn_ednZ2d@giganews.com> |
| In reply to | #87686 |
On 6/8/26 03:26, Richard Kettlewell wrote: > Lawrence D’Oliveiro <ldo@nz.invalid> writes: >> Lars Poulsen wrote: >> >>> For almost all file encryption, we use symmetric encryption: The >>> same key is used for encrypting and decrypting. These are DES, AES >>> etc. >> >> I hate the use of “symmetric” for this usage. > > The usage is completely standard, you’ll have to get used to it. It's a 'conventional' way of referring to it. Not perfectly descriptive, but Good Enough. >>> 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. >> >> But the key exchange uses a separate protocol, e.g. the one known as >> “Diffie-Hellman”. Cracking of those is an entirely separate matter >> from cracking private/public key encryption itself. Has any “quantum” >> weakness been demonstrated in Diffie-Hellman? Not that I’ve heard of. > > Yes, Diffie-Hellman is vulnerable to a quantum computer. As said, so FAR, quantum computers are kind of few and far between and you need to make a reservation for time months in advance. But that IS changing. The Intel quantum chip looks pretty GOOD and should make quantum much more available. Also posted about a couple of new conventional math methods that can FAKE quantum - within limits - pretty well. SO ... 'quantum-resistant' soon needs to become a new Must-Have for online commerce. We will only know just HOW resistant it really is once the barbarian horde has a go at it. Jacked-up 12 year olds can be VERY creative and 'AI' can look for patterns humans will never see. Also ARCHIVED data on you ... there's a LONG 'tail' there going back years, decades. Bet a lot of your account numbers haven't changed since then. 'Old' stuff probably isn't guarded as zealously as new stuff - but can STILL do you a lot of damage. Most of that will be 'symmetric' encryption - but may include some older, esp vulnerable, methods. Wasn't THAT long ago that 'DES' was considered 'ok' ..... Oh, finally, five or so years, what if there are NO encryption methods that are generally 'resistant' to either the 12-year-olds and/or AI ??? What happens to the 'online' models then ? Back to the Sears catalogue store ... walk-in and show your face ... ultra-temporary moving acct numbers ? How's that work ? Fifteen+ years ago one bank "proto-Wachovia ?" had an interesting online payment method. You'd quickly create a temporary FAKE CCard account number with just so much money for just so long. You could use that for online transactions. It went away - but now maybe it and more needs to come back ??? Over-net 'biometrics' can already be fooled and AI is making that MUCH easier. Yer prints, yer face, NO longer 'secure'. Besides, post 'em ONCE and they get copied across the un-free world in seconds. It's a PROBLEM. There are a few 'geniuses' who post here and around, not shy about it either. Can THEY come up with fixes ? If so, do it QUICK. It's the New Mission.
[toc] | [prev] | [next] | [standalone]
| From | c186282 <c186282@nnada.net> |
|---|---|
| Date | 2026-06-08 00:11 -0400 |
| Message-ID | <InGdndjgSouM3Lv3nZ2dnZfqn_oAAAAA@giganews.com> |
| In reply to | #87651 |
On 6/7/26 11:00, Lars Poulsen wrote: > 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: SHAME on me !!! However I can read what those to DO "get" crypto have to say. Past couple of years they're starting to say "be cautious". > 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? Hmm ... saved all my cloud backups as symmetric. But banking/biz web work is asymmetric. Won't be much biz after Xi disappears all our money.
[toc] | [prev] | [next] | [standalone]
| From | Rich <rich@example.invalid> |
|---|---|
| Date | 2026-06-09 17:42 +0000 |
| Message-ID | <1109j99$6g9r$1@dont-email.me> |
| In reply to | #87651 |
Lars Poulsen <lars@beagle-ears.com> wrote: > 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? This exchange points out what XKCD 538 is parioding in a comical way: https://xkcd.com/538/ There's usually a shortcut to unlocking something that was encrypted, but that shortcut does not in any way involve "breaking the encryption".
[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]
| From | c186282 <c186282@nnada.net> |
|---|---|
| Date | 2026-06-05 23:55 -0400 |
| Message-ID | <1eCcnWvfKdOnB773nZ2dnZfqn_SdnZ2d@giganews.com> |
| In reply to | #87551 |
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]
| From | TheLastSysop <thelastsysop@dev.null> |
|---|---|
| Date | 2026-06-06 09:40 +0000 |
| Message-ID | <c0f267880de5d4b776d5@dev.null> |
| In reply to | #87565 |
>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]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-06-07 02:47 +0000 |
| Message-ID | <1102m4u$287og$4@dont-email.me> |
| In reply to | #87596 |
On Sat, 06 Jun 2026 09:40:20 GMT, TheLastSysop wrote: > 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. I must admit, I could probably live with forbidding newlines in file/directory names. Why not reserve one little character, just to make life that little bit easier for shell script writers? ;)
[toc] | [prev] | [next] | [standalone]
Page 3 of 7 — ← Prev page 1 2 [3] 4 5 6 7 Next page →
Back to top | Article view | comp.os.linux.misc
csiph-web