RTTY
[Top] [All Lists]

Re: [RTTY] About encryption: an example

To: Dave Greig <daven3buo@att.net>
Subject: Re: [RTTY] About encryption: an example
From: "aflowers@frontiernet.net" <aflowers@frontiernet.net>
Reply-to: "aflowers@frontiernet.net" <aflowers@frontiernet.net>
Date: Tue, 18 Mar 2014 09:32:52 -0700 (PDT)
List-post: <rtty@contesting.com">mailto:rtty@contesting.com>
Dave and the Group;
 
Apologies if this goes far afield for the RTTY discussion, but I'm just trying 
to provide some background data that is helpful when looking at the "big 
picture" around RM-11708.
 
To be clear, RM-11699 (the "encryption petition") was filed by Don Rolph, not 
the ARRL. You can read the ARRL's response in the comments.  They basically 
said as much about HIPAA, but I suggest you all read it as I think it avoids 
some serious questions about the relationship between "emergency 
communications" and amateur radio.  The FCC decicion is helpful as it is a 
datapoint on their thinking within the last year.
 
The ARRL's comments are also worth reading because it does give you at least a 
picture of how they chose to address the issue. You might see what values were 
important to them:
 
http://apps.fcc.gov/ecfs/comment_search/execute?proceeding=RM-11699
 
Footnotes 11 and 12 concern me.  It seems to me that the need for privacy is 
something that is served by other services and in fact is a helpful distinction 
as to whether or not Amateur Radio is an appropriate service for such 
communication, and not necessarily something that should be accomidated because 
amateur radio is the kitchen sink.  It seems to me that at least some are happy 
to let the tail wag the dog, but perhaps I'm reading too much into it.  You can 
decide.  
 
The bottom of page 8 addresses "unspecified codes" in relation to this--also 
that the pupose of specified codes.  Here's a lengthy section, but again, I 
encourge you to read the whole thing:
 "The ability to monitor ongoing Amateur communications, to determine, if for 
no other purpose, whether or not the ongoing communications are between or 
among licensed radio amateurs, is of value. It is for this reason that the 
Commission requires that, where unspecified digital codes are used by radio 
amateurs, the characteristics of digital emissions should be published and 
therefore available to radio Amateurs generally. 
See, 47 C.F.R. § 97.309(b) and the discussion infra."
 
So the idea behind the "specified codes", according to the League, was to make 
sure that amateurs could monitor communications and make sure they are of 
value--hence the publication requirement.  The cite some of the ITU wording in 
support of this, so they are on pretty firm ground.  Forget the hair splitting 
over whether this or that modem fulfils the letter of the law as that is not 
going to be helpful.  Look at the intent.
 
Here's the FCC's ruling for completeness:
 
http://apps.fcc.gov/ecfs/document/view?id=7520944376
 
Item III.6 is pretty important in my view.
 
I'll also note that the FCC dismissed this petition without predjudice, which 
as I understand it, means it can be brought up again should someone make a 
better case.  Rest assured lots of people are trying to do that.
 
Andy K0SM/2
 
 
 



On Tuesday, March 18, 2014 10:51 AM, Dave Greig <daven3buo@att.net> wrote:
  
http://apps.fcc.gov/ecfs/comment_search/execute?proceeding=RM-11699

This information on this link is incorrect. HIPAA only talks about specific 
patient names and the correlation of that data to sickness or injury.  Body 
count, how many injured, how many people have an illness can be transmitted in 
the open un-encrypted.  
As for The HIPAA, the law is all about interpretation. The short paragraph out 
of the 950 or so pages of the HIPAA act, that talks about encryption say that 
data must be encrypted. Does matter if it is 1 bit encryption or 256M 
encryption.  

Sorry for the subject change.  It just shows how UNINFORMED our law makers and 
ARRL are. 


Thank You!
Dave Greig N3BUO 
801 Tactical
Phone: (682) 422-6667 
http://www.801tactical.com/

Google Plus: gplus.to/801Tactical

Facebook: https://www.facebook.com/801Tactical
Twitter: @801tactical  


On Tue, Mar 18, 2014 at 8:28 AM, aflowers@frontiernet.net 
<aflowers@frontiernet.net> wrote:


>
>Hi Friends,
>
>The talk about encryption is an interesting issue and in fact came up last 
>year in a petition to the FCC.  You can read that and the comments to get an 
>idea about what the motivation is and the issues involved:
>
>http://apps.fcc.gov/ecfs/comment_search/execute?proceeding=RM-11699
>
>It's very helpful to understand who wants this and ostensibly why.  Not 
>necessarily all bad, but I would ask the question whether this is a 
>bridge-to-far for amateur radio.  The FCC seems to think so and you can see 
>their reasoning.  For those of you concerned about winlink and why encryption 
>is "necessary" I suggest you look up some of the more prominent names in that 
>organization and look at their comments.  Here's a starter:
>http://apps.fcc.gov/ecfs/document/view?id=7520927665
>
>But I'm not really all that interested in winlink per se, but rather the 
>philosophy driving some of the decisions you are now seeing, and that's not 
>why I'm writing.
>
>All this email is intended to do is to show you a concrete example of 
>encryption being sold to hams *today*, lest anyone think this is simply an 
>existential discussion.
>
>SCSmail is a personal email program that is freeware to go with your pactor 
>modem.  The product is designed for low-cost personal email service 
>independent of any networks. In other words, this is so you can use ham radio 
>for your own private email server:
>
>"It is not the intention of SCSmail to replace or to interfere with existing 
>professional HF email providers with their highly sophisticated solutions and 
>services. Its purpose is just to give private users and small organizations 
>the chance to quickly install an own, private email service without additional 
>costs and without the need to subscribe to an existing provider and thus being 
>dependent from an external service."
>
>http://www.scs-ptc.com/downloads/scs-mail
>
>Its about low cost email service with privacy.  Not a bad thing in itself.  I 
>like free stuff too....but *why* is ham radio a market for this?  That's a 
>serious question.
>
>If you look at the SCSmail 2.0.1.4 manual it clearly explains that there is 
>session encryption key unique to each pactor connection.  The download shows 
>the OpenSSL license in the bundle so I can assure you that its using 
>Public/Private key pairs to exchange a key just like you do when you manage 
>your bank account over HTTPS on the internet.  This is not just encrypting 
>login information (authentication purposes have special exceptions, at least 
>in the US and most other countries and for good reason), but encryption of 
>everything including the content of the messages themselves.  The manual makes 
>this clear.
>
>Of course, you don't have to use encryption, and to SCS's credit they point 
>out that you need to follow the rules of whatever service you have.  
>Nonetheless you have someone specifically marketing a product to the amateur 
>service for private email communication that has encryption as a key feature.  
>Lets not pretend there isn't an interest in this as can be seen from the 
>discussion of RM-11699....is it being used on amateur radio bands right now?  
>Better questions:  (1) Is it important for you to know and (2) How would you 
>know?
>
>Oh, and encryption is on by default when you run the program.
>
>Its there, its ready, and its already wrapped in an unpublished code by any 
>reasonable interpretation.  Like I said, this is for information only and it 
>may be helpful in understanding some of the broader issues and drawing your 
>own conclusions.
>
>Andy K0SM/2
>_______________________________________________
>RTTY mailing list
>RTTY@contesting.com
>http://lists.contesting.com/mailman/listinfo/rtty
>
_______________________________________________
RTTY mailing list
RTTY@contesting.com
http://lists.contesting.com/mailman/listinfo/rtty

<Prev in Thread] Current Thread [Next in Thread>