[Sls-sea-dls] Exclusive CMAC use in SDLS

[Sipos, Brian J.]

Thanks all for information and clarification about the SDLS baseline.

I read it originally as more of a "mandatory to implement" minimum starting
point rather than a purely optional, somewhat arbitrary choice for
interoperation testing. My take-away is that the baseline does not represent
any kind of preference or starting point, just a set of algorithms that is
straightforward to implement and test while providing modern security
strengths broadly suitable for many missions. Omission of other algorithm
families simplifies the baseline but doesn't imply that they are
non-preferred or discouraged.

 

Brian S.

 

From: Antonios Atlasis <Antonios.Atlasis at esa.int> 
Sent: Tuesday, December 16, 2025 4:22 AM
To: Sipos, Brian J. <Brian.Sipos at jhuapl.edu>; sls-sea-dls at mailman.ccsds.org
Subject: [EXT] RE: Exclusive CMAC use in SDLS

 


APL external email warning: Verify sender Antonios.Atlasis at esa.int
<mailto:Antonios.Atlasis at esa.int>  before clicking links or attachments

 

Dear Brian, 

 

I am afraid I cannot enlighten you about the historical discussions (these
may have taken place before myself joining the group), but my understanding,
also by reading the corresponding blue books, is that while indeed CMAC is
prescribed as baseline mode with TC (Page E-2) , HMAC is also included in
CCSDS Blue book (page 6-2); so this is aligned with HMAC with SHA2 inclusion
in crypto Blue book (section 4.2.2). 

 

Regarding potential reasons for baselining CMAC for authentication, (here I
am speculating)  on top  of what you mentioned (sharing same primitive with
other AES based implementations, which can facilitate industry
implementation), it could also be that CMAC in some implementations provides
very high throughput (if this is needed, of course) 

 

Regards

 

Antonis 

 

__________________________________________
Dr Antonios Atlasis 
Hd. System Security Section (TEC-SES)

End-to-End Systems Division

Directorate of Technology, Engineering and Quality

 

European Space Research and Technology Centre (ESTEC)
Keplerlaan 1, PO Box 299
NL-2201 AZ Noordwijk, The Netherlands
T  +31 71 565 6095
M +31 61 873 5554

 

From: SLS-SEA-DLS <sls-sea-dls-bounces at mailman.ccsds.org
<mailto:sls-sea-dls-bounces at mailman.ccsds.org> > On Behalf Of Sipos, Brian
J. via SLS-SEA-DLS
Sent: 03 November 2025 18:09
To: sls-sea-dls at mailman.ccsds.org <mailto:sls-sea-dls at mailman.ccsds.org> 
Subject: [Sls-sea-dls] Exclusive CMAC use in SDLS

 

SDLS WG,

I'm posting a question to the mailing list because I'm not able to search
the mail archive and haven't come across any discussion on this topic in
recent years looking through the archives manually.

 

The current SDLS blue books and green book prescribe a single variation of
AES-GCM for AEAD and AES-CMAC for authentication. Was there any earlier
discussion about other authentication methods (e.g. HMAC with SHA2.) that
led to the current books? Or was it deemed more consistent to use CMAC
because of the shared AES primitive with the AEAD cipher suite?

 

I'm asking from the perspective of the full list of approved algorithms from
FIPS 140-3 [1] under Section 6.2.6, which includes some block cipher based
(including CMAC) and some hash based, and which primitives in that list
would be more or less acceptable to CCSDS community because of technical
limitations, required conformances, historical reasons, etc.

 

Thanks for any feedback or pointers to earlier mailing list discussion about
this.

Brian S.

 

[1]
https://csrc.nist.gov/Projects/cryptographic-module-validation-program/sp-80
0-140-series-supplemental-information/sp800-140c

 

This message is intended only for the recipient(s) named above. It may
contain proprietary information and/or protected content. Any unauthorised
disclosure, use, retention or dissemination is prohibited. If you have
received this e-mail in error, please notify the sender immediately. ESA
applies appropriate organisational measures to protect personal data, in
case of data privacy queries, please contact the ESA Data Protection Officer
(dpo at esa.int <mailto:dpo at esa.int> ). 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sls-sea-dls/attachments/20251216/d819be8c/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6541 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/sls-sea-dls/attachments/20251216/d819be8c/attachment.bin>