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