[Cryptography] open questions in secure protocol design?

ianG iang at iang.org
Tue Jun 2 06:54:26 EDT 2015


On 30/05/2015 02:49 am, Tony Arcieri wrote:
> On Fri, May 29, 2015 at 6:24 PM, ianG <iang at iang.org
> <mailto:iang at iang.org>> wrote:
>
>         Strongly disagree. I have a long-form comment on this as part of
>         this
>         blog post (see "A Bitcoin Crypto Meltdown")
>
>         http://tonyarcieri.com/the-death-of-bitcoin
>
>
>
>     Except, you changed the topic.  Coming back to the topic ... do you
>     disagree that Bitcoin uses one alg for each function?  Oh wait, your
>     post is about how you agree that it's only using one alg.
>
>     You're real disagreement is that you don't like that it is using one
>     alg, and predict it will therefore melt-down :)
>
>
> Satoshi chose a bad curve. Nobody who knows anything about ECC would
> suggest using secp256k1 over Curve25519.


Nah.  You can't make the point like that.  You have to make it from the 
context of 2007-2008 timeframe.

   What was the environment like then?  nobody cared.

   Did Curve25519 even exist?  Yes.  But safecurves.cr.yp.to didn't.

   Where the problems then known?  No, not widespreadly.

   Did a reasonably good engineer have access to this info?  No - he 
talked here, and nobody blinked.

   Did he pick a ciphersuite that lasted a good while?  Yes - in year 7.



Picking a bad curve is a given - we only have to wait long enough for 
that to come true.  The engineering comes in being prepared for that 
day.  Until recently, very few have thought about this problem.



> They should switch, if only
> because that 1-bit backdoor is particularly scary, but they can't do
> that easily because the Bitcoin protocol has nothing to signal that
> wallet keys are anything but ECDSA with secp256k1.


Apparently they've got something.  But whether it is good enough to move 
I don't know.

What they might want to do is to develop a future algorithm, so that 
they are ready for the event when it happens.  Trying to push people to 
change beforehand without clear evidence (losses) will be hard, here cue 
in the recent debate about the block size.


>     Actually, I suspect regardless of our views, Bitcoin is locked into
>     the 1TCS for now.  Because if they add another algorithm, it is
>     totally worthless until every client has got it.  Which to
>     paraphrase Peter "will make them think."  And we will benefit from
>     the experience.
>
>
> I expect that Bitcoin and/or future pubkey-based decentralized
> transaction consensus protocols will begin switching to Ed25519 soon.

I just checked, three I asked haven't switched and don't have much 
intention to do so.

> The interop problem is a difficult one, and the reason why most sites
> continue to use RSA certificates for TLS. But forward progress is
> possible. AES-GCM is seeing widespread usage now where just a few years
> ago AES-CBC and RC4 were the norm.


So, think about the protocol for a bit.  Let's say we put into Bitcoin a 
new feature such that the chief scientist can launch a packet into the 
blockchain that causes the key algorithm to change to say Curve25519. 
(Wave away the mining consensus problem for now.)

Is that going to fix it?  No.  These keys aren't ephemeral like AES, 
where as you noted there has been progress.  They aren't even 
short-lifetime like certs that expire every 2 years.  These are keys 
holding *value* and some of these keys remain dormant for years.  Indeed 
there is a sub-sector called cold storage built around this opportunity.

So, we can probably rule out 1TCS as a complete answer because just 
shipping a better version in a new protocol doesn't say anything about 
the older keys -- which is the real problem they have.  Same with 
classical view on 'algorithmic agility' which handwaves about the 
existing product out there.  Legacy keys is such a dominating issue, 
that the engineering probably wants to focus on that, and when that is 
solved, see what else is left.

Absent a key expiry concept or a key pensioning system or a revocation 
method ... this is a hard problem.


> Given Bitcoin's lack of cipher agility, using Ed25519 instead of
> secp256k1 provides another checkmark on a gumball chart for any would-be
> Bitcoin killer. Secure elliptic curve according to safecurves.cr.yp.to
> <http://safecurves.cr.yp.to>? Usurper: check.


I doubt.  Most all the world has no idea what crypto Bitcoin uses, and 
the altCoins have barely scratched at Bitcoin, regardless of what 
difference they pretend.  Why would a "stronger key" make a difference, 
absent any actual key attacks?

Empirical evidence on the ground suggests they want an 
easier-to-implement key not a stronger one.  Including a better RNG ;-)



iang


More information about the cryptography mailing list