Error: Bad length of salt (32) for AES when importing a p12 certificate

[Nils Schween]

Thanks for joining the discussion. I changed the value of the salt length
to 32. That did not change anything. However, I tried to get some more
information. I used gpsm -vv --import for both certificates and a
difference appeared:

When I am importing the self-created certificate the import process is
skipping shrouded_key_bag.attribute_set when reaching the private key.
Here the output:

gpgsm: enabled compatibility flags:
gpgsm: processing bag.encryptedData
gpgsm: 1536 bytes of AES256 encrypted text
gpgsm: processing certBag
gpgsm: certificate already in DB
gpgsm: skipping bag.attribute_set
gpgsm: processing bag data
gpgsm: processing shrouded_key_bag
gpgsm: 2384 bytes of AES256 encrypted text
gpgsm: skipping shrouded_key_bag.attribute_set

Whereas the import of the (non-distributable) certificate yields

gpgsm: bad length of salt (32) for AES
gpgsm: parse_shrouded_key_bag(shrouded_key_bag.pkcs5PBES2-params): lvl=16 (tlv_expect_octet_string): Erfolg - Ungültige Länge
gpgsm: parse_bag_data(data.oid): lvl=16 (tlv_expect_octet_string): Erfolg - Ungültige Länge
gpgsm: p12_parse(bag.data): @6724 lvl=16 tlv_expect_octet_string: Erfolg - Ungültige Länge
gpgsm: error parsing or decrypting the PKCS#12 file

The import is not skipping shrouded_key_bag.attribute_set.

That the error goes away when I change the salt array length in
parse_shrouded_key_bag, makes from sense from this perspective.

Unfortunately, I do not know how I can change my self-created certificate
such that the gpgsm --import command does not skip the shrouded_key_bag
attribute when importing the private key. Do you have any idea what
options I need to set when creating the key or the p12 file to set the
shrouded_key_bag attribute? 

Thank you.
Nils

Jakob Bohm via Gnupg-users <gnupg-users at gnupg.org> writes:

> Dear Nils,
>
> Given the error message in the subject line above, the step to reproduce may be
> to pass 32 instead of 64 to the openssl command that makes the test certificate.
>
> Otherwise, look for a command that can dump out the formatting details of the
> (non-distributable) problematic pkcs12 file to see what values it actually uses.
>
> On 2024-09-20 12:02, Nils Schween wrote:
>>> Given the brittleness of pkcs#12/minip12.c I would really appricate to
>>> have a sample file.  But the worst thing which could happen is that the
>>> 64 bit salt does not work anymore in the future.  It is unlikey, though.
>> I do understand. I tried to create one this morning, but I was not able
>> to reproduce the error when importing my self created certificate.
>>
>> I used the following commands to create the certificate:
>>
>> openssl req -newkey rsa:4096 -nodes -keyout key.pem -x509 -sha384 -days 365 -out certificate.pem
>>
>> openssl pkcs12 -inkey key.pem -in certificate.pem -export -macsaltlen 64 -iter 20000 -out certificate.p12
>>
>> To compare my own certificate with the one issued by the certificate
>> provider I used the following two commands:
>>
>> openssl pkcs12 -in certificate.p12 -noout -info
>> openssl x509 -text -noout -in certificate.p12
>>
>> I could not find any significant difference in the output. Though the
>> one from the certificate provider causes the error when imported with
>> gpgsm while my own certificate does not.
>>
>> Since I am not very knowledgeable when it comes to S/MIME certificates,
>> it is riddle to me why the error appears: My certificate and the one
>> from the provider have a salt length of 64bit and that was the only
>> thing I changed in minip12.c
>>
>> So, I have to say that I am sorry, I cannot reproduce the error with a
>> self-created certificate.
>>
>>> Please give me some days to apply the patch.
>> No hurry, for now I have a personal work around.
>>
>> Thank you,
>> Nils
>>
>> Werner Koch <wk at gnupg.org> writes:
>>
>>> On Thu, 19 Sep 2024 13:42, Nils Schween said:
>>>
>>>> If it is necessary, I can try to create a certificate with openssl, that
>>>> reproduces the error.
>>> Given the brittleness of pkcs#12/minip12.c I would really appricate to
>>> have a sample file.  But the worst thing which could happen is that the
>>> 64 bit salt does not work anymore in the future.  It is unlikey, though.
>>>
>>> Please give me some days to apply the patch.
>>>
>>>
>>> Salam-Shalom,
>>>
>>>     Werner
>
> Enjoy
>
> Jakob

-- 
Nils Schween
PhD Student

Phone: +49 6221 516 557
Mail: nils.schween at mpi-hd.mpg.de
PGP-Key: 4DD3DCC0532EE96DB0C1F8B5368DBFA14CB81849

Max Planck Institute for Nuclear Physics
Astrophysical Plasma Theory (APT)
Saupfercheckweg 1, D-69117 Heidelberg
https://www.mpi-hd.mpg.de/mpi/en/research/scientific-divisions-and-groups/independent-research-groups/apt