Re: [Tm-rid] HHIT trust proof for Auth messages

["Wiethuechter, Adam" <[e-mail]>]

Michael,

If you mean 4x23=92 bytes  (pages 0-3 of the auth message) which then
creates 23 bytes of parity; which I use to fill the final page, then yes.
However each time I look at what you wrote I come back with something
different in my head - rather annoying.

I haven't had much exposure to FECs other than seeing them in text and
knowing that it is being used in something; for instance Reed-Solomon,
which I think is a FEC, is used in Tahoe LAFS which I use often. I will
read up on them to get a better idea what you are saying.

On Tue, Oct 1, 2019 at 2:41 PM Michael Richardson <[e-mail]> wrote:

>
> Wiethuechter, Adam <[e-mail]> wrote:
>     > My concern, is that we are broadcasting over Bluetooth. There are 5
> pages
>     > to the authentication message (from my understanding of the new
> standard).
>     > If we lose any one page it is most likely going to be a signature
> page (as
>     > it spans 3 whole pages) and there will be no way to achieve that
> which this
>     > format is intended for without the full signature. Perhaps the
> payload
>     > section that Bob marked in (and fills the final page of the
> authentication
>     > message) should be some sort of error correction on the signature?
>
> I think what you have in mind is that you take the 5x25 = 100 bytes, and
> did a FEC to get 6x25 pages, such that one can lose any single page.
> Each page no longer can ever stand alone now, btw.
>
> --
> ]               Never tell me the odds!                 | ipv6 mesh
> networks [
> ]   Michael Richardson, Sandelman Software Works        |    IoT
> architect   [
> ]     [e-mail]  http://www.sandelman.ca/        |   ruby on
> rails    [
>
>

-- 
73's,
Adam T. Wiethuechter