Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 5 of 5

Thread: Teensy 3 CRC

  1. #1

    Teensy 3 CRC

    I've looked over the docs on the CRC module a few times, (mostly on the tiny phone screen, which never helps). I think I can figure out how to feed it stuff and get results out. I'm a bit unsure of ther bigger picture though.

    I'm wanting to use it for message authentication, rather than simply integrity verification. the payload for this app is approx 100Hz 3 axis accelerometer data sent via RFM12B. I'm not worried about encryption, just the possibility of someone spoofing the transmitter

    Can CRC handle this?
    Last edited by swarfrat; 04-27-2013 at 04:13 PM.

  2. #2
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    CRC is a great algorithm for detecting random data errors, but it's terrible for thwarting intentional tempering. There are lots of references to this written by people who know far more than cryptography than I do.

  3. #3
    Junior Member
    Join Date
    Mar 2013
    If you're transmitting data that's not encrypted, anyone could easily replicate that particular signal and cause said spoofing, or even unintentional interference which CRC would cause. If you're only doing one way encoding, it's easy enough to do either a or symmetrical cryptography.

    Think of the following scenario psuedo payload:

    Even encrypted someone could simply replicate this data signal even though they may not be able to tell 'what' the payload was -- which is perfectly fine for things such ensuring people can't read what you're doing, but also consider repetative messages of the same format also lend themselves to be easier to hack due to known vectors. Now, bring in the Initialization Vector ( ) but the basic answer is this:

    If I have one way encryption, I'd need a known value from source 1 to 2, ex:

    Now, we've added a bit of data that will cause the message to constantly change which will then cause the encrypted message to change drastically based off a constantly changing value. But, of course a steady stream of this too can be easy to hack since it's simple encryption with a changing value. But, how does your receiving device know that KNOWNCOUNTERVALUE is from *your* device? The easiest way to combat this is asymmetrical encryption with a negotiation initialization:

    Device 1 has public key for Device 2, and a private key for Device 1.
    Device 2 has public key for Device 1 and a private key for Device 2.

    Device 1 initiates a message encrypted using Device 2's private key saying 'Hey, I'm ready to send, by the way I'm going to give X value randomized by X data'
    Device 2 receives a message, attempts to decrypt it using its private key, sees the message format matches what it expects, does whatever it is it wants to do and sends a message encrypted with Device 1's public key

    The logic that goes there is really up to you, but that's my easiest explanation of public-key crypto. Also found this on google:

    Anyways, you can imagine the overhead caused by all this, so it's worth may be contingent on how crazy you want to get...

  4. #4
    Thanks, I'll check out the AES lib. Up until recently I was under similar impression about CRC. I'm not sure how I picked up the idea that it could work for authenticating the sender. (Seed perhaps)

    It's not National Security stuff. The project is a accelerometer on a guitar headstock driving a Wah/Pan/MIDI expression parameter. It just strikes me as an irresistably attractive target if it gets anywhere/any exposure. (Lots of attention and low consequences) Of course, the irony is I need to remember to move in order to make it work.

  5. #5
    Senior Member
    Join Date
    May 2013
    CRC is for detecting burst errors, not to prevent spoofing. For that you need an HMAC.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts