secure: use HKDF for session key derivation, bind transcript to both peers - #35
Conversation
fix(node): add handshake timeout and connection limit to accept loop …
|
Thanks for taking this on. The HKDF direction is the right direction, but I am going to request changes before we merge this. Main blockers:
I am going to make a more detailed plan in the issues section and assign it to you so we can move this forward in smaller pieces. The change is valuable, but I want us to test and roll out the HKDF shift slowly and securely instead of merging it as one implicit protocol break. |
|
@ethical-buddy |
|
Thanks for the follow-up and for addressing the earlier review comments. We are going to move forward with this PR as the base for the secure-session HKDF migration. The current version solves the important parts we needed before merge: it adds HKDF-based key derivation, binds the transcript to the full static Ed25519 public keys instead of truncated node IDs, includes both ephemeral keys, adds an explicit secure-session version gate, and expands the tests around transcript consistency, key separation, public-key binding, and version mismatch behavior. Before merging, we are going to make a small final cleanup commit on top of this PR:
Those are small hardening/cleanup changes, not a rejection of the PR direction. The core design is correct and this is the PR we plan to merge. Thanks again for sticking with the review and improving the migration path. |
hey, i noticed the handshake was deriving the session key by just SHA256-ing the raw shared secret with the kind byte appended. it works, but SHA256 isn't really a proper KDF, and the resulting key isn't bound to the actual session participants, which leaves a small misbinding risk if someone is relaying the handshake in the middle
i switched it over to HKDF-SHA256 and included a transcript hash that binds both ephemeral keys and both node IDs
same overall behavior, but the key derivation is now tied to the session context
changes: