--- Log opened Sun Dec 01 00:00:24 2019
00:12 < elichai2> Andytoshi, lol. Isn't that just pure aes though? (you probably want an AEAD)
00:12 < elichai2> And you're out again :/
00:52 -!- reallll is now known as belcher
01:53 -!- jonatack [~jon@2a01:e35:8aba:8220:6627:dad:d967:649d] has quit [Quit: jonatack]
02:52 -!- nijynot [~nijynot@h-177-96.A785.priv.bahnhof.se] has joined #rust-bitcoin
03:17 -!- nijynot [~nijynot@h-177-96.A785.priv.bahnhof.se] has quit [Ping timeout: 250 seconds]
04:44 < stevenroose> In what cases does the Rust Bitcoin decoding give a "failed to fill whole buffer" error? Anytime a length prefix is higher than the remaining buffer length?
04:44 < stevenroose> it's an io::ErrorKind::UnexpectedEof
05:31 < elichai2> yes. if there's not enough bytes in the file/reader
06:00 -!- andytoshi [~apoelstra@wpsoftware.net] has joined #rust-bitcoin
06:00 -!- andytoshi [~apoelstra@wpsoftware.net] has quit [Changing host]
06:00 -!- andytoshi [~apoelstra@unaffiliated/andytoshi] has joined #rust-bitcoin
06:06 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
06:06 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has joined #rust-bitcoin
07:00 < dr-orlovsky> andytoshi: while you are here, what do you think about adding other hash types, namely MerkleRoot, MerkleBranch (which may be useful for Taproot as well), SigHash, WitnessHash (for the root witness commitment) and FilterHash?
07:01 < dr-orlovsky> oh, I see, you have thumbed up for that in github, Ok, I'll work on them
07:11 < andytoshi> oh, i should have clarified a bit
07:11 < andytoshi> there are different kinds of merkle roots
07:11 < andytoshi> the ones in blocks, the ones in taproot
07:11 < andytoshi> and these should be distinct
07:13 < dr-orlovsky> in Taproot, as far as I understand, will be a tagged branches/root, implying a different type (wrapper around TaggedHash, not a simple hash)
07:13 < dr-orlovsky> but I will do just a block level for now, since Taproot spec is not finished
07:14 < elichai2> elichai2: Andytoshi, lol. Isn't that just pure aes though? (you probably want an AEAD)
07:15 < elichai2> andytoshi: and related to what you and Matt were talking, I personally would be honored to be a maintainer in rust-bitcoin
07:21 < andytoshi> elichai2: cool, i'll make you a maintainer
07:21 < andytoshi> and yes, pieter's code is just the block cipher
07:22 < andytoshi> the cipher modes are not that hard :)
07:22 < andytoshi> dr-orlovsky: ah good point about taproot branches
07:34 < elichai2> andytoshi: yeah, altough GCM seems a bit complicated (but I didn't have a chance to implement so idk). at any case I think these days I prefer chacha-poly over aes for the exact reason of why aes is hard to implement correctly :)
07:34 < andytoshi> so fortunately(?) i just need to be compatible with existing software
07:34 < andytoshi> and nothing implements gcm
07:34 < andytoshi> everything is cbc or ctr (eeek)
07:34 < elichai2> oh ok. so yeah, regular CTR/CBC is quite easy
07:35 < andytoshi> and sometimes things layer on a weird broken authentication scheme
07:35 < andytoshi> eg signing with a different key, or signing keys instead of signing -with- keys
07:35 < elichai2> the more time passes the more i'm scared everything out there is broken lol
07:35 < andytoshi> lol
07:36 < elichai2> I'm reading now papers on what happens when you do `H_1(H_2(INPUT))` with 2 different CRH functions. and it doesn't sound good lol
07:36 < andytoshi> oh fun
07:37 < andytoshi> it's actually likely fine in practice if both functions are secure hashes
07:37 < andytoshi> but you do reduce the security to the minimum of the two (at least for collision resistance) rather than adding them
07:38 < elichai2> some papers suggest you might even lower it lower than that. especially if they're both Merkle Damgard constructions
07:38 < elichai2> but i
07:38 < elichai2> *but i'm still at a reading phase heh
07:39 < elichai2> andytoshi: do you consider RIPEMD160 a secure hash function?
07:41 < elichai2> anyway, i'm not trying to say that anything right now is insecure, i'm just reading on how suboptimal is these things :) (altough right now it seems like everything is still theoretical, couldn't find an attack in the wild that exploits the `H_1(H_2(INPUT))` case)
07:47 < andytoshi> yes i consider ripemd160 "secure", in that afaik it has almost 160 bits of security against preimage attacks and 80 against collisions
07:48 < andytoshi> and it is true that in bitcoin, the collision security of legacy addresses is only 80 bits because of this construction, so you can't use them for multisig without additional precautions
07:49 < andytoshi> elichai2: if you click on https://github.com/rust-bitcoin/rust-bitcoin/invitations you should have write access now
07:50 < andytoshi> i'm curious what MD-specific vulnerabilities to H1(H2(...)) you find
07:51 < andytoshi> my guess is that, as usual, bitcoin is accidentally safe by virtue of having self-describing data structures, lots of highly-constrained fields, and lots of cryptographically-random-looking fields
07:52 < elichai2> On my phone now, I'll send you the paper when I'm on the computer and/or write an explanation when I finish reading and hopefully understand heh
07:54 < elichai2> Iirc ripemd160 already have collisions and maybe even a 2nd preimage in the wild, I don't belive it will stay too safe for a while, but as you said because of how bitcoin works collisions/preimage to a p2pkh doesn't immediately means stealing coins
07:55 < andytoshi> i don't think there are collisions on full-round ripemd160. https://en.wikipedia.org/wiki/Hash_function_security_summary says we're ok. but agreed, for how long?
07:55 < andytoshi> maybe that bitcoin's move away from it will reduce the incentive
08:04 < elichai2> andytoshi: I clicked agree on the invitation, Altough it's weird (different than what I'm used to) because it's access and not joining the organization, I should try acking something and see if it's green hehe
08:04 < andytoshi> oh i thought you were already in the org. one sec
08:05 < andytoshi> (a) you are not; (b) matt is the only one who can add people
08:05 < andytoshi> BlueMatt: can you add elichai2 to the rust-bitcoin org
08:05 < andytoshi> and increase my permissions :P
08:06 < dr-orlovsky> If you can also add me to the org I will appreciate that as well
08:07 < andytoshi> +!
08:07 < andytoshi> +1
09:11 -!- Netsplit *.net <-> *.split quits: philbw4, dr-orlovsky, kanzure, stevenroose, wumpus, elichai2, jamesob, titanbiscuit
09:12 -!- Netsplit over, joins: dr-orlovsky, kanzure, elichai2, jamesob, stevenroose, wumpus, titanbiscuit, philbw4
09:12 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-siqapwxxfgnswisr] has quit [Max SendQ exceeded]
09:14 -!- elichai2 [sid212594@gateway/web/irccloud.com/x-btcupeghbgvkjake] has joined #rust-bitcoin
14:21 -!- TamasBlummer1 [~Thunderbi@p200300DD671264319D69360EED605E75.dip0.t-ipconnect.de] has joined #rust-bitcoin
14:23 -!- TamasBlummer [~Thunderbi@p200300DD671264239D69360EED605E75.dip0.t-ipconnect.de] has quit [Ping timeout: 264 seconds]
14:23 -!- TamasBlummer1 is now known as TamasBlummer
15:46 < BlueMatt> andytoshi: huh?! I thought you had super permissions on the org......
15:46 < BlueMatt> grrr I hate github
15:47 < BlueMatt> andytoshi: hmm, guess you didnt. you do now.
15:48 < BlueMatt> andytoshi: note, however, that member of the org appears to grant ~0 permissions. its the per-repo permissions that matter (and are separate)
17:11 -!- andytoshi [~apoelstra@unaffiliated/andytoshi] has quit [Ping timeout: 240 seconds]
19:27 -!- reallll [~belcher@unaffiliated/belcher] has joined #rust-bitcoin
19:30 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 252 seconds]
--- Log closed Mon Dec 02 00:00:25 2019