[botan-devel] Botan and Signed-and-Enveloped-Data - question

Jack Lloyd lloyd at randombit.net
Sat Feb 6 09:47:12 EST 2016

On Sat, Feb 06, 2016 at 12:17:36PM +0100, Roberto Petrillo wrote:
> *Problem description*: *I must create a simple utility that, given a text
> file in input, produces a Signed-and-Enveloped-Data type data structure,
> according to PKCS#7* (https://tools.ietf.org/html/rfc2315#section-11.1).
> The output should be serializable to file and printable (sort of
> X509::PEM_encode() output for certificates).

Hi Roberto,

Out of the box PKCS #7 (aka Cryptographic Message Syntax (CMS)) is not
supported. All of the 'pieces' are there - ASN.1 encoding, certificates,
the relevant crypto - but CMS combines these with a fairly complex
and general format.

In versions up to 1.11.3 a partial implementation of CMS was
included. However there was not the spare dev resources to actually
finish it and make it truly usable for applications, so it was removed
at that point. You can read the last version here:


Your specific use case (supporting just Signed-and-Enveloped-Data and
not being a totally general CMS parser) is likely a much easier than
the task the original version of the code was setting out for, and
much of the old code could be adapted for this purpose, or at least
serve as a guide.

I think the easiest approach, in terms of implementing something that
would do what you want, would be to write something with a signature
along the lines of:

std::vector<byte> create_signed_and_enveloped_data(
  const X509_Certificate& my_cert,
  const Private_Key& my_key,
  std::vector<const X509_Certificate>& recipients,
  std::vector<std::string>& hash_ids,

and a cooresponding read_signed_and_enveloped_data that decrypts the
message and returns the plaintext, or throws if the signature is

I think functions along these lines would be a good addition to the
library since they provide a standard format for encrypted and signed
data which is already implemented by other libs such as OpenSSL.

That said, depending on your timeline you should probably also
consider just using the OpenSSL CMS implementation as it is already
there and presumably works. And as OpenSSL APIs go, cms.h actually
looks fairly reasonable.

If you did decide to take a plunge on an implementation I'd be happy
to help when I can. Another good thing to look at is RFC 5084 which
specifies AES-CCM and AES-GCM support for CMS - the original version
of CMS only used 3DES, RC2, or CAST-128 in unauthenticated CBC mode.
Even *just* supporting the AES modes seems pretty reasonable to
me, at least at first.


More information about the botan-devel mailing list