Is there any plan to allow SHA256 as sub-key signing algorithm for the next version of Bouncy Castle ?

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Is there any plan to allow SHA256 as sub-key signing algorithm for the next version of Bouncy Castle ?

Denis BEURIVE

Hello,

I am new to this mailing list and to the Bouncy Castle library too.

I start my training by writing small examples that illustrates the use of the library. You can find it here :

https://github.com/denis-beurive/bouncy-castle-examples

In order to test the sample programs, I use GPG to perform tests.

I found that :

  1. I generate keys and sub-keys using Bouncy Castle.
  2. I sign a document with a sub-key, using Bouncy Castle.
  3. Then, I verify the signature with GPG.

And then, GPG tells me that the "signing sub-key is not cross-certified.

This document gives information about "Signing Sub-key Cross-Certification":

https://gnupg.org/faq/subkey-cross-certify.html

However, I am not sure to fully understand it.

Thus I imagined the following experiment :

  1. I generate sub-keys with Bouncy Castle.
  2. I use GPG to cross-sign the sub-keys (see https://gnupg.org/faq/subkey-cross-certify.html).
  3. I export the cross-signed sub-keys.
  4. And, finally, I compare the original sub-keys (generated by Bouncy Castle) with the cross-signed sub-keys.

However, when I follow this procedure, a new error occurs :

GPG tells me that "third-party key signatures using the SHA1 algorithm are rejected."

I did research and I found interesting documents :

  1. https://lists.gnupg.org/pipermail/gnupg-devel/2019-November/034487.html
  2. https://github.com/bcgit/bc-java/issues/200
  3. https://arstechnica.com/information-technology/2020/01/pgp-keys-software-security-and-much-more-threatened-by-new-sha1-exploit/

From the second document, I understand that Bouncy Castle signs the sub-keys with the SHA1 algorithm, because that's what is specified by RFC4880.

If I look at a sub-key generated by GPG, I notice that GPG uses SHA256 as signing algorithm (algo = 8).

$ gpg --list-packets --verbose toto.gpg

:signature packet: algo 1, keyid 040E8937EDB35B90
        version 4, created 1587587801, md5len 0, sigclass 0x13
        digest algo 8, begin of digest 5a 9d
        subpkt 16 len 8 (issuer key ID 040E8937EDB35B90)


From the third document, I understand that it is not safe to use SHA1 signed sub-keys.

What is your point of view ? Is it really risky to use SHA1 signed sub-keys ?

Is there any plan to allow SHA256 as sub-key signing algorithm for the next version of Bouncy Castle ?

Thank you,

Denis

Reply | Threaded
Open this post in threaded view
|

Re: Is there any plan to allow SHA256 as sub-key signing algorithm for the next version of Bouncy Castle ?

David Hook-3

The reference to SHA-1 in the github issue is about the key checksum algorithm, it's not connected with certifications.

Can you say what's stopping you from using an algorithm that makes use of SHA-256 when certifying a sub-key?

Thanks,

David

On 24/4/20 5:21 pm, Denis BEURIVE wrote:

Hello,

I am new to this mailing list and to the Bouncy Castle library too.

I start my training by writing small examples that illustrates the use of the library. You can find it here :

https://github.com/denis-beurive/bouncy-castle-examples

In order to test the sample programs, I use GPG to perform tests.

I found that :

  1. I generate keys and sub-keys using Bouncy Castle.
  2. I sign a document with a sub-key, using Bouncy Castle.
  3. Then, I verify the signature with GPG.

And then, GPG tells me that the "signing sub-key is not cross-certified.

This document gives information about "Signing Sub-key Cross-Certification":

https://gnupg.org/faq/subkey-cross-certify.html

However, I am not sure to fully understand it.

Thus I imagined the following experiment :

  1. I generate sub-keys with Bouncy Castle.
  2. I use GPG to cross-sign the sub-keys (see https://gnupg.org/faq/subkey-cross-certify.html).
  3. I export the cross-signed sub-keys.
  4. And, finally, I compare the original sub-keys (generated by Bouncy Castle) with the cross-signed sub-keys.

However, when I follow this procedure, a new error occurs :

GPG tells me that "third-party key signatures using the SHA1 algorithm are rejected."

I did research and I found interesting documents :

  1. https://lists.gnupg.org/pipermail/gnupg-devel/2019-November/034487.html
  2. https://github.com/bcgit/bc-java/issues/200
  3. https://arstechnica.com/information-technology/2020/01/pgp-keys-software-security-and-much-more-threatened-by-new-sha1-exploit/

From the second document, I understand that Bouncy Castle signs the sub-keys with the SHA1 algorithm, because that's what is specified by RFC4880.

If I look at a sub-key generated by GPG, I notice that GPG uses SHA256 as signing algorithm (algo = 8).

$ gpg --list-packets --verbose toto.gpg

:signature packet: algo 1, keyid 040E8937EDB35B90
        version 4, created 1587587801, md5len 0, sigclass 0x13
        digest algo 8, begin of digest 5a 9d
        subpkt 16 len 8 (issuer key ID 040E8937EDB35B90)


From the third document, I understand that it is not safe to use SHA1 signed sub-keys.

What is your point of view ? Is it really risky to use SHA1 signed sub-keys ?

Is there any plan to allow SHA256 as sub-key signing algorithm for the next version of Bouncy Castle ?

Thank you,

Denis


Reply | Threaded
Open this post in threaded view
|

AW: [dev-crypto] Is there any plan to allow SHA256 as sub-key signing algorithm for the next version of Bouncy Castle ?

Eckenfels. Bernd
In reply to this post by Denis BEURIVE

Do you mean this sha1?

 

https://github.com/denis-beurive/bouncy-castle-examples/blob/master/app-pgp-keygen/src/main/java/com/beurive/Main.java#L293

 

Von: Denis BEURIVE <[hidden email]>
Gesendet: Freitag, 24. April 2020 09:21
An: [hidden email]
Betreff: [dev-crypto] Is there any plan to allow SHA256 as sub-key signing algorithm for the next version of Bouncy Castle ?

 

Hello,

I am new to this mailing list and to the Bouncy Castle library too.

I start my training by writing small examples that illustrates the use of the library. You can find it here :

https://github.com/denis-beurive/bouncy-castle-examples

In order to test the sample programs, I use GPG to perform tests.

I found that :

  1. I generate keys and sub-keys using Bouncy Castle.
  2. I sign a document with a sub-key, using Bouncy Castle.
  3. Then, I verify the signature with GPG.

And then, GPG tells me that the "signing sub-key is not cross-certified.

This document gives information about "Signing Sub-key Cross-Certification":

https://gnupg.org/faq/subkey-cross-certify.html

However, I am not sure to fully understand it.

Thus I imagined the following experiment :

  1. I generate sub-keys with Bouncy Castle.
  2. I use GPG to cross-sign the sub-keys (see https://gnupg.org/faq/subkey-cross-certify.html).
  3. I export the cross-signed sub-keys.
  4. And, finally, I compare the original sub-keys (generated by Bouncy Castle) with the cross-signed sub-keys.

However, when I follow this procedure, a new error occurs :

GPG tells me that "third-party key signatures using the SHA1 algorithm are rejected."

I did research and I found interesting documents :

  1. https://lists.gnupg.org/pipermail/gnupg-devel/2019-November/034487.html
  2. https://github.com/bcgit/bc-java/issues/200
  3. https://arstechnica.com/information-technology/2020/01/pgp-keys-software-security-and-much-more-threatened-by-new-sha1-exploit/

From the second document, I understand that Bouncy Castle signs the sub-keys with the SHA1 algorithm, because that's what is specified by RFC4880.

If I look at a sub-key generated by GPG, I notice that GPG uses SHA256 as signing algorithm (algo = 8).

$ gpg --list-packets --verbose toto.gpg

:signature packet: algo 1, keyid 040E8937EDB35B90
        version 4, created 1587587801, md5len 0, sigclass 0x13
        digest algo 8, begin of digest 5a 9d
        subpkt 16 len 8 (issuer key ID 040E8937EDB35B90)

 

From the third document, I understand that it is not safe to use SHA1 signed sub-keys.

What is your point of view ? Is it really risky to use SHA1 signed sub-keys ?

Is there any plan to allow SHA256 as sub-key signing algorithm for the next version of Bouncy Castle ?

Thank you,

Denis






     


SEEBURGER AG   Vorstand/SEEBURGER Executive Board:
Sitz der Gesellschaft/Registered Office:   Axel Haas, Michael Kleeberg, Axel Otto, Dr. Martin Kuntz, Matthias Feßenbecker
Edisonstr. 1  
D-75015 Bretten Vorsitzende des Aufsichtsrats/Chairperson of the SEEBURGER Supervisory Board:
Tel.: 07252 / 96 - 0 Prof. Dr. Simone Zeuchner
Fax: 07252 / 96 - 2222
Internet: http://www.seeburger.de Registergericht/Commercial Register:
e-mail: [hidden email] HRB 240708 Mannheim


Dieses E-Mail ist nur für den Empfänger bestimmt, an den es gerichtet ist und kann vertrauliches bzw. unter das Berufsgeheimnis fallendes Material enthalten. Jegliche darin enthaltene Ansicht oder Meinungsäußerung ist die des Autors und stellt nicht notwendigerweise die Ansicht oder Meinung der SEEBURGER AG dar. Sind Sie nicht der Empfänger, so haben Sie diese E-Mail irrtümlich erhalten und jegliche Verwendung, Veröffentlichung, Weiterleitung, Abschrift oder jeglicher Druck dieser E-Mail ist strengstens untersagt. Weder die SEEBURGER AG noch der Absender (Eckenfels. Bernd) übernehmen die Haftung für Viren; es obliegt Ihrer Verantwortung, die E-Mail und deren Anhänge auf Viren zu prüfen.

This email is intended only for the recipient(s) to whom it is addressed. This email may contain confidential material that may be protected by professional secrecy. Any fact or opinion contained, or expression of the material herein, does not necessarily reflect that of SEEBURGER AG. If you are not the addressee or if you have received this email in error, any use, publication or distribution including forwarding, copying or printing is strictly prohibited. Neither SEEBURGER AG, nor the sender (Eckenfels. Bernd) accept liability for viruses; it is your responsibility to check this email and its attachments for viruses.

Reply | Threaded
Open this post in threaded view
|

Re: AW: [dev-crypto] Is there any plan to allow SHA256 as sub-key signing algorithm for the next version of Bouncy Castle ?

David Hook-3

Actually, looking at the code again today, is it just me or do the public key sizes seem a bit small? I think GPG rejects any signature using DSA that less than 1024 as it assumes SHA-1. Try setting everything to 2048 bits and you might find it's happier.

Regards,

David

On 25/4/20 12:31 am, Eckenfels. Bernd wrote:

Do you mean this sha1?

 

https://github.com/denis-beurive/bouncy-castle-examples/blob/master/app-pgp-keygen/src/main/java/com/beurive/Main.java#L293

 

Von: Denis BEURIVE [hidden email]
Gesendet: Freitag, 24. April 2020 09:21
An: [hidden email]
Betreff: [dev-crypto] Is there any plan to allow SHA256 as sub-key signing algorithm for the next version of Bouncy Castle ?

 

Hello,

I am new to this mailing list and to the Bouncy Castle library too.

I start my training by writing small examples that illustrates the use of the library. You can find it here :

https://github.com/denis-beurive/bouncy-castle-examples

In order to test the sample programs, I use GPG to perform tests.

I found that :

  1. I generate keys and sub-keys using Bouncy Castle.
  2. I sign a document with a sub-key, using Bouncy Castle.
  3. Then, I verify the signature with GPG.

And then, GPG tells me that the "signing sub-key is not cross-certified.

This document gives information about "Signing Sub-key Cross-Certification":

https://gnupg.org/faq/subkey-cross-certify.html

However, I am not sure to fully understand it.

Thus I imagined the following experiment :

  1. I generate sub-keys with Bouncy Castle.
  2. I use GPG to cross-sign the sub-keys (see https://gnupg.org/faq/subkey-cross-certify.html).
  3. I export the cross-signed sub-keys.
  4. And, finally, I compare the original sub-keys (generated by Bouncy Castle) with the cross-signed sub-keys.

However, when I follow this procedure, a new error occurs :

GPG tells me that "third-party key signatures using the SHA1 algorithm are rejected."

I did research and I found interesting documents :

  1. https://lists.gnupg.org/pipermail/gnupg-devel/2019-November/034487.html
  2. https://github.com/bcgit/bc-java/issues/200
  3. https://arstechnica.com/information-technology/2020/01/pgp-keys-software-security-and-much-more-threatened-by-new-sha1-exploit/

From the second document, I understand that Bouncy Castle signs the sub-keys with the SHA1 algorithm, because that's what is specified by RFC4880.

If I look at a sub-key generated by GPG, I notice that GPG uses SHA256 as signing algorithm (algo = 8).

$ gpg --list-packets --verbose toto.gpg

:signature packet: algo 1, keyid 040E8937EDB35B90
        version 4, created 1587587801, md5len 0, sigclass 0x13
        digest algo 8, begin of digest 5a 9d
        subpkt 16 len 8 (issuer key ID 040E8937EDB35B90)

 

From the third document, I understand that it is not safe to use SHA1 signed sub-keys.

What is your point of view ? Is it really risky to use SHA1 signed sub-keys ?

Is there any plan to allow SHA256 as sub-key signing algorithm for the next version of Bouncy Castle ?

Thank you,

Denis






     


SEEBURGER AG   Vorstand/SEEBURGER Executive Board:
Sitz der Gesellschaft/Registered Office:   Axel Haas, Michael Kleeberg, Axel Otto, Dr. Martin Kuntz, Matthias Feßenbecker
Edisonstr. 1  
D-75015 Bretten
Vorsitzende des Aufsichtsrats/Chairperson of the SEEBURGER Supervisory Board:
Tel.: 07252 / 96 - 0
Prof. Dr. Simone Zeuchner
Fax: 07252 / 96 - 2222

Internet: http://www.seeburger.de
Registergericht/Commercial Register:
e-mail: [hidden email]
HRB 240708 Mannheim


Dieses E-Mail ist nur für den Empfänger bestimmt, an den es gerichtet ist und kann vertrauliches bzw. unter das Berufsgeheimnis fallendes Material enthalten. Jegliche darin enthaltene Ansicht oder Meinungsäußerung ist die des Autors und stellt nicht notwendigerweise die Ansicht oder Meinung der SEEBURGER AG dar. Sind Sie nicht der Empfänger, so haben Sie diese E-Mail irrtümlich erhalten und jegliche Verwendung, Veröffentlichung, Weiterleitung, Abschrift oder jeglicher Druck dieser E-Mail ist strengstens untersagt. Weder die SEEBURGER AG noch der Absender (Eckenfels. Bernd) übernehmen die Haftung für Viren; es obliegt Ihrer Verantwortung, die E-Mail und deren Anhänge auf Viren zu prüfen.

This email is intended only for the recipient(s) to whom it is addressed. This email may contain confidential material that may be protected by professional secrecy. Any fact or opinion contained, or expression of the material herein, does not necessarily reflect that of SEEBURGER AG. If you are not the addressee or if you have received this email in error, any use, publication or distribution including forwarding, copying or printing is strictly prohibited. Neither SEEBURGER AG, nor the sender (Eckenfels. Bernd) accept liability for viruses; it is your responsibility to check this email and its attachments for viruses.