
Brainpool curves - grey-area
http://bada55.cr.yp.to/brainpool.html
======
bazzargh
The link just points at the Brainpool curves, but the paper describing the
'new curves' etc is lots of fun.
([http://bada55.cr.yp.to/pubs.html](http://bada55.cr.yp.to/pubs.html), _How to
manipulate curve standards: a white paper for the black hat._ ) It takes a
swipe at the wider issue of how a procedure for picking constants like
Brainpool's can be gamed, by using a template procedure with lots of
'justifiable' choices - the hash function, the seed, etc, but only presenting
the one that leads to your 'known-weak' curve.

 _Our experience is that Alice and Bob, when faced with a single procedure
such as [BADA55-VPR 's] (or [Brainpool's]), find it extremely difficult to
envision the entire space of possible procedures (they typically see just a
few dimensions of flexibility), and find it inconceivable that the space could
have size as large as 2^20, never mind 2^30._ (s5.3)

I find it pretty hilarious that someone found a way to weaponize the old quote
"The wonderful thing about standards is that there are so many of them to
choose from"

------
brohee
If anyone wonders about the potential practical impact of the subversion of
the Brainpool curves, it's pretty bad, as the curves have been standardized
for use in TLS by RFC 7027.

Any other standard using Brainpool curves?

~~~
wolf550e
But nobody uses the Brainpool curves for TLS. Everyone uses NIST P-256 and
P-384, and everyone will move to Curve25519 "real soon now".

key exchange:

[https://tools.ietf.org/html/draft-irtf-cfrg-
curves-09](https://tools.ietf.org/html/draft-irtf-cfrg-curves-09)

signatures:

[https://www.ietf.org/mail-
archive/web/cfrg/current/msg07364....](https://www.ietf.org/mail-
archive/web/cfrg/current/msg07364.html)

~~~
brohee
Someone actively avoiding the NIST curves might use them, but it looks more
and more like chosing between Scylla and Charybdis.

~~~
wolf550e
Looks like Brainpool curves are not supported by NSS, SChannel or
SecureTransport, so they're useless for TLS when the client is a browser. If
the client is something that uses openssl, you can use them.

[https://en.wikipedia.org/wiki/Comparison_of_TLS_implementati...](https://en.wikipedia.org/wiki/Comparison_of_TLS_implementations#Supported_elliptic_curves)

------
tveita
So in the original specification, if B failed the non-square test, it would
start over with the next seed and regenerate both A and B.

In the RFC version, it will regenerate B until it is square, then do the other
security checks.

That's unfortunate, but the generated curve should still satisfy all the
requirements. There is little room for this to have an actual security impact.
You would need an unknown attack that the original specification did not guard
against, but randomly happened to avoid by its choice of seeding for the RFC
method to be worse.

