Telnet Encryption: CAST-128 64 bit Output Feedback
Extracted elements (17)
OFB mode was chosen originally when CPU speeds were insufficient for CFB; now that CPUs are faster, the RFC author suggests OFB modes should perhaps be deprecated in favor of CFB modes given OFB's inherent weaknesses.
OFB64_IV_BAD should only be sent in the case of a protocol violation where the IV received was not the correct length (8 bytes); OFB64_IV_OK is otherwise always required for backwards compatibility.
If a new OFB64_IV command is received while encryption is enabled, the encryption machine must be re-initialized immediately following the END of the OFB64_IV command using the new IV and the keyid from the last START command.
If a START command is received with a different keyid, the encryption machine must be re-initialized immediately following the END of the START command using the new key and the last received OFB64_IV vector.
If encryption is not enabled when a OFB64_IV command is received, the encryption machine must be re-initialized after the next START command using the keyid from that START and the IV from the OFB64_IV command.
If encryption is turned off and back on using the same keyid, the intervening clear text must not change the state of the encryption machine; the OFB stream state must be preserved across the gap.
If the default encryption key derived from the telnet AUTHENTICATION option contains less than 16 bytes (for CAST128_OFB64) or less than 5 bytes (for CAST5_40_OFB64), the respective option must not be offered or used.
The OFB64_IV_OK command MUST be sent by the DO ENCRYPT side upon receiving a valid OFB64_IV command, for backwards compatibility with existing implementations.
Any extra key data beyond the required minimum is used as random data to serve as an initialization vector for the cipher.
Key assignment for keyid 0: if fewer than 32 (10) bytes of key data are available, the first 16 (5) bytes are used in both directions; if 32 (10) or more bytes are available, the first 16 (5) bytes encrypt client-to-server and the second 16 (5) bytes encrypt server-to-client.
The OFB64_IV command carries a random 8-byte (64-bit) initial vector sent in clear text by the WILL ENCRYPT side to establish the starting state of the OFB cipher.
Three suboption commands are defined for IV exchange: OFB64_IV (code 1) to send the initial vector, OFB64_IV_OK (code 2) to accept it, and OFB64_IV_BAD (code 3) to reject it.
Two encryption type codes are defined: CAST5_40_OFB64 assigned code 9 (40-bit key) and CAST128_OFB64 assigned code 11 (128-bit key), for use with the telnet ENCRYPT option.
40-bit key modes (CAST5_40_OFB64) are not to be considered secure and are documented solely to record already-prevalent implementations; they should not be used for new deployments requiring strong security.
OFB mode does not ensure data integrity; an active attacker who can predict plaintext may be able to substitute text. Adding a MAC would address this but significantly increases per-character overhead, impacting performance on slow links.
After OFB64_IV_OK is received, the WILL ENCRYPT side performs keyid negotiation via ENC_KEYID; once a common keyid is identified, START and END commands may be exchanged to enable/disable encryption.
The OFB64 algorithm uses a 64-bit (8-byte) IV and processes data in 64-bit chunks. The keystream is computed as V0 = CAST(iV, key), V(n+1) = CAST(Vn, key), and ciphertext On = Dn XOR Vn.