Hi Joe & WSJT development team, I've been thinking for the past few days on how to create alternate anti-piracy mechanism using public key cryptography, based on some of the public SuperFox details & examining the disassembled binaries. The key constraints appear to be:
* Signature data within regular messages (i.e. acking other stations) should be small (20 bits). The existing `signature` function looks like it masks some bits with 0xfffff, which would yield a 20-bit signature (correct me if I'm wrong), so we can match that. * WSJT-X clients should be able to verify DXpedition signatures without software updates or internet access. * A key attestation mechanism should exist, with built-in (WSJT-X developers & NCDXF) and probably user-addable keys to keep things open. * The system should handle message loss gracefully. * The approach should be secure with open-source code. * No use of encryption, since it would run afoul of FCC regulations. Assuming we can create a new special message type for key/signature data -- perhaps alongside a CQ? -- here's the proposed approach: 1) Every 10-15 minutes, a DXpedition station transmits a special message: - 224-bit ECC key for the DXpedition - 448-bit BLS signature of this key from an authoritative source - 128-bit value of a hash chain - 448-bit BLS signature of the above + rounded timestamp, using the DXpedition key Total payload: ~1,250 bits Given FT8 has a 77-bit payload and a bandwidth of roughly 50Hz, I'm speculating a SuperFox message could contain up to a maximum of about 2,300 bits. So, the special message payload is well under this limit. The key is generated by the DXpedition group & it's signature is distributed to them before a DXpedition, similar to the existing SuperFox approach. A key aspect is that the WSJT-X app used by the DX station first generates a random 128 bits to seed a hash chain. It then pre-generates a long sequence of hashes, and the special message reveals later hash chain values first. Given one of the 128-bit hash values, a receiver can generate all forward hashes but cannot generate the reverse ones. Each normal message contains 20 signature bits: a truncated HMAC of the QSO data, timestamp, and hash chain value advanced by one step per 30-second period that's elapsed since the last special message. 2) Receiver-side verification: - Operators receive regular messages + 20-bit signatures, and place them in a buffer - Special messages allow verification of the DXpedition key and a hash chain state - Clients can advance the hash chain to validate regular messages in the buffer - Since the DX station reveals hash chain states earlier and earlier in the sequence, a receiver can still verify buffered regular messages even if they miss the first special message transmitted after the regular message. Any special message will allow verifying all earlier regular messages. In terms of security against pirates: - 224-bit keys resist brute force - A secure hash function (SHA-256, BLAKE3, etc.) prevents reversal of the hash chain - Timestamps & advancing the hash chain once per 30-second period prevent backdating with later-revealed hash chain states, or acceptance of out-of-orderness in the sequence - 20-bit signatures are large enough that a pirate randomly guessing a correct signature is vanishingly small After looking in the literature, it turns out this scheme is nearly identical to the one proposed in [1] -- so we can have some confidence that it's cryptographically sound. -- 73, David, KD0BTO [1] A. Perrig, R. Canetti, J. D. Tygar and Dawn Song, "Efficient authentication and signing of multicast streams over lossy channels," Proceeding 2000 IEEE Symposium on Security and Privacy. S&P 2000, Berkeley, CA, USA, 2000, pp. 56-73, doi: 10.1109/SECPRI.2000.848446. On Wednesday, July 24th, 2024 at 1:11 PM, Joe Taylor via wsjt-devel <wsjt-devel@lists.sourceforge.net> wrote: > > > Understandably, a number of people have asked us about how SuperFox > works. I have explained that we are intentionally moving slowly and > deliberately in our early tests, and we have not published source code > or specifications in part because many details may still change. > > The basic SuperFox scheme has been proven to work well. It delivers the > promised weak-signal gain of around 10 dB over multi-streaming FT8 with > 5 streams. The present scheme will certainly be used for the Jarvis > Island operations next month, but a variety of things could change after > that. > > Our goals for design of a SuperFox mode have included the following: > > 1. Constant envelope waveform, and hence up to 10 dB signal-strength > improvement over multi-streamed FT8. > > 2. Anti-piracy feature: a way to establish legitimacy of signal origin. > > 3. A way to prevent (or make much more difficult) misuse or our > technology by derivative or modified programs, for example enabling > robotic strings of QSOs. > > 4. Better use of available bandwidth: Fox should use (say) at least half > of a ~3 kHz slice. > > 5. Better immunity to QRM, including deliberate QRM. > > 6. Operational aids for the Fox operator, including longer free text > messages. > > As you can see, technical details have been important in our planning > but sociological, moral, and even legal issues are involved as well. > Objective 2 in the above list involves cyber security matters, an area > in which we have little expertise. Our weak-signal performance > requirements demand small message payloads, and these are incompatible > with (for example) most public/private key schemes. > > For nearly all of its 24 year history the WSJT project has been entirely > open source. Ideally we'd like to keep it that way. But objective 3 in > the list is especially difficult (and likely impossible) to achieve in a > fully open source project. > > We appreciate all the help we have received in testing an early SuperFox > scheme. We hope many will work a new one when N5J operates as SuperFox > from Jarvis Island. We'll continue working toward a maxmially effective > SuperFox design in the presence of many challenges, including possible > software licensing issues, and we welcome all constructive input from > other interested hams. As always, our efforts are intended to benefit > the wonderful hobby we share. > > -- 73, Joe, K1JT > > > _______________________________________________ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel _______________________________________________ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
