[HCARC] Fwd: [CTDXCC] How Winlink effectively encrypts- in their own words .....

[w4wj at aol.com]

More information from Ted, N9NB regardingWinlink encryption in the amateur service.

73DonW4WJ

From: ctdxcc at lists.kkn.net
Reply-to: tsrwvcomm at aol.com
To: ctdxcc at lists.kkn.net
Sent: 7/18/2019 2:05:38 PM Central Standard Time
Subject: [CTDXCC] How Winlink effectively encrypts- in their own words .....

The use of ARQ and Proprietary compression and FEC together make it virtually impossible for hams to intercept the over the air signals for meaning.

This is a violation of Part 97.113(a)4 and enables many more violations, Including illegal 3rd party messages from "non-hams to hams" and vice versa.

This is not about Pactor 4, it's about *any* mode that cannot be intercepted for meaning.


AMBE and Fusion are easily decoded using an available chip, Winlink data modes cannot be intercepted for meaning over the air. Period.

Even given what they have published and claim is documented.

Read this to learn more, and see how even if a compression scheme is fully publicly known, the use of ARQ with FEC and compression provides an illegal "security by obscurity".

It's like knowing how a "zip file" works is public, but missing just one bit makes it impossible to open the zip file for a 3rd party observer, while the lone secret recipient has the knowledge of that one missing bit, and recovers the secret file.

That's how Winlink data transmissions work in ham radio.  See this confession, and let all of Hamdom and ARRL board members know about this.

Here's the entire email thread of Winlink programmers and users discussing "getting around FCC rules," and how hard it is to decode for meaning ARQ with compression, minus the re-quoted messages. 

 

See how Winlink ARSFI board member Tom Whiteside wants to change the topic and End the Thread! 

 

Is this what we want for ham radio? Is this an open use of the spectrum? Let your ARRL board members and the FCC ECFS today know that you support RM-11831 and the requiment of only open, transparent data for over the air copy, and urge rejection of WT 16-239.




“Security by obscurity”  is mentioned here. These are emails from yahoo groups in 2016. Spread rhe word--hams need to see this confession and inform ARRL board members and the FCC about such this activity in ham radio.

 

73, ted N9NB 



 

| 
Subject: 
 | 
[Winlink_Programs_Group] Digest Number 2817
 |
| 
Date: 
 | 
5 Sep 2016 02:29:46 -0000
 |
| 
From: 
 | 
Winlink_Programs_Group at yahoogroups.com
 |
| 
Reply-To: 
 | 
No Reply <notify-dg-Winlink_Programs_Group at yahoogroups.com>
 |
| 
To: 
 | 
Winlink_Programs_Group at yahoogroups.com
 |







3 

Monitoring WINMOR traffic?


Sun Sep 4, 2016 11:31 am (PDT) . Posted by: 

steve_k6eta


Is there a way to directly monitor/decode WINMOR traffic heard on the air? Can a terminal or chat program connect to 127.0.0.1 port 8500 on a machine running an instance of the WINMOR TNC similar to the ARDOP Chat situation? 

Thanks, 
Steve K6ETA 

2a 

Re: Monitoring WINMOR traffic?


Tue Sep 6, 2016 9:56 am (PDT) . Posted by: 

steve_k6eta


I hear crickets chirping... heh. 

I would presume we get around the §97.113 (4) edict that prohibits "messages encoded for the purpose of obscuring their meaning" by allowing a sysop to monitor his/her relayed traffic? 

It would be nice to provide a way to allow the larger amateur community to decode and monitor WINMOR transmissions. I imagine this opens up a can of worms with PACTOR, but at least anyone who wants to spend big $$$ on a PACTOR modem should be able to monitor?? 

Aside from wishing to monitor other WINMOR traffic to better understand propagation and QTH of stations, it would also be nice to assure that the system isn't being used for prohibited transmissions (information for pecuniary interest, re-transmission of programs, etc.) 

I suppose it could be argued that §97.219 (b) covers the potential abuses and lays all of the enforcement responsibilities on the shoulders of the sysop. If would be nice, however, if other stations could help in this regard by providing a way for wider monitoring... just a thought.


Reply to sender . Reply to group . Reply via Web Post . All Messages (5) . Top ^




2b 

Re: Monitoring WINMOR traffic?


Tue Sep 6, 2016 11:24 am (PDT) . Posted by: 

"Hal" hal_merritt


97.113 (4) does not apply since there is nothing being encoded for the 
purpose of obscuring meaning. The encoding is for the purposes of speed and 
accuracy. And possibly for testing purposes.

The ways to monitor PACTOR traffic involve licensed technology. If you want 
to use the technology, then you must pay for it. Nothing illegal there. 
Anyone who wants to monitor WINMOR / ARDOP is free to write the software. 
The waveform specs are published. That said, *I think* that the terms of 
the WINMOR license prohibit commercial use, so no one can build and sell a 
decoding device/software. They would have to give it away or at least share 
the proceeds. I think.

SYSOPs can monitor all the traffic if they wish, and many do.

hal kd5hw

2c 

Re: Monitoring WINMOR traffic?


Tue Sep 6, 2016 1:30 pm (PDT) . Posted by: 

la7um


As I see it, this is based on the principle of F6FBB which was used in packet radio BBSs from the 80/90ies. Compression for the sake of speed and accuracy, protocoll published, and sysops could read all. 
73 de LA7UM Finn

2d 

Re: Monitoring WINMOR traffic?


Tue Sep 6, 2016 6:51 pm (PDT) . Posted by: 

"Matthew Pitts" daywalker_blade_2004


Finn,

Yes, F6FBB was involved with the development, but you can't get certain folks in the US outside of Winlink to understand that the data compression used by Winlink is the same as what's used by pretty much every packet BBS out there because they do not want to believe anything of the sort. Just like they refuse to accept that a majority of whatever interference they experience is simply a matter of the infamous "hidden transmitter effect" where one side of a QSO can be heard and triggers the busy channel detection, but when the other station transmits, the ACDS station thinks the channel is clear and transmits in reply to a connect request.

Matthew Pitts
N8OHU

1a 

Re: Monitoring WINMOR traffic?


Wed Sep 7, 2016 2:49 am (PDT) . Posted by: 

daveskolnick



---In Winlink_Programs_Group at yahoogroups.com, <k6eta at ...> wrote : 

> I would presume we get around the §97.113 (4) edict that prohibits "messages 
> encoded for the purpose of obscuring their meaning" by allowing a sysop to 
> monitor his/her relayed traffic? 

It doesn't apply so we aren't getting around anything. 

> It would be nice to provide a way to allow the larger amateur community to 
> decode and monitor WINMOR transmissions. 

Other commenters have missed an important point. The protocol retransmits packets not received by the intended receiver. There is no guarantee that a monitor will get all the packets. That makes reassembly of the entire message problematic. A monitor can get most of the message but may well not get all of it. This is the case with any ARQ protocol including PACTOR and packet. 

73 es sail fast de dave KO4MI 
S/V Auspicious 



1b 

Re: Monitoring WINMOR traffic?


Wed Sep 7, 2016 5:11 am (PDT) . Posted by: 

"Christopher Story" radionerds


All,

I've kinda held back on this one as I'm new to the forum, but I think I can
contribute here..

I've written many parsers for networking and application protocols for
capture applications like wireshark. In a few cases there were lots of
pushback on doing so because it was felt that the complexity of the
protocol, sequences, structure and compression contributed to its security
(security by obscurity) even though it was fully documented.

What we have are people who want to "see all" without having to do a
protocol analysis. They want someone else to do the heavy lifting and make
it easy.

Part 97 says nothing about easy, just that the meaning isn't intentionally
being encrypted.

Additionally it also doesn't say that it needs to be "readable" by all
hams, really that it just needs to be readable by the fcc. If the fcc
wanted to monitor winmor they can do so, it's documented

Chris
K6RWJ

1c 

Re: Monitoring WINMOR traffic?


Wed Sep 7, 2016 8:51 am (PDT) . Posted by: 

"W6IDS" w6ids2003


AHHH! Some fresh air. . . . .. thank you Sir.

Howard W6IDS
Richmond, IN

2 

Re: Monitoring WINMOR traffic? END OF THREAD please


Wed Sep 7, 2016 5:30 am (PDT) . Posted by: 

"Tom Whiteside" n5tw


Thanks for the comments on this but let’s move on to other topics. END OF THREAD.

Tom N5TW

2a 

Re: Monitoring WINMOR traffic?


Sat Sep 10, 2016 10:23 pm (PDT) . Posted by: 

steve_k6eta


Thanks and understood. 

OK, so if we read Part 97 to mean that the FCC, not all hams and SWL stations, should be able to monitor the traffic, I can see how the burden is lifted for encoding software (binary, PACTOR, WINMOR, etc) to provide a general means for monitoring. It's published and the FCC could monitor if they wish. I agree with this logic. 

So then my request becomes something more like, "gee, it sure would be nice to have someone write software that could be used to monitor such traffic..." and again, I agree that is simply a request thrown out there. 

But what I hope is obvious is that this isn't just a personal request for the convenience of just a one or a few stations. Hopefully everyone can see how this would benefit the quality and security of our allocated band spectra in an era where the FCC is scaling back on enforcement? 

Thanks everyone, 
Steve K6ETA






1a 

Re: Monitoring WINMOR traffic? 

Sun Sep 11, 2016 1:14 am (PDT) . Posted by: 

"Rick Muething" kn6kb


Steve (K6ETA),

The problem of monitoring ARQ transmissions is a technical one...not 
just software. If two stations are connected in an ARQ session 
forwarding messages each has the ability to request a repeat of a data 
frame (through the ARQ mechanism) until it gets a proper frame decode. 
This is the basic mechanism that all ARQ systems (and BBSs that use ARQ) 
work. It applies to Pactor, WINMOR, the new ARDOP in development etc.

Also Winlink and other BBS systems often use binary encoded compression. 
This takes a simple text message (or attached text or other file) and 
compressed it (something like ZIP) for transmission. This can save 
typically 50% on text messages and more (or less) on other file types. 
But if just one byte of the compressed message is not received correctly 
it is impossible (well at least VERY difficult) to decompress the 
message and get the original text or compressed files. A station 
monitoring such a transmission would have to receive EVERY ARQ frame 
perfectly without being able to request a repeat from the sending 
station. (ARQ occurs only between the TWO connected 
stations...monitoring stations can't request a repeat)

So while it is technically feasible to monitor and decode (there is no 
encryption of the message ...that is illegal on ham frequencies) it is 
extremely difficult to recover a message completely by just monitoring. 
With a lot of work and fancy software it might be possible to recover 
parts of a message that is compressed but that is not very practical and 
would require some tricky software (decompression with missing data) to 
get anything.

Hope this clears things up a bit.

73,
Rick Muething, KN6KB Winlink developer and author of WINMOR and ARDOP

 

3a 

Re: Monitoring WINMOR traffic?


Fri Oct 21, 2016 3:19 pm (PDT) . Posted by: 

steve_k6eta


Hi Rick, 

Understood. As with any monitoring process, some info will certainly be lost due to condx. I wasn't hoping to reconstruct partially rx'd frames, just the ability to decode fully copied ones... 

Again, many thanks for your development efforts - I'm enjoying ARDOP Chat and can't wait to see ARDOP released on Winlink Express! My RMS will finally be 100% low-power once I can get rid of the Windows hogs! Even the Windows tablet I have for WINMOR (everything else is RPi) is a drag on my solar powered batteries... 

ARDOP is a godsend! 

-Steve K6ETA


 

3b 

Re: Monitoring WINMOR traffic?


Fri Oct 21, 2016 3:54 pm (PDT) . Posted by: 

"Christopher Story" radionerds


Rick is quite right regarding the difficulty is assembling error correcting
transmissions.. about 20 years ago i wrote a "man in the middle" monitoring
application for a proprietary data transfer protocol.

It was difficult to say the least and we were using perfect capture files,
where data fidelity is 100% from the monitoring applications perspective.

With an over the air protocol you have that plus transmission path issues.

I shutter thinking about re-assembling that.

Someone would need to open their checkbook with at least a 50% deposit to
start..

Chris STORY
K6RWJ

3c 

Re: Monitoring WINMOR traffic?


Fri Oct 21, 2016 6:50 pm (PDT) . Posted by: 

"Matthew Pitts" daywalker_blade_2004


Plus, with an ARQ protocol, you have to know or be able to figure out the actual data rate including any FEC, and operating bandwidth, on the fly while trying to decode it. Even having every aspect of it published it's not going to be an easy task.
Matthew PittsN8OHUCo-developer of ARDOP






_______________________________________________
CTDXCC mailing list
CTDXCC at lists.kkn.net
https://lists.kkn.net/mailman/listinfo/ctdxcc