Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

🐞 HashedElGamal is not compliant with the spec #646

Open
1 task done
danwallach opened this issue May 27, 2022 · 2 comments
Open
1 task done

🐞 HashedElGamal is not compliant with the spec #646

danwallach opened this issue May 27, 2022 · 2 comments
Labels
bug Something isn't working enhancement New feature or request

Comments

@danwallach
Copy link
Collaborator

Is there an existing issue for this?

  • I have searched the existing issues

Current Behavior

The code in hmac.py (in particular, the get_hmac() function) is being used as part of HashedElGamalCiphertext for two very different purposes.

For the first purpose, computing an HMAC, it seems to be correct. Example, where the spec says to use HMAC (e.g., $c_2 = HMAC(k_0, c_0 | c_1)$), the code says:

mac = get_hmac(mac_key, to_mac)

This is fine.

The ElectionGuard spec notes that the actual encryption of the message ($c_1 = m_1 \oplus k_1 | m_2 \oplus k_2 | \cdots | m_{b_m} \oplus k_{b_m}$) is supposed to use a NIST 800-108-compliant key derivation function (KDF). The Python code is not compliant with the NIST spec. In particular, the code that creates those $k_i$ values does this:

        data_key = get_hmac(
            session_key.to_hex_bytes(),
            encryption_seed.to_hex_bytes(),
            bit_length,
            (i + 1),
        )

So, what's going on inside get_hmac? Its input to the HMAC function is ultimately the byte concatenation of three values: start_byte + msg + end_byte where start_byte is the index $i$, and end_byte is the message length. The NIST spec says:

K(i) := PRF (KI, [i] || Label || 0x00 || Context || [L])

Suggested fixes below.

Expected Behavior

It's confusing to use get_hmac to serve two radically different purposes. First and foremost, it would be good to have a KDF class that implements the NIST spec correctly and then use it to compute the $k_i$'s. Anyway, even if you don't do that, there are a few things that you do need to do:

  • You're not doing anything for the NIST-defined Label or Context strings (okay for a start, but these strings serve a purpose and should be defined and used)
  • You're not using the zero byte after the Label (Suggestion: add the byte.)
  • You're using precisely 32 bits to encode the two numbers ($i$ and $L$), when it's possible (if unlikely) that this code might be used to encrypt more than 4 billion blocks. (Suggestion: use a variable-length encoding for lengths.)
  • You should not be converting keys to hexadecimal bytes. Those are originally ElementModQ values, which already fit into 32 bytes. This encoding process yields more bits than HMAC-SHA256 normally supports for its key values. (Suggestion: extract the internal BigInteger as exactly 32 big-endian bytes.)

Steps To Reproduce

No response

Environment

No response

Anything else?

No response

@danwallach danwallach added bug Something isn't working triage Waiting to be triaged labels May 27, 2022
@danwallach
Copy link
Collaborator Author

FWIW, in both our Kotlin and TypeScript code, we've implemented a UInt256 class, as distinct from arbitrary bigints or ElementModQ. This turns out to make everything involving hash and MAC computation much more straightforward. We then have helper methods to convert from UInt256 to ElementModQ and back again when necessary.

@rc-ms
Copy link
Contributor

rc-ms commented Jun 3, 2022

Thanks @danwallach this is helpful. We've discussed and will certainly adopt these or variations for 2.0. We will unlikely be able to accommodate them for 1.0.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants