Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

How do you operator overload in C++ so that calling computeHmac(secret(string)) returns secret(string)?


Define the computeHmac method to return a secret(string) type?

Then define the equals operator for "secret" to behave in the needed way.


But now you've forced computeHmac to only work only secrets, when there is no such need. You've coupled an implementation of an abstract algorithm with the particular case that _you_ want to use it this one time with sensitive secrets.

The advantages of monads include exactly the opposite decoupling: the hmac algorithm implementation is true to its bare specification, and it is the context that changes some of its behavior.


You could overload computeHmac's return value so that it would return either a string or a secret, then you could use it directly with checkHmac, if you wanted, or as a string in other applications.


Consider this: I don't even know what hmac is, and it's implemented in a library.

Also, I can't overload return values on their own in C++, I would have to overload the whole signature. In fact, to get the same monadic result, I need 2^n-1 overloads for a function with n arguments (one for each subset of the arguments except the empty one).

Of course monads' advantages can be coded directly, just as functions can be coded directly in assembly. Personally I code in C++, so I've never used proper monads, but I see where they save work.


I was just considering a nicer interface for computeHmac at a library level, but if you don't have that, you could still just implement checkHmac using your Secret class and call it with checkHmac(Secret(str), message, mac).


It's turtles all the way down. Without the secrets monad support in the language, at some point I have to be the one enforcing secrets in multiple places: if I implement checkHmac(secret(str),...) that calls computeHmac(str)->str then I must both "unbox" the secret(str) _and_ "box" the return value of computeHmac.

I can do this, sure, and if I forget then I'll have a security bug. This is similar to the situation with c++ destructors over c's manual malloc+free. If you're happy freeing at every function's end, then this secrets thing adds nothing for you, and that's cool. It's your own choice what language to use.


If you try to call computeHmac from checkHmac surely you'll get some sort of error or warning, wouldn't you? You have no guarantee computeHmac will your secret will be treated as a secret by computeHmac, if its signature is simply "str". Unboxing it is never safe.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: