FCC Regulation 97.113 (a) 4 states that:

"messages encoded for the purpose of obscuring their meaning"

Are "Prohibited transmissions", I believe this is the clause that is used to prohibit encryption over ham radios. Are there any other clauses that are used to prohibit encryption.

If not, is "signing" of messages acceptable/legal over ham radios. For example consider the following transmission:

A digitally transmitted message contains:

  1. The callsign of the sender.
  2. The callsign of the intended recipient
  3. The public key of the sender
  4. The entire body of the message in plain text.
  5. A checksum/signature generated from the private key of the sender and the body of the message.

In this case no encrypted information is sent. Additionally any receiver of the message can verify both the integrity of the message (by validating the signature) and that no additional information has been sent, since the entire signature is used as part of the validation process.

Note: I realize that sending the public key is superfluous, but I didn’t want to get into the details of key exchange protocols as part of this question.

Edit: 3/10/19

Thank you all, for the high quality responses.

As pointed out by others in the comments, I had three concerns:

  1. That it would be possible to authenticate the generation of the message (this system cannot detect the retransmission of the message in full).
  2. That a third party can verify the message contains no encrypted information.
  3. That in the US, the only applicable regulation was 97.113 (a) 4

I had read another article specifically on CRAM-MD5 over amateur radio, however my concern was that any system that uses a shared secret, will require the secret in order to prove that no encrypted information is present (if you don’t know the secret, the checksum might be an encrypted string).

This was the reason I based the question on public/private key crypto and why I included the public key in the transmission - I realize that any receiver that wishes to authenticate the transmission needs to obtain the public key via a secure channel.

However with the message formatted as it is, any receiver that knows the protocol, can verify that the message contains no encrypted data.

I feel all these concerns have been addressed and I have accepted the answer.

  • $\begingroup$ I think the wording is explicit enough. No obscured messages. There's no obscured messages in your question. What is your question, then? Also: closely enough related to: ham.stackexchange.com/questions/5259/… and the answer explicitly answers your question. $\endgroup$ Mar 10 '19 at 9:41
  • $\begingroup$ @MarcusMüller We should distinguish a question regarding hashes from cryptographic signatures as there are nuances with regard to the latter. $\endgroup$
    – Glenn W9IQ
    Mar 10 '19 at 12:21
  • $\begingroup$ @GlennW9IQ a "hash for authentication" (the other question) is a cryptographic signature, far as I can tell? $\endgroup$ Mar 10 '19 at 12:28
  • 3
    $\begingroup$ @MarcusMüller The author of the linked question wanted to use md5 for authentication. This is cryptographically weak as it only facilitates integrity. This question asks specifically about using asymmetric keys for signing of a digest. No doubt the two questions are related, but they are not duplicates from my perspective. $\endgroup$
    – Glenn W9IQ
    Mar 10 '19 at 12:40
  • 1
    $\begingroup$ Ah, you're right, the asymmetry makes the difference here (I consider the MD5 from the title of the other question to be just a bad example) for me. That's an interesting point! $\endgroup$ Mar 10 '19 at 12:46

Even though signing of a digest uses cryptographic techniques, this is permitted.

The Part 97 regulations regarding obscuring clearly speaks of purpose/intent. The regulation you quoted is the only one that applies to this topic for amateur radio. The FCC has previously commented that encryption is prohibited under this regulation even if the algorithm is well published.

A signed digest is not intended, nor is its purpose, to obscure, rather it is used for authentication, integrity and non-repudiation. It would be wise to publically publish the protocol in order to avoid any misunderstandings. In order to minimize potential legal issues, I recommend that you make certain the digest only uses information derived from the clear text (no new or hidden information, no salting, etc.) and its derivation and the signing technique be based on a publicly available method or standard (e.g. SHA or DSA). Similarly, the public keys should be publicly obtainable from a recognized CA (certificate authority).

Be aware that other countries may not permit this technique so it may not see world wide adaption or use.

While I believe your comment regarding the sending of the public key was simply to clarify your question, in practice this is cryptographically weak and should be avoided.

  • $\begingroup$ The "check" item in an ARRL datagram provides an elementary, published version of this function: a count of the number of words in the message. Inasmuch as it doesn't account for common errors such as misspelling or transposition of numbers, a more sophisticated check would be helpful. I suspect this could be easily implemented on a modern handheld, laptop or desktop computer. $\endgroup$
    – Brian K1LI
    Mar 10 '19 at 15:40
  • $\begingroup$ @BrianK1LI The ARRL check functions as a weak form of integrity but it lacks authentication and non-repudiation. $\endgroup$
    – Glenn W9IQ
    Mar 10 '19 at 17:02
  • $\begingroup$ I don't see how salting should be an issue. Salts are typically included in the message and aren't secret. $\endgroup$
    – Chris_F
    Jan 3 at 21:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.