Author: mario

What is the reason that the BSI does not allow Chacha20 / Poly 1305?

The BSI does not allow ChaCha20/Poly1305 in its technical guidelines such as TR-03116-4 because it is primarily based on the NSA’s Suites-B specification and established European or German standards. There are several reasons the Focus is on AES-GCM and CNSA Suites.

1. The BSI relies on AES (Advanced Encryption Standard), especially in AES-GCM (Galois/Counter Mode), because this algorithm is recommended by both the NSA and European standardization bodies such as ENISA and ISO/IEC. AES is highly optimized for modern hardware (e.g. AES-NI in x86 processors), which makes it efficient and secure to implement.

2. FIPS and Common Criteria certification. The BSI prefers algorithms that are certified according to FIPS 140-2/3 or Common Criteria (CC). ChaCha20/Poly1305 is less widely used in these circles than AES, especially for government applications.

3. AES has dedicated hardware acceleration (e.g. AES-NI on Intel/AMD or ARMv8-A Cryptography Extensions), while ChaCha20 was primarily intended for software-side implementations on CPUs without AES hardware. In modern environments, AES-GCM with hardware acceleration is usually faster than ChaCha20.

4. Assessment of security properties. Although ChaCha20 is considered secure, there is less formal security analysis and certification than for AES.
Poly1305 is an efficient MAC (Message Authentication Code), but the BSI prefers GCM because it is already closely coupled with AES.

5. Interoperability and long-term strategy. Government IT infrastructures rely on long-term support. AES has a clearly defined future (e.g. through the CNSA Suite 2.0), while ChaCha20 is not treated equally in official European crypto standards. Future migrations to post-quantum cryptography (PQC) are likely to build on AES-based hybrid approaches.

But why is there an algorithm with CBC? As far as I know, CBC is vulnerable to attacks.

Yes, you are right: CBC (Cipher Block Chaining) has known weaknesses, especially padding oracle attacks, which is why many security guidelines (e.g. TLS 1.3) have abolished it. The BSI continues to list AES-CBC in TR-03116-4 for the following reasons:

Backward compatibility with existing systems. Many older or security-critical systems (e.g. in administration or industry) are based on AES-CBC because it was the standard for a long time. A complete switch to AES-GCM is difficult in some environments because not all systems support GCM (e.g. smart cards or older hardware). AES-CBC is still widely used in IPsec, S/MIME, OpenPGP and other protocols. In some scenarios, CBC can be used safely if additional protection mechanisms are in place (e.g. Encrypt-then-MAC (EtM) instead of MAC-then-Encrypt).
In TLS 1.3, CBC was removed because padding oracle attacks were particularly critical there.
In other applications, especially for offline encryption or fixed protocols, CBC can remain secure under certain conditions.
If the BSI allows AES-CBC, then only with HMAC protection (Encrypt-then-MAC) or in precisely defined areas of use. Usually there are strict guidelines for IV handling and padding checking to prevent attacks.

What is the reason for specifying the brainpoolP256r1 curve?

The BSI’s specification of the brainpoolP256r1 curve (also known as brainpoolP256r1, more precisely brainpoolP256t1 or brainpoolP256r1) has several security and strategic reasons. Here are the most important: Alternative to NIST curves (e.g. secp256r1 / P-256) The NIST curves (e.g. secp256r1, also known as P-256) are widely used, but there has been distrust of the origin of the parameters for years. It is speculated that the choice of parameters for the NIST curves was influenced by the NSA, so that backdoors could possibly exist. Brainpool curves, on the other hand, were developed independently (by the ECC Brainpool group led by German cryptographers). Brainpool curves were designed specifically for European security standards and are preferred by the BSI in German government projects. They are specified in various BSI guidelines, e.g. TR-03111 (Cryptographic specifications for eID applications).
For NIST curves, the parameters are published, but their derivation is unclear. The parameters of the Brainpool curves were generated using an open, traceable process.
Brainpool curves are specified in many European protocols, including eIDAS (electronic identities and signatures in the EU), German smart cards, TR-03110 (security of electronic identities). Brainpool curves were chosen to make certain timing and side-channel attacks more difficult, especially in hardware-based implementations. Their structure is intended to prevent implementation errors from leading to vulnerabilities.