A few days ago, Ted Ashton asked:

> I got to wondering: Are you going to put anything like SSL into QCTerm?

If we use the standard means of encryption in QCTerm, we don't have much 
control over either the situation or the timeframe. While we were at HPWorld, 
the IETF-Telnet group mailed out about 20 new RFCs regarding telnet 
security/encryption. In total, the complete stack of paper is about 400 pages 
and I haven't begun to do anything more than skim read it. However, the 
proposed telnet standards are essentially the same as being used on the web 
now.

The downside of this is: at the moment there are no encryption standards for 
telnet, thus to my knowledge, no one is encrypting telnet in a "standard" 
manner. Worse, I expect that it will be several years before the proposed 
standards are implemented, both on the client/terminal side and the host 
HP3000 side (only doing it one side or the other doesn't get you anywhere). 
Even worse yet, of course, is that no terminal emulator (Reflection, KEA, 
QCTerm, etc.) presently encrypts any of the data that flows back and forth to 
a remote host.

Ordinarily, this is exactly the kind of situation where we would just plow 
ahead and do something on our own -- if it weren't the for the fact that 
encryption has to be done at each end of the wire simultaneously if it is to 
be of any value. In this case, there may actually be a way to put encryption 
into QCTerm fairly quickly and not rely on any other party.

First, there are a couple of questions that I would truly appreciate opinions 
on. They all deal with what level of security do you feel is necessary: Is 
the security level required necessary that it be (i) merely capable of 
confusing the fairly intense college hacker for a period of weeks, or (ii) is 
the intent foiling the National Security Agency?

Secondly, should the encryption extend to only very sensitive items, such as 
passwords, or should all transmitted material between the HP3000 and QCTerm 
be encrypted? Any form of encryption is going to slow the data transfer down. 
Recognizing that, it would be possible to apply encryption asymmetrically, so 
that keyboarded material, typed by a user, is transmitted in the clear 
(excluding passwords, of course), but so that all text returned by the HP3000 
(which is the massive side of the transmission) is encrypted.

Because of the way that both telnet and most encryption algorithms work, I 
would vote for either the first choice (only passwords) or the third 
(passwords & HP3000 generated text encrypted). Besides adding a very slight 
increase in transmission times, transmitting just one encrypted character at 
a time doesn't get you very much. One letter-at-a-time would going to allow a 
nefarious observer very rapidly to decode the nature of the typist's 
commands, so it might as well not even be encrypted. A block of text needs to 
be transmitted, all at a time, if encryption is to work, thus only block mode 
transmissions would be of much value encrypted.

While most encryption algorithms nowadays work through the use of polynomial 
factoring, simple substitution routines still are tough to break -- even if 
you know the actual encryption routine. And that's essentially what I'm 
proposing. 

The following routine is written in VB3. It is a quick and dirty routine that 
takes a string of any length, XOR's each byte with a keytext string supplied 
by you, and, just to add a little more confusion, alternates an offset value, 
also supplied by you, on every other byte. Passing a string through the 
routine once encrypts it; passing it through a second time decrypts it. The 
routine is actually fairly good -- and it's quick.

=============================================

Function EncryptDecrypt (ByVal InputData As String) As String
  Dim KeyText  As String
  Dim KeyOffset As Long
  Dim ByteKey As String
  Dim TempData As String
  Dim n As Integer
  Dim Key As String
  KeyText = "MPEForeverOrSomeSuchSlogan"
  Rem ***********************************
  Rem   The offset is optional. If used,
  Rem   it should be kept smaller than
  Rem   the lowest ASCII value used in
  Rem   the KeyText string above.
  Rem ***********************************
  KeyOffset = 38
  Rem ***********************************
  Rem   Build a sufficiently long key
  Rem   text string
  Rem ***********************************
  For n = 1 To ((Len(InputData) \ Len(KeyText)) + 1)
    Key = Key & KeyText
  Next n
  Rem ***********************************
  Rem   Trim the key string to fit
  Rem ***********************************
  Key = Left$(Key, Len(InputData))
  Rem ***********************************
  Rem   Encrypt/Decrypt data by XOR'ing
  Rem   with key string text
  Rem ***********************************
  TempData = InputData
  For n = 1 To Len(TempData)
    If n Mod 2 Then
      Mid$(TempData, n, 1) = Chr$(Asc(Mid$(TempData, n, 1)) Xor 
(Asc(Mid$(Key, n, 1)) + KeyOffset))
    Else
      Mid$(TempData, n, 1) = Chr$(Asc(Mid$(TempData, n, 1)) Xor 
(Asc(Mid$(Key, n, 1)) - KeyOffset))
    End If
  Next n
  EncryptDecrypt = TempData
End Function

============================================

A bit of VB code that would drive the Encrypt/Decrypt function might look 
like this:

  Dim Test As String
  Test = "Now is the time for all good men to come."
  Debug.Print Test
  Test = EncryptDecrypt(Test)
  Debug.Print Test
  Test = EncryptDecrypt(Test)
  Debug.Print Test

and produce output that looks like this:

     Now is the time for all good men to come.
     7RïóN®7òVµ;$ðfRêûQâcý\ú+L$ð(YI÷ùRã&´
     Now is the time for all good men to come.

Security is derived in using this routine not by knowing the algorithm -- 
sooner or later that would get out anyway, so we might as well make it public 
early on. Rather, security is derived from you creating a keytext string and 
an offset fairly regularly and distributing it to your end users by some 
secure method. Exactly identical routines, similar to that above, would be in 
QCTerm (and any other emulator that wished to use it), as well as in an SL on 
the HP3000 or in your chosen language's code, as a subroutine. Incoming and 
outgoing text from both ends would be encrypted whenever the host program 
invoked such encryption. A few new terminal escape sequences would be 
necessary to be defined to synchronize when encryption was to take place. It 
is my feeling that the host HP3000 program should be in total control, 
dictating when encryption should be on and when it should be off.

This routine will not fool anybody at the NSA or the CIA for long, but you 
have compare it with what we currently have, which is nothing. Everything 
that's being transmitted over telnet or NS/VT at the moment is right out 
there in the clear, for anyone to read if they want to. This routine provides 
an encryption algorithm that is simple, relatively secure (quite secure to 
the casual hacker), and quick. More importantly yet, it's doable in a short 
period of time. Any other implementation is going to take years.

Comments?

Wirt Atmar