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

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

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