[Info-vax] Current state of file/disk encryption on VMS

[glenn everhart]

On Friday, September 2, 2022 at 7:31:37 PM UTC-4, Stephen Hoffman wrote:
> On 2022-09-02 21:26:26 +0000, Alexander Schreiber said: 
> 
> > Stephen Hoffman <seao... at hoffmanlabs.invalid> wrote: 
> >> On 2022-09-01 20:45:30 +0000, Alexander Schreiber said: 
> >> 
> >>> Stephen Hoffman <seao... at 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.
> 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.
> -- 
> Pure Personal Opinion | HoffmanLabs LLC
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.