< cfields>
sipa / jonasschnelli: i pushed a quick hack to libbtcnet that adds an option for chunked reads as opposed to header+message. It's clunky, but should be enough to test with
< gmaxwell>
yippie. mutation testing proves the existing tests are inadequate.
< gmaxwell>
(for ct aes)
< jonasschnelli>
gmaxwell: what do you mean with inadequate? IIRC, the tests included a subset of the NIST test vectors.
< jonasschnelli>
Or do you aim in particular for something to test the CT?
< gmaxwell>
I mean I can add plausable bugs to the implementation which pass the vectors.
< gmaxwell>
I'll create more vectors to resolve this, of course.
< jonasschnelli>
Okay. Yes. That would be good.
< jonasschnelli>
Is the CT behavior somehow testable in a test script that should be portable enought?
< gmaxwell>
No, and not much reason to 'test' generally.. all the promises that can be given from C on that front are statically decidable.
< jonasschnelli>
For ChaCha20-poly1305, would this require two keys? One for the chacha cipher and one for the poly1305 AED?
< demaged>
besideds, what's the reason bitcoin isn't migrating to testing, stuck in ustable for years now :/
< wumpus>
I'm quite happy that bitcoin isn't packaged by distributions - we had some bad experiences in the past with ubuntu's bitcoin package being stuck at 0.3.x, for example.
< wumpus>
distributions have their own pecularities in versioning, releases, etc. I think it'd be better to release our own packages for various distros, like we do with the ppa.
< demaged>
wumpus, maybe though I think for the convenience of users, free auditing done by the maintaners, extra exposure and bug reporting, etc. is worth the cooperation
< wumpus>
well, feel free to do so
< wumpus>
I can say a lot of people have tried and failed :)
< wumpus>
and for example it doesn't help bug reporting *at all* if some distribution, in its stable release, keeps shipping bitcoin 10.2 forever. We'd get tons of reports against old versions, for bugs that have probably been solved ages ago.
< wumpus>
also philosophically, upgrading bitcoin core should be a conscioius decision. You may or may not agree with any consensus changes.
< wumpus>
that's why there are no auto-upgraders nor even new version notification in the client
< demaged>
wumpus, regarding your comment on bug reporting I disagree, imo it helps with the diversification of the ecosystem as it would be a disaster if all the nodes were on v0.12 for example
< demaged>
just wondering, debian has what 50k+ packages in its main repo, surely there's a way to cooperate otherewise the number wouldn't be so high
< demaged>
i agree with you on the point of forced upgrades but I don't see distro updates as such
< demaged>
anyway, I only wanted to point out that bug report in case it's interesting for devs as I don't have github account to report
< demaged>
from personal experience, I'm a sys-admin and have been running non-wallet full nodes on multiple servers I maintaining for many years now to help the network and having bitcoind package in Debian was always my biggest wish... for convenience... one day.
< demaged>
thanks
< wumpus>
no, it wouldn't be a disaster if all nodes were 0.12
< wumpus>
a group like debian indescriminately deciding what version a large part of the network runs is much more disastrous
< demaged>
wumpus, I'm sorry but you're wrong. With no safe fallback to nodes running v0.10 or v0.11 one critical security bug could bring the whole network down or worse.
< demaged>
Also, Debian is far from indiscriminate in their choices nor it would make up large part of the network. This would add to diversity and decentralisation of, for example, update channels, etc.
< wumpus>
what makes you think v0.10 or v0.11 is any safer?
< wumpus>
if anything, many security bugs get solved every release
< demaged>
wumpus, it may not contain bu that was introduced in v0.12
< demaged>
s/bu/bug
< demaged>
What if your infrastructure is compromised? What you're proposing is very dangerous.
< wumpus>
that's true, that is a reason why one would run multiple versions of bitcoin core, some people indeed do that
< wumpus>
consciouisly, not because a distro forces them to
< wumpus>
I'm not proposing anything but keeping the status quo, you are the one proposing something
< demaged>
in practical terms distro dosn't force me to do anything, it makes things more convenient
< demaged>
Decentralisation in terms of whether software can run on RasPi is important but so is decentralisation of update channels, development, ideas. Just m y 2c.
< wumpus>
the point is that distros are used by a lot of newbies, and for newbies the best choice is generally to use the latest and greatest version. Advanced users may indeed chose to run older versions for verious reasons, that's fine.
< wumpus>
in any case, I'm done discussing this
< demaged>
true, that's why different distros target different audience for example ubuntu and debian; diversification of bitoind for free :)
< demaged>
I didn't mean to sound pushy
< wumpus>
hm re: https://github.com/bitcoin/bitcoin/issues/7463, it seems that if bitcoind never spins up RPC (for example, if init failures) the successive bitcoin-cli -rpcwait getblockcount will wait forever
< wumpus>
that's something of a race condition, I think I'm going to implement the getblockcount loop myself, each time checking if bitcoind is still alive, instead of relying on -rpcwait
< GitHub25>
[bitcoin] laanwj opened pull request #7744: test_framework: detect failure of bitcoind startup (master...2016_03_detect_startup_failure) https://github.com/bitcoin/bitcoin/pull/7744
< wumpus>
voila
< wumpus>
heh "In fact one of the reasons given for OpenSSH's adoption of the chacha20-poly1305 crypto mechanisms (alongside Curve25519 and others) was that it finally allowed them to remove the last vestiges of OpenSSL from their code."
< instagibbs>
does an empty vector being serialized using READWRITE end up being read correctly? I'm running tests and have read the code to the best of my ability, but want to check.
< sipa>
it should
< instagibbs>
ok thanks
< instagibbs>
It appears you attach a size message of 0, then nothing else, which should be enough.
< gmaxwell>
jonasschnelli: I see your updated encryption draft. It doesn't appear to specify a KDF. The output of ECDH should not be used directly. (also, you're going to need a 256 bit session ID for later auth, and two 512 bit keys for the authenticated encryption); so that will be needed. I'm not sure if that ciphersuite negoiation procedure is sufficient to achieve the goal that if X is faster for bot
< gmaxwell>
h peers, they'll pick it... but regardless, both of their ciphersuite sets also need to be included in the KDF. Otherwise a MITM could force ciphersuite selection (say to a weaker cipher) without disrupting changing the session ID. Personally I'd just suggest dropping the negoation; having it and avoiding introducing downgrading attacks is hard... also supporting many ciphers pushes people to
< gmaxwell>
using kitchen soup crypto libraries, which is bad for attack surface.
< gmaxwell>
the input to the KDF should probably be the ECDH value, one of the public keys (doesn't matter which of the two-- assuming the pubkeys are all valid), and the offered paramters of each side.
< jonasschnelli>
gmaxwell: I'm kind of afk but will check you feedback and update the BIP. Thanks!
< sipa>
jonasschnelli: typically what you'll do is take the ECDH result (an EC point), and use that to seed some PRNG, from which you then draw the session key, encryption keys, ...
< sipa>
jonasschnelli: note that libsecp256k1 at this point does not return the ECDH result point directly, but it returns a SHA256 of it (which guarantees all its entropy is used)