[Feature Request]: Make disabling encryption and authentication optional in ham mode

[securityguy]

Platform

Cross-Platform

Description

In the USA, FCC regulations (Title 47 Section 97.113) prohibit "messages encoded for the purpose of obscuring their meaning." This is generally interpreted as prohibiting encryption, but the prohibition applies only when encryption is used to obscure the message's meaning. Digitally signing a message or using a symmetric message authentication code does not obscure the meaning of the message and therefore is not prohibited in the USA.

In Canada, the regulations state that hams may only use a code or cipher that is not secret. This clearly also does not apply to the use of cryptography for authentication purposes. In addition, it applies only if the cipher is a secret. For example, if I wish to use AES-256 (a published algorithm) and I publish the key, there is no secret. RAC has had discussions with ISED and developed a simple solution that you can read about here: https://www.rac.ca/encryption/

Please stop attempting to enforce regulations via software intended global use. It is the responsibility of the licensed amateur operator to comply with the law in their jurisdiction.

Disabling encryption in ham mode should be an option.

Disabling cryptographic authentication in ham mode should be an option.

Some amateur operators have a requirement to ensure that their amateur station does not communicate with stations not in the amateur radio service. However, in some situations and in some jurisdictions, doing so may be acceptable. The operator should be allowed to make this decision.

[garthvh]

Everyone in Canada is in lora range of the US and using the US preset.

[securityguy]

Everyone in Canada is in lora range of the US and using the US preset.

That's neither true nor relevant.

The fact that some Canadians are within the range of the USA is not relevant. A person in Canada is obligated to obey Canadian law. A person in the USA is obligated to follow US law. I am familiar with both because I hold licences in both countries.

In Canada, we use the US preset because of what I hope was an accidental oversight. Meshtasic refers to "Region" and, for Europe, correctly identifies the EU. However, there is no entry for Canada, Mexico, or North America, resulting in no preset for where I live.

Just to be clear, this is not a political issue. Canada and the US are separate countries and have different laws. New Meshtastic users in Canada are left wondering what "Region" to select. if the true intent of Meshtastic is to remain international, it is not appropriate to force US law on the rest of the world.

[b8b8]

1. About 80% of Canadians live within 100miles of the USA border which is easily within RF range of Meshtastic.
2. Vancouver and Toronto are def. within RF range.
3. There are CAN/USA agreements in place to not cause "harmful or disruptive" interference to each other close to the border, it would be courteous to follow this.
4. If the encryption key is set to AQ== then all USA non-ham radios will repeat CAN ham traffic (not legal).
5. If the encryption key is set to AQ== then all CAN non-ham radios can repeat CAN ham traffic (not legal).
6. Encrypted vs. unencrypted is a super simple and robust way of differentiating ham traffic from ism traffic.
7. The project is open source, you are free to make your own firmware.
8. The project has said many times before that it errs on the side of caution, in which blocking all encryption in ham mode is.
9. If/when Canada or Mexico make significant changes to their band plan in say both freq. and power allowance, it would make sense to spin off a new and legal CAN915 band. But as of right now Canada follows the US915 band plan, and is subject to its limitations in totality for interoptibility. I am actually in favour of petitioning the CRTC to make a CAN915 band, maybe they'll give us more transmission power and other capabilities.
10. Do you really want Americans to just switch to Canada mode and break the law, thats how the project gets banned from the USA and therefore Canada as it is a USA project with primarily American devs, registered in the states.
11. Most importantly, Meshtastic is not a HAM focused project. The inclusion of ham functionality is a courtesy and they dont need to be catered to. Adding "published" encryption keys adds little to no ham functionality as they are PUBLISHED. You guys got APRS.
12. Authentication (not encryption) is a valid use case for controlling remote ham nodes.

I do not speak for Meshtast.org, these are my own thoughts as a Canadian.

My main argument is not ever letting the standard ISM and HAM network blend.

[securityguy]

It's a feature request and I respect that the developers may not wish to implement it.

If the concern is that someone might break the law, the software doesn't stop a Canadian or American operator from selecting EU_868, just like my car doesn't stop me from speeding. If I choose to use the software as part of a ham station, it's up to me to ensure legal and regulatory compliance.

With respect to items 4 and 5 above, I don't think this is the place to debate radio regulations, but I'm curious where you found the prohibition on a non-ham unlicensed ISM-band station repeating traffic that originated at a ham station. I would think the opposite (ham station retransmitting non-ham traffic) would be the primary concern.

[b8b8]

Maybe that's the case i would have to look for what i read previously, but further to that point the network is still two way for node discovery. You could then get into a scenario where one side sees but cannot communicate with said nodes.