Skip to content

Fix/branch number computation#419

Open
peacker wants to merge 27 commits intodevelopfrom
fix/branch-number-computation
Open

Fix/branch number computation#419
peacker wants to merge 27 commits intodevelopfrom
fix/branch-number-computation

Conversation

@peacker
Copy link
Copy Markdown
Collaborator

@peacker peacker commented Mar 13, 2026

This branch overhauls branch-number computation and test coverage/performance for component analysis, with a focus on correctness across finite-field representations and practical runtime.

What changed

Refactored branch-number logic into explicit method-specific functions:

  • binary matrix: exact Sage/LinearCode path + bounded-enumeration path
  • field matrix: exact Sage/LinearCode path + bounded-enumeration path
  • wrappers with method selection ("sage" / "bounded"), input validation, and consistent errors.

Added optimized bounded search behavior:

  • reusable helper for best-value update + early exit
  • efficient low-weight enumeration strategy to avoid unnecessary work.

Improved GF(2) handling:

  • fast-path detection for GF(2) in field wrapper and delegation to binary implementation
  • exact binary branch number now uses LinearCode.minimum_distance() in Sage path.

Hardened runtime behavior:

  • automatic sage -> bounded fallback (with RuntimeWarning) when backend/runtime issues occur.

Added exact custom-field compatibility fix:

  • when GAP rejects custom-modulus extension fields, matrices are remapped to an isomorphic Conway-defined field via field homomorphism and exact computation is retried.

Kept MixColumn word-level path runtime-safe:

  • calculate_weights_for_mix_column(..., format="word") uses bounded enumeration by default for performance on common matrices.

Expanded and aligned documentation:

  • docstrings/examples updated for new APIs, strategy, fallback semantics, and bounded-method limitations.

peacker added 11 commits March 12, 2026 15:22
…) optimization

- Extract duplicated 'if candidate < best' conditional logic into _update_best_branch_number() helper
- Add GF(2) fast-path detection: delegate to optimized binary algorithm when field is GF(2)
- Consolidate 4 weight-tier loops to use consistent helper function for state updates
- All tests passing: branch_number_with_word_format_exact_mix_column, branch_number_with_bit_format
…d implementations

- Create compute_branch_number_from_binary_matrix_with_sage() for LinearCode-based computation
- Create compute_branch_number_from_binary_matrix_with_bounded_enumeration() for bounded search
- Create compute_branch_number_from_binary_matrix() wrapper with method parameter (default='sage')
- Create compute_branch_number_from_field_matrix_with_sage() for LinearCode-based computation
- Create compute_branch_number_from_field_matrix_with_bounded_enumeration() for bounded search
- Create compute_branch_number_from_field_matrix() wrapper with method parameter (default='sage')
- Both wrappers support method='sage' (exact) and method='bounded' (fallback) options
- Add comprehensive pytest test suite: 49 tests across 7 test classes
- Test classes: TestBinaryMatrixWithSage, TestBinaryMatrixWithBoundedEnumeration
  TestBinaryMatrixW
- Create compute_branch_number_from_binary_matrix_with_sage() for LinearCode-based computation
- Create compute_branch_number_from_binary_matrix_with_bounded_enumeration() for bounded s co- Ctibility (sage is default method)
…lumn

Sage's LinearCode.minimum_distance() delegates to GAP internally, which
only supports Givaro GF(2^m) fields defined by Conway polynomials. Cipher
fields (e.g. AES GF(2^8) with the Rijndael polynomial x^8+x^4+x^3+x+1)
use a non-Conway Givaro representation, causing:

  NotImplementedError: conversion of (Givaro) finite field element to GAP
  not implemented except for fields defined by Conway polynomials.

This broke the branch_number() and has_maximal_branch_number() doctests
(and any call through calculate_weights_for_mix_column).

Fix: change calculate_weights_for_mix_column to use method='bounded'
explicitly. For AES's 4×4 MDS matrix the branch number (5) is achieved
at input weight 1 (1+4=5), so bounded enumeration with default
max_input_weight=3 gives the exact result without needing GAP.

Also add a NOTE comment in compute_branch_number_from_field_matrix_with_sage
explaining the GAP/Conway restriction, and update the method parameter
docstring in the wrapper to document the limitation.
@peacker peacker requested review from ale-depi and michelag99 March 13, 2026 11:29
DavidGerault
DavidGerault previously approved these changes Mar 23, 2026
michelag99
michelag99 previously approved these changes Mar 23, 2026
ale-depi
ale-depi previously approved these changes Mar 23, 2026
@peacker peacker dismissed stale reviews from ale-depi, michelag99, and DavidGerault via 95fb31b March 26, 2026 20:00
@sonarqubecloud
Copy link
Copy Markdown

sonarqubecloud bot commented Apr 1, 2026

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants