Use TOTP (RFC-6238) to generate EphIDs from daily Changing SK(t)

[sslHello]

Suggestion/Request for discussion:
According to the discussion in Issue #66 and the mentioned assessment of the DESIRE proposal, solely BLE beacons are estimated to be used (no individual, bidirectional communication).
So I'd suggest to use the TOTP: Time-Based One-Time Password Algorithm (RFC6238) to generate the EphIDs based on a daily changing seed (SK(t)). Use a strong seed to generate HMAC-SHA256, but truncate the calculated EphID to 16-20 bytes as needed (still looking for a RFC where they have done this already).
Clocks should be relatively synchronized, perhaps this could be verified by as a part of the daily dummy for the upload function.
The EphID should be calculated as often as possible and needed according to locally trace the time of a contact. If possible at least 2 different EphIDs should be sent within the critical contact time (from medical view). So if you calculate that you miss closely the first and the last beacon in this time-frame, t(EphID)="critical time-frame"/3.
Changing the EphIDs could also reduce the risk of false positives as a sequence or a subset of a sequence EphIDs from the same sender helps to recognize the contact using the uploaded SK(t) for the day.
Received EpIDs, time and signal strength should be stored on the phone.
If there are no strong signals within a sliding window (e.g. n * "critical time-frame") these signals could be ignored (e.g. deleted) to reduce the size of local data. Weak signals within the sliding window of a strong signal should be persisted to recognize dangerous contacts with an as infected reported person.

Note: SK(t) should additionally be changed after an infected patient uploaded its SK(t, t-1, t-n) of the last days where he could have infected other persons.
From my point of view it should be also considered to go on beaconing, as it may get more suspicious to pass by a person that does not use the app than continuing beaconing after being tested positive or getting healthy (and not uploading any SK(t) later).

[sslHello]

According to RFC4868 it is OK to truncate a HMAC-SHA-256 to 128 bits for IPSec, so the EphIDs could use the same HMAC-SHA-256-128 standard.
Just use the first 128 bits of a SHA-256 HMAC, sounds reasoable for me to be better than HMAC-SHA-128.