7
$\begingroup$

I am looking for CMS AuthEnvelopedData test vectors for AES-GCM mode. I haven’t seen any ready-to-use test vectors for it. There are test vectors for AES-GCM mode but not for its CMS support.

I even checked open source cryptography libraries which implemented AES-GCM with CMS support (AuthEnvelopedData Content Type), but none of them contained any test vectors that I could extract and use. Openssl doesn’t seem to provide any cms support for aes-gcm either. I also checked the Bouncy Castle cryptography library. In their release notes they state

AES GCM mode is now supported by CMS EnvelopedData.

but the standards (RFC 5083 & RFC 5084) say it should be AuthEnvelopedData. Am I missing something here? Also, in the source code of Bouncy Castle there is a class named CMSAuthEnvelopedGenerator which is supposed to do the work, but only a few static variables have been defined in the class – no methods defined yet. So, it seems that there are some unfinished business left there.

Warn me if I am wrong but I have come to the decision that very few people are using AES-GCM mode in file encryption and other encryption purposes (except TLS). Because in the other case, how can a library decrypt a file encrypted by another library without using the standard syntax?

TL;DR

I am looking for CMS AuthEnvelopedData test vectors for AES-GCM mode. Can anyone provide (or point me to) test vectors for the CMS content type AuthEnvelopedData (for AES-GCM)?

Improve this question
$\endgroup$
6
  • $\begingroup$ It would be tricky to use the GCM as currently in Bouncy as it includes the tag in the ciphertext (something I really don't like as it messes up symmetry and flexibility). So this might be solution in the sense that it just uses the OID for GCM instead of CBC and that's it. $\endgroup$
    – Maarten Bodewes ♦
    Sep 14, 2015 at 11:42
  • $\begingroup$ Looked on the mailing list: the class is incomplete because of API issues with Java JCE. The class requires out of order AAD it seems. So CMSAuthEnvelopedGenerator is waiting for a contributor to finish it. That was on 2014-05-02 though. Bouncy questions are usually best asked on the dev-crypto mailing list. $\endgroup$
    – Maarten Bodewes ♦
    Sep 14, 2015 at 11:49
  • $\begingroup$ Link here $\endgroup$
    – Maarten Bodewes ♦
    Sep 14, 2015 at 13:25
  • $\begingroup$ @MaartenBodewes Technically speaking, the authentication tag is not in the ciphertext, it is another output of the encryption process. So how to keep it or send it leaved up to the protocol designer.I understand that adding AuthEnvelopedData support may require a lot of change in previous code. However, solution of this should not be something like self-defined structure so that the code will not be affected much. I believe this goes against the reason why CMS exists. So that, two cryptograpy implementations can encrypt/decrypt the same content without knowing about each others implementation. $\endgroup$
    – Makif
    Sep 14, 2015 at 13:45
  • $\begingroup$ I fully agree with above of course. However, many API's do output the tag as part of the ciphertext (including Java & Bouncy) and there are of course also persons that would like to standardize this: " There is a single output: "A ciphertext C, which is at least as long as the plaintext, or (failure)". As for the explanation in my first comment: I just wanted to show how these kind of things may have happened; I'm certainly not defending such practices. $\endgroup$
    – Maarten Bodewes ♦
    Sep 14, 2015 at 13:55

0

Reset to default

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.