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

Deprecate signature API without context string? #2001

Open
dstebila opened this issue Nov 19, 2024 · 1 comment
Open

Deprecate signature API without context string? #2001

dstebila opened this issue Nov 19, 2024 · 1 comment
Labels
question Further information is requested
Milestone

Comments

@dstebila
Copy link
Member

dstebila commented Nov 19, 2024

Currently the signing and verification API within liboqs are as follows:

OQS_API OQS_STATUS OQS_SIG_sign(const OQS_SIG *sig, uint8_t *signature, 
    size_t *signature_len, const uint8_t *message, size_t message_len, 
    const uint8_t *secret_key);
OQS_API OQS_STATUS OQS_SIG_verify(const OQS_SIG *sig, const uint8_t *message, 
    size_t message_len, const uint8_t *signature, size_t signature_len, 
    const uint8_t *public_key);

The API that NIST has introduced in FIPS 204 for ML-DSA includes a context string of length ≥ 0.

PR #1919 adds a new API for signing with a context string:

OQS_API OQS_STATUS OQS_SIG_sign_with_ctx_str(const OQS_SIG *sig, uint8_t *signature, 
    size_t *signature_len, const uint8_t *message, size_t message_len, const uint8_t *ctx_str, 
    size_t ctx_str_len, const uint8_t *secret_key);
OQS_API OQS_STATUS OQS_SIG_verify_with_ctx_str(const OQS_SIG *sig, const uint8_t *message, 
    size_t message_len, const uint8_t *signature, size_t signature_len, const uint8_t *ctx_str, 
    size_t ctx_str_len, const uint8_t *public_key);

Once #1919 lands, all signature algorithms would be available under both APIs. For algorithms that do support context strings, if they are called via the old API, it uses a length-0 NULL context string. For algorithms that do not support context strings, if they are called via the new API, it will fail if they use a length >0 context string.

The question in this issue is whether to keep both these APIs indefinitely, or to deprecate the old API. See the discussion of #1919 (e.g., comments A, B, C, D, E). If we were to deprecate the old API, we would at the very least have both APIs in the 0.12.0 release, advertise in the 0.12.0 release notes that the old API will be removed, and then remove the old API in the 0.13.0 release.

@baentsch
Copy link
Member

fwiw, Yes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
Status: In Progress
Development

No branches or pull requests

2 participants