Teensy 3 CRC

Status
Not open for further replies.
S

swarfrat

Active member
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:
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.
 
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:
'STARTMARKER LEN DATA CRC ENDMARKER'

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 ( http://en.wikipedia.org/wiki/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:
'STARTMARKER LEN DATA KNOWNCOUNTERVALUE CRC ENDMARKER'

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: https://github.com/DavyLandman/AESLib

Anyways, you can imagine the overhead caused by all this, so it's worth may be contingent on how crazy you want to get...
 
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.
 
Status
Not open for further replies.
Back
Top