On 24/04/2023 09:32, Don Y wrote:
> On 4/22/2023 7:57 AM, David Brown wrote:
>>>> However, in almost every case where CRC's might be useful, you have
>>>> additional checks of the sanity of the data, and an all-zero or
>>>> all-one data block would be rejected.  For example, Ethernet packets
>>>> use CRC for integrity checking, but an attempt to send a packet type
>>>> 0 from MAC address 00:00:00:00:00:00 to address 00:00:00:00:00:00,
>>>> of length 0, would be rejected anyway.
>>>
>>> Why look at "data" -- which may be suspect -- and *then* check its CRC?
>>> Run the CRC first.  If it fails, decide how you are going to proceed
>>> or recover.
>>
>> That is usually the order, yes.  Sometimes you want "fail fast", such
>> as dropping a packet that was not addressed to you (it doesn't matter
>> if it was received correctly but for someone else, or it was addressed
>> to you but the receiver address was corrupted - you are dropping the
>> packet either way).  But usually you will run the CRC then look at the
>> data.
>>
>> But the order doesn't matter - either way, you are still checking for
>> valid data, and if the data is invalid, it does not matter if the CRC
>> only passed by luck or by all zeros.
>
> You're assuming the CRC is supposed to *vouch* for the data.
> The CRC can be there simply to vouch for the *transport* of a
> datagram.

I am assuming that the CRC is there to determine the integrity of the
data in the face of possible unintentional errors. That's what CRC
checks are for. They have nothing to do with the content of the data,
or the type of the data package or image.

As an example of the use of CRC's in messaging, look at Ethernet frames:

<https://en.wikipedia.org/wiki/Ethernet_frame>

The CRC does not care about the content of the data it protects.

>
> So, use a version-specific CRC on the packet.  If it fails, then
> either the data in the packet has been corrupted (which could just
> as easily have involved an embedded "interface version" parameter);
> or the packet was formed with the wrong CRC.
>
> If the CRC is correct FOR THAT VERSION OF THE PROTOCOL, then
> why bother looking at a "protocol version" parameter?  Would
> you ALSO want to verify all the rest of the parameters?
>

I'm sorry, I simply cannot see your point. Identifying the version of a
protocol, or other protocol type information, is a totally orthogonal
task to ensuring the integrity of the data. The concepts should be
handled separately.

>>> What term would you have me use to indicate a "bias" applied to a CRC
>>> algorithm?
>>
>> Well, first I'd note that any kind of modification to the basic CRC
>> algorithm is pointless from the viewpoint of its use as an integrity
>> check.  (There have been, mostly historically, some justifications in
>> terms of implementation efficiency.  For example, bit and byte
>> re-ordering could be done to suit hardware bit-wise implementations.)
>>
>> Otherwise I'd say you are picking a specific initial value if that is
>> what you are doing, or modifying the final value (inverting it or
>> xor'ing it with a fixed value).  There is, AFAIK, no specific terms
>> for these - and I don't see any benefit in having one.  Misusing the
>> term "salt" from cryptography is certainly not helpful.
>
> Salt just ensures that you can differentiate between functionally identical
> values.  I.e., in a CRC, it differentiates between the "0x0000" that CRC-1
> generates from the "0x0000" that CRC-2 generates.

Can we agree that this is called an "initial value", not "salt" ?

>
> You don't see the parallel to ensuring that *my* use of "Passw0rd" is
> encoded in a different manner than *your* use of "Passw0rd"?

No. They are different things.

An important difference is that adding "salt" to a password hash is an
important security feature. Picking a different initial value for a CRC
instead of having appropriate protocol versioning in the data (or a
surrounding envelope) is a misfeature.

The second difference is the purpose of the hashing. The CRC here is
for data integrity - spotting mistakes in the data during transfer or
storage. The hash in a password is for security, avoiding the password
ever being transmitted or stored in plain text.

Any coincidence in the the way these might be implemented is just that -
coincidence.

>
>>> See the RMI desciption.
>>
>> I'm sorry, I have no idea what "RMI" is or where it is described.
>> You've mentioned that abbreviation twice, but I can't figure it out.
>
> <https://en.wikipedia.org/wiki/RMI>
> <https://en.wikipedia.org/wiki/OCL>
>
> Nothing magical with either term.

I looked up RMI on Wikipedia before asking, and saw nothing of relevance
to CRC's or checksums. I noticed no mention of "OCL" in your posts, and
looking it up on Wikipedia gives no clues.

So for now, I'll assume you don't want anyone to know what you meant and
I can safely ignore anything you write in connection with the terms.

>
>>> OTOH, "salting" the calculation so that it is expected to yield
>>> a value of 0x13 means *those* situations will be flagged as errors
>>> (and a different set of situations will sneak by, undetected).
>>
>> And that gives you exactly /zero/ benefit.
>
> See above.

I did. Zero benefit.

Actually, it is worse than useless - it makes it harder to identify the
protocol, and reduces the information content of the CRC check.

>
>> You run your hash algorithm, and check for the single value that
>> indicates no errors.  It does not matter if that number is 0, 0x13, or
>> - often more
> -----------^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> As you've admitted, it doesn't matter.  So, why wouldn't I opt to have
> an algorithm for THIS interface give me a result that is EXPECTED
> for this protocol?  What value picking "0"?
>

A /single/ result does not matter (other than needlessly complicating
things). Having multiple different valid results /does/ matter.

>>>> That is why you need to distinguish between the two possibilities.
>>>> If you don't have to worry about malicious attacks, a 32-bit CRC
>>>> takes a dozen lines of C code and a 1 KB table, all running
>>>> extremely efficiently.  If security is an issue, you need digital
>>>> signatures - an RSA-based signature system is orders of magnitude
>>>> more effort in both development time and in run time.
>>>
>>> It's considerably more expensive AND not fool-proof -- esp if the
>>> attacker knows you are signing binaries.  "OK, now I need to find
>>> WHERE the signature is verified and just patch that "CALL" out
>>> of the code".
>>
>> I'm not sure if that is a straw-man argument, or just showing your
>> ignorance of the topic.  Do you really think security checks are done
>> by the program you are trying to send securely?  That would be like
>> trying to have building security where people entering the building
>> look at their own security cards.
>
> Do YOU really think we all design applications that run in PCs where some
> CLOSED OS performs these tests in a manner that can't be subverted?

Do you bother to read my posts at all? Or do you prefer to make up
things that you imagine I write, so that you can make nonsensical
attacks on them? Certainly there is no sane reading of my posts
(written and sent from an /open/ OS) where "do not rely on security by
obscurity" could be taken to mean "rely on obscured and closed platforms".

> *WE* (tend to) write ALL the code in the products developed, here.
> So, whether it's the POST WE wrote that is performing the test or
> the loader WE wrote, it's still *our* program.
>
> Yes, we ARE looking at our own security cards!
>
> Manufacturers *try* to hide ("obscurity") details of these mechanisms
> in an attempt to improve effective security.  But, there's nothing
> that makes these guarantees.

Why are you trying to "persuade" me that manufacturer obscurity is a bad
thing? You have been promoting obscurity of algorithms as though it
were helpful for security - I have made clear that it is not. Are you
getting your own position mixed up with mine?

>
> Give me the sources for Windows (Linux, *BSD, etc.) and I can
> subvert all the state-of-the-art digital signing used to ensure
> binaries aren't altered.  Nothing *outside* the box is involved
> so, by definition, everything I need has to reside *in* the box.

No, you can't. The sources for Linux and *BSD /are/ all freely
available. The private signing keys used by, for example, Red Hat or
Debian, are /not/ freely available. You cannot make changes to a Red
Hat or Debian package that will pass the security checks - you are
unable to sign the packages.

This is precisely because something /outside/ the box /is/ involved -
the private half of the public/private key used for signing. The public
half - and all the details of the algorithms - is easily available to
let people verify the signature, but the private half is kept secret.

(Sorry, but I've skipped and snipped the rest. I simply don't have time
to go through it in detail. If others find it useful or interesting,
that's great, but there has to be limits somewhere.)