BUIP idea: BU version of BIP151

priestc

Member
Nov 19, 2015
94
191
BIP151 is a core proposal to add authentication and encryption to the bitcoin protocol. I think pretty much the entire Bitcoin Unlimited community agrees with the *intent* of the BIP151 proposal. What many BU people may not agree with is the way the core developers are going about implementing this proposal.

At the Scaling Bitcoin conference in Milan, a presenter made the case of a lightweight wallet running on a smart phone connecting to a node of the owners choosing, instead of that smartphone wallet connecting to a random node on the network. This functionality is something that is needed.

Th eproblem is that the core developers are doing this by not using OpenSSL, and are instead writing their own implementation of all the crypto. This is bad because writing cryptography code requires a lot of work and requires cryptography experts to review the code. A better approach is to utilize existing libraries. This way instead of taking months and months, the update can take merely weeks or even days.

This is how it should be implemented:

* In the settings dialog there should be a button that reads "set up blockchain API". When you click that button, the software downloads three pieces of software: Bitpay Insight, the Let's Encrypt script, and dyndns setup script.

* Below the button there is a field where the user can enter their preferred node name.

* Bitpay Insight is installed and is automatically configured to use the blockchain data. Lets Encrypt is invoked and a SSL certificate is issued and installed into the built in webserver that comes with Insight (which is provided by Node)

* Dyndns (or some other DNS provider) is invoked and the DNS entry is pointed to the Insight API running on that machine.

The result is a running API instance running on that node and is publically available to whoever knows the domain. If the user enters "my_cool_node" into the "Node name" box, the API will be access by going to https://my_cool_node.dyndns.com.

Then the user can install a mobile wallet on their phone that uses the Bitpay Insight API, and then can enter "my_cool_node.dnsdns.com" into that wallet, and it will always use the node of the user's choice through Insight. Encryption is handled by HTTPS, and is sybil attack resistant.

The advantage of doing it this way is that the code that needs to be written is basically packaging code, instead of cryptography code. There should be less effort required in testing, and the whole thing should get done in orders of magnitude faster time that Core's BIP151 approach.
 

priestc

Member
Nov 19, 2015
94
191
Yes, there should be multiple dynamic DNS providers. It should work like how you enter DNS servers when you register a dimain:

ns1.webhost.com
ns2.webhost.com
ns3.webhost.com
ns4.webhost.com

You should be able to plug your lightweight smartphone wallet into your full node ran from home by entering multiple names going to the same place:

my_cool_node.no-ip.org
my_cool_node.dyndns.com
my_cool_node.someotherservice.com
my_cool_node.anotherservice.com

If any of the four are up, the connection will be made. A connection can not be made only if all 4 services are down.
 

HelloGuy

Member
Mar 16, 2016
42
20
Core writing all the cryptographic related code themselves is for security reasons. They used to find related bugs of OpenSSL in the process. They have good intention to make the Bitcoin software very safe. Lots of the libraries are open source, which means they usually are poorly funded and poorly reviewed, though widely used. OpenSSL got a serious bug(https://en.wikipedia.org/wiki/Heartbleed) for years without being found, and the whole project merely got any donation support before the bug was found.
 

priestc

Member
Nov 19, 2015
94
191
Core writing all the cryptographic related code themselves is for security reasons.
This is completely unnecessary. OpenSSL is what Google, Facebook, Amazon and many many others use. If it's good enough for them it's good enough for bitcoin.

They have good intention to make the Bitcoin software very safe.
I'm sure their intentions are good. Robert Mugabe's intentions are also to make Zimbabwe a better country, but unfortunately intentions do not dictate reality. There is a saying that "The road to Hell is paved with good intentions". If you google the phrase, it'll tell you: An alternative form is "Hell is full of good meanings, but Heaven is full of good works"

https://www.google.com/webhp?sourceid=chrome-instant&rlz=1C5CHFA_enUS706US706&ion=1&espv=2&ie=UTF-8#q="paved with good intentions"

Which I think is a better saying. Core's approach to BIP151 will never be completed. It'll take just as long to rewrite OpenSSL as it took to build OpenSSL in the first place, which is probably years. I'll eat my hat of BIP151 is ready to use before 2020. The plan in my OP can be ready to use before the end of the year if you can find a Node expert who knows the internals of deploying Node projects through HTTPS.

OpenSSL got a serious bug(https://en.wikipedia.org/wiki/Heartbleed) for years without being found, and the whole project merely got any donation support before the bug was found.
Just because software had had a vulnerability once in the past does not justify a complete rewrite. There has been security vulnerabilities found in Chrome, Windows, Linux, and many other pieces of software, that does not make it a good idea to rewrite those for any purpose.
 

Jonas Schnelli

New Member
Nov 8, 2016
2
1
Is is probably simple to do the implementation with openSSL.
But maybe research first the reason, why BIP151 is based on ChaCha20Poly1305@openssh and do a quick research why openSSH has its openSSL free implementation/mode.

Core is not inventing new crypto.
Core has the plan to just use well known crypto (ChaCha20Poly1305) from a well tested library (openSSH). Core has the plan to copy out the code of openSSH.

Also, the implementation ChaCha20Poly1305@openssl is relatively simple. Its a symmetric stream cipher. Code is ~300 lines of code. Two or three audits (by some researches) after the implementation has been done (copied) should probably be sufficient.
I wonder if openSSL has its own ChaCha20Poly1305 implementation and if it was really audited.
 
  • Like
Reactions: freetrader

freetrader

Moderator
Staff member
Dec 16, 2015
2,806
6,088
I wonder if openSSL has its own ChaCha20Poly1305 implementation and if it was really audited.
Major changes between OpenSSL 1.0.2h and OpenSSL 1.1.0 [25 Aug 2016]
  • Support for ChaCha20 and Poly1305 added to libcrypto and libssl
Not sure if its "their own" (haven't compared). An audit should be underway, I haven't seen results announced from this:
https://cryptoservices.github.io/openssl/2015/03/09/openssl-audit.html

It seems the audit initiative predates the announcement for 1.1.0 with ChaCha20 / Poly1305, so it may not be covered.

Also: http://isopensslauditedyet.com/

 
Last edited:

priestc

Member
Nov 19, 2015
94
191
Is is probably simple to do the implementation with openSSL.
But maybe research first the reason, why BIP151 is based on ChaCha20Poly1305@openssh and do a quick research why openSSH has its openSSL free implementation/mode.
What exactly am I supposed to be researching?

Core is not inventing new crypto.
Core has the plan to just use well known crypto (ChaCha20Poly1305) from a well tested library (openSSH). Core has the plan to copy out the code of openSSH.
What I don't get is, if you're just going to copy OpenSSH, then why not just *use* OpenSSH? What is the benefit to extracting the code?
 

Jonas Schnelli

New Member
Nov 8, 2016
2
1
What I don't get is, if you're just going to copy OpenSSH, then why not just *use* OpenSSH? What is the benefit to extracting the code?​

I think you mix up openSSH with openSSL.
openSSH has a slightly different ChaCha20Poly1305 AEAD then the one implemented in OpenSSL (the IETF one).
Have a look at the draft version of the extracted implementation, is extremely straight forward:
https://github.com/jonasschnelli/chacha20poly1305

And check this (https://www.openssl.org/news/secadv/20161110.txt).
OpenSSL recently disclosed a heap buffer overflow in its chacha20poly1305 implementation.
 

sickpig

Active Member
Aug 28, 2015
926
2,541
Core has the plan to just use well known crypto (ChaCha20Poly1305) from a well tested library (openSSH). Core has the plan to copy out the code of openSSH.
Doesn't libssh expose the crypto you need?