"but there's always a face before me now, somewhere out
beyond the edge of the crowd..." Charles Norstadt, 1972
E-Mail: myjht@kerailya.tunkki.fi
On Mon, 2 Mar 1998, Mike Bilow wrote:
>
>
> Ben Kram wrote in a message to Mike Bilow:
>
> BK> Now we are forbidden to encrypt data - but we can agree on
> BK> protocalls -i.e. ax25 - that we dein not to be encryption,
> BK> because the means for interpreting the packets is open and
> BK> available.
>
> U.S. FCC regulations do not prohibit encryption per se, and this is a common
> misunderstanding. U.S. regulations prohibits only "messages in codes or
> ciphers intended to obscure the meaning thereof" [47 CFR 97.113(a)(4)]. Where
> the message is essentially devoid of content, as in an authentication protocol,
> U.S. regulations have generally been understood to permit encryption.
>
> BK> So - we have an uncomfortable intersection. We agree as
> BK> hams overall, simply not to look at eachother's passwords
> BK> etc. when we log in, but this is not terribly secure.
>
> BK> One alternative is a request systerm, where the
> BK> authentication is done by the server asks you a question
> BK> (i.e the number 234252) and you look up on a chart the
> BK> coordinating word (i.e. FISH) and thus you are authenticated
> BK> and you password is different every time.
>
> BK> I usually use ssh for authentication, but of course I can't
> BK> over ham radio.
>
> SSH authentication is allowable under U.S. regulations, provided that the
> actual data stream is not encrypted. This is accomplished by using the command
> line switch "-c none" to specify the stream encryption method. Some binaries
> of SSH are compiled with this option disabled, since it is considered a
> security risk to leave the "none" encryption method available for selection.
>
> -- Mike, N1BEE
>
>