logoalt Hacker News

eqvinoxyesterday at 1:03 PM3 repliesview on HN

I don't think this helps against someone receiving the signals (all satellites) and rebroadcasting them. The effect of that would be that any receiver of those rebroadcasted signals will believe they are located where the receiver of the rebroadcast is located (just the time is slightly off/late, but that doesn't help much without a reference to check against.)


Replies

rkourdisyesterday at 2:22 PM

It's been a few years since I've worked with this stuff but I'm under the impression that you can do this sort of replay only for a short amount of time. If so, is there a point?

If the receiver expects a key to have been revealed at a particular timestep, it won't accept a replayed message with that key after that, so you can't record and replay indefinitely.

EDIT: Unless you indeed meant to instantly replay - would the receiver accept the highest strength signal, ie. yours?

show 2 replies
throw0101ayesterday at 5:26 PM

> […] (just the time is slightly off/late, but that doesn't help much without a reference to check against.)

The 'time sync' does not need to be done in the same absolutely sense (time_t is the same everywhere), but only in the relative sense:

    Various approaches exist for time synchronization [15,16,17,18].
    TESLA only requires the receiver to know an upper bound on the delay
    of its local clock with respect to the sender's clock, so a simple
    algorithm is sufficient. 
* https://datatracker.ietf.org/doc/html/rfc4082#section-3.3.1

Knowing the (rough) broadcast delay from sender to receiver is sufficient.

show 1 reply
DoctorOetkeryesterday at 2:48 PM

nobody would send a military vehicle (manned or drone) without initializing a proper clock, the replays would be stale.

show 1 reply