Electronics > Projects, Designs, and Technical Stuff

Custom 1 wire (open drain aka I2C ) protocol bytes with CRC and ID arbitration

<< < (3/4) > >>

GeorgeOfTheJungle:

--- Quote from: T3sl4co1l on November 11, 2019, 06:14:26 am ---It's more just to show that you put in the effort to protect it against casual investigation, not to make it crypto secure.

--- End quote ---
I hope that does not become fashionable.

jhpadjustable:

--- Quote from: GeorgeOfTheJungle on November 11, 2019, 09:19:44 am ---I hope that does not become fashionable.

--- End quote ---
Too late. The cheap lock suffices to enable the severe anti-circumvention laws in many countries. Why spend time on engineering if Johnny Law will be your enforcer after the fact, at no cost to you?

T3sl4co1l:

--- Quote from: GeorgeOfTheJungle on November 11, 2019, 09:19:44 am ---
--- Quote from: T3sl4co1l on November 11, 2019, 06:14:26 am ---It's more just to show that you put in the effort to protect it against casual investigation, not to make it crypto secure.

--- End quote ---
I hope that does not become fashionable.

--- End quote ---

:-DD :-DD :-DD

Friend, that IS all it ever was! :D  To varying degrees, of course.  But even top tier crypto is just another barrier against attack.  A finite barrier, not at all insurmountable, just impractical.

For example, even if you implement top crypto in a 8-bit MCU, well first of all you'll burn probably half your Flash on it alone, not to mention the computation time (which might drag down even a 1kbps connection like the present case).  Not to mention you'll spend more time on that, than the application code itself.  Huge footgun.  Meanwhile there's a dozen other attack vectors left open; your crypto implementation may be easily circumvented with a carefully crafted message, or race conditions, or supply voltage glitching, or decapping.  Or the com protocol is missing checks and a companion device can be used to probe the target device (common example: abusing USB device descriptor length to read out well beyond the actual descriptor table).  Or maybe you ordered the chips programmed by a 3rd party that occasionally forgot to set the lock bits, and the ROM can just be dumped with a normal programmer.

Yeah, security is not theoretical, it is practical.  No one needs perfect security, nor does anyone truly want it.  It only has to be good enough so that the effort required to circumvent it is expected to be greater than, say, circumventing a competitor's product, or for that matter just recreating the functionality from scratch.  Also, if security is bothersome to use -- it isn't security.  Example: frequently changed passwords causing users to write down their password on a post-it hanging on their monitor.

Tim

beduino:
Back to Hamming Code for 8 bit data there is something I'd like make clear - do we need extend byte with Hamming Code 4 bits included in a way:
P1 P2 D1 P4 D2 D3 D4 P8 D5 D6 D7 D8
or maybe it doesn't matter during transmision when we send byte as it is with Hamming Code bits appended
in the form easy later to find error bit for correction?  :-\
D1 D2 D3 D4 D5 D6 D7 D8  P8 P4 P2 P1

When we example byte from videos linked above we have:
Data byte: 0x4D 01001101  Hamming Code parity bits:  P8: 1  P4: 0  P2: 1  P1: 0  0x41  01000001  crc: 1010
where somekind of crc is simply: P8 P4 P2 P1 Hamming Code bits calculated from byte while sending

After receiving with D7 bit changed to 1 as in linked YT examples above we can calculate in receiver again:
Data byte: 0x4F 01001111  Hamming Code parity bits:  P8: 0  P4: 0  P2: 0  P1: 1  0x80  10000000  crc: 0001

So, according to calculation formula of Hamming Code for 8 bit data showed above we make: P8P4P2P1 XOR C8C4C2C1:
C= 1010 XOR 0001 = 1011 = 11.0 
Since C<>0 we detected the error and C=11 (decimal) shows that D7 bit changed, since when in the case of error we compose full 12 bit Hamming Code fro given byte:
P1 P2 D1 P4 D2 D3 D4 P8 D5 D6 D7 D8
it is clear which bit we need to correct to try avoid this error.

So, that is why it is not clear  for me whwther there is any requirement (advantage?) when using Hamming Code for byte to create those 12bit pattern during transmition or as I've shown above I still was able detect error and make attempt to correct D7 bit by appending those calculated Hamming Code parity bits to the end and send byte as it is untouched which makes this transmision easier to read by humans while we know last 4 bits a Hamming Codes?  ::)

What do you think?


BTW: For someone interested I've attached precomputed table of Hamming Code bits for byte to be able use lookup table intead of pure XOR calculation to speed up especially on AVR MPUs (I mean ATTiny85 for example) where there is no one step  instruction to shift bits right/left in register by given amount of bits  :o
Yes, It can be supprise for many until one looks in assembller code listing eg. for something as simply as it is  - it is not what one expects to see in assembler code for many CPUs >:D

--- Code: ---uint8_t x= 0x1;
uint8_t y= (x<<4)

--- End code ---

T3sl4co1l:
You're just shuffling the bits around anyway.  Might as well keep them unpacked. 8)



--- Quote from: beduino on November 11, 2019, 08:59:20 pm ---BTW: For someone interested I've attached precomputed table of Hamming Code bits for byte to be able use lookup table intead of pure XOR calculation to speed up especially on AVR MPUs (I mean ATTiny85 for example) where there is no one step  instruction to shift bits right/left in register by given amount of bits  :o
Yes, It can be supprise for many until one looks in assembller code listing eg. for something as simply as it is  - it is not what one expects to see in assembler code for many CPUs >:D

--- End quote ---

Yeah, avr-gcc typically generates individual shifts until four or so, at which point it may generate a loop, or use the swap instruction.


Incidentally, to encourage optimal use of the swap instruction, you actually want to write:


--- Code: ---var = (var >> 4) | (var << 4); // swap var
--- End code ---

even if you're only using the lower nibble of the result (var & 0x0f).

Shame AVR doesn't have a parity flag, but there's #include <util/parity.h> available.

Cleverer shortcuts should be possible for the various bit patterns; the straightforward way is to simply mask the bit patterns as you go.

I would expect the software implementation for error detection would be smaller than a 256 byte lookup table, and execution time shouldn't be a problem here; the table is a lot faster to develop with though.

Tim

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod