[strongSwan-dev] RSA-PSS-SHA256

[Sahana Prasad]

Hello,

I am trying to interop rsa-pss-sha256 with stronswan as per RFC 7427.

Question 1 : Difference in OID bytes :

The 67 bytes ASN.1 OID that should be sent as per the errata from 7427 (
https://www.rfc-editor.org/errata_search.php?rfc=7427) and the 67 bytes
that I receive from strongswan are different.

errata specifies :

Length = 67
0000: 3046 0609 2a86 4886 f70d 0101 0a30 39a0
0010: 0f30 0d06 0960 8648 0165 0304 0201 0500
0020: a11c 301a 0609 2a86 4886 f70d 0101 0830
0030: 0d06 0960 8648 0165 0304 0201 0500 a203
| 0040: 0201 20


However, strongswan sends :

30 41 06 09 2a 86 48 86 f7 0d 01 01 0a 30 34 a0

0f 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00

a1 1c 30 1a 06 09 2a 86 48 86 f7 0d 01 01 08 30

0d 06 09 60 86 48 01 65 03 04 02 01 05 00 a2 03

02 01 20

Is there a reason for this behaviour/difference?

2nd byte and 15th byte are different.

Although both decode to the same parameters when converted from ASN.1 to
text.

To enable rsa-pss-sha256, I have added the charon option in strongswan.conf
:

rsa_pss = yes


and leftauth=rsa/pss-sha256 in ipsec.conf


Question 2 : Calculation of RSA signature


To calculate the 128 byte signature, the 67 bytes OID plus the 32 bytes
hash (sha256) is considered right?


Is there a way to see the hash that is generated? I have all logs enabled,
but do not see the hash value. I can only see the 128 byte rss-signature
that gets added to the 204 byte long auth payload


Thank you.


Regards,

Sahana Prasad

[Andreas Steffen]

Hi Sahana,

the 2nd and 15th octets are ASN.1 length fields which are incorrect
if your algorithmIdentifier comprises 67 octets as well (see ASN.1
decoded attachments). Your length values are too large by 5 octets.

Regards

Andreas

Post by Sahana Prasad
Hello,
I am trying to interop rsa-pss-sha256 with stronswan as per RFC 7427.
The 67 bytes ASN.1 OID that should be sent as per the errata from 7427
(https://www.rfc-editor.org/errata_search.php?rfc=7427) and the 67
bytes that I receive from strongswan are different.
Length = 67 0000: 3046 0609 2a86 4886 f70d 0101 0a30 39a0 0010: 0f30
0d06 0960 8648 0165 0304 0201 0500 0020: a11c 301a 0609 2a86 4886 f70d
0101 0830 0030: 0d06 0960 8648 0165 0304 0201 0500 a203 | 0040: 0201 20
30 41 06 09 2a 86 48 86 f7 0d 01 01 0a 30 34 a0
0f 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00
a1 1c 30 1a 06 09 2a 86 48 86 f7 0d 01 01 08 30
0d 06 09 60 86 48 01 65 03 04 02 01 05 00 a2 03
02 01 20
Is there a reason for this behaviour/difference?
2nd byte and 15th byte are different.
Although both decode to the same parameters when converted from ASN.1 to
text.
To enable rsa-pss-sha256, I have added the charon option
rsa_pss = yes
and leftauth=rsa/pss-sha256 in ipsec.conf
Question 2 : Calculation of RSA signature
To calculate the 128 byte signature, the 67 bytes OID plus the 32 bytes
hash (sha256) is considered right?
Is there a way to see the hash that is generated? I have all logs
enabled, but do not see the hash value. I can only see the 128
byte rss-signature that gets added to the 204 byte long auth payload
Thank you.
Regards,
Sahana Prasad

[Tobias Brunner]

Hi Sahana,

Post by Sahana Prasad
The 67 bytes ASN.1 OID that should be sent as per the errata from 7427
(https://www.rfc-editor.org/errata_search.php?rfc=7427)  and the 67
bytes that I receive from strongswan are different.

Please note that both of these erratas were rejected. And as Andreas
mentioned the second errata's ASN.1 encoding is incorrect. While the
ASCII length was changed the ASN.1 encoding was not.

Post by Sahana Prasad
Question 2 : Calculation of RSA signature
To calculate the 128 byte signature, the 67 bytes OID plus the 32 bytes
hash (sha256)  is considered right?

No, the signature is built as specified in RFC 7296, section 2.15. The
length and OID are just added in front of the signature value within the
Authentication Data field of the Authentication payload.

Post by Sahana Prasad
Is there a way to see the hash that is generated? I have all logs
enabled, but do not see the hash value. I can only see the 128
byte rss-signature that gets added to the 204 byte long auth payload

There are no log messages that print the value to be signed.

Regards,
Tobias

[Sahana Prasad]

Thanks Andreas and Tobias for your reply.

Is there a reason why a new errata was not reported with the 2nd and 15th
byte changed (rightly done as in the current strongswan identifier/ASN.1
blob) from the rejected errata?

Just want to know which ASN.1 blob we should use to interop and maybe
standardise/generalise it since the RFC ASN.1 blob (72 byte long) and the
rejected errata are wrong.

Regards,
Sahana Prasad

Post by Andreas Steffen
Hi Sahana,

Post by Sahana Prasad
The 67 bytes ASN.1 OID that should be sent as per the errata from 7427
(https://www.rfc-editor.org/errata_search.php?rfc=7427) and the 67
bytes that I receive from strongswan are different.

Please note that both of these erratas were rejected. And as Andreas
mentioned the second errata's ASN.1 encoding is incorrect. While the
ASCII length was changed the ASN.1 encoding was not.

Post by Sahana Prasad
Question 2 : Calculation of RSA signature
To calculate the 128 byte signature, the 67 bytes OID plus the 32 bytes
hash (sha256) is considered right?

No, the signature is built as specified in RFC 7296, section 2.15. The
length and OID are just added in front of the signature value within the
Authentication Data field of the Authentication payload.

Post by Sahana Prasad
Is there a way to see the hash that is generated? I have all logs
enabled, but do not see the hash value. I can only see the 128
byte rss-signature that gets added to the 204 byte long auth payload

There are no log messages that print the value to be signed.
Regards,
Tobias

[Tobias Brunner]

Hi Sahana,

Post by Sahana Prasad
Is there a reason why a new errata was not reported with the 2nd and
15th byte changed (rightly done as in the current strongswan
identifier/ASN.1 blob) from the rejected errata?
Just want to know which ASN.1 blob we should use to interop and maybe
standardise/generalise it since the RFC ASN.1 blob (72 byte long) and
the rejected errata are wrong.

Please read Tero's remarks below the erratas ("VERIFIER NOTES"). While
as sender you should e.g. not explicitly encode SHA-1 or send the
trailerField (i.e. the encoding from the erratas, with corrected length,
should be used) a recipient must understand both formats. So the ASN.1
blobs in the RFC are not really wrong (they can be parsed perfectly
fine), they are just too explicit.

Regards,
Tobias