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

[Robert Moskowitz <[e-mail]>]

On 10/2/19 4:04 PM, Wiethuechter, Adam 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).

A supposition is that there were performance/reliability challenges with 
more pages.  Unfortunately, we have a weak connection into the closed 
ATSM wg.

>
> 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.

You have the 'MAC' mapping to work with, so if something goes, it is the 
HHIT to save 16 bytes (almost a page).

> 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".

The trusted timestamp is very important.  More details to follow on what 
this small 'cert' is.

>
> 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.

My BT5 comment was wondering why they cut the BT4 down to less than what 
BT5 will deliver.  It makes it a challenge for developing messages that 
work with both.  We definitely have to live within BT4 constraints.  Now 
to find out what they are.

>
> [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] <mailto:[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] <mailto:[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] <mailto:[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] <mailto:[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

-- 
Standard 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