Egothor/ZeroEcho
2
0
Fork 0
Code Issues 18 Pull Requests Actions Packages Projects 1 Releases 2 Wiki Activity

Refactor HybridKexBuilder: extract shared classic-leg wiring into a private method #18

New Issue
Open
opened 2026-03-27 00:35:11 +01:00 by galambos · 0 comments
galambos commented 2026-03-27 00:35:11 +01:00
Owner
Copy Link

HybridKexBuilder.buildInitiator() and buildResponder() contain an identical
block (~20 lines) that resolves the classic agreement leg based on ClassicMode.
The two methods differ only in which PQC key they require. Any future change to
the classic-leg logic (e.g. a new ClassicMode variant, tightened validation, or
additional error context) must currently be applied twice, which is error-prone.

Why this matters

A missed update in one branch would silently produce inconsistent behavior between
initiator and responder construction — exactly the kind of asymmetry that is hard
to catch in review and leads to subtle protocol bugs.

Proposed change

Extract a private buildClassicLeg() method containing the shared ClassicMode
switch and return the resulting AgreementContext. Both buildInitiator() and
buildResponder() then delegate to it before handling their respective PQC key
requirement.

Acceptance criteria

  • buildClassicLeg() (or equivalently named private method) exists and is called
    by both buildInitiator() and buildResponder().
  • No behavioral change — all existing demo and unit tests pass unchanged.
  • The extracted method carries Javadoc explaining which state it validates and what
    it returns.
`HybridKexBuilder.buildInitiator()` and `buildResponder()` contain an identical block (~20 lines) that resolves the classic agreement leg based on `ClassicMode`. The two methods differ only in which PQC key they require. Any future change to the classic-leg logic (e.g. a new `ClassicMode` variant, tightened validation, or additional error context) must currently be applied twice, which is error-prone. ## Why this matters A missed update in one branch would silently produce inconsistent behavior between initiator and responder construction — exactly the kind of asymmetry that is hard to catch in review and leads to subtle protocol bugs. ## Proposed change Extract a private `buildClassicLeg()` method containing the shared `ClassicMode` switch and return the resulting `AgreementContext`. Both `buildInitiator()` and `buildResponder()` then delegate to it before handling their respective PQC key requirement. ## Acceptance criteria - `buildClassicLeg()` (or equivalently named private method) exists and is called by both `buildInitiator()` and `buildResponder()`. - No behavioral change — all existing demo and unit tests pass unchanged. - The extracted method carries Javadoc explaining which state it validates and what it returns.
galambos added this to the PKI Foundation Hardening and Regulated Operations Roadmap project 2026-03-27 00:36:38 +01:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project PKI Foundation Hardening and Regulated Operations Roadmap
Assignees
Clear assignees
galambos gitea-ci
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Egothor/ZeroEcho#18
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?