[OpenTRV-dev] FAQ 11: is it safe to do without the CRC on secure frames?

Bo Herrmannsen bo.herrmannsen at gmail.com
Sat Dec 19 18:51:25 GMT 2015


a spanner in the works....

maybe we are using the wrong AVR? ie maybe we should consider a bigger one?

2015-12-19 19:46 GMT+01:00 Damon Hart-Davis <dhd at exnet.com>:

> We are very very pushed for TX/RX frame space.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> Rgds
>
> Damon
>
> 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!
>
>
> > On 19 Dec 2015, at 15:36, Jeremy Poulter <jeremy at bigjungle.net> wrote:
> >
> > Hi,
> >
> > 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.
> >
> > 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.
> >
> > Jeremy
> >
> > On 19 Dec 2015 14:29, "Damon Hart-Davis" <damon at opentrv.uk> wrote:
> >
> http://www.earth.org.uk/OpenTRV/stds/network/20151203-DRAFT-SecureBasicFrame.txt
> > _______________________________________________
> > OpenTRV-dev mailing list
> > OpenTRV-dev at lists.opentrv.org.uk
> > http://lists.opentrv.org.uk/listinfo/opentrv-dev
> > _______________________________________________
> > OpenTRV-dev mailing list
> > OpenTRV-dev at lists.opentrv.org.uk
> > http://lists.opentrv.org.uk/listinfo/opentrv-dev
>
> _______________________________________________
> OpenTRV-dev mailing list
> OpenTRV-dev at lists.opentrv.org.uk
> http://lists.opentrv.org.uk/listinfo/opentrv-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opentrv.org.uk/pipermail/opentrv-dev/attachments/20151219/06278368/attachment.html>


More information about the OpenTRV-dev mailing list