<div dir="ltr"><div><div><div>Mike,<br><br>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?<br><br></div>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?<br><br></div>0x00 0xC1 0xFF 0x01<br><br></div><div>Please tell me if that question is stupid as I'm a bit fuzzy about how buffer overflow attacks work.<br><br></div>Bruno<br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On 10 December 2014 at 13:59, Damon Hart-Davis <span dir="ltr"><<a href="mailto:dhd@exnet.com" target="_blank">dhd@exnet.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Maybe we (you, I, others) can discuss in the IRC session tomorrow night?<br>
<br>
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^><br>
<br>
(I’m up to my eyes in motor drive code kinda sorta; production engineering is moving along well.)<br>
<br>
Rgds<br>
<span class="HOEnZb"><font color="#888888"><br>
Damon<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
> On 10 Dec 2014, at 13:47, Mike Stirling <<a href="mailto:mail@mikestirling.co.uk">mail@mikestirling.co.uk</a>> wrote:<br>
><br>
> Hi All,<br>
><br>
> 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: <a href="http://www.mike-stirling.com/redmine/projects/tinyhan/wiki/TinyHAN_application_protocol" target="_blank">http://www.mike-stirling.com/redmine/projects/tinyhan/wiki/TinyHAN_application_protocol</a><br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> Mike<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" target="_blank">http://lists.opentrv.org.uk/listinfo/opentrv-dev</a><br>
<br>
</div></div></blockquote></div><br></div>