Arne Vajhøj <arne@vajhoej.dk> wrote:
> 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).

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.

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-02 21:26:26 +0000, Alexander Schreiber said:

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

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

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...@hoffmanlabs.invalid> wrote:
> >> 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.
> >
> > *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.

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

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.

--
Pure Personal Opinion | HoffmanLabs LLC