It seems that the implementation of the brainpool-curves by the BSI (Bundesamt für Sicherheit in der Informationstechnik / Laufer) is potentially insecure (hard-coded SHA-1, etc ...); see analysis of the BADA55 Research Team unter DJB, etc.:
See additional informations to the group of brainpool-curves in an example of curve "brainpoolP256t1" at the site of DJB due to investigations on rigidity of elliptic curves: "SafeCurves Rigidity" by "Daniel J. Bernstein" and "Tanja Lange":
CVE-Details to the vulnerability "DragonBlood" in the WPA3 Wi-Fi standard that refers to the usage of brainpool-curves of the BSI:
Details to the vulnerability "DragonBlood" in the WPA3 Wi-Fi standard that refers to the usage of brainpool-curves of the BSI:
and in the Heise Security Forum:
In the most recent Security Considerations of the Wi-Fi Alliance ("Security Considerations"), the Diffie-Hellman Groups 27-30 (brainpool groups) are no longer listed in a diplomatic manner (WITHOUT EXPRESSLY REFERING TO THE NON-USE OF BRAINPOOL CURVES ):
In old Security Considerations of the Wi-Fi Alliance, the Diffie-Hellman Groups 27-30 (Brainpool groups) were still included (Suitable Diffie-Hellman Groups Page 5 / 7):
Diffie-Hellman Groups 27-30:
27 224-bit Random ECP group (Brainpool)
28 256-bit Random ECP group (Brainpool)
29 384-bit Random ECP group (Brainpool)
30 512-bit Random ECP group (Brainpool)
These curves were (among others) designed by the BSI (Lochter) ...
Details on hash-collisions by simulations on a SAGE-system (BADA55-Team):
--- cut here ---
For example, Figure 5.1
(designed to be shown tothe public) uses Brainpool’s procedure to generate a 224-bit curve. The outputconsists of the following “verifiably pseudorandom” integers p,a,b defining an elliptic curve y2 = x3 + ax + b over Fp:
b=0x6 [8AEC4BF8E84C659E]<==!! BB8B81DC39355A2EBFA3870D98976FA2F17D2D8D
In the case of the 160-bit, 224-bit, 320-bit, and 384-bit Brainpool curves, one can immediately demonstrate this discrepancy by observing that the gap listed between “seed A” and “seed B” in [14, Section 11] is larger than 1, while the standard procedure always produces a gap of exactly 1:
- Validation Data
seed_A: 2B7E151628AED2A6ABF7158809CF4F3C762E727A <= !
seed_B: 2B7E151628AED2A6ABF7158809CF4F3C762E727D <= !
--- cut here ---
At the sourcecode of GnuPG, you will see that the "Save Curves" of "Daniel J. Bernstein" (Curve 25519) and "Mike Hamburg" (Curve 448) are disabled, when activating the "VS-NfD" mode (de-vs) of the BSI and that their Barinpool Curves are prioritized.
Best regards ...