On Saturday, August 20, 2022 at 12:47:47 PM UTC-5, Robert A. Brooks wrote:
> On 8/20/2022 1:05 PM, Stephen Hoffman wrote:
>
> > If BACKUP is encrypting data before performing data compression, that's a design
> > bug in BACKUP.
> That is, unfortunately, the way it was implemented.
>
> --
>
> --- Rob

That is unfortunate. Do you think it is something VSI might look at correcting?

On 8/22/2022 11:32 AM, Alexander Schreiber wrote:
> Dave Froble <davef@tsoft-inc.com> wrote:
>> On 8/21/2022 8:47 PM, Arne Vajhøj wrote:
>>> On 8/21/2022 7:57 PM, Dave Froble wrote:
>>>> On 8/21/2022 7:08 PM, Arne Vajhøj wrote:
>>>>> On 8/21/2022 2:58 PM, Dave Froble wrote:
>>>>>> On 8/21/2022 12:43 PM, Bill Gunshannon wrote:
>>>>>>> On 8/21/22 11:33, Dave Froble wrote:
>>>>>>>> Back to auditors. Would not a reasonable person/company determine whether a
>>>>>>>> prospective employee was qualified for a job? Then why would not a
>>>>>>>> reasonable
>>>>>>>> person/company do the same for auditors? But all too often that doesn't
>>>>>>>> happen. If an auditing firm could show reasonable knowledge about VMS, then
>>>>>>>> they might be qualified to perform auditing on a VMS solution.
>>>>>>>
>>>>>>> Of course at the level where the decisions are made (and the auditors
>>>>>>> contracted) your demand for VMS knowledgeable auditors is just more
>>>>>>> ammunition to throw VMS out the door and go with something more in line
>>>>>>> with modern business practice.
>>>>>>
>>>>>> Total bullshit!
>>>>>>
>>>>>> I'd demand the same expertise of those auditing Unix, Linux, WEENDOZE, and
>>>>>> anything else. Anything else is just total nonsense.
>>>>>
>>>>> I don't think Bill was saying that there should be a difference in
>>>>> skills to audit VMS vs audit Linux and Windows.
>>>>>
>>>>> I think he is saying that if there is 100 companies that have
>>>>> skills to audit Linux and Windows but only 10 companies with
>>>>> skill to audit VMS then it is sending a bad signal to
>>>>> senior management about VMS having a support problem.
>>>>
>>>> But there would be those 10 companies, and the service most likely will be good.
>>>
>>> I believe there would still be audit companies either with
>>> VMS skills in house or smart enough to hire external VMS
>>> expertise when needed (someone like Robert Gezelter comes
>>> to my mind as a proper expert for something like this).
>>>
>>> But senior management doesn't like stuff that require
>>> special consideration. The smart ones can be convinced
>>> to accept something requiring special consideration if
>>> there are good reasons for it.
>>
>> Is "these apps run our company better than anything else" a good reason?
>
> More likely: "These internal applications have decades of development in them,
> there aren't really any turnkey solutions that you can buy to replace them
> and switching to a different platform would mean $lots of investment to make
> them useful replacements - investments in time, money and people"

You understand it well ...

>> Many executives are smart enough to not screww up things that are working well.
>
> Sadly, there are just enough that "need to leave their mark" (i.e. piss on
> something) to be a problem.

You also understand that well ...

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 8/22/2022 11:28 AM, Alexander Schreiber wrote:
> Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>> On 8/21/22 11:33, Dave Froble wrote:
>>> On 8/21/2022 9:54 AM, Alexander Schreiber wrote:
>>>> Dave Froble <davef@tsoft-inc.com> wrote:
>>>>> On 8/19/2022 4:18 AM, David Wade wrote:
>>>>>> On 19/08/2022 03:20, Dave Froble wrote:
>>>>>>> On 8/18/2022 6:50 PM, Rich Jordan wrote:
>>>>>>>> Wee!, its audit time again!
>>>>>>>>
>>>>>>>> I reviewed the VSI site and didn't see mention but thought I would
>>>>>>>> ask here
>>>>>>>> also.
>>>>>>>>
>>>>>>>> Last time I looked, VMS, even current VSI versions, can do manual
>>>>>>>> per-file
>>>>>>>> encryption/decryption, but not whole disk. That means you
>>>>>>>> couldn't encrypt
>>>>>>>> production files and have them usable; you'd have to decrypt, use,
>>>>>>>> re-encrypt, then delete the unencrypted version; a no go save
>>>>>>>> perhaps for
>>>>>>>> small critical files sync'd by human usage.
>>>>>>>>
>>>>>>>> And backup savesets can be encrypted, but at the cost of both
>>>>>>>> increased time
>>>>>>>> and the loss of compression (which is often a substantial time and
>>>>>>>> space
>>>>>>>> saver itself).
>>>>>>>>
>>>>>>>> I presume that is still the current state of things?
>>>>>>>>
>>>>>>>> I poked our pc guys to find out if the various hypervisors
>>>>>>>> support running
>>>>>>>> VMs whose disk files are on encrypted disks; a possible future
>>>>>>>> option for a
>>>>>>>> VMS 9.x VM to keep the auditors happy.
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>>
>>>>>>>
>>>>>>> Fire the auditors ...
>>>>>>>
>>>>>> What difference would that make? They work from the same tick list.
>>>>>> Dave
>>>>>
>>>>> The question is, is that list valid? Perhaps, and perhaps not.
>>>>>
>>>>> Some auditors might be helpful and have some good advice. But I'm
>>>>> currently
>>>>> aware of some auditors that are basically crooks. Accepting
>>>>> everything auditors
>>>>> might suggest may not be a good thing. And shouldn't their
>>>>> "suggestions" be
>>>>> just that, "suggestions"?
>>>>
>>>> That depends. Any credit card processor who deems the PCI DSS rules to
>>>> be mere suggestions will eventually (usually rather quickly) discover
>>>> that it doesn't have a business anymore.
>>>>
>>>> Kind regards,
>>>> Alex.
>>>>
>>>
>>> Credit card processing is not just protecting your data, thus being a
>>> bit different.
>>>
>>> A while back we came up with a design to protect credit card data,
>>> checking account data, and such. Basically breaking up the data, and
>>> storing pieces in different databases, on multiple servers, encrypted.
>>> Thus all the information was not in one location. Might get pieces, a
>>> tad more difficult to get a complete piece of data.
>>>
>>> Regardless, had to transmit the data at some point in time, so that
>>> exposure is constant.
>>>
>>> Then we took a look at the third party vendors who would store, and
>>> protect, the data, AND take all responsibility. It was a no-brainer, we
>>> abandoned all plans to store the data ourselves.
>>>
>>> Back to auditors. Would not a reasonable person/company determine
>>> whether a prospective employee was qualified for a job? Then why would
>>> not a reasonable person/company do the same for auditors? But all too
>>> often that doesn't happen. If an auditing firm could show reasonable
>>> knowledge about VMS, then they might be qualified to perform auditing on
>>> a VMS solution.
>>
>> Of course at the level where the decisions are made (and the auditors
>> contracted) your demand for VMS knowledgeable auditors is just more
>> ammunition to throw VMS out the door and go with something more in line
>> with modern business practice.
>
> "Modern business practice" appears to be:
> - run Windows on everything (bonus points for running old versions
> because some critical software only runs on that 10y old Windows)
> - don't bother too much with the patching
> - don't bother with access/network restrictions or
> secure system design because "security just gets in the way"
> - get your stuff encrypted by some ransomware gang
> - bonus points for getting juicy data published
> - claim "there was nothing we could do"
> - do the same again

:-) :-) :-)

> When in fact it is possible to run solid reliable infrastructure that
> doesn't get 0wned by some random drive-by bot. But doing so has a price,
> a price that some companies are willing to pay since not paying it can
> be a lot more expensive.
>
> Kind regards,
> Alex.
>

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 8/22/2022 1:55 PM, Arne Vajhøj wrote:
> On 8/22/2022 11:28 AM, Alexander Schreiber wrote:
>> Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>>> Of course at the level where the decisions are made (and the auditors
>>> contracted) your demand for VMS knowledgeable auditors is just more
>>> ammunition to throw VMS out the door and go with something more in line
>>> with modern business practice.
>>
>> "Modern business practice" appears to be:
>> - run Windows on everything (bonus points for running old versions
>> because some critical software only runs on that 10y old Windows)
>
> (I assume we are talking servers here)
>
> Most run Linux and are trying to move to k8s.
>
>> - don't bother too much with the patching
>
> Most are trying to keep up with patches but there are a lot
> of patches today.
>
>> - don't bother with access/network restrictions or
>> secure system design because "security just gets in the way"
>
> Almost everybody got firewalls in place everywhere today.

Arne, you might need a recount ...

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

> Ummm just to be clear, OP _does_ care about the quality of available encryption, but the question was not about quality, it was about availability.
>
> And right now encryption support of the type required (which means running programs accessing data on encrypted disks but not needing to care about that because the OS takes care of it) is not currently available.
>
> Also, it is not, at this time, a requirement. Its a question that got asked by the auditors about all of the site's servers, including two linux boxes, a ton of window servers, and the VMS server. The site does not need to encrypt its windows servers at this time. They _do_ encrypt data connections between sites (on top of that provided by the VPN tunnels) but a lot of traffic on the local LANs is not required to be encrypted either. More of that may be coming, but so far it is not required.
>
> Thanks!

Rich,

I know of some sites that are using 3PAR that have that capability. The encryption is handled by the 3PAR and VMS knows nothing. I am not aware of a similar tape option however. I would suspect that any SAN system that has encryption would work similarly.

I know of emulated OpenVMS systems that work in this fashion as well. In these cases, the backup savesets are on disk and thus are also encrypted.

Dan

On 8/22/2022 2:44 PM, Rich Jordan wrote:
> On Saturday, August 20, 2022 at 12:47:47 PM UTC-5, Robert A. Brooks wrote:
>> On 8/20/2022 1:05 PM, Stephen Hoffman wrote:
>>
>>> If BACKUP is encrypting data before performing data compression, that's a design
>>> bug in BACKUP.
>> That is, unfortunately, the way it was implemented.
>>
>> --
>>
>> --- Rob
>
> That is unfortunate. Do you think it is something VSI might look at correcting?

That would be pretty hard to do and retain the (broken) backward compatibility.

--
-- Rob

On Saturday, August 20, 2022 at 12:05:38 PM UTC-5, Stephen Hoffman wrote:
> On 2022-08-18 22:50:38 +0000, Rich Jordan said:
>
> > Wee!, its audit time again!
> >
> > I reviewed the VSI site and didn't see mention but thought I would ask
> > here also.
> If you have VSI support, open a support call. That'll get this
> discussion added to whatever escalation and enhancement and scheduling
> discussions are underway within VSI, and might also get some
> documentation created and reviewed.
> > Last time I looked, VMS, even current VSI versions, can do manual
> > per-file encryption/decryption, but not whole disk. That means you
> > couldn't encrypt production files and have them usable; you'd have to
> > decrypt, use, re-encrypt, then delete the unencrypted version; a no go
> > save perhaps for small critical files sync'd by human usage.
> Correct. You'll need outboard encrypting storage to meet this
> requirement, either as a guest in a VM that can encrypt its backing
> storage, or using encrypting storage hardware.
>
> If SSD storage hardware is involved, ensure it supports
> erase-on-zero-sector writes, and also ensure that OpenVMS highwater
> marking and erase-on-delete are enabled, and that no site-local $ERAPAT
> service is loaded.
>
> For those unclear on the purpose of and usefulness of full-disk
> encryption (FDE) in this and other OpenVMS contexts, FDE is intended to
> make server decommissioning and server repairs much less likely to leak
> data, as well as cases of server or storage theft. You can't
> necessarily erase a failed storage component, but somebody inclined to
> try might be able to access any data remaining on the device. With FDE,
> any remaining data will be inaccessible without the key.
> > And backup savesets can be encrypted, but at the cost of both increased
> > time and the loss of compression (which is often a substantial time and
> > space saver itself).
> If BACKUP is encrypting data before performing data compression, that's
> a design bug in BACKUP.
>
> Properly encrypted data is not compressible, but properly compressed
> data can be encrypted.
>
> And yes, OpenVMS systems are comparatively slow, and supported
> processors prior to x86-64 are lacking in encryption acceleration
> hardware features.
>
> https://en.wikipedia.org/wiki/AES_instruction_set
>
> While most (all?) recent x86-64 hardware does have hardware
> acceleration support for encryption, I'd assume OpenVMS x86-64 is not
> (yet?) using that.
> > I presume that is still the current state of things?
> Correct.
>
> The OpenVMS security-related documentation—both for server management,
> and for app development—is unfortunately also outdated, too.
>
> Auditors can be difficult to deal with and can miss other issues, but
> FDE and basic data security discussed here is not an unusual, onerous,
> nor even remotely questionable requirement.
>
> TL;DR: waivers and maybe FDE HW/SW support incoming.
>
>
>
>
> --
> Pure Personal Opinion | HoffmanLabs LLC

Hoff, thanks for responding again.

Right now its a question, not a requirement or so far as we know, an impending requirement.

Our HyperV guy says that once VSI VMS is available for HyperV that the underlying files can be on encrypted storage. Still waiting to hear about VMWare, but Virtualbox does support encrypting its storage (files? disks?) directly if I understand their docs from a very quick overview, so that might be a future option too (unless the auditors don't like virtualbox because its not HyperV or VMWare).

I don't consider the decommissioning thing to be an issue at our level; it certainly might be for a site that has tons of servers and high turnover, but in this case, VMS hardware lives for 10 years, PC hardware at least 5, and we're talking about decomming maybe 2 servers per year on average, maybe 20-40 related disks. The customer contracts out storage destruction and hardware recycling to a bonded company, though in the case of the last VMS server, we did the destruction and recycling. Nice magnets in those hard drives (though I had to do that after hours... ;)

Your point on auditors and data encryption is well taken, but we have had to deal with some in the past who literally could not understand anything not microsoft based and had to be kindergarten level shown the security features that were available and implemented, system auditing and how it worked, etc because they were otherwise going to report that the VMS box didn't have any security and was wide open and anyone could connect and brute force it and it wouldn't stop them from trying... that was at a publicly traded company, the underlying reason for the audit along with S-OX.

Thanks again.

On 2022-08-22 18:58:07 +0000, Robert A. Brooks said:

> On 8/22/2022 2:44 PM, Rich Jordan wrote:
>> On Saturday, August 20, 2022 at 12:47:47 PM UTC-5, Robert A. Brooks wrote:
>>> On 8/20/2022 1:05 PM, Stephen Hoffman wrote:
>>>
>>>> If BACKUP is encrypting data before performing data compression, that's
>>>> a design
>>>> bug in BACKUP.
>>> That is, unfortunately, the way it was implemented.
>>>
>>> --
>>>
>>> --- Rob
>>
>> That is unfortunate. Do you think it is something VSI might look at
>> correcting?
>
> That would be pretty hard to do and retain the (broken) backward compatibility.

This would be the second or third time BACKUP compatibility was broken.

The API was badly broken a while back, and the fix broke some apps.

The BACKUP header files were still mislocated, when last I checked.

As for this case, I'd expect the number of sites decompressing an
encrypted saveset without also decrypting it would be negligible.

Meaning fixing this would reduce storage usage—probably a fair
amount—at the risk of breaking those sites decompressing but not
decrypting.

But then BACKUP itself is also ~at its design limit, so investing in a
replacement for BACKUP would seem a more prudent longer-term approach.

Y'all get to make these calls, of course. Not sure I'd want to wade
into BACKUP without a plan to refactor or replace it.

--
Pure Personal Opinion | HoffmanLabs LLC

On 8/22/2022 2:58 PM, Robert A. Brooks wrote:
> On 8/22/2022 2:44 PM, Rich Jordan wrote:
>> On Saturday, August 20, 2022 at 12:47:47 PM UTC-5, Robert A. Brooks wrote:
>>> On 8/20/2022 1:05 PM, Stephen Hoffman wrote:
>>>> If BACKUP is encrypting data before performing data compression,
>>>> that's a design
>>>> bug in BACKUP.

>>> That is, unfortunately, the way it was implemented.

>> That is unfortunate.  Do you think it is something VSI might look at
>> correcting?
>
> That would be pretty hard to do and retain the (broken) backward
> compatibility.

I assume you have a flag field in the header - does it have free bits?

If so then duplicate BCK$M_ENCR as BCK$M_ENCR_BEF_COMP and add a new
BCK$M_ENCR_AFT_COMP.

Newer VMS versions can still read old VMS versions backups, but not the
other way around.

That may be acceptable.

Arne

On 2022-08-22 19:01:40 +0000, Rich Jordan said:

> Hoff, thanks for responding again.
>
> Right now its a question, not a requirement or so far as we know, an
> impending requirement.
>
> Our HyperV guy says that once VSI VMS is available for HyperV that the
> underlying files can be on encrypted storage. Still waiting to hear
> about VMWare, but Virtualbox does support encrypting its storage
> (files? disks?) directly if I understand their docs from a very quick
> overview, so that might be a future option too (unless the auditors
> don't like virtualbox because its not HyperV or VMWare).

Yep. For those running on a recent Mac, your internal storage is
encrypted at the controller.

Crucial MX series SSDs advertise 256-bit AES, though loading the keys
from OpenVMS might be "interesting". That might involve some time with
a manual and some custom code with the $qio IO$_DIAGNOSE calls.

> I don't consider the decommissioning thing to be an issue at our level;
> it certainly might be for a site that has tons of servers and high
> turnover, but in this case, VMS hardware lives for 10 years, PC
> hardware at least 5, and we're talking about decomming maybe 2 servers
> per year on average, maybe 20-40 related disks. The customer
> contracts out storage destruction and hardware recycling to a bonded
> company, though in the case of the last VMS server, we did the
> destruction and recycling. Nice magnets in those hard drives (though
> I had to do that after hours... ;)

Hardware destruction works fine, where that's an option. For sites with
weaker controls, or for sites that are or will be using hosting, or
where repairs can expect or require parts for remanufacturing, or where
the storage is embedded as is increasingly the case, media destruction
isn't always an option. But if it is, go for it.

> Your point on auditors and data encryption is well taken, but we have
> had to deal with some in the past who literally could not understand
> anything not microsoft based and had to be kindergarten level shown the
> security features that were available and implemented, system auditing
> and how it worked, etc because they were otherwise going to report that
> the VMS box didn't have any security and was wide open and anyone could
> connect and brute force it and it wouldn't stop them from trying...
> that was at a publicly traded company, the underlying reason for the
> audit along with S-OX.

You're assuming the auditors particularly understand Windows, or any
other platform they're auditing. (It'd be useful if they did, of
course. But there aren't all that many people that do, at this level.)
The auditors are almost always working off checklists and tooling
designed and written by others. The better auditing firms will have an
internal escalation path available for obtaining answers or
clarifications for an auditor's questions.

Many (all?) folks working here will involve or reference or incorporate
DoD/NIST/NCSC guidelines/checklists/STIGs for audits and reviews,
including (in years past) those for OpenVMS.
https://ncp.nist.gov/checklist/133

Here's a recent STIG, for those that have not seen one:
https://www.stigviewer.com/stig/apple_macos_12_monterey/

More than a few of an audit's more general expectations—storage
encryption, password and private key storage, etc—are entirely platform
independent. It's the details of the implementations that will vary.

As often implemented, audits are centrally used by business management
to contractually outsource legal or technical risks to others (to the
auditors and their insurance), and can thus be rather less about the
results of the audit than about the process and findings.

I've had interesting discussions with auditors over the years. The
better ones will look for ways to suggest or to improve security. But
there are always checklists involved, and variously auditing tools, and
increasingly endpoint security tools to maintain security. (The OpenVMS
and RSX-11M/M+ breaches and ransom-related messes I've worked over the
years have been tedious, as there are no available tools for
verification. DECinspect (its issues aside) is long gone, etc.

--
Pure Personal Opinion | HoffmanLabs LLC

On 2022-08-22 19:51:26 +0000, Arne Vajhj said:

> I assume you have a flag field in the header - does it have free bits?
> ...
> That may be acceptable.

In this same realm, BACKUP hasn't been able to fix corrupted saveset
metadata transparently, which makes the whole app design and its I/O
path somewhat suspect.

BACKUP has gotten better, and remains reliable—both of which are major
factors in any similar app—but it's also effectively reached its design
limit.

--
Pure Personal Opinion | HoffmanLabs LLC

On 8/22/2022 2:58 PM, Robert A. Brooks wrote:
> On 8/22/2022 2:44 PM, Rich Jordan wrote:
>> On Saturday, August 20, 2022 at 12:47:47 PM UTC-5, Robert A. Brooks wrote:
>>> On 8/20/2022 1:05 PM, Stephen Hoffman wrote:
>>>
>>>> If BACKUP is encrypting data before performing data compression, that's a
>>>> design
>>>> bug in BACKUP.
>>> That is, unfortunately, the way it was implemented.
>>>
>>> --
>>>
>>> --- Rob
>>
>> That is unfortunate. Do you think it is something VSI might look at correcting?
>
> That would be pretty hard to do and retain the (broken) backward compatibility.
>

Broken is broken. Maybe time to move on. It's not that bad, tell those few
that want the old version to keep a copy, and move on to a better fixed product..

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

Alexander Schreiber <als@usenet.thangorodrim.de> wrote:
>Scott Dorsey <kludge@panix.com> wrote:
>> Alexander Schreiber <als@usenet.thangorodrim.de> wrote:
>>>Scott Dorsey <kludge@panix.com> wrote:
>>>> Rich Jordan <jordan@ccs4vms.com> wrote:
>>>>>Last time I looked, VMS, even current VSI versions, can do manual per-file =
>>>>>encryption/decryption, but not whole disk. That means you couldn't encrypt=
>>>>> production files and have them usable; you'd have to decrypt, use, re-encr=
>>>>>ypt, then delete the unencrypted version; a no go save perhaps for small cr=
>>>>>itical files sync'd by human usage. =20
>>>>
>>>> Right, so you go with disks that have hardware encryption. You can buy a
>>>> number of gadgets where you have to type in a number on a keypad on the disk
>>>> box before the disk becomes available to the SATA buss.
>>>
>>>You named them correctly: gadgets, nothing more.
>>>
>>>Because you've got no idea if this is actually any good. Do they actually
>>>encrypt the data (or just do the equivalent of a shoddy bike lock?), what
>>>algorithm and key length is used (hint: if it's just a 4 digit pin .. LOL),
>>>are key derivation and encryption algorithms even implemented properly
>>>(note: most encrypted systems that got broken where broken not because
>>>the math or algorithm was attacked, but because the implementation was
>>>bad and vulnerable)?
>>
>> You have FIPS certification on some of them which tells you that it's pretty
>> good. But there are plenty of others which are not certified. Some vendors
>> (like Aegist) offer certified and uncertified versions.
>
>I wonder if that certification actually involves handing over hardware
>designs and source code - because that's pretty much the only way you
>can verify any claims.

That is the difference between "FIPS-compliant" and "FIPS-certified."
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

<< sorry I have lost the attributions...>>
>
>> I don't consider the decommissioning thing to be an issue at our
>> level; it certainly might be for a site that has tons of servers and
>> high turnover, but in this case, VMS hardware lives for 10 years, PC
>> hardware at least 5, and we're talking about decomming maybe 2 servers
>> per year on average, maybe 20-40 related disks.   The customer
>> contracts out storage destruction and hardware recycling to a bonded
>> company, though in the case of the last VMS server, we did the
>> destruction and recycling.   Nice magnets in those hard drives (though
>> I had to do that after hours... ;)

In an enterprise virtual environment, even on-premises, storage and
servers are almost certainly separate hardware boxes, with all "disk" in
a SAN connected to the server farm by fibre. You probably don't even
know where your disks are in the SAN storage, and in fact where they are
may vary depending on load.

This allows virtual machines to be re-located in the event of physical
server issues.

There is a good chance there won't be any magnets, SSD storage is pretty
much universal. Even my el-cheapo cloud web servers now come with that
as standard.

So when you decommission a SAN instead of a small challenge of getting a
handful of server disk crushed, the are probably at least 100 disks to
get rid of, perhaps thousands....

... mind you the SAN we had would perform a secure erase so we could wipe
i before re-moving it from the data centre. I think it did take a couple
of days. Of course with SSD this is harder to achieve as it may
re-allocate cells to disk blocks....

Dave

On 8/22/22 1:26 PM, Stephen Hoffman wrote:
> On 2022-08-22 18:58:07 +0000, Robert A. Brooks said:
>
>> On 8/22/2022 2:44 PM, Rich Jordan wrote:
>>> On Saturday, August 20, 2022 at 12:47:47 PM UTC-5, Robert A. Brooks
>>> wrote:
>>>> On 8/20/2022 1:05 PM, Stephen Hoffman wrote:
>>>>
>>>>> If BACKUP is encrypting data before performing data compression,
>>>>> that's a design
>>>>> bug in BACKUP.
>>>> That is, unfortunately, the way it was implemented.
>>>>
>>>> --
>>>>
>>>> --- Rob
>>>
>>> That is unfortunate.  Do you think it is something VSI might look at
>>> correcting?
>>
>> That would be pretty hard to do and retain the (broken) backward
>> compatibility.
>
..
..
..
> But then BACKUP itself is also ~at its design limit, so investing in a
> replacement for BACKUP would seem a more prudent longer-term approach.
>
> Y'all get to make these calls, of course. Not sure I'd want to wade into
> BACKUP without a plan to refactor or replace it.

Add one more vote for a new backup (number 303,224,117 on the list of
things to work on). For me, backup currently sits at 100% CPU (on both
alpha and ia64) but doesn't come close to writing at the speed the tape
drive is capable of. It makes me wish backup was capable of using
multiple CPUs.

As perhaps an additional request, it would also be nice if backup (and
VMS) supported a more recent version of the ANSI standard for tape labels.

Mark Berryman

On 2022-08-23 17:47:37 +0000, Mark Berryman said:

> On 8/22/22 1:26 PM, Stephen Hoffman wrote:
>
>> But then BACKUP itself is also ~at its design limit, so investing in a
>> replacement for BACKUP would seem a more prudent longer-term approach.
>>
>> Y'all get to make these calls, of course. Not sure I'd want to wade
>> into BACKUP without a plan to refactor or replace it.
>
> Add one more vote for a new backup (number 303,224,117 on the list of
> things to work on). For me, backup currently sits at 100% CPU (on both
> alpha and ia64) but doesn't come close to writing at the speed the tape
> drive is capable of.

Out of curiosity, how deep is the input I/O queue on that box? Probably
parked permanently past 0.5. But being CPU-bound, the throttling here
is likely either compression or encryption.

Adding CPUs usually means better multiprocessing scheduling, though
OpenVMS lacks app-level constructs for that. The existing pthreads and
the KP threads APIs aren't a great abstraction.

Also whether adding CPUs may or will speed processing? That's obviously
entirely dependent on how parallel the compression and the encryption
can be. Given the current and rather unfortunate encrypt-then-compress
sequencing, I wouldn't expect adding parallelism will be a particularly
easy option within the current BACKUP design.

Whether incorporating the x86-64 cryptographic instructions would be
more helpful?

Yet more work in the project queue at VSI. If this got "above the fold"
in the project schedule, it'll probably look at hardware
acceleration—x86-64 instructions and encrypting storage hardware—for
the ENCRYPT (formerly) layered product support. The rest of this work
is a much bigger project.

> It makes me wish backup was capable of using multiple CPUs.

That, and selective input to reduce the total size of the I/O transfers
necessary, though that usually integrates with a fast search function,
and file and directory change notifications, and that's some work to
add. Scanning the whole volume for the change data is slow, and
wasteful.

> As perhaps an additional request, it would also be nice if backup (and
> VMS) supported a more recent version of the ANSI standard for tape
> labels.

ISO/IEC 1001:2012 looks to be current, while the older (and apparently
still "current") ANSI X3.27-1987 (R1998) appears archived. Based on a
quick check, it's unclear if IBM supports the newer labels with z/OS.

--
Pure Personal Opinion | HoffmanLabs LLC

On 8/24/2022 11:13 AM, Stephen Hoffman wrote:
> Adding CPUs usually means better multiprocessing scheduling, though
> OpenVMS lacks app-level constructs for that. The existing pthreads and
> the KP threads APIs aren't a great abstraction.

pthreads are not that bad. The model is the foundation for most
multi-threading implementations.

A builtin thread pool would be nice as icing on the the cake though.

VMS already got a lot of async API's - they just need some much higher
level abstractions.

> Also whether adding CPUs may or will speed processing? That's obviously
> entirely dependent on how parallel the compression and the encryption
> can be. Given the current and rather unfortunate encrypt-then-compress
> sequencing, I wouldn't expect adding parallelism will be a particularly
> easy option within the current BACKUP design.

Most compression algorithms (at least anything LZ based) and
encryption algorithms (block ciphers with chaining) would require
some extra blocking to be parallelizable themselves.

But just:
* thread for reads
* optional thread for compression
* optional thread for encryption
* thread for writes
would help a bit.

Arne

On 8/24/22 9:13 AM, Stephen Hoffman wrote:
> On 2022-08-23 17:47:37 +0000, Mark Berryman said:
>
>> On 8/22/22 1:26 PM, Stephen Hoffman wrote:
>>
>>> But then BACKUP itself is also ~at its design limit, so investing in
>>> a replacement for BACKUP would seem a more prudent longer-term approach.
>>>
>>> Y'all get to make these calls, of course. Not sure I'd want to wade
>>> into BACKUP without a plan to refactor or replace it.
>>
>> Add one more vote for a new backup (number 303,224,117 on the list of
>> things to work on).  For me, backup currently sits at 100% CPU (on
>> both alpha and ia64) but doesn't come close to writing at the speed
>> the tape drive is capable of.
>
> Out of curiosity, how deep is the input I/O queue on that box? Probably
> parked permanently past 0.5. But being CPU-bound, the throttling here is
> likely either compression or encryption.
..
..
..

Neither, since compression and encryption are both handled by the tape
drive.

Some numbers:
DFG file fragmentation number: 2.5

On an LTO4 drive:
Direct I/O rate: between 4000 and 5000
Buffered I/O rate: between 1500 and 2000
Disk I/O Queue: max: 15.00, average ~1.92, frequently at zero
CPU: wildly fluctuated, only occasionally maxed out
Tape speed (MB/sec): typically 20's and 30's, maxed around 60
This is on a tape drive that other platforms get nearly 100 MB/sec on.

On an LTO7 drive:
The LTO7 is rated at roughly 3 times the speed of an LTO4 (depending on
data) but backup could only manage a bare increase in throughput writing
to it. The save rate was probably in the 30s more often on the LTO7.
The other numbers were all pretty much identical except for the Disk I/O
Queue depth with never got above 8.33.

The disk being backed up used to be my most fragmented disk but has
since been cleaned up (as shown above) which is probably why the CPU
didn't stay pegged at 100% as it had done before.

Mark Berryman

Stephen Hoffman <seaohveh@hoffmanlabs.invalid> wrote:
> On 2022-08-18 22:50:38 +0000, Rich Jordan said:
>
>> Wee!, its audit time again!
>>
>> I reviewed the VSI site and didn't see mention but thought I would ask
>> here also.
>
>> And backup savesets can be encrypted, but at the cost of both increased
>> time and the loss of compression (which is often a substantial time and
>> space saver itself).
>
> If BACKUP is encrypting data before performing data compression, that's
> a design bug in BACKUP.

Well, that is actually the right thing do to from a crypto security
point of view. Compressed files tend to have specified headers and
structures, which means that "compress, then encrypt" potentially
enables a nice automatic known plaintext attack. And I suspect that
is the reason it was done this way.

And yes, my personal backups do the "archive, compress, encrypt"
dance because "someone with enough resources to run a known plaintext
attack against my backups" is not part of my threat scenarios, I'm
not exactly a very high profile (or profitable even) target, to put it
mildly.

> Properly encrypted data is not compressible, but properly compressed
> data can be encrypted.

Of course once encrypted, compression doesn't really serve a purpose
except eat some CPU time.

> And yes, OpenVMS systems are comparatively slow, and supported
> processors prior to x86-64 are lacking in encryption acceleration
> hardware features.
>
> https://en.wikipedia.org/wiki/AES_instruction_set
>
> While most (all?) recent x86-64 hardware does have hardware
> acceleration support for encryption, I'd assume OpenVMS x86-64 is not
> (yet?) using that.

I would hope that will happen soon, as pretty much any supported
platform for OpenVMS amd64 probably can be safely assumed to have
AESNI (and it is easy to check).

Kind regards,
Alex.
--
"Opportunity is missed by most people because it is dressed in overalls and
looks like work." -- Thomas A. Edison

On 2022-09-01 20:45:30 +0000, Alexander Schreiber said:

> Stephen Hoffman <seaohveh@hoffmanlabs.invalid> wrote:
>>
>> If BACKUP is encrypting data before performing data compression, that's
>> a design bug in BACKUP.
>
> Well, that is actually the right thing do to from a crypto security
> point of view. Compressed files tend to have specified headers and
> structures, which means that "compress, then encrypt" potentially
> enables a nice automatic known plaintext attack. And I suspect that is
> the reason it was done this way.

If your chosen encryption reveals your plaintext, your encryption needs
help. Whether ghostly penguins, or otherwise.

--
Pure Personal Opinion | HoffmanLabs LLC

On Thursday, September 1, 2022 at 5:08:04 PM UTC-4, Alexander Schreiber wrote:
> Well, that is actually the right thing do to from a crypto security
> point of view. Compressed files tend to have specified headers and
> structures, which means that "compress, then encrypt" potentially
> enables a nice automatic known plaintext attack. And I suspect that
> is the reason it was done this way.

I'm guessing the redundancy blocks backup includes by default weaken the
encryption also.

On 2022-09-01 21:35:11 +0000, David Jones said:

> I'm guessing the redundancy blocks backup includes by default weaken
> the encryption also.

That would be faulty encryption. Whatever the input, the goal of any
viable encryption algorithm is uncompressible random bytes out.

--
Pure Personal Opinion | HoffmanLabs LLC

On 9/1/2022 4:45 PM, Alexander Schreiber wrote:
> Stephen Hoffman <seaohveh@hoffmanlabs.invalid> wrote:
>> On 2022-08-18 22:50:38 +0000, Rich Jordan said:
>>> And backup savesets can be encrypted, but at the cost of both increased
>>> time and the loss of compression (which is often a substantial time and
>>> space saver itself).
>>
>> If BACKUP is encrypting data before performing data compression, that's
>> a design bug in BACKUP.
>
> Well, that is actually the right thing do to from a crypto security
> point of view. Compressed files tend to have specified headers and
> structures, which means that "compress, then encrypt" potentially
> enables a nice automatic known plaintext attack. And I suspect that
> is the reason it was done this way.
>
> And yes, my personal backups do the "archive, compress, encrypt"
> dance because "someone with enough resources to run a known plaintext
> attack against my backups" is not part of my threat scenarios, I'm
> not exactly a very high profile (or profitable even) target, to put it
> mildly.

I don't think AES with random IV and block chaining is vulnerable to
known plain text attacks even with very valuable data aka large
resources available (at least no such attack possibility has been
publicized).

Arne

David Jones <osuvman50@gmail.com> wrote:
> On Thursday, September 1, 2022 at 5:08:04 PM UTC-4, Alexander Schreiber wrote:
>> Well, that is actually the right thing do to from a crypto security
>> point of view. Compressed files tend to have specified headers and
>> structures, which means that "compress, then encrypt" potentially
>> enables a nice automatic known plaintext attack. And I suspect that
>> is the reason it was done this way.
>
> I'm guessing the redundancy blocks backup includes by default weaken the
> encryption also.

Not really, unless their content can be reliably predicted without
decryption (which I assume is not true).

Kind regards,
Alex.
--
"Opportunity is missed by most people because it is dressed in overalls and
looks like work." -- Thomas A. Edison

Stephen Hoffman <seaohveh@hoffmanlabs.invalid> wrote:
> On 2022-09-01 20:45:30 +0000, Alexander Schreiber said:
>
>> Stephen Hoffman <seaohveh@hoffmanlabs.invalid> wrote:
>>>
>>> If BACKUP is encrypting data before performing data compression, that's
>>> a design bug in BACKUP.
>>
>> Well, that is actually the right thing do to from a crypto security
>> point of view. Compressed files tend to have specified headers and
>> structures, which means that "compress, then encrypt" potentially
>> enables a nice automatic known plaintext attack. And I suspect that is
>> the reason it was done this way.
>
> If your chosen encryption reveals your plaintext, your encryption needs
> help. Whether ghostly penguins, or otherwise.

*sigh*

That is _not_ what "know plaintext attack" means. It means you have
the encrypted message and somehow, through other means, got (part)
of the plaintext. E.g. in WW2 ciphers where broken by this because
the used (known) standard headers and known standard text in known
places (e.g. standard greeting of "Heil Hitler" - now run the brute
forcer until it finds a key that makes the ciphertext decrypt to that).

With modern fileformats, standard headers serve this role - e.g. if
you know that you have an encrypted JPEG image, you know that the
plaintext has a certain header structure (in this case, including
the string "JFIF") you have some help ;-)

One way to guard against this (as has been pointed out elsewhere in
this thread) is to use proper encryption algorithms and protocols
(e.g. AES with random IV in CBC mode), correctly implemented.

Kind regards,
Alex.
--
"Opportunity is missed by most people because it is dressed in overalls and
looks like work." -- Thomas A. Edison