Shared keys in TLS bug
2003-09-22 06:19:21 GMT
Joseph Salowey has pointed out a problem with draft-ietf-(Continue reading)
tls- sharedkeys-01.txt. I was using the TLS PRF as a black-box PRF (which it was in the SSL original), when in fact the TLS variant isn't a "pure" black-box PRF. Specifically, it splits the input secret value in half, so as used in the draft it would in effect be reinventing crypt16. Even as a general PRF (used outside of the shared-keys draft) it's not safe to use without providing large amounts of secret material, for example an otherwise-adequate 128-bit key is split into two independent 64-bit keys by the PRF. (Aside: Does anyone have any idea why TLS does this? I can't see any good reason for it, and it acts as a booby-trap for anyone who's counting on the PRF being a black box. If this problem hadn't been pointed out, I'd never have noticed it, since I was thinking of it as an SSL-style black box). Anyway, the result of this is pretty ugly: Instead of just feeding the shared secret into the PRF, it's necessary to be aware of its internal structure and pre- process the input in a way that negates what the PRF does. If the PRF is changed in future versions of TLS, the pre-processing will need to change as well in a PRF-dependent manner, unless it's made a true black box by eliminating the secret-splitting step (hint, hint). Some of the possible options to fix the problem are: 1. Synthesise a new PRF from HMAC to pre-PRF the input to the TLS PRF. Downsides: Yuck. Also, this violates the minimal code-change requirement for TLS implementations that the shared-keys draft is supposed to provide, instead of just feeding data in via a standard mechanism you'd now need to extend the implementation to introduce new crypto mechanisms.