Re: [lmi] PATCH: use compressed .mst files

[Greg Chicares]

On 2018-10-29 13:08, Vadim Zeitlin wrote:
> On Mon, 29 Oct 2018 10:25:12 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> On 2018-10-25 18:00, Vadim Zeitlin wrote:
> GC> [...]
> GC> >         https://github.com/vadz/lmi/pull/100
> GC> 
> GC> I've done something quite similar in commit 0f81d542.
> 
>  So do I understand correctly that the idea of using LZMA compression for
> these files is abandoned now?

Yes.

> GC> This would have introduced a dependency on classes
> GC>     wxFileInputStream
> GC>     wxLZMAInputStream
> GC>     wxStringOutputStream
> GC> which aren't otherwise used in lmi code.
> 
>  The use of wxFileInputStream and wxStringOutputStream could be avoided,
> they just provide the most succinct way of using wxLZMAInputStream in this
> situation. And I didn't think there was any point in avoiding them in the
> code which already uses wxWidgets anyhow (as indicated by the "_wx" suffix
> in the file name...).

We certainly do rely on wx. But it's a vast library, and we rely only
on a portion of it. And, although it's actively maintained, any project
that big has defects--as does OpenSSH, or even the software that guides
trains and controls medical X-ray machines--so expanding our reliance
on any library entails some risk. Therefore, I ask myself: if you were
to retire, and something went wrong in one of these stream classes, or
in liblzma, would I be able to fix it myself, easily?

> GC> But, given that the only purpose is obfuscation, I decided to XOR the
> GC> MST files' contents with 0xFF instead of calling into any libraries.
> GC> I should have thought of that simple, robust solution up front.
> 
>  I don't think it's especially robust.

I mean "robust" in the narrow sense that there's probably no defect in
'(unsigned char)(c ^ 0xFF)'. If there is, I'm confident I can fix it.

Cryptographically speaking, XOR 0xFF is just silly. But we aren't trying
to protect against a determined attack. All we need is assurance that
these distributed files can't be modified without deliberate misconduct.
They contain no personal data or trade secrets; they only control the
formatting of PDF output, and there are easier ways to forge PDF files.

> Using compressed files had a
> marginal but potentially useful side effect of detecting not just tampering
> but any other accidental modification, as a corrupted file would fail to
> decompress, while XOR encryption doesn't provide any integrity protection
> whatsoever.

Such protection is provided by md5sum validation: see 'authenticity.cpp'.
(You and I have a "skeleton key" which bypasses that, but end users don't.)