I agree with Bill!  There are NO legitimate or valid reasons for encryption of 
the Amateur Radio frequencies! To do so would HINDER the flow of traffic during 
emergencies because MOST Hams wouldn't have the encryption equipment, nor would 
they have the same encryption codes.

After 20 years in Air Force Communications, coordinating getting encryption 
codes to 500,000 plus hams in just the USA alone would be impossible!  

You ask, WHY would you need to get the encryption codes to all Amateur Radio 
Operators??? Because EVERY HAM is a vital link in our communications system!  
What one ham can' hear, someone else will and will be able to pass on the 
traffic!

WHY encryption CODES?  Because ANYONE can listen in, with the right device, to 
the generic encryption "methods"!  To make the system truly secure you must 
have equipment (that costs $$$$$) that is capable of varying it's encryption 
coding, otherwise you have nothing more than FRS radios with fixed codes that 
anyone can read!

Now, show me a legitimate reason for it and I'll join Bill!

Rod
KC7CJO
Clackamas County Electronic Services, Radio Shop
USAF Retired


Chris Jewell <[EMAIL PROTECTED]> wrote:                                  
expeditionradio writes:
  > > Bill N9DSJ wrote:
  > > Can see no valid reason for encryption on our frequencies. If one 
  > > could provide an single example I would be interested......
  >  
  > Hi Bill,
  > 
  > Hams should certainly have the capability to pass over-the-air
  > encrypted traffic or scrambled speech for emergencies and disaster
  > relief. There are other situations where it would be useful, too. In
  > order to have seamless capability in an emergency, hams should be
  > familiar and proficient with the use of it on a regular basis.
  > 
  > Encryption should not be with the sole intent to obscure the content
  > from other hams, but it should be availble to hams when there is a
  > need to shield sensitive data and information from evil-doers.
  > 
  > Here are a few reasons for hams to use limited encryption in the
  > over-the-air communication:
  > 
  > 1. To shield private data 
  > 2. To shield private telephone numbers 
  > 3. To shield sensitive email addresses
 
 The many administrations which don't permit amateurs to carry third
 party traffic at all (in many cases to protect their national
 government's monopoly position as a provider of secure
 radiocommunication within their borders) seem unlikely to agree to
 revise the International Radio Regulations in a way which would make
 it easier for their hams to conceal that they might be carrying
 third-party traffic.
 
 > 4. To shield system passwords
 
 Logins over potentially-compromised media (including ham radio) should
 use technical means to cryptographically authenticate transmissions,
 but that does not require cryptographic concealment of the content.
 
 If I chose, I could use private-key encryption to ssh into my shell
 account at my ISP, while passing the text of my session in the clear.
 Someone who sniffed my packets would be able to see what I was doing
 during my session at my ISP, but would not be able to masquerade as me
 using the information gleaned from tapping my lines or sniffing my
 packets.
 
 Something similar involving, e.g., exponential key exchange, could be
 used over ham radio.  Multiple-use passwords sent in the clear became
 obsolete for network use more than a decade ago: there is no reason
 why ham radio should adopt content encryption to make up for the
 weaknesses of such obsolete methods of authentication.
 
 > 5. To shield station remote control
 
 Concatenate the command and a timestamp, and use a crytographically
 strong a hash of the combination to prove that the command comes from
 someone authorized to remotely control the station, and to prevent
 replay attacks.  There is no need to cryptographically conceal the
 command itself, only to cryptographically sign it.
 
 Challenge-response single-use passwords are another possible solution,
 still not requiring cryptographic concealment.
 
 > 6. To secure access to stations 
 
 Same answer as number 4 or 5, depending on what exactly is meant by that.
 
 > 7. To control satellites 
 
 The same as number 5.  (ISTR that crypto concealment for control of
 ham satellites is already authorized, but I assert that there is no
 technical need for it: crypto authentication would be sufficient.)
 
 > 8. To shield messages sent by a 3rd party to ham
 
 Same answer as numbers 1-3.
 
 > 9. To protect medical information
 
 Now we *may* be getting somewhere, but I'm still not sure.
 
 It seems to me that, e.g., a hospital could call via ham radio for
 helicopter evacuation of a patient to a regional trauma center,
 providing sufficient information about the case to justify dispatching
 the helicopter, but provide the actual name of the patient to the EMTs
 along with the patient's file and the patient himself when the
 helicopter arrives, rather than by radio.
 
 Is it really necessary to transmit personally-identifiable medical
 information over ham radio in emergencies?
 
 > 10. To protect 3rd party traffic requiring confidentiality
 
 See reply to items 1-3.
 
 > 11. To control repeaters 
 
 See reply to item 5.
 
 > 12. To shield identities of children 
 
 It's not clear to me exactly what that means.
 
 > I'm sure there are more reasons... but that's some of the things I
  > thought of in the few minutes it took to write this.
  > 
  > Bonnie KQ6XA
 
 It may be that I am wrong, that Bonnie is right, and that the world at
 large (not just the FCC) is willing to permit hams to conceal the
 content of our traffic by cryptographir means, but I don't see a lot
 of evidence of that yet.
 
 It also may be that, say, on 2M and above, where F-layer propagation
 is unknown, hams could be permitted the use of crypto without
 disturbing international agreements too much.
 
 -- 
 73 DE KW6H (ex AE6VW), Chris Jewell  [EMAIL PROTECTED]
 
     
                       

       
---------------------------------
Ahhh...imagining that irresistible "new car" smell?
 Check outnew cars at Yahoo! Autos.

Reply via email to