nterfacer protocol lacks forward secrecy

[pandame]

The nterfacer protocol has no forward security: Once the password for any connection that was fully recorded is known, the key derivation algorithm allows decryption of all data. If the session in question is still going on, creating valid MACs becomes viable as the key becomes known.

Assuming best case, brute-forcing passwords is infeasible. Best case is all characters other than \n and \0 are actually used in the password. The maximum password length is 255 - strlen("password=") - 1 == 245. This leads to a potential maximum password strength of meaning 245 bytes with each byte having 253 potential values, which is entirely unreasonable to brute-force. However, should it ever be leaked or cracked due to a weak password (matching /^[a-z]{8}$/, for example), all previous captured communications would be compromised.

(There are other somewhat scary things, such as using memcmp instead of a function with constant timing for HMAC comparison, but it apparently can't be abused since the connection is immediately dropped on invalid MAC, plus keys are only per-session as well as not generated until after authentication of the other party. Additionally, CBC here shouldn't have any issues with its predictable PKCS#7 padding since the nterfacer protocol is correctly encrypt-then-MAC.)

[retropc]

hi,

yeah, the recent forward secrecy push is a lot newer than this protocol, I would accept a patchset that adds it!

good catch on the memcmp, I thought I had caught all of those last scan through the code base...

as a note we don't transmit anything directly sensitive over it, everything could quite easily go in the clear, and the passwords are a lot longer than 8 chars in our configs.