`digest::Algorithm` definitions are defined as `static` instead of `const`

[jsparj]

Security issue notifications

If you discover a potential security issue in AWS-LC for Rust we ask that you notify AWS Security via our
vulnerability reporting page. Please do not create a
public github issue, if in doubt contact AWS security first.

Problem:

digest::Algorithm definitions are static instead of const in aws-lc-rs/src/digest/sha/*.

That makes them:

1. The digest::Algorithm definitions are not consistent with other algorithm definitions, like definitions for aead::Algorithm which use const correctly instead of static.
2. Impractical to use.
   • They are not directly &'static referencable
   • Cannot be used to create const combinational definitiones
     (for example the following use case, this would result to better memory locality when using &'static references for algorithm bundles)

/// **See**: [RFC 8446 - B.4. Cipher Suites](https://www.rfc-editor.org/rfc/rfc8446#appendix-B.4)
pub struct Tls13CipherSuite {
    pub aead: aead::Algorithm,
    pub hash: digest::Algorithm,
}

impl Tls13CipherSuite {
    ///**See**: [RFC 5116 - 5.1. AEAD_AES_128_GCM](https://www.rfc-editor.org/rfc/rfc5116#section-5.1)
    pub const AES_128_GCM_SHA256: Self = Self {
        aead: aead::AES_128_GCM,
        hash: digest::SHA256   // <-- not possible now
    };
    ///**See**: [RFC 5116 - 5.2. AEAD_AES_256_GCM](https://www.rfc-editor.org/rfc/rfc5116#section-5.2)
    pub const AES_256_GCM_SHA384: Self = Self {
        aead: aead::AES_256_GCM,
        hash: digest::SHA3_384   // <-- not possible now
    };
    ///**See**: [RFC 8439 - ChaCha20 and Poly1305 for IETF Protocols](https://www.rfc-editor.org/rfc/rfc8439)
    pub const CHACHA20_POLY1305_SHA256: Self = Self {
        aead: aead::CHACHA20_POLY1305,
        hash: digest::SHA256   // <-- not possible now
    };
}

3. static instead of const will also result in less optimal machine code since complier inlining is not possible for the underlying algorithm parameters.

Solution:

A description of the possible solution in terms of AWS-LC for Rust architecture. Highlight and explain any potentially
controversial design decisions taken.

• Does this change any public APIs?

No.

• Which algorithm(s) will this impact?

digest::Algorithm definitions in aws-lc-rs/src/digest/sha/*.

Requirements / Acceptance Criteria:

What must a solution address in order to solve the problem? How do we know the solution is complete?

• RFC links: Links to relevant RFC(s)

None.

• Related Issues: Link any relevant issues

None.

• Will the Usage Guide or other documentation need to be updated?

None needed.

• Testing: How will this change be tested? Call out new integration tests, functional tests, or particularly
  interesting/important unit tests.

None needed.

Out of scope:

Is there anything the solution will intentionally NOT address?

No.

[justsmth]

digest::Algorithm definitions are static instead of const in aws-lc-rs/src/digest/sha/*.

I think this would be a good change to make, but I am concerned about its potential to break existing consumers. However, the only way I could see it breaking consumers is fairly contrived -- the consumer would need to be comparing pointer addresses when determining the equality of two digest::Algorithm. This seems highly improbably and, arguably, not a supported use-case.

I'll need to consult with some people more knowledgable than myself about such things. I'll follow up here.

[Mark-Simulacrum]

Impractical to use. (they are not directly &'static referencable)

Can you say more about this? You should be able to create 'static references to a global static -- see e.g. here's a playground link showing that (https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=80aaf78dfda3bfb971b51c9e4a49683a). Doing so to a const in contrast depends on promotion, which I believe always works for const items today too, but there shouldn't be a change in customer use here.

I'm not aware of concrete breakage (outside the pointer stability outlined above) that could be caused by changing these to consts. It might be a minor size increase (unlike statics, consts don't guarantee one allocation, so the data may be duplicated more times in the binary. But Algorithm is relatively small so it's probably not a huge concern.)

[jsparj]

Oh, got a bit of my wording mixed what &'static referencing I meant.

Updated cases to make my arguments more clear.

[jsparj]

The static definitions seems to be used other places as well when searching the project folder aws-lc-rs with "pub static " I found them in:

• aws-lc-rs/src/aead/quic.rs
• aws-lc-rs/src/digest/sha.rs
• aws-lc-rs/src/unsable/signature.rs
• aws-lc-rs/src/cipher.rs
• aws-lc-rs/src/hkdf.rs
• aws-lc-rs/src/hmac.rs
• aws-lc-rs/src/pbkdf2.rs
• aws-lc-rs/src/pbkdf2.rs
• aws-lc-rs/src/signature.rs

More can be found also on other root folders.

Seems that pretty much all of the static definitions could be changed to const:

There is also usage of &'static referenced AlgorithmIds or "id-like" enums in some of them, which increases the underlying struct size representation & possibly alignment requirements which would be good to be addressed.

Some examples of this happening can be found in:

aws-lc-rs/src/pqdsa/signature.rs :: PqdsaVerificationAlgorithm
aws-lc-rs/src/ec/signature.rs :: EcdsaVerificationAlgorithm
...

[justsmth]

Hello! We just released aws-lc-rs v1.15.0, which updates the API so that previously pub static values are now pub const.

This issue will now be closed. Feel free to comment here, or open another issue if you continue to have concerns after upgrading. Thanks for reporting and helping us improve our library! 😃