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

[Alexander Schreiber]

Stephen Hoffman <seaohveh at hoffmanlabs.invalid> wrote:
> On 2022-09-02 21:26:26 +0000, Alexander Schreiber said:
>
>> Stephen Hoffman <seaohveh at hoffmanlabs.invalid> wrote:
>>> On 2022-09-01 20:45:30 +0000, Alexander Schreiber said:
>>> 
>>>> Stephen Hoffman <seaohveh 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.

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.

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