[OpenTRV-dev] tinyHAN application protocol and mapping to MQTT

[Bruno Girin]

Mike,

I've got a stupid question on your wiki paper. It says: "If data type is
variable then the data is prefixed by a single length byte. There is no end
of field delimiter." Is there a risk of buffer overflow if the value in the
length byte is higher than the actual length of the field/message?

So if I send the following 4 byte message, is there a risk that the code
reading that message would read byte #3 indicating a 255 byte value when in
fact it's just one byte and therefore read the remaining 254 byte of random
memory beyond the message?

0x00 0xC1 0xFF 0x01

Please tell me if that question is stupid as I'm a bit fuzzy about how
buffer overflow attacks work.

Bruno


On 10 December 2014 at 13:59, Damon Hart-Davis <EMAIL ADDRESS HIDDEN> wrote:

> Maybe we (you, I, others) can discuss in the IRC session tomorrow night?
>
> I do want to support one-way encryption for deployments using transport
> other than TinyHAN where a backchannel is hard/slow/expensive/periodic, and
> I’d prefer to avoid doing security stuff twice!  B^>
>
> (I’m up to my eyes in motor drive code kinda sorta; production engineering
> is moving along well.)
>
> Rgds
>
> Damon
>
>
> > On 10 Dec 2014, at 13:47, Mike Stirling <EMAIL ADDRESS HIDDEN> wrote:
> >
> > Hi All,
> >
> > I've been thinking about the proposed TinyHAN binary protocol and how to
> automatically map it to grown-up IoT protocols such as MQTT. I've committed
> my initial thoughts to virtual paper here and would be grateful for
> comments:
> http://www.mike-stirling.com/redmine/projects/tinyhan/wiki/TinyHAN_application_protocol
> >
> > The write access is something that has been bothering me, because MQTT
> does not actually seem like that good a fit for what is essentially a
> remote procedure call.  However, the approach I've proposed on the wiki
> feels reasonable.
> >
> > I've got most of what I've described up and running with a couple of
> sensors and I'm quite pleased with the result so far.
> >
> > Mike
> >
> > _______________________________________________
> > OpenTRV-dev mailing list
> > EMAIL ADDRESS HIDDEN
> > 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/20141210/3a6a6c93/attachment.html>