On 03/05/2023 09:15, Don Y wrote:
> On 4/24/2023 7:37 AM, David Brown wrote:
>> 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.
>
> Exactly.  And, a CRC on *a* protocol can use ANY ALGORITHM that the
> protocol
> defines.  Not some "canned one-size fits all" approach.

It makes sense to use an 8-bit CRC on small telegrams, 16-bit CRC on
bigger things, 32-bit CRC on flash images, and 64-bit CRC when you want
to use the CRC as an identifying hash (and malicious tampering is
non-existent). There can also be benefits of particular choices of CRC
for particular use-cases, in terms of detection of certain error
patterns for certain lengths of data.

What I don't see any point in is using variations, such as different
initial values. I've already said why I think pathological cases such
as all zero data are normally irrelevant - but I can accept that there
may be occasions when they could happen, and thus a /single/ non-zero
initial value would be useful.

>
>> 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.
>
> AND, if the packet yielded an incorrect CRC, you can assume the
> data was corrupt... OR, you are looking at a different protocol
> and MISTAKING it for something that you *think* it might be.

If the CRC does not match, you reject the packet or data. End of story.
You don't know or care /why/ - because you cannot be sure of any reason.

>
> If I produce a stream of data, can you tell me what the checksum
> for THAT stream *should* be?  You have to either be told what
> it is (and have a way of knowing what the checksum SHOULD be)
> *or* have to make some assumptions about it.

If you are transmitting some data then both sides need to agree on the
CRC algorithm (size, polynomial, initial value, etc.), and on whether a
check is "CRC of everything gives 0" or "CRC of everything except the
pre-calculated CRC equals the transmitted pre-calculated CRC".

>
> If you have assumed wrong *or* if the data has been corrupt, then
> the CRC should fail.  You don't care why it failed -- because you
> can't do anything about it.  You just know that you can't use the data
> in the way you THOUGHT it could be used.
>

Well, yes. Obviously.

If you are making incorrect assumptions here, someone is doing a pretty
poor job at designing, describing or implementing the communications
system. It is just like getting the baud rate wrong on a UART link.

>>> 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.
>
> It is.  A packet using protocol XYZ is delivered to port ABC.
> Port ABC *only* handles protocol XYZ.  Anything else arriving there,
> with a potentially different checksum, is invalid.  Even if, for example,
> byte number 27 happens to have the correct "magic number" for that
> protocol.
>
> Because the message doesn't obey the rules defined by the protocol
> FOR THAT PORT.  What do I gain by insisting that byte number 27 must
> be 0x5A that the CRC doesn't already tell me?
>

A CRC failure doesn't tell you that the telegram type is wrong. It
tells you that the data is corrupted.

If there can be different protocols, or telegram types, or whatever,
then identify them. Stop playing silly buggers with abuse of different
concepts that have different roles in the communication system.

>>> 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" ?
>
> It depends on how you implement it.  The point is to produce
> different results for the same polynmomial.

It is called an "initial value" - it is not "salt". It doesn't matter
if you want to pick different initial values for your CRC, or why you
want to do that. You are still not talking about salt.

If you insist on using your own terminology, you will be left talking to
yourself.

>
>>> 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.
>
> And you don't see that verifying that a packet of data received at
> port ABC that should only see the checksum associated with protocol
> XYZ as being similarly related?

No. They are different things.

Look, I /do/ understand what you are doing, and I appreciate that you
think it is a good idea. To me, it is an unpleasant mix of orthogonal
concepts that needlessly complicates things. Just because something is
/possible/, does not mean it is a good idea.

>>
>>>>> 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've snipped the ramblings that have nothing to do with the question I
asked. I assume you don't want to answer me.

>
>> I noticed no mention of "OCL" in your posts, and looking
>
> You need to read more carefully.

I've looked. You did not mention "OCL" anywhere before giving the URL
to the wikipedia page. You only mentioned it /afterwards/ - without any
context that suggests what you meant. (Here's a hint for you - if you
want to refer to a wikipedia page, put a link to the /relevant/ page.)

Presumably "RMI" and "OCL" have particular meanings that are relevant
for projects you work on, and are so familiar to you that they are part
of your language. No one else knows or cares what they are, and they
are irrelevant in this thread. So let's leave them there.

>
>>> 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.
>
> Sure I can!  If you are just signing a package to verify that it hasn't
> been tampered with BUT THE CONTENTS ARE NOT ENCRYPTED, then all you have
> to do is remove the signature check -- leaving the signature in the
> (unchecked) executable.

Woah, you /really/ don't understand this stuff, do you? Here's a clue -
ask yourself what is being signed, and what is doing the checking.

Perhaps also ask yourself if /all/ the people involved in security for
Linux or BSD - all the companies such as Red Hat, IBM, Intel, etc., -
ask if /all/ of them have got it wrong, and only /you/ realise that
digital signatures on open source software is useless? /Very/
occasionally, there is a lone genius that understands something while
all the other experts are wrong - but in most cases, the loner is the
one that is wrong.