Skip to content

Comments

Add ASCON#953

Open
xmamalou wants to merge 1 commit intocisco:libacvp_2_3_0-throttlefrom
xmamalou:main
Open

Add ASCON#953
xmamalou wants to merge 1 commit intocisco:libacvp_2_3_0-throttlefrom
xmamalou:main

Conversation

@xmamalou
Copy link

@xmamalou xmamalou commented Feb 6, 2026

Add handling for ASCON

@abkarcher
Copy link
Contributor

Hello,
Thank you for the contribution! Before I take a look at this, could you please remove the formatting/style changes unrelated to ASCON, and ensure consistent code style is used in the ASCON additions?

And then, if you could base this from the "libacvp_2_3_0-throttle" branch instead of main, that would be needed too.

Thanks again,
Andrew

@xmamalou xmamalou force-pushed the main branch 2 times, most recently from 50bda28 to 60eff14 Compare February 11, 2026 17:00
@xmamalou xmamalou force-pushed the main branch 6 times, most recently from 9aca533 to 392d1d4 Compare February 21, 2026 20:03
@xmamalou
Copy link
Author

xmamalou commented Feb 21, 2026

Hello, sorry for the long wait.

I have done the changes as requested. Sorry again for the formatting, Emacs was more zealous with the autoformatting than I expected and I hadn't noticed it had changed the entire file.

Best regards,
Christoforos

@xmamalou xmamalou changed the base branch from main to libacvp_2_3_0-throttle February 21, 2026 20:09
@abkarcher
Copy link
Contributor

Thanks! Taking a look now.

ACVP_ASCON_CUSSTRLEN_PARM,
} ACVP_ASCON_PARM;

typedef enum acvp_ascon_direction {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we name these "ACVP_ASCON_DIR_ENCRYPT" and "ACVP_ASCON_DIR_DECRYPT"? It would follow the naming scheme for other params a bit more closely.

I would also prefer having an "ACVP_ASCON_DIR_BOTH" instead of the extra append API in acvp_capabilities, and having a single param for this instead of the list. For example, see: ACVP_SYM_CIPH_DIR

* @brief This struct holds data that represents a single test case for ASCON
* testing. This data is passed between libacvp and the crypto module.
*/
typedef struct acvp_ascon_tc_t {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since we are using this struct for some fundamentally different test types, could we organize or comment these to indicate which fields are used for which test types? For example, see: acvp_ml_kem_tc_t

bool nonce_masking;
ACVP_JSON_DOMAIN_OBJ msg_len;
ACVP_JSON_DOMAIN_OBJ out_len;
ACVP_JSON_DOMAIN_OBJ cusstr_len;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: maybe "custom_len"?

return ACVP_SUCCESS;
}

ACVP_RESULT acvp_cap_ascon_append_value(ACVP_CTX *ctx, ACVP_CIPHER cipher,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See above comment regarding ACVP_ASCON_DIRECTION - I would rather have a "both" value than a separate API for this, like AES/TDES does

return result;
}

ACVP_RESULT acvp_cap_ascon_set_value(ACVP_CTX *ctx, ACVP_CIPHER cipher,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we rename this to acvp_cap_ascon_set_parm? I agree "value" is a better naming convention, but I would rather it be consistent with the other APIs until we can change all of them.

This API should also be able to set individual values within a domain. Not all of the algorithms can do this currently, but I have added it when adjusting existing ones moving forward. For example, see acvp_cap_hmac_set_parm. It appends to the ACVP_JSON_DOMAIN_OBJ "values" list.

return cap;
}

static ACVP_ASCON_CAP *allocate_ascon_cap(void) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should free this in acvp_free_test_session() in acvp.c

JSON_Object *pl_obj = json_value_get_object(pl_value);
json_object_set_number(pl_obj, "min", cap->payload_len.min);
json_object_set_number(pl_obj, "max", cap->payload_len.max);
json_object_set_number(pl_obj, "increment", cap->payload_len.increment);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For all domains, see the comment about setting individual values in acvp_capabilities.c. See acvp_build_hmac_register_cap() for an example of how that list is added to the JSON.

return rv;
}

static ACVP_RESULT acvp_ascon_aead128_init_tc(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: Match existing code style for other _init_tc() APIs

}
stc->payload_len = payload_len;

stc->key = calloc(1, ACVP_ASCON_KEY_BYTE_MAX);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Null check all calloc before calling hexstr_to_bin for extra code durability (a few more instances below this)

}

// Create ACVP array for response
JSON_Array *reg_array = NULL;
Copy link
Contributor

@abkarcher abkarcher Feb 24, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For code consistency, I would prefer to declare all variables throughout this function at the top of the function with 0/null values, then define them later on. It also can help avoid some free() edge cases with the loops, if the code needs adjustments later on.

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.

2 participants