Posts

Showing posts from June, 2015

BusyBeaver and the state of near-native code in browsers

Image
Curious how cryptography performs in asm.js vs. Google Native Client? Check it out for yourself:
In Firefox, try BusyBeaver in JavaScript.In Chrome, try BusyBeaver in Google Native Client.A description of my path to these examples follows.


I was impressed recently with what I read about Google Native Client, which is embedded in Chrome, and Firefox's asm.js and Emscripten. I was further impressed by how I can play Prince of Persia in my browser, and it works via DOSBox inside JavaScript, and it's actually perfectly playable, aside from key lag. :-)

I've recently been working on BusyBeaver, a new password hashing, key derivation, and proof of work function. Existing commonly used password hashing approaches suffer from extreme brute forcing susceptibility on hardware as widely available as an AMD GPU. BusyBeaver is my attempt to improve upon PBKDF2 and scrypt in its resistance to optimization via execution on a GPU, FPGA, or most anything other than the intended usage platfo…
3 comments
Read more

Against the hating of cheaters

Cheating, as in relationships, is not an upstanding thing to do. It is exemplary of an immature, confused, untrustworthy, undependable character. Let me be clear: I don't think it's wrong to fuck around. But it's important to be open about it. Relationships and sex are a big deal to people. If you're going to be doing that with more than one person, make sure that everyone involved is aware, and understands.

Now, that being said - there are those who hate cheaters. I must say I dislike that more than cheating. When it comes to cheating, the well-adjusted person is one who neither cheats, nor hates with a passion. But if I had to choose between a cheater, and someone really sour about it...

The cheater, you see, is only selfish in their seeking of pleasure. But the hater is ignorant and bitter; coercive and entitled in imposing their views. These views tend to be naively monogamous, as if to imply: My expectations should be met. This should just work. I shouldn't ha…
Post a Comment
Read more

Visual C++ ternary operator considered harmful

Image
We've recently begun upgrading our code from Visual Studio 2005 to a newer version, and we ran into the following doozy.

Imagine that you have classes with the following relationships:

// Lightweight reference to data owned by another object.struct Light { Light(); Light(Light const&);};// Owns data freed on release. Constructor copies data. Conversion to Light does not copy.struct Heavy { Heavy(); Heavy(Heavy const&); Heavy(Light const&);operator Light()const;};
In a reasonable world, you would then expect the following code, using the C++ conditional operator:

Light DataOrDefault(Heavy const* h){return h ?*h : Light();}// BAD BAD BAD!
... to work like this code using a simple if statement:

Light DataOrDefault(Heavy const* h){if(h)return*h;return Light();}// OK
... or like this code, using a template:

template<class T>inline T Cond(bool expr, T a, T b){return expr ? a : b;} Light DataOrDefault(Heavy const* h){return Cond<Light>(h,*h, Light());}// OK
But it do…
8 comments
Read more