Current state of file/disk encryption on VMS

[Rich Jordan]

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

[Scott Dorsey]

Rich Jordan <jor...@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. This gives you the
full disk encryption the bean counters want, without any OS changes or
overhead, and without impairing the ability to move drives from machine
to machine.

>And backup savesets can be encrypted, but at the cost of both increased tim=
>e and the loss of compression (which is often a substantial time and space =
>saver itself).

Yes. There is a big CPU hit on alphas, although I would imagine it is
likely better on x86 systems where there is more mippage available.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

[Dave Froble]

Fire the auditors ...

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

[David Wade]

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

[David Jones]

On Thursday, August 18, 2022 at 6:50:39 PM UTC-4, Rich Jordan wrote:
> Last time I looked, VMS, even current VSI versions, can do manual per-file encryption/decryption, but not whole disk.

Whole disk encryption only makes sense where you don't have physical security of the device (i.e. mobile devices).
Data breaches come from compromised networks, in which WDE is worthless because every process on the
system has access to the disk through the key loaded in the driver at boot.

[Simon Clubley]

On 2022-08-18, Dave Froble <da...@tsoft-inc.com> 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 ...
>

The auditors are there to do a job and the people running the systems
are not the people who employed the auditors.

If you can't comply, you had better have a _VERY_ good answer for why
_you_ can't when everyone else can.

You had also better have an even better answer for "In that case, why
should those VMS systems be allowed to be kept in production use instead
of being replaced with more secure systems ?"

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

[Scott Dorsey]

It also makes some amount of sense in that it reduces your need to wipe
everything completely before discarding old equipment. But it's not the
wonderful thing that some security consultants believe it to be.

Some data breaches are caused by backup tapes pulled out of dumpsters and
computers purchased from surplus dealers which still contain customer data.
These aren't as popular as they once were, though.

[Dave Froble]

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

[Simon Clubley]

On 2022-08-19, Dave Froble <da...@tsoft-inc.com> wrote:
> And shouldn't their "suggestions" be
> just that, "suggestions"?
>

In some cases, they are doing their audits to ensure a company complies
with required security and legal standards. In those cases, their report
is _way_ more than a "suggestion".

[Rich Jordan]

Most of the auditors our customers tend to get (some self hired, some because they are publicly traded) are 100% windows centric and know nothing about even the existence of other platforms, and some have gotten quite flummoxed when presented by Unix/Linux or VMS systems in those environments. I am certain this is another checkbox question; I'm trying to find out if they have the same question or actual insistence on having the windows servers run with all disks encrypted also.

My own feeling has always been its not needed on reasonably secure, non-portable systems; its just for laptops/tablets, and maybe desktops in unsecure environments. But thats just me.

So I assume I'm correct that there are no changes regarding disk encryption in VMS.

PC guru here says Hyper-V can run with the VMs VHD files on bitlocker encrypted disks, still checking on VMWare and Virtualbox. But again that's for future; right now the customer is on Integrity 2800 servers, so no go on encryption.

[Rich Jordan]

There is also the new issue of cyber-insurance. A number of our customers are having to change their procedures in order to qualify for a cyber insurance addendum on their coverage (or standalone insurance).

[Dave Froble]

On 8/19/2022 1:07 PM, Simon Clubley wrote:
> On 2022-08-19, Dave Froble <da...@tsoft-inc.com> wrote:
>> And shouldn't their "suggestions" be
>> just that, "suggestions"?
>>
>
> In some cases, they are doing their audits to ensure a company complies
> with required security and legal standards. In those cases, their report
> is _way_ more than a "suggestion".
>
> Simon.
>

I guess my question is, "who specifies required security and legal standards"?

There may be cases where external requirements exist. But if not, then isn't it
solely up to a company what they do?

[Dave Froble]

On 8/19/2022 1:23 PM, Rich Jordan wrote:

> Most of the auditors our customers tend to get (some self hired, some because they are publicly traded) are 100% windows centric and know nothing about even the existence of other platforms, and some have gotten quite flummoxed when presented by Unix/Linux or VMS systems in those environments. I am certain this is another checkbox question; I'm trying to find out if they have the same question or actual insistence on having the windows servers run with all disks encrypted also.

This is the problem. When the auditors don't know what they are doing, and
won't learn, then they demand you do what isn't reasonable.

For an auditor to work with VMS, they should know VMS very well. Would you want
a non-programmer to tell you how to write programs?

> My own feeling has always been its not needed on reasonably secure, non-portable systems; its just for laptops/tablets, and maybe desktops in unsecure environments. But thats just me.

And you are correct.

> So I assume I'm correct that there are no changes regarding disk encryption in VMS.
>
> PC guru here says Hyper-V can run with the VMs VHD files on bitlocker encrypted disks, still checking on VMWare and Virtualbox. But again that's for future; right now the customer is on Integrity 2800 servers, so no go on encryption.
>

[Arne Vajhøj]

On 8/18/2022 10:00 PM, Scott Dorsey wrote:

> Rich Jordan <jor...@ccs4vms.com> wrote:
>> And backup savesets can be encrypted, but at the cost of both increased tim=
>> e and the loss of compression (which is often a substantial time and space =
>> saver itself).
>
> Yes. There is a big CPU hit on alphas, although I would imagine it is
> likely better on x86 systems where there is more mippage available.

Todays x86-64's got a lot more CPU power than the Alpha's of
25 years ago (not surprising).

But if VMS BACKUP is using AES and VMS x86-64 are able to use
the AES supporting instructions in newer x86-64's, then it will
really speed up!

Arne

[Arne Vajhøj]

That type of encryption let us call it transparent device encryption
for lack of a better word does provide some benefits, but its benefits
are often overestimated - it only helps with a few use cases.

Same with transparent database encryption.

Arne

[Arne Vajhøj]

On 8/19/2022 6:48 PM, Dave Froble wrote:
> For an auditor to work with VMS, they should know VMS very well.

To do an effective audit of VMS they would need a
good VMS checklist and auditors with some VMS knowledge.

Passing the audit with SYSTEM password being SYSTEM,
because the auditor just checked root and admin
usernames is no good.

Arne

[Arne Vajhøj]

On 8/19/2022 1:23 PM, Rich Jordan wrote:

> Most of the auditors our customers tend to get (some self hired, some
> because they are publicly traded) are 100% windows centric and know
> nothing about even the existence of other platforms, and some have
> gotten quite flummoxed when presented by Unix/Linux or VMS systems in
> those environments.

Many auditors are quite Linux capable. They have to with like
2/3-3/4 of all servers running Linux.

> My own feeling has always been its not needed on reasonably secure,
> non-portable systems; its just for laptops/tablets, and maybe
> desktops in unsecure environments. But thats just me.

I believe that is just you.

:-)

Most of the important functionality are on servers, so
to properly assess then entire solution, then auditors
need to look at the servers as well.

Arne

[Stephen Hoffman]

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

[Robert A. Brooks]

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

[Arne Vajhøj]

Would:

disallow (DATA_FORMAT.COMPRESS and ENCRYPT)

make sense?

Arne

[Alexander Schreiber]

Scott Dorsey <klu...@panix.com> wrote:
> Rich Jordan <jor...@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)?

> This gives you the
> full disk encryption the bean counters want, without any OS changes or
> overhead, and without impairing the ability to move drives from machine
> to machine.

So everytime the machine reboots/powercycles someone has to crawl into
the broom closet (because you won't see nonsense like that in a proper
production setup) where the "server" lives and type in a number?

>>And backup savesets can be encrypted, but at the cost of both increased tim=
>>e and the loss of compression (which is often a substantial time and space =
>>saver itself).
>
> Yes. There is a big CPU hit on alphas, although I would imagine it is
> likely better on x86 systems where there is more mippage available.

Pretty much any modern amd64 machine has the AES-NI extensions which
effectively drops the overhead of AES encryption to almost zero.
An Intel Core i5-3570K @ 3.40GHz can do aes-xts with 512 bit keylength
at 1.3 GB/s, an Intel Xeon E3-1245 v5 @ 3.50GHz can do the same at
1.8 GB/s - both encrypt and decrypt (just checked with
'cryptsetup benchmark').

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

[Alexander Schreiber]

That's why a large company I know mandates full disk encryption on
_all_ systems. And yes, the backup tapes are also encrypted. This allows
one to "delete" a backup set by just wiping the keys. All backup sets
on that tape are deleted - now you can reuse the tape.

[Alexander Schreiber]

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.

[Dave Froble]

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.

That just doesn't happen very often ...

Human intelligence is a myth ...

[Bill Gunshannon]

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.

bill

[Dave Froble]

Total bullshit!

I'd demand the same expertise of those auditing Unix, Linux, WEENDOZE, and
anything else. Anything else is just total nonsense.

I have no idea of what you refer to as "modern business practice". Perhaps you
refer to "total nonsense"?

Lot of that coming from you these days ...

[Scott Dorsey]

Alexander Schreiber <a...@usenet.thangorodrim.de> wrote:
>Scott Dorsey <klu...@panix.com> wrote:
>> Rich Jordan <jor...@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.

That said, the original poster doesn't actually care if the encryption is
good, he just wants to allow the consultant to check off the correct box
on their checklist.

>> This gives you the
>> full disk encryption the bean counters want, without any OS changes or
>> overhead, and without impairing the ability to move drives from machine
>> to machine.
>
>So everytime the machine reboots/powercycles someone has to crawl into
>the broom closet (because you won't see nonsense like that in a proper
>production setup) where the "server" lives and type in a number?

You see that in a lot of production setups today. And yes, you do have to
type a number every time the drive is power-cycled... but not every time the
computer itself is power cycled. How often do you reboot anyway? We do it
twice a year to install updates.

[Jan-Erik Söderholm]

The auditors are not hired by the company that is being audited.

Usually it is some other entity that enforce the auditing. Can be
a major custumer, a state authority, your insurance company or such.

And the auditing is usually not done on a strictly technical level,
it is more to see that you can prove that you are following what is
general practice on a higher level.

[Dave Froble]

The question here is, what if the "suggestions" do not fit your activities?
Should one change their business to be "like everyone else", thus perhaps losing
advantages?

I have no problem with auditors, as long as they are reasonable, and have some
clue of what they are looking at. The burden should be on the auditors to show
they are competent.

[Arne Vajhøj]

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.

Arne

[Arne Vajhøj]

On 8/21/2022 11:33 AM, Dave Froble wrote:
> On 8/21/2022 9:54 AM, Alexander Schreiber wrote:
>> Dave Froble <da...@tsoft-inc.com> wrote:
>>> On 8/19/2022 4:18 AM, David Wade wrote:
>>>> On 19/08/2022 03:20, Dave Froble wrote:
>>>>> Fire the auditors ...
>>>>>
>>>> What difference would that make? They work from the same tick list.
>>>

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

> Credit card processing is not just protecting your data, thus being a
> bit different.

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

Most come to that conclusion. Storing credit card info is as desirable
as having the plague and cholera.

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

The auditors should definitely have skills in what they audit -
otherwise they can't perform a good audit.

But there are some reasons why this sometimes becomes
a problem.

First there is the level where decisions are made. If a company
got a lot of stuff and audit need to cover Linux servers, Windows
servers, Windows PC's, network, some devices, organizational stuff
etc. besides a few VMS systems, then sometimes the CxO of the
company requesting the audit (which may be different from the company
being audited) and the CxO of the audit company may not discuss
VMS at all when signing agreement.

Second the IT security industry has a huge skill problem. The demand
for IT security people have exploded over the last decade and
there are simply not enough good people available. So they hire
people with a few months of training for IT security. And
obviously they know very little. Everybody knows about this
problem but just because we know about it does not make
a half million IT security people with years of experience
fall down from the sky. And those few months of training
obviously only focus on the most widely used stuff - for
OS that means Linux and Windows.

Arne

[Dave Froble]

But there would be those 10 companies, and the service most likely will be good.

[Dave Froble]

And this justifies the know nothing idiots attempting to audit anything they are
not trained in in what manner.

Going down this path is just wrong, and people should "just say no".

[Arne Vajhøj]

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

Arne

[Arne Vajhøj]

On 8/21/2022 8:00 PM, Dave Froble wrote:
> On 8/21/2022 7:20 PM, Arne Vajhøj wrote:
>> Second the IT security industry has a huge skill problem. The demand
>> for IT security people have exploded over the last decade and
>> there are simply not enough good people available. So they hire
>> people with a few months of training for IT security. And
>> obviously they know very little. Everybody knows about this
>> problem but just because we know about it does not make
>> a half million IT security people with years of experience
>> fall down from the sky. And those few months of training
>> obviously only focus on the most widely used stuff - for
>> OS that means Linux and Windows.
>

> And this justifies the know nothing idiots attempting to audit anything
> they are not trained in in what manner.
>
> Going down this path is just wrong, and people should "just say no".

You can't wave a magic wand and have an extra half million experienced
IT security people tomorrow.

So the industry use what they can get.

And it can be painful.

But it is not just VMS.

And most consider an audit by less than desired experienced
people better than no audit.

Arne

[Dave Froble]

Is "these apps run our company better than anything else" a good reason?

Many executives are smart enough to not screww up things that are working well.

[Dave Froble]

And if the idiots tell you to do something that you know is wrong?

[David Wade]

Bot if they cost ten times more than apps that "run the company passably
well"

> Many executives are smart enough to not screww up things that are
> working well.
>
>

I find post execs want to change things to prove they are adding value.
Another problem for VMS

[Dave Froble]

They do not cost so much more, sometimes even less. There can be many hidden
costs to "passably well".

>> Many executives are smart enough to not screww up things that are working well.
>>
>>
>
> I find post execs want to change things to prove they are adding value. Another
> problem for VMS

Of course some think that way. Then get some bonus for the next quarter's
results, then be on their way. I think we've seen how that usually works out
for the company, it's employees, and it's customers. Only one winner, and
that's not deserved.

[Arne Vajhøj]

There are a few options:
1) Crying.
2) Turning violent.
3) Arguing as good as you can and if no luck then tell yourself that
you can still win the war even though you lost the battle.

:-)

Arne

[Bill Gunshannon]

In this day and age the number is much more likely to be zero
rather than even 10. I am not against VMS, I am just a realist
and, apparently, have a better grip on the reality of the IT
business today than you do. I learned a lot during my beltway
bandit days. Most of what I learned applies today as well as
it did 30 years ago.

bill

[Bill Gunshannon]

If that were true products like Banner or even SAP would not even
exist. It is debatable that they offer any improvement and they
certainly require a complete change from the way you used to do
things.

bill

[Bill Gunshannon]

But it is the reality of how business is done today. Like it or not.

bill

[Dave Froble]

"Business", or scams? Yes, some, but not all.

[Alexander Schreiber]

Scott Dorsey <klu...@panix.com> wrote:
> Alexander Schreiber <a...@usenet.thangorodrim.de> wrote:
>>Scott Dorsey <klu...@panix.com> wrote:
>>> Rich Jordan <jor...@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 said, the original poster doesn't actually care if the encryption is
> good, he just wants to allow the consultant to check off the correct box
> on their checklist.

I've seen that in some places. Tends to work ok until it doesn't.

>
>>> This gives you the
>>> full disk encryption the bean counters want, without any OS changes or
>>> overhead, and without impairing the ability to move drives from machine
>>> to machine.
>>
>>So everytime the machine reboots/powercycles someone has to crawl into
>>the broom closet (because you won't see nonsense like that in a proper
>>production setup) where the "server" lives and type in a number?
>
> You see that in a lot of production setups today. And yes, you do have to
> type a number every time the drive is power-cycled... but not every time the
> computer itself is power cycled. How often do you reboot anyway? We do it
> twice a year to install updates.

I've seen large production setups that reboot a _lot_ more frequently than
that. But they also have proper key management setups - which they need,
since the "dude with a keyboard" approach doesn't scale beyond a small
handful of machines.

[Alexander Schreiber]

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"

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

[Alexander Schreiber]

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

[Arne Vajhøj]

On 8/22/2022 11:21 AM, Alexander Schreiber wrote:
> Scott Dorsey <klu...@panix.com> wrote:
>> Alexander Schreiber <a...@usenet.thangorodrim.de> wrote:
>>> Scott Dorsey <klu...@panix.com> wrote:
>>>> 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 usually what that type of certification involves.

Arne

[Arne Vajhøj]

On 8/22/2022 11:28 AM, Alexander Schreiber wrote:

> Bill Gunshannon <bill.gu...@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

[Rich Jordan]

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

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?

[Dave Froble]

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

[Dave Froble]

On 8/22/2022 11:28 AM, Alexander Schreiber wrote:

:-) :-) :-)

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


--

[Dave Froble]

Arne, you might need a recount ...

[abrsvc]

> 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

[Robert A. Brooks]

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

--
-- Rob

[Rich Jordan]

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.

[Stephen Hoffman]

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.

[Arne Vajhøj]

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

[Stephen Hoffman]

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.

[Stephen Hoffman]

On 2022-08-22 19:51:26 +0000, Arne Vajh j 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.

[Dave Froble]

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

[Scott Dorsey]

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

[David Wade]

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

[Mark Berryman]

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

[Stephen Hoffman]

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.

[Arne Vajhøj]

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

[Mark Berryman]

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

[Alexander Schreiber]

Stephen Hoffman <seao...@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).

[Stephen Hoffman]

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

> Stephen Hoffman <seao...@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.

[David Jones]

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.

[Stephen Hoffman]

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.

[Arne Vajhøj]

On 9/1/2022 4:45 PM, Alexander Schreiber wrote:
> Stephen Hoffman <seao...@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

[Alexander Schreiber]

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

[Alexander Schreiber]

Yes, AES with properly random IV and CBC mode is resistant against
it as far as we know, it is not. And the size of the key space will
keep the spectre of brute force attacks away for quite some time.

[Alexander Schreiber]

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

[Stephen Hoffman]

The "ghostly penguins" was a reference to a famous example of the
foibles of using AES-ECB using an image of the Linux penguin.

The plaintext references in my reply were to recovering the data, and
not to a known-plaintext attack.

Attempting data compression after data encryption is somewhere in the
range of futile, unnecessary, and resource-wasteful.

And if data compression performed after data encryption does provide a
substantial storage savings, your chosen encryption algorithm is
suspect.

More generally, the OpenVMS APIs here are either not helpful or wholly
missing, whether with how BACKUP mis-sequences here, or more generally
around API designs for data protection and network connection security
that are inherently prone to errors.

[glenn everhart]

If you try to compress encrypted data, you may cause it to enlarge. Not a useful practice.
For giggles (code for vax or alpha only, kinda old) if you dig around sigtapes to find something called DTDRIVER you will find some "host process" examples that work with it to enable a few types of virtual disk. One of these implements encrypted virtual disk, encrypting the real storage onto a file or device. The algorithm is simple and will resist attack by rank amateurs but the source is there if anyone is interested. It is a cheap way to see the effect of encrypted data causing compression routines to misbehave.

The problem of how to set up keys so the material can be turned on at boot was of interest. Somewhere in there I had an example that checked its runtime and would allow mounting a small encrypted disk at boot time, so that stored keys could be used then. Dismount and it would not remount the key-store disk till next boot. There was a version of the program that worked all the time, to set up with, intent being it should be kept on external drive and never live online. Of course an attacker with the source code (potentially anybody at all) could fairly readily reverse this.
My prejudice is that encrypting hardware volumes so you can remove and reuse them elsewhere is likely to lead to trying to use disks that are near their deaths. I would not want anything important to be trusted to such a device.

[Alexander Schreiber]

Anyone using ECB without a _very_, _very_ good excuse needs to go
back to Crypto 101.

> Attempting data compression after data encryption is somewhere in the
> range of futile, unnecessary, and resource-wasteful.

It's a waste of time and CPU cycles, yes.

> And if data compression performed after data encryption does provide a
> substantial storage savings, your chosen encryption algorithm is
> suspect.

Indeed.

> More generally, the OpenVMS APIs here are either not helpful or wholly
> missing, whether with how BACKUP mis-sequences here, or more generally
> around API designs for data protection and network connection security
> that are inherently prone to errors.

I suspect that a lot of those design decisions where made in more
innocent times.

[Stephen Hoffman]

On 2022-09-03 21:22:17 +0000, Alexander Schreiber said:

> I suspect that a lot of those design decisions where made in more
> innocent times.

The "most secure operating system on the planet" hasn't kept up with the times.

What security features have been added have largely been grafted on,
too. The digital certificate support is funky to use.

There's little (~no) network security documentation for app developers
included in the OpenVMS base manuals, and the upstream Open Source
Security (CDSA, etc) was long ago deprecated.

Getting a private CA going, and issuing CSRs and signing same, and then
creating a client-server app that connects to a peer using TLSv1.3
while verifying client and server certs is my benchmark for
experiencing the true complexity of what should be (and is) a very
common task.

Add in a DNS translation or two, include a TLS upgrade, and perform the
connection via IPv6, for best "fun" here.

Encrypting your data and then using that as part of storing passwords
and private certs is entirely home-grown, too.

VSI is keeping fairly current with the OpenSSL support, which is a
refreshing change from years past.

There's a whole lot of work here, and more than many realize.