This is in respose to http://blog.bettercrypto.com/?p=1004 Unfortunately
the site claims to allow responses but just eats them.



That you are aggressively promoting the controversial
(http://crypto.stackexchange.com/questions/10263/should-we-trust-the-nist-recommended-ecc-parameters)
secp256r1 at this point over the rigid secp256k1, really makes this
bundle of posts a joyous bit of comedy. Thank you.

If you're actually interested in contributing to the Bitcoin
ecosystem: we do our work out in the open and all are invited to the
Bitcoin-development mailing-list. But, keep in mind: You'll be asked to
substantiate your claims by the very experts you so stridently claim do
not exist, and may be ignored if you cannot maintain a reasonable level
of professionalism. It's may be easier addressing an ignorant audience
who won't question your mistakes or misunderstanding, or find themselves
offended when you've decided to try to promote your own reputation by
attacking the reputation (or existence) of others which you've never
worked with or spoken to, so I understand why you may prefer to not
share your views with the Bitcoin community.

Since you're clearly somewhat ignorant on the subject-- and I don't
believe in hiding away knowledge, I'll take a moment to actually educate
you about a little bit of the relevant cryptography:

The curve used in Bitcoin was originally specified in the
same standards documents as the curves now endorsed by NIST.
STANDARDS FOR EFFICIENT CRYPTOGRAPHY by Certicom Research in the
document "SEC 2: Recommended Elliptic Curve Domain Parameters"
published in 2000.  (You can find a copy of the 2000 version here:
http://perso.univ-rennes1.fr/sylvain.duquesne/master/standards/sec2_final.pdf)

Unlike some curves Secp256k1's parameters are constrained by the security
and performance requirements. Curves like secp256r1 (NIST P-256) are taken
from the output of a CSPRNG with an seemingly high entropy unexplained
(and apparently unexplainable) seed.

In the case of secp256k1 you can simply state the requirements and
start testing candidate coefficients from intuitive starting positions
(e.g. zero) and arrive at secp256k1. The constraint is so tight as
to make the solution basically unique (there are only six possible GLV
curves for any chosen field, and usually the resulting group order is not
prime). (Fortuitously, you can even eliminate many of the requirements and
arrive at the same result). This doesn't eliminate all possible problems
but it does narrow level of control that could be used to intentionally
select a weak curve.

It's possible that new advances could make any curve selection turn
out to be insecure. But only curves with unexplained 'random' inputs
could have been specifically selected to expose known-to-some one in
trillion weaknesses, as amusingly demonstrated by DJB's "BADA55" curves:
http://safecurves.cr.yp.to/bada55.html

As a result such unexplained parameters are strongly frowned on. I doubt
any new standard could get away with that approach today, it's only
inertia and installed base that keep people on P-256. In the context of
Bitcoin an unexplainable high entropy magic number would be a constant
source of not-completely-non-credible FUD that the cryptosystem was
explicitly back doored. It really isn't a consideration.  In a laughable
turn, it would seem that your advise is-- in fact-- the advice no sensible
cryptographer would actually make today. This has a strong parallel with
Dual_EC_DRBG: it's prudent to reject unexplained high entropy paramters.

Though secp256k1 isn't one of the most widely used curves, its not
unique to Bitcoin. As far as I know, at the time of Bitcoin's creation
was the only standardized and widely deployed (e.g. in OpenSSL) non
characteristic-2 curve that didn't have unexplinable high entropy
parameters. It also has very good performance characteristics. (see below)

[Adoption wasn't helped that SECG referred to it as 'Kobilitz' curve,
since the endomorphism can be used in a manner similar to the frobenius
map; but this often causes it to get confused with the binary extension
field curves.]

>  vague very academic shortcut attacks and definite suspicion [...]
> which just happens to be incredibly low for the bitcoin secp256k1

There is nothing vague-- except perhaps DJB's ed25519 promotion page's
short coverage of the subject-- nor is it mysterious or a happenstance.
Secp256k1 is specifically constructed to enable the use of the GLV
method (https://www.iacr.org/archive/crypto2001/21390189.pdf). This
requires that the CM field discriminant be low so that the CM method
can be used to find the parameters. The result is that secp256k1 is,
if you choose to use these optimizations, the fastest standardized
curve that I'm aware of and the fastest curve I've seen implemented at
all that doesn't resort to more exotic approaches like extension fields
(and the extra constraints around weil descent).

This speedup is useful constructively, for faster signing and
verification, as well as destructively: it speeds up the rho attack
because with only two more field multiplies you can extract 6 points
from a single addition, instead of the usual 2.  Many competing curves
(e.g. ed25519) have smaller order such that they're less rho-secure
than secp256k1 even when considering the bit secp256k1 loses to the
endomorphism speedup, and yet they're considered secure.

In Bitcoin's case selecting a high performance curve may well turn
out to be an important _security_ consideration: We have a fundamental
trade off between how decentralized our system is (consensus security)
and what scale it can achieve, because additional costs in enforcing the
rules of the system can cause people to drop out of participating in
enforcing its rules.  Because the soundness of the consensus parts of
Bitcoin are much weaker than the more traditional absolutely sound or
computationally-sound cryptographic parts it can be a very intelligent
trade-off to favor decisions that help the decentralized consensus,
even if there is some degradation elsewhere.  Though generally it seems
that bandwidth limitations are more pressing than computational ones,
though we've been making advances on the bandwidth front.

In regard to your comments about agility:  The Bitcoin system itself was
designed to be agile and it includes specific affordances (e.g. no-op
instructions in script) to allow users to use new signature systems
without breaking compatibility for existing users at all. The community
has previously used this capability to provide a complete replacement
called P2SH for the method used to specify recipients (scriptPubkeys)
which allowed arbitrarily complex access policies, to be specified via
a single 160 bit value.

Like other systems, Bitcoin takes a substantial complexity penalty
for this agility and suffered for it. This is a pattern we've seen
elsewhere: E.g. agility in SSL/TLS has introduced many more severe
emergency grade vulnerabilities than we would have had from a less
agile system. While there are benefits to agility given that the
security of the _complete_ system is always our goal I think the
people arguing for less agility are rightfully gaining more traction
in the standards bodies, but for better or worse Bitcoin is already agile.

The specific upgrade path you propose (in your other post), however,
would not work-- At least not as described: Bitcoin is a consensus system
and all it's participants reach the same conclusion about the validity
of the chain, you cannot generally just "permit" something new which is
currently forbidden except through the specifically mechanisms we have
for forward compatible upgrading, or otherwise the consensus will diverge
and there is (and should be) no central authority which can mandate what
software people run.  Your additional point about prohibiting the old
cryptosystem would generally be regarded as theft by current owners of
Bitcoin who might be left behind.

Its likely that bitcoin will deploy additional cryptographic tools in the
future(*), though they'll be ones that actually add value, as development
in this space requires conservative engineering significantly beyond
ordinary cryptographic systems due to the high level of shared fate in
consensus systems and the coordination challenges of a decentralized
system.

(*e.g. because of FUD related to quantum computers, I implemented lamport
signatures (well technically a Winternitz hash based signature)  back in
2012; but interest in the area hasn't grown and bandwidth constraints
probably remain our greatest true security challenge when considering
the whole system. I didn't publish the system publicly in order to avoid
having to compete against my own code-- by people who scrape the Bitcoin
community for code and ideas to promote their altcoin systems, but if
there were a serious concern about existing cryptographic tools in the
system new ones could be deployed in weeks via the existing backwards
compatibility infrastructure.)

Much of the work we've done on libsecp256k1 is applicable to other
curves (including the several novel algebraic optimizations applicable
to DSA verification that we've discovered) and for the only likely to be
publicly acceptable alternative (ed25519; though I am unhappy that it has
a co-factor since protocol designers often make errors as a result of not
handling that) there are already highly performant implementations. We
will need to continue to support secp256k1 regardless of what is added,
having a state of the art implementation of what we're using is in no
way commitment to not use something else... it's just that right now,
the alternatives-- and certainly your alternative-- are not attractive.

Cheers,
Greg Maxwell