Errata Search
RFC Number:		Errata ID:
Source of RFC		Status:	All/Any Verified+Reported Verified Reported Held for Document Update Rejected
Area Acronym:	All/Any app art gen int ops rai rtg sec tsv wit	Type:	All/Any Editorial Technical
WG Acronym:		Submitter Name:
Other:	All/Any IAB INDEPENDENT IRTF Legacy Editorial	Date Submitted:
Summary Table Full Records

RFC 6143, "The Remote Framebuffer Protocol", March 2011

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: rai

---

Errata ID: 4951
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Simon Kissane
Date Reported: 2017-02-26

Section 7.2.2 says:

   The client encrypts the challenge with DES, using a password supplied
   by the user as the key.  To form the key, the password is truncated
   to eight characters, or padded with null bytes on the right.  The
   client then sends the resulting 16-byte response:

It should say:

   The client encrypts the challenge with DES, using a password supplied
   by the user as the key.  To form the key, the password is truncated
   to eight characters, or padded with null bytes on the right; then the
   bits of each byte of the key are reversed. The client then sends the
   resulting 16-byte response:

Notes:

Added text "; then the bits of each byte of the key are reversed" is essential to implementation of a VNC client or server which interoperates with existing VNC clients or servers, but the text fails to mention this.

See https://www.vidarholen.net/contents/junk/vnc.html

I confirmed the claims of the above web page while writing my own VNC server. I implemented VNC authentication without mirroring the bytes of the DES key and TigerVNC 1.5.0 could not authenticate to my VNC server. When I added code to mirror each byte of the DES key as described by the above web page, TigerVNC 1.5.0 could authenticate to my test VNC server.

Report New Errata