Hey all, been a hectic period of time since the initial release of my library.

We were going to release the latest crypto utility along with the initial release, but nerves got the better of us. Anyway, it is all sorted, and there is a $250K AUD reward for anyone who can undo my goods.

Moderators: If this belongs in amongst the original release thread, please advise and I will delete and move accordingly if necessary.

https://2ton.com.au/throwdown/

Cheers!

A must for all of those interested in easy money that cannot be so easy.

I am just wondering who is going to pay such a significant prize. Or are they so confident in their work they know no one will succeed in that task!?

I'm always wondering... D:

I apologize for any inconveniences I may have caused.

Provided I have done everything exactly right and without error, the problem/throwdown is as intractable as AES256.

That caveat of "without error" is not insignificant, and 2 Ton Digital's throwdown prize incentivizes a great deal of scrutiny into the implementation itself, and that is the point.

It looks like it is a very useful library. It is certainly a better idea to write security sensitive code in assembler rather than c because c is the royal path to swiss cheese.

Greetings, everyone!

Well, a bit more than 6 months later we ended the challenge. Back when we turned this loose, I wasn't really sure how many people would really have a proper look at the assembly language source for toplip, but to my surprise a lot of people seem to have done exactly that.

See https://2ton.com.au/throwdown/ for my closing commentary and keys to unlock the original challenge image contents if you are interested.

Cheers!
Edit: haha, fixed the url.

Congrats on keeping your $250k. It seems you got quite a bit of free analysis from the challenge.

But realistically no one really breaks crypto from a single offline sample (unless it is some trivial xor, or something equally lame). A better test is in its intended real world usage with people of various levels of experience using in their systems. Things like timing/cache attacks and other non-code hardware related key recovery methods are difficult to counter with software because of the wide range, and changing nature, of hardware implementations.

Thanks, was a bit puckering there to begin with.. Static third-party analysis of any assembler+crypto would have been a tall order anyway, so I am happy with how it ended up (obviously).

Not sure I entirely agree here, there are a _ton_ of static forensic analysis tools that do precisely this, and since toplip's intended use case is static offline storage, yeah... agreed that "in the wild usage" where timing et al can be a mighty useful hat trick, this one was designed specifically for the use case that it ended up being scrutinized under...

Hi redsock
As I understood there was no single submission for your contest. However reading the description of it on your webpage I wonder if you have received some comments / input regarding possible bugs or issues concerning the library? If so would you care to share those publicly if possible. The reason I ask is that the number of people who can audit x64 assembly source code is quite limited comparing to the number of people who audit C++, PHP or Java code. Similar situation is on the static source code analysis tools front - the support for x64 assembly is quite limited. Obviously some dynamic analysis methods can be used like binary instrumentation, fuzzing etc. and since the source code is in assembly what you see under debugger is quite similar to the source (symbols in ELF executable are also available) which makes the process easier.

Hey ACP, back in the land of being semi-social finally after a very hectic end to 2015 and start of this year.

I did receive quite a few questions regarding the library itself, but none directly on my implementation of toplip that I did the "throwdown" for.

Some of the questions related to the fact that I didn't document in detail possible timing channel avoidance methods, things like that.

All were from crypto backgrounds though and obviously they could all read my code well enough.

I think the prevalence of static analysis and dynamic analysis frontend tools (I use Hopper for Mac OS X binaries as an example) means that there are actually quite a few people with intimate knowledge of x86_64 architecture. Vulns are discovered in what seems like an endless procession using similar tools for the various popular OSs.


Also, on semi-related note, I have updated my library to v1.15 now, see: https://2ton.com.au/HeavyThing/.

Included in this release are Daniel J. Bernstein's Curve25519, Ed25519, Poly1305 routines, libsodium/NaCl's crypto_box compatibility (XSalsa20, etc), SHA3/Keccak, etc.

Hope everyone lurking around here is doing well...

Cheers!