Live data from Hacker News

Show HN: A new protocol for packet radio including ECDSA and compression

github.com

51–60 of 94 posts

Re: Show HN: A new protocol for packet radio including ECDSA and compression

#51
post #13

Earlier quoted context omitted.

There are more hams in the US, and more active hams, than ever before. That's a funny sort of dying! Joe Taylor's work on below-the-noise signal extraction has revitalized shortwave: https://physics.princeton.edu/pulsar/k1jt/wsjtx.html , particularly at the nadir of the sunspot cycle. That's a funny sort of dying! Amateur satellites are accessible for $100 in parts: https://www.n2yo.com/satellites/?c=18 ; with the sa…

I've actually seen my young amateur radio communities die off during this new solar minimum, and a lot of my friends sold their expensive equipment. You really need money and space right now unless you want to sit at your desk and do some of the new low SNR "can talk to the mars rover with a wet sock as an antenna" modes that a lot of people don't like because it's too easy and poses no challenge. There's also VHF/UH…

You should be able to talk to anyone in the USA with 100W and a wire antenna.

I think the bigger issue is noise in urban areas. The FCC does a shit job of regulating noisy equipment. I had to go through my house and dispose of certain Ethernet switches, an audio device, notebook power supply, etc.

Re: Show HN: A new protocol for packet radio including ECDSA and compression

#52
An AX.25 packet radio chat protocol with support for digital signatures and binary compression. Like IRC over radio waves

I just wanted to say thank you for such a concise, clear summary. So many projects get posted with cryptic descriptions full of insider terms.

Re: Show HN: A new protocol for packet radio including ECDSA and compression

#53
post #23
post #2

Cool project! I have always been interested in the amateur radio scene. So encrypting amateur radio comms is illegal in the US? Is there a particular reason for this?

This one is not encrypted. Its plaintext or compressed (gzip I think). Crypto is only for digital signatures.

What if you used a nonstandard proprietary compression algorithm? Does non-encrypted have to mean “widely documented/implemented compression”?

Re: Show HN: A new protocol for packet radio including ECDSA and compression

#54
post #11
post #9

Earlier quoted context omitted.

The amateur public radio bands are supposed to be open and useful to everyone so the broadcasts in those spectra are supposed to be readable by everyone as part of the accessible part. On top of that encrypted transmissions would be basically noise pumped into the system making the open uses more difficult and harder to police.

what about steganography?

someone has to figure out there's a hidden message first. much like using a 'non-type-accepted' radio. on the internet no one knows you're a dog.

Re: Show HN: A new protocol for packet radio including ECDSA and compression

#55
post #9

Earlier quoted context omitted.

The amateur public radio bands are supposed to be open and useful to everyone so the broadcasts in those spectra are supposed to be readable by everyone as part of the accessible part. On top of that encrypted transmissions would be basically noise pumped into the system making the open uses more difficult and harder to police.

> The amateur public radio bands are supposed to be open and useful to everyone so the broadcasts in those spectra are supposed to be readable by everyone as part of the accessible part. Except that proprietary voice codices are allowed :(

This is a dead horse but it isn't encryption.

Re: Show HN: A new protocol for packet radio including ECDSA and compression

#56
post #28

Maybe messages should include a coarse timestamp to prevent replay of old messages by some adversary. Someone could resend a month old "yes" with your valid signature to a question someone asks now. Also it might be beneficial to include sequence numbers or message IDs and for example echo the last 4 ids in following messages so recipients can detect holes. - The chat could insert some placeholder to notify recipient…

This is a really great idea. Might be a good github issue to open?

Re: Show HN: A new protocol for packet radio including ECDSA and compression

#57
post #44

Does this do any sort of FEC? One of the things that makes stuff like this tricky(and APRS in general) is that one flipped bit throws off the whole decode. From what I've seen out there would be a 40% improvement[1] in just base APRS if there was some form of basic FEC built into the protocol. Sadly most of "state of the art" is stuck back in the 80s. [1] http://eludium.stensat.org/mcguire/projects/FX-25/FX-25_perf..…

AX.25 has no FEC but there is FX.25 which is an encapsulation of the AX.25 packet with a preamble at the front and reed soloman at the end. But the issue is the speed of AX.25, 1200baud is dreadfully slow to be adding much onto the packet. The FX.25 protocol is a neat idea that allows for old TNC hardware to still be on the air. However, TNCs can be built with the cheapest of the raspberry pi clones so there really i…

The stagnation of packet radio is due to FCC legal restrictions on data rate that are divorced from the reality of bandwidth usage in modern protocols.

You need to get to UHF before doing anything reasonable (if you call 56k reasonable) and by then, your range is toast unless your friend is on top of a mountain.

Re: Show HN: A new protocol for packet radio including ECDSA and compression

#58

Does this do any sort of FEC? One of the things that makes stuff like this tricky(and APRS in general) is that one flipped bit throws off the whole decode. From what I've seen out there would be a 40% improvement[1] in just base APRS if there was some form of basic FEC built into the protocol. Sadly most of "state of the art" is stuck back in the 80s. [1] http://eludium.stensat.org/mcguire/projects/FX-25/FX-25_perf..…

FEC is forward error correction. https://en.m.wikipedia.org/wiki/Forward_error_correction

Re: Show HN: A new protocol for packet radio including ECDSA and compression

#59
post #11
post #9

Earlier quoted context omitted.

The amateur public radio bands are supposed to be open and useful to everyone so the broadcasts in those spectra are supposed to be readable by everyone as part of the accessible part. On top of that encrypted transmissions would be basically noise pumped into the system making the open uses more difficult and harder to police.

what about steganography?

See: Direct Sequence Spread Spectrum. It is possible to communicate below the perceived noise floor of a narrowband signal using much more bandwidth than is actually required for the transmission and intended channel conditions. You can basically encode your data across a much wider range of code points which directly modulate the broadband signal. This generates in RF terms what any unawares outside observer would describe as "broadband noise". E.g. WiFi communicates in 20MHz channels, a DSSS solution could use 100-1000 MHz channels (albeit at a MUCH lower baud). Most use/scanning/jamming/licensing of the airwaves is done in a narrowband context, so this is a sort of strategic way to get around these constraints.

If done properly and using a sequence that only you understand, it is possible to become completely invisible to interception for most practical situations. Someone with RF monitoring equipment could determine the source of broadband emissions, but without actually investigating the design of the physical transmitter they wouldn't ever know conclusively what is happening. This is why the FCC requires you publish the algorithm of the PRNG which modulates the data into the final DSSS signal. If you never do this and take decent measures to ensure your sequence appears as pure noise (simply encrypting your payload would do this), there is little anyone could hope to do to discover your presence if they were listening in the middle.

Re: Show HN: A new protocol for packet radio including ECDSA and compression

#60
post #28

Maybe messages should include a coarse timestamp to prevent replay of old messages by some adversary. Someone could resend a month old "yes" with your valid signature to a question someone asks now. Also it might be beneficial to include sequence numbers or message IDs and for example echo the last 4 ids in following messages so recipients can detect holes. - The chat could insert some placeholder to notify recipient…

A rolling code might be another similar solution to the counter.
Post reply on HN