Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #31936
| From | Ulf Samuelsson <ulf.r.samuelsson@gmail.com> |
|---|---|
| Newsgroups | comp.arch.embedded |
| Subject | Re: Embedding a Checksum in an Image File |
| Date | 2023-05-09 20:42 +0200 |
| Organization | eMagii |
| Message-ID | <u3e46p$bcui$2@dont-email.me> (permalink) |
| References | (9 earlier) <u20sli$3ag7l$1@dont-email.me> <u25bas$8fh0$2@dont-email.me> <u2646q$clg2$1@dont-email.me> <u2t1mh$16mg5$1@dont-email.me> <u2tl7k$19ji0$1@dont-email.me> |
Den 2023-05-03 kl. 14:48, skrev David Brown: > 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. Flash images larger than X kB may need a 64-bit CRC. I don't remember exactly when to start considering it, but something between 64kB-256kB is probably correct. It is all to do with Hamming Distance, and this is also affected by the polynome. /Ulf > > > 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. >
Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Embedding a Checksum in an Image File Rick C <gnuarm.deletethisbit@gmail.com> - 2023-04-19 19:06 -0700
Re: Embedding a Checksum in an Image File Niklas Holsti <niklas.holsti@tidorum.invalid> - 2023-04-20 12:14 +0300
Re: Embedding a Checksum in an Image File Rick C <gnuarm.deletethisbit@gmail.com> - 2023-04-20 06:18 -0700
Re: Embedding a Checksum in an Image File "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2023-04-20 11:30 +0000
Re: Embedding a Checksum in an Image File dalai lamah <antonio12358@hotmail.com> - 2023-04-20 13:47 +0200
Re: Embedding a Checksum in an Image File Rick C <gnuarm.deletethisbit@gmail.com> - 2023-04-20 06:04 -0700
Re: Embedding a Checksum in an Image File David Brown <david.brown@hesbynett.no> - 2023-04-20 16:46 +0200
Re: Embedding a Checksum in an Image File George Neuner <gneuner2@comcast.net> - 2023-04-20 11:33 -0400
Re: Embedding a Checksum in an Image File Rick C <gnuarm.deletethisbit@gmail.com> - 2023-04-20 09:45 -0700
Re: Embedding a Checksum in an Image File David Brown <david.brown@hesbynett.no> - 2023-04-20 22:26 +0200
Re: Embedding a Checksum in an Image File Ulf Samuelsson <ulf.r.samuelsson@gmail.com> - 2023-04-27 18:36 +0200
Re: Embedding a Checksum in an Image File David Brown <david.brown@hesbynett.no> - 2023-04-28 09:12 +0200
Re: Embedding a Checksum in an Image File Ulf Samuelsson <ulf.r.samuelsson@gmail.com> - 2023-04-28 10:35 +0200
Re: Embedding a Checksum in an Image File George Neuner <gneuner2@comcast.net> - 2023-04-20 16:44 -0400
Re: Embedding a Checksum in an Image File Don Y <blockedofcourse@foo.invalid> - 2023-04-20 22:37 -0700
Re: Embedding a Checksum in an Image File David Brown <david.brown@hesbynett.no> - 2023-04-21 12:43 +0200
Re: Embedding a Checksum in an Image File Don Y <blockedofcourse@foo.invalid> - 2023-04-21 04:39 -0700
Re: Embedding a Checksum in an Image File David Brown <david.brown@hesbynett.no> - 2023-04-21 16:50 +0200
Re: Embedding a Checksum in an Image File Don Y <blockedofcourse@foo.invalid> - 2023-04-21 17:29 -0700
Re: Embedding a Checksum in an Image File David Brown <david.brown@hesbynett.no> - 2023-04-22 16:57 +0200
Re: Embedding a Checksum in an Image File Don Y <blockedofcourse@foo.invalid> - 2023-04-24 00:32 -0700
Re: Embedding a Checksum in an Image File David Brown <david.brown@hesbynett.no> - 2023-04-24 16:37 +0200
Re: Embedding a Checksum in an Image File Don Y <blockedofcourse@foo.invalid> - 2023-05-03 00:15 -0700
Re: Embedding a Checksum in an Image File David Brown <david.brown@hesbynett.no> - 2023-05-03 14:48 +0200
Re: Embedding a Checksum in an Image File Ulf Samuelsson <ulf.r.samuelsson@gmail.com> - 2023-05-09 20:42 +0200
Re: Embedding a Checksum in an Image File David Brown <david.brown@hesbynett.no> - 2023-05-10 10:06 +0200
Re: Embedding a Checksum in an Image File Ulf Samuelsson <ulf.r.samuelsson@gmail.com> - 2023-05-10 12:03 +0200
Re: Embedding a Checksum in an Image File Don Y <blockedofcourse@foo.invalid> - 2023-08-05 01:48 -0700
Re: Embedding a Checksum in an Image File Don Y <blockedofcourse@foo.invalid> - 2023-08-05 01:42 -0700
Re: Embedding a Checksum in an Image File Stefan Reuther <stefan.news@arcor.de> - 2023-04-21 19:40 +0200
Re: Embedding a Checksum in an Image File Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2023-04-20 20:17 +0300
Re: Embedding a Checksum in an Image File George Neuner <gneuner2@comcast.net> - 2023-04-20 16:49 -0400
Re: Embedding a Checksum in an Image File Richard Damon <Richard@Damon-Family.org> - 2023-04-20 22:09 -0400
Re: Embedding a Checksum in an Image File Rick C <gnuarm.deletethisbit@gmail.com> - 2023-04-20 19:41 -0700
Re: Embedding a Checksum in an Image File Richard Damon <Richard@Damon-Family.org> - 2023-04-21 19:30 -0400
Re: Embedding a Checksum in an Image File Brian Cockburn <brian.cockburn.1959@gmail.com> - 2023-04-21 01:53 -0700
Re: Embedding a Checksum in an Image File Rick C <gnuarm.deletethisbit@gmail.com> - 2023-04-21 05:12 -0700
Re: Embedding a Checksum in an Image File David Brown <david.brown@hesbynett.no> - 2023-04-21 17:02 +0200
Re: Embedding a Checksum in an Image File Brian Cockburn <brian.cockburn.1959@gmail.com> - 2023-04-21 16:56 -0700
Re: Embedding a Checksum in an Image File David Brown <david.brown@hesbynett.no> - 2023-04-22 17:01 +0200
Re: Embedding a Checksum in an Image File Rick C <gnuarm.deletethisbit@gmail.com> - 2023-04-21 20:14 -0700
Re: Embedding a Checksum in an Image File David Brown <david.brown@hesbynett.no> - 2023-04-22 17:13 +0200
Re: Embedding a Checksum in an Image File Rick C <gnuarm.deletethisbit@gmail.com> - 2023-04-22 09:56 -0700
Re: Embedding a Checksum in an Image File David Brown <david.brown@hesbynett.no> - 2023-04-22 19:54 +0200
Re: Embedding a Checksum in an Image File Grant Edwards <invalid@invalid.invalid> - 2023-04-22 20:05 +0000
Re: Embedding a Checksum in an Image File David Brown <david.brown@hesbynett.no> - 2023-04-23 17:37 +0200
Re: Embedding a Checksum in an Image File Grant Edwards <invalid@invalid.invalid> - 2023-04-23 17:37 +0000
Re: Embedding a Checksum in an Image File David Brown <david.brown@hesbynett.no> - 2023-04-23 23:45 +0200
Re: Embedding a Checksum in an Image File Richard Damon <Richard@Damon-Family.org> - 2023-04-23 18:16 -0400
Re: Embedding a Checksum in an Image File David Brown <david.brown@hesbynett.no> - 2023-04-24 09:13 +0200
Re: Embedding a Checksum in an Image File boB <boB@K7IQ.com> - 2023-04-22 13:41 -0700
Re: Embedding a Checksum in an Image File Rick C <gnuarm.deletethisbit@gmail.com> - 2023-04-23 10:34 -0700
Re: Embedding a Checksum in an Image File David Brown <david.brown@hesbynett.no> - 2023-04-23 23:58 +0200
Re: Embedding a Checksum in an Image File Rick C <gnuarm.deletethisbit@gmail.com> - 2023-04-23 15:24 -0700
Re: Embedding a Checksum in an Image File David Brown <david.brown@hesbynett.no> - 2023-04-24 09:17 +0200
Re: Embedding a Checksum in an Image File Rick C <gnuarm.deletethisbit@gmail.com> - 2023-04-24 01:07 -0700
Re: Embedding a Checksum in an Image File Ulf Samuelsson <ulf.r.samuelsson@gmail.com> - 2023-04-27 18:42 +0200
Re: Embedding a Checksum in an Image File David Brown <david.brown@hesbynett.no> - 2023-04-28 09:20 +0200
Re: Embedding a Checksum in an Image File Ulf Samuelsson <ulf.r.samuelsson@gmail.com> - 2023-04-28 10:44 +0200
Re: Embedding a Checksum in an Image File Brian Cockburn <brian.cockburn.1959@gmail.com> - 2023-04-21 16:52 -0700
Re: Embedding a Checksum in an Image File Rick C <gnuarm.deletethisbit@gmail.com> - 2023-04-21 20:23 -0700
Re: Embedding a Checksum in an Image File Brian Cockburn <brian.cockburn.1959@gmail.com> - 2023-04-22 07:07 -0700
Re: Embedding a Checksum in an Image File Richard Damon <Richard@Damon-Family.org> - 2023-04-22 10:31 -0400
Re: Embedding a Checksum in an Image File Rick C <gnuarm.deletethisbit@gmail.com> - 2023-04-22 09:54 -0700
Re: Embedding a Checksum in an Image File Ulf Samuelsson <ulf.r.samuelsson@gmail.com> - 2023-04-27 18:26 +0200
Re: Embedding a Checksum in an Image File Rick C <gnuarm.deletethisbit@gmail.com> - 2023-04-27 10:09 -0700
Re: Embedding a Checksum in an Image File Niklas Holsti <niklas.holsti@tidorum.invalid> - 2023-04-27 21:29 +0300
Re: Embedding a Checksum in an Image File Niklas Holsti <niklas.holsti@tidorum.invalid> - 2023-04-27 21:39 +0300
Re: Embedding a Checksum in an Image File Ulf Samuelsson <ulf.r.samuelsson@gmail.com> - 2023-04-27 22:44 +0200
Re: Embedding a Checksum in an Image File David Brown <david.brown@hesbynett.no> - 2023-04-28 09:38 +0200
Re: Embedding a Checksum in an Image File Ulf Samuelsson <ulf.r.samuelsson@gmail.com> - 2023-04-28 10:50 +0200
Re: Embedding a Checksum in an Image File David Brown <david.brown@hesbynett.no> - 2023-04-28 15:04 +0200
Re: Embedding a Checksum in an Image File Ulf Samuelsson <ulf.r.samuelsson@gmail.com> - 2023-04-29 23:03 +0200
Re: Embedding a Checksum in an Image File David Brown <david.brown@hesbynett.no> - 2023-04-30 16:19 +0200
Re: Embedding a Checksum in an Image File Ulf Samuelsson <ulf.r.samuelsson@gmail.com> - 2023-05-09 20:34 +0200
Re: Embedding a Checksum in an Image File David Brown <david.brown@hesbynett.no> - 2023-05-10 10:18 +0200
Re: Embedding a Checksum in an Image File David Brown <david.brown@hesbynett.no> - 2023-04-28 09:33 +0200
Re: Embedding a Checksum in an Image File Ulf Samuelsson <ulf.r.samuelsson@gmail.com> - 2023-04-27 22:36 +0200
Re: Embedding a Checksum in an Image File Niklas Holsti <niklas.holsti@tidorum.invalid> - 2023-04-28 01:10 +0300
Re: Embedding a Checksum in an Image File Ulf Samuelsson <ulf.r.samuelsson@gmail.com> - 2023-04-28 10:54 +0200
Re: Embedding a Checksum in an Image File David Brown <david.brown@hesbynett.no> - 2023-04-28 09:24 +0200
Re: Embedding a Checksum in an Image File Ulf Samuelsson <ulf.r.samuelsson@gmail.com> - 2023-04-28 10:56 +0200
Re: Embedding a Checksum in an Image File David Brown <david.brown@hesbynett.no> - 2023-04-28 15:09 +0200
Re: Embedding a Checksum in an Image File Ulf Samuelsson <ulf.r.samuelsson@gmail.com> - 2023-04-29 23:02 +0200
Re: Embedding a Checksum in an Image File Ulf Samuelsson <ulf.r.samuelsson@gmail.com> - 2023-04-27 18:27 +0200
csiph-web