Hashing the premaster key in SRP

[r4v3n6101]

Hello! I've noticed some SRP uses the premaster secret (aka S) directly even though both SRP-related RFCs define the session key as K = H(S).
Here they are:
RFC 2945: https://www.rfc-editor.org/rfc/rfc2945
RFC 5054: https://www.rfc-editor.org/rfc/rfc5054

Are there any reasons this isn’t the default behavior? Back-compatibility or something else?

[tarcieri]

We recently merged a change (#153) but would love some guidance from actual SRP users as far as what’s being used in the wild.

[r4v3n6101]

Here's my experience with SRP.
I’m using SRP in the HomeKit protocol. HomeKit derives the session key with a simple H(x) instead of the SHA_Interleaved method mentioned in RFC 2945. It also differs in other spots — for example, the RFCs require u to be padded to the full key size, but the current implementation doesn’t do that, even though the doc-comment claims it does.

[tarcieri]

@r4v3n6101 that sounds like #166 potentially?

[r4v3n6101]

It might help for correct implementation. Both RFCs require padding when computing u.

In fact there are two possible adjustments:
1. Add the required padding wherever it’s needed (the doc comments already point out those spots).
2. Hash the premaster secret before computing M1/M2, that's done in #153.

RFC 5054 says that once the premaster is calculated, everything should follow RFC 2945. That spec defines K = SHA_Interleave(S), where S is the premaster and K is the session key. But interleaving is only necessary for the old SHA-1. With SHA-2, H(x) is just a normal hash.