<div dir="ltr">a spanner in the works....<div><br></div><div>maybe we are using the wrong AVR? ie maybe we should consider a bigger one?</div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-12-19 19:46 GMT+01:00 Damon Hart-Davis <span dir="ltr"><<a href="mailto:dhd@exnet.com" target="_blank">dhd@exnet.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">We are very very pushed for TX/RX frame space.<br>
<br>
If I add the CRC we may in practice may not be able to receive a frame with more than 15 bytes of data on a typical 64-byte FIFO radio module such as the RFM23B.  Leaving out the CRC byte gets us to 31!  And that’s assuming that I haven’t missed something vital.<br>
<br>
Experience suggests that if the frame’s preamble and sync work, and structural elements of the frame look good, eg valid length and frame type, then the CRC is going to reject very few frames in fact.  And if someone was maliciously injecting bad frames they could have good CRCs so we’d still waste CPU cycles decoding things.<br>
<br>
We’re also very pushed for code space*, and in fact, I’ll generally not even link the code to decode insecure frames if secure is expected, so as things are currently specifed I wouldn't need to include the CRC code at all.<br>
<br>
If someone can give me a very good reason to double up CRC on top of AES-GCM I will, but some other feature will probably have to be chucked out.  My ears remain open.  Easier to fix things now if I’m wrong.<br>
<br>
Rgds<br>
<br>
Damon<br>
<br>
PS. *We have *just* got our lightweight stats half-relay up and running (from the local ISM onto GSM) albeit without security yet.  And there has been a lot of chopping stuff out (not over yet) to get everything to fit!<br>
<br>
<br>
> On 19 Dec 2015, at 15:36, Jeremy Poulter <<a href="mailto:jeremy@bigjungle.net">jeremy@bigjungle.net</a>> wrote:<br>
><br>
> Hi,<br>
><br>
> On the assumption that the security layer  digitally signs the message then a CRC would be redundant as the digital signature would tell you the content of the frame is as sent.<br>
><br>
> That being said a CRC may still be of value if outside the encryption to enable quick filtering of corrupt frames before decryption and further validation.<br>
><br>
> Jeremy<br>
><br>
> On 19 Dec 2015 14:29, "Damon Hart-Davis" <<a href="mailto:damon@opentrv.uk">damon@opentrv.uk</a>> wrote:<br>
> <a href="http://www.earth.org.uk/OpenTRV/stds/network/20151203-DRAFT-SecureBasicFrame.txt" rel="noreferrer" target="_blank">http://www.earth.org.uk/OpenTRV/stds/network/20151203-DRAFT-SecureBasicFrame.txt</a><br>
> _______________________________________________<br>
> OpenTRV-dev mailing list<br>
> <a href="mailto:OpenTRV-dev@lists.opentrv.org.uk">OpenTRV-dev@lists.opentrv.org.uk</a><br>
> <a href="http://lists.opentrv.org.uk/listinfo/opentrv-dev" rel="noreferrer" target="_blank">http://lists.opentrv.org.uk/listinfo/opentrv-dev</a><br>
> _______________________________________________<br>
> OpenTRV-dev mailing list<br>
> <a href="mailto:OpenTRV-dev@lists.opentrv.org.uk">OpenTRV-dev@lists.opentrv.org.uk</a><br>
> <a href="http://lists.opentrv.org.uk/listinfo/opentrv-dev" rel="noreferrer" target="_blank">http://lists.opentrv.org.uk/listinfo/opentrv-dev</a><br>
<br>
_______________________________________________<br>
OpenTRV-dev mailing list<br>
<a href="mailto:OpenTRV-dev@lists.opentrv.org.uk">OpenTRV-dev@lists.opentrv.org.uk</a><br>
<a href="http://lists.opentrv.org.uk/listinfo/opentrv-dev" rel="noreferrer" target="_blank">http://lists.opentrv.org.uk/listinfo/opentrv-dev</a><br>
</blockquote></div><br></div>