Re: [wsjt-devel] WSJT-X SuperFox Verification is flawed
On Wed, Jul 24, 2024 at 02:19:51PM +0100, Hibby via wsjt-devel wrote: > Identity and keysigning is a solved problem True. What is required here is a public-key signature scheme. The fox produces a key pair and publishes the public key which is then used by the hounds. The problem is that all public-key signature schemes I know of produce quite long signatures, and you can't truncate them (accepting the reduced security) as you could when using a symmetric key scheme. For example the detached public-key signatures provided by libsodium are 64 bytes, probably way too long for a fox message. So this will require some research, and the first question is how many signature bits could be accomodated in a fox message. Ciao, -- FA ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Licensing Issue of SuperFox Mode
On Fri, Jul 19, 2024 at 03:07:34PM -0400, Joe Taylor via wsjt-devel wrote: > The following text is from "Frequently Asked Questions about the GNU > Licenses", https://www.gnu.org/licenses/gpl-faq.html : > > "[P]ipes, sockets and command-line arguments are communication mechanisms > normally used between two separate programs... [W]hen they are used for > communication, the modules normally are [considered] separate programs." That certainly makes sense if there is a clear separation of functionality or if that functionality is entirely optional, e.g. logging or visualisation. The text you quoted continues: "But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program." In this case the three closed source programs perform what could be considered 'core' functionality: encoding/modulation and demodulation/decoding of the superfox waveform. If that is acceptable, then the whole DSP part of WSJTX could be delegated to some closed source binaries, leaving only the user interface. Would you call such a WSJTX still 'open source' ? If not, then where is the dividing line ? IMHO at least the waveform should be fully documented, allowing others to create their own implementation of the closed source programs. And I wonder what are the legal aspects of using an undocumented waveform on the HAM bands. If the secrecy is there only to protect the fox callsign authentication, then it will be just a matter of time before we'll see another example of why 'security by obscurity' is a bad idea. The amount of data that can be squeezed into a fox message seems to be way too small for any really secure cryptographic scheme. So this will be a very juicy target for anyone who enjoys cracking such things. That includes me :-) At least that would be an 'educational' side of superfox... Just my 2 Eurocents of course. Ciao, -- FA ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Fwd: Enhancement suggestion - 30 second cycles
On Tue, May 09, 2023 at 03:06:34AM +1000, Adrian via wsjt-devel wrote: > On 9/5/23 02:49, Jim Brown via wsjt-devel wrote: > > > #3 is bogus. > > How would you know ? You lack the technical ability.. I'm not an AES fellow, but as another audio 'expert' I can only confirm that #3 is complete bogus. Even if the audio HW is usually the most crappy part of most PCs, it's not that bad that generating signals in the 1.5 to 2.5 kHz range would have less 'digitisation nonlinearities' (whatever that means) than anything outside that range. If there are any nonlinear effects, that would be mostly due to the complete mismatch between a typical PC headphone/line output (a few hundred mV) and a typical rig mic input (expecting maybe a few mV). What you need to avoid that is a passive attenuator (two resistors) between the two, allowing the PC audio output to operate at its normal level while avoiding overload on the mic input. Also relying on the rig's filters to remove any harmonics is just bad practice again. There shouldn't be any harmonic content in the audio to start with. The really hilarious thing about this whole thread is that it is just the result of an implementation detail of WSJT - using audio signals as the interface between a PC and a rig. In these days of SDR hardware, I'd expect a rig to both output and accept digital complex-valued baseband signals. Even the cheapest SDR hardware can provide and handle at leas 1 MHz bandwidth with a near perfect flat frequency response. Just my 0.02 Euro of course. ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] The #$&% Windows 10 audio issue, and a proposal
On Sat, Jan 15, 2022 at 11:17:58PM -0800, Paul Kube via wsjt-devel wrote: > On Fri, Jan 7, 2022 at 1:25 AM Fons Adriaensen via wsjt-devel > > > So does this mean that when a new audio device becomes available > > while a music app is playing some file, the output from that > > app would be redirected to some other device ? > > > > No, rather it seems to be a result of what happens when an audio device in > use becomes unavailable. For example, headphones get unplugged, or an HDMI > monitor goes into sleep mode, etc. Then it kind of makes sense that Windows > would try to find another device that applications can use. Of course, it > does this badly, not always correctly restoring connections when the device > becomes available again. But in this case the audio interface is used to transfer signals to/from the rig, so why should it ever become 'unavailable' during operation ? > Isn't the real issue here that WSJT is opening and closing the audio > > devices again and again for each RX or TX cycle ? > > I don't think so; have you looked at the source code, or traced audio > subsystem calls? :-) I'm not a WSJT dev, so just finding all the right places in the huge code base in order to answer that question with any degree of certainty would probably take a very long time... But surely the devs should know how they are using the audio interface. If they are indeed opening and closing the audio device in each cycle then I'm pretty sure that is the source of the problem. Ciao, -- FA ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] The #$&% Windows 10 audio issue, and a proposal
On Thu, Jan 06, 2022 at 09:48:22PM -0800, Paul Kube via wsjt-devel wrote: > Any change to audio device availability on MS Windows is likely to renumber > the indexes of other devices, when this happens WSJT-X gets no notification > that it has happened. So does this mean that when a new audio device becomes available while a music app is playing some file, the output from that app would be redirected to some other device ? I can't imagine this to be so, such a system would be unusable. Isn't the real issue here that WSJT is opening and closing the audio devices again and again for each RX or TX cycle ? Then the solution is to not do that: open the devices once and keep them open for as long as the programs runs. So don't stop the output stream during RX, just output silence. During TX keep reading the data from the audio input and discard it. -- FA ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] VAC issue
On Tue, Jul 27, 2021 at 06:37:18AM -0400, William Smith wrote: > They use an API called QT5, and AFAICT it's not that easy. Oh dear. That is probably the worst possible choice. Portaudio would come second. On Linux, use ALSA (via a lib such as zita-alsa-pcmi), or use Jack. Do not use PulseAudio. On Windows, use ASIO, bypassing all the system and desktop stuff which will only get in the way. On OSX, use Core Audio. This requires a one-time effort to create a simple wrapper class for each of them. Compared to the rest of WSJT-X, that's a trivial exercise. My job is to develop professional audio software, so I know what I'm talking about. Things like the QT API are for toys, not for anything serious. -- FA ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] VAC issue
On Tue, Jul 27, 2021 at 09:53:11AM +0100, Bill Somerville via wsjt-devel wrote: > WSJT-X saves audio device names in its settings file but to access the > devices we look them up and get an index number which we must use to > interact with them. These index numbers are somewhat volatile and can change > while WSJT-X is running if other audio devices on the system appear or > disappear. It is too costly to look up the audio device index every time we > need to start a transmission, e.g. on some platforms it takes several > seconds to complete enumeration of the audio devices, so we are vulnerable > to the devices that the index numbers reference changing without our > knowledge. So does that mean that WSJT-X opens and closes the audio device each time ? That is not a sane way to use any audio device. Just open it once when the program starts and keep it open, and output silence when not transmitting. Same for RX of course. Anyway the audio device should not be the one used by the OS or desktop for anything else, so there won't be any conflicts. -- FA ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
