--- Log opened Mon Mar 11 00:00:13 2019
02:16 -!- TamasBlummer1 [~Thunderbi@p200300DD670F9D98CD2DA3DC56E0C496.dip0.t-ipconnect.de] has joined #rust-bitcoin
02:18 -!- TamasBlummer [~Thunderbi@p200300DD670F9D9455390938040F2904.dip0.t-ipconnect.de] has quit [Ping timeout: 264 seconds]
02:18 -!- TamasBlummer1 is now known as TamasBlummer
02:40 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #rust-bitcoin
05:26 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
05:26 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #rust-bitcoin
06:17 < stevenroose> nickler: any suggestions for it? I've incorporated a lot of the suggestions put there over time. Lost track of it a bit since, but I can take it back up.
06:30 -!- belcher [~belcher@unaffiliated/belcher] has joined #rust-bitcoin
06:44 < stevenroose> If that is preferred, I can make an alternative PR that does just i64/msat (no generalization over the internal unit) that exposes the same API.
08:42 -!- eugene_nickname [ad4462ba@gateway/web/freenode/ip.173.68.98.186] has joined #rust-bitcoin
08:50 < eugene_nickname> So..q for people involved with the rust-lightning project.  I see that protocol fuzzing is implemented in a way where you setup some nodes, accept a random blob of bytes from a fuzzer, and each byte operates on the state in some way.  I have a very minimal understanding of rust, but from the chanmon_fail_consistency.rs file I think this is what's happening.  Has this approach been very successful?
08:53 < eugene_nickname> I think in the way the fuzzer is currently being used, it just provides randomness really and that a typical coverage-guided fuzzer (with the exception of syzkaller) will just get confused on the inputs and start generating noise (which can still be a very viable method of fuzzing!)
08:54 < eugene_nickname> Also, because you are fuzzing the protocol itself and not something shallow like deserialization, have you had any hash collision issues with the underlying fuzzers (specifically AFL)?
08:56 < eugene_nickname> I ask all of this because I want to do something similar for lnd so any advice / comments / what have you help
08:58 < andytoshi> BlueMatt: ^
08:59 < andytoshi> my understanding is (a) yes, it's been incredibly successfull; (b) we had to stub out a ton of the crypto stuff to prevent the fuzzer getting stuck (see the "fuzztarget" feature in rust-secp256k1)
09:28 -!- icota [~igor@4-173.dsl.iskon.hr] has joined #rust-bitcoin
10:23 < BlueMatt> eugene_nickname: what do you mean by "hash collision in the underlying fuzzer"? we stubbed out the hashes themselves so we have lots of collisions of sha256, but I presume thats not what you meant
10:24 < BlueMatt> and, yes, its not quite what most fuzzers are optimized for, but they've generally been really quite good at branching into related things so I dont think the coverage-guidance is all that bad there
10:24 < BlueMatt> out of curiosity, how do you plan on doing something similar with lnd?
10:45 < gmaxwell> he's referring to the coverage maps
10:55 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Ping timeout: 256 seconds]
10:57 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-dgjuhnfslgicarss] has joined #rust-bitcoin
11:00 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #rust-bitcoin
11:27 < BlueMatt> yea....how does one check for such cases?
12:58 -!- eugene_nickname [ad4462ba@gateway/web/freenode/ip.173.68.98.186] has quit [Ping timeout: 256 seconds]
14:27 < nickler> stevenroose: tbh I haven't really looked into the PR because discussion was long and with so many people that I thought it was better when I didn't get involved
15:15 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 256 seconds]
16:01 -!- icota [~igor@4-173.dsl.iskon.hr] has quit [Quit: Konversation terminated!]
16:06 -!- eugene_nickname [43f720fa@gateway/web/freenode/ip.67.247.32.250] has joined #rust-bitcoin
16:08 < eugene_nickname> BlueMatt: yeah I guess why I've never used this approach to fuzzing (which I'm learning is actually pretty good!) initially is that the fuzzer performs suboptimal mutations.
16:09 < eugene_nickname> Since you have a limited range of values you accept (0x00 -> 0x1e), fuzzer mutates on a lot of garbage data.  Bit flips, byte flips, int insertion would all be suboptimal.  But the fact that the fuzzer is coverage-guided makes up for this.  I think fuzzers are moving in a direction where performing command sequences becomes the norm and will get improved
16:11 < eugene_nickname> For the coverage bitmap hash collision, you can't really directly see it unless you modified AFL, but you CAN look at your bitmap coverage % in the AFL output and compare to here: http://chao.100871.net/papers/oakland18.pdf
16:12 < eugene_nickname> Table I in that paper roughly shows the correlation between # of edges & collision percentage.  It's also obvious if you look at the coverage and if there are any basic blocks that SHOULD be hit, but aren't getting hit
16:12 < eugene_nickname> I was wondering specifically about hash collision b/c fuzzing at the protocol level would have a lot of edges I think, so it's possible some blocks weren't being hit due to collision
16:14 < eugene_nickname> Since the fuzzer mutates on unused data (0x1f and greater), you COULD like specify "ranges" that signify certain functions but this might? confuse the fuzzer.  Not too sure about that
16:16 < eugene_nickname> Specifically re: lnd, I wanted to fuzz the brontide handshake in a similar vein. Something like successful encryption + decryption where initiator encrypts, successful encryption + decryption where responder encrypts, failed encryption + decryption both sides, key rotation.  And have that be a command sequence supplied by the fuzzer
16:17 < eugene_nickname> And then eventually, use your rust tests as a guide and see if I could fuzz something more complex
16:17 < eugene_nickname> Anyways, gotta go but I can read this chat later
16:17 -!- eugene_nickname [43f720fa@gateway/web/freenode/ip.67.247.32.250] has quit [Quit: Page closed]
17:40 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-dgjuhnfslgicarss] has quit [Quit: Connection closed for inactivity]
17:54 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #rust-bitcoin
18:41 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 256 seconds]
23:02 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Ping timeout: 256 seconds]
23:08 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #rust-bitcoin
--- Log closed Tue Mar 12 00:00:14 2019