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

["Card, Stu" <[e-mail]>]

We can do better than that. We are not dealing with random byte errors in
unknown locations but rather the loss of an entire BT frame, the location
of which will be known due to the missing sequence number. Thus one 23 byte
Reed-Solomon check frame can correct for the loss of one 23 byte data frame.

On Wed, Oct 2, 2019, 16:04 Wiethuechter, Adam <
[e-mail]> wrote:

> While waiting for Gabriel to answer our emails I have been playing with
> Reed-Solomon encoding with the message formats. I assume worst case
> scenario of having only 5 pages to play with (the more I examine what I can
> access for implementation the more convinced I am that this is the reality
> of our situation) and I am using the above format to work out something
> (specifically the shorter format as its the only one that fits currently).
>
> The first page has 17 bytes of user data, which is just to HHIT. We can
> also obtain this via the Basic ID message so I am not that worried about
> loss here.
> The next 3 pages contain the trusted timestamp (not terribly important but
> useful information) and the HHIT Signature (very important). If we lose any
> one of these packets the whole point of authentication is gone. We still
> have one page left, that Bob has marked as "payload".
>
> Assuming we want to run Reed-Solomon (and to my knowledge after doing some
> internet search to understand it) we want an RS(92,69) with 8 bit symbols.
> This will give us 23 bytes of parity that we would place into the "payload"
> section and would protect the 3 signature pages from up to 11 errors. This
> is assuming the following: RS(n,k) and 2t=n-k where; n=payload size, k=data
> size, t=correctable errors. I used [1] as a reference to understand what I
> was doing.
>
> Bob, also note that while I know BT5 is an option I am constraining myself
> to BT4 for the time being as it is widely available and I don't fully
> understand BT5 Extended Message format at this time. I also want to develop
> up into BT5 (after getting BT4 formatting in a good state) and not develop
> down into BT4.
>
> [1]
> https://www.cs.cmu.edu/~guyb/realworld/reedsolomon/reed_solomon_codes.html
>
> On Wed, Oct 2, 2019 at 8:40 AM Robert Moskowitz <[e-mail]>
> wrote:
>
>> Quickly,
>>
>> We have to find out why the reduction in size when BT5 is 255 bytes and
>> the extended messages were designed to work in BT5.
>>
>> Bob
>>
>> On 10/1/19 12:12 PM, Wiethuechter, Adam wrote:
>>
>> All,
>>
>> Attached is a mock up of what Bob has here just in the new 0.8 version of
>> the authentication message.
>>
>> There is a 23 byte payload limit or 25 bytes if we remove the reserved
>> bytes and condense. I am unwilling to do this though as then the HHIT or
>> Trust Timestamp fields would be fragmented across pages. Its already bad
>> enough that the Trusted Timestamp and standard Timestamp fragment across
>> the 32 bit boundary (within a page) and worse the signature across 3 whole
>> pages already. While in practice this probably wouldn't affect much it
>> makes it harder to understand/read I think.
>>
>> 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?
>>
>> The second version I think is unattainable in the new format, unless
>> someone here can defy the laws of physics and make numbers smaller than
>> they actually are thus allowing more to fit within the 109 byte constrain
>> of the message format.
>>
>> Questions, comments, concerns?
>>
>> On Fri, Sep 27, 2019 at 12:40 PM Robert Moskowitz <
>> [e-mail]> wrote:
>>
>>> And here is something I have been working on as condensed proof of HHIT
>>> ownership objects that can be put into the auth messages.  I have not
>>> done that yet, like Adam has:
>>>
>>>      <figure>
>>>          <artwork>
>>>     0                   1 2                   3
>>>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>> |                                                               |
>>>    | HHIT                              |
>>> |                                                               |
>>> |                                                               |
>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>    | TIMESTAMP                          |
>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>> |                                                               |
>>>    | HHIT                              |
>>>    | SIG                              |
>>> .                                                               .
>>> .                                                               .
>>> .                                                               .
>>> |                                                               |
>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>    / PAYLOAD                            /
>>> /                                                               /
>>>    / +-------------------------------+
>>>    / |                               |
>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>
>>>    HHIT           16 byte HHIT of EdDSA25519 HI
>>>    TIMESTAMP      4 byte packet trust until timestamp
>>>    HHIT SIG       64 byte Signature of whole packet
>>>    PAYLOAD        0 to n bytes of payload
>>>        Length     84 + n bytes
>>>          </artwork>
>>>      </figure>
>>>      <figure>
>>>          <artwork>
>>>     0                   1 2                   3
>>>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>> |                                                               |
>>>    |                            DEV HHIT                           |
>>> |                                                               |
>>> |                                                               |
>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>    | TIMESTAMP                          |
>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>> |                                                               |
>>>    |                            DEV HHIT                           |
>>>    | SIG                              |
>>> .                                                               .
>>> .                                                               .
>>> .                                                               .
>>> |                                                               |
>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>> |                                                               |
>>>    |                              DEV HI                           |
>>> |                                                               |
>>> |                                                               |
>>> |                                                               |
>>> |                                                               |
>>> |                                                               |
>>> |                                                               |
>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>    |                         AUTH TIMESTAMP                        |
>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>> |                                                               |
>>>    |                           AUTH HHIT                           |
>>> |                                                               |
>>> |                                                               |
>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>> |                                                               |
>>>    | AUTH                               |
>>>    | SIG                              |
>>> .                                                               .
>>> .                                                               .
>>> .                                                               .
>>> |                                                               |
>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>    / PAYLOAD                            /
>>> /                                                               /
>>>    / +-------------------------------+
>>>    / |                               |
>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>
>>>    DEV HHIT       16 byte Dev HHIT of EdDSA25519 HI
>>>    TIMESTAMP      4 byte packet trust until timestamp
>>>    DEV HHIT SIG   64 byte Signature of whole packet
>>>    DEV HI         32 byte Device HI of EdDSA25519 HI
>>>    AUTH TIMESTAMP 4 byte Dev HHIT trust until timestamp
>>>    AUTH HHIT      16 byte Authorizer's HHIT of EdDSA25519 HI
>>>    AUTH SIG       64 byte Signature of Device HHIT-HI
>>>    PAYLOAD        0 to n bytes of payload
>>>        Length    200 + n bytes
>>>          </artwork>
>>>      </figure>
>>>
>>>    |             Type              | Length            |
>>>
>>> --
>>> Tm-rid mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/tm-rid
>>>
>>
>>
>> --
>> 73's,
>> Adam T. Wiethuechter
>>
>>
>> --
>> Robert Moskowitz
>> Owner
>> HTT Consulting
>> C:      248-219-2059
>> F:      248-968-2824
>> E:      [e-mail]
>>
>> There's no limit to what can be accomplished if it doesn't matter who
>> gets the credit
>>
>
>
> --
> 73's,
> Adam T. Wiethuechter
> --
> Tm-rid mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tm-rid
>