Hacker News Reader

Comment by tptacek | Hacker News Reader

I will match this bounty. Colin's word on whether it should be awarded is final, and Colin can reach out to me to tell me who I have to pay up to (or, if the recipient would prefer, I can transfer money to Colin and he can just double the bounty).

Colin: if you post this bounty publicly anywhere, you have my permission to note also my commitment to match the bounty, which will remain ongoing until either (a) your bounty changes, or (b) I notify you otherwise (which is unlikely).

Good luck, everyone. I will be surprised and happy if this HN comment costs me anything. :)

View on HN

Funny, I was just about to send you an email asking if you wanted to try your hand at this, given that you're much better at this sort of thing than I am. :-)

you have my permission to note also my commitment to match the bounty

Thanks! I've updated the blog post with a link to this comment.

Just to be candid: putting an extra $1000 into the pot is way less costly than me spending the time trying (and almost certainly failing) to get a heap overflow in Tarsnap working (even if were an easy one). Also: it's an easy bet for me to make, because at the figures we're talking about, I think we might be unlikely to attract the right talent. :P

But if there was anyone whose code I would bet on, your name at the top of the list anyways!

To be equally candid: I didn't think you would want the $1000, but I thought you might enjoy the challenge. Similarly, I think the people who are most likely to win this are going to be more interested by the puzzle than by the money. The $1000 is there mainly as linkbait to increase the odds that the right people hear about this.

But if there was anyone whose code I would bet on, your name at the top of the list anyways!

Well, we've already established that the code was wrong...

> Well, we've already established that the code was wrong...

Hah, it's been a while since I read:

http://www.daemonology.net/blog/2011-01-18-tarsnap-critical-...

Makes me feel a little less bad for the Debian issue with (way!) too low entropy in key-generation.

Refactoring code using crypto dangerous :-/

Have you considered creating a 2.0 on top of NaCL? I could see that it would probably not be a good idea to actually throw out all the existing tarsnap-code etc -- I generally just mean if you'd want to move to a simple, yet "batteries-included"/shrink-wrapped crypto library?

That's part of why I have code in libcperciva which is shared with other projects -- the new AESNI code in tarsnap was all tested via its inclusion in spiped and scrypt before it came into this tarsnap release.

Reply on news.ycombinator.com