What if we used Scrypt with one-minute work factor for SSNs?

I've only lived about 24 years on this planet, and already I feel like my SSN has probably been compromised somewhere due to the leaky information channels I've had to transmit it, database hacks (published and unpublished) of big companies (government or non-government), a couple mistakes on my part, and maybe some other reasons. It'd be nice if this weren't so, just about every story I hear of people who do get an attacker is unpleasant. I don't want it to happen to me.

Would Scrypt be a panacea? No. But it would surely be better than what we have now. We could make it so that there's only a single point of failure instead of multiple ones in easily identifying the link between a person's name and their SSN by having that unhashed association existing within one government agency and nowhere else. (Make it illegal to store SSNs unhashed.)

If my SSN is required, the party requiring it can give me a publicly known salt (for instance, their company name) and request I send them my full legal name and the result of scrypt(SSN, genSalt(work_factor) + salt + interactionNumber) where work_factor is such that on the latest AMD GPU generating the hash takes, say, one minute. For an average person's CPU, this could take quite a bit longer. interactionNumber is just an integer representing how many times the company has had to request the SSN. Say they're a loan company: you want a loan, you give SSN hash (and probably a hash with a credit agency's salt+interactionNumber too so the loan company can look up your credit score). If you want a new loan, or an extended loan, you give a new SSN hash with a new interactionNumber.

See Full Post and Comments

Random birthday gifts

It's difficult to shop for others when you don't really know what they want. Especially if they are financially stable enough to in all likelihood already have what they want that's in the $20 or less range.

My method: I grab a random word from my computer dictionary with cat /usr/share/dict/words | shuf -n 1, enter it into Amazon's search bar, and see if anything I think the other person might be kind of interested in shows up. If not, I try more words. This has led to some good finds, and the recipients did enjoy them. It seems unlikely I or they would have found them otherwise.

I'm thinking of making a simple Clojure application that makes this process easier (since sometimes I'll have to go through a lot of random words). I spent some time today looking at doing native UIs in Clojure, alas it looks like there's no really awesome solution yet. (My feelings about Seesaw are a little cold...) I've thought about having a web app instead since holy crap the box model and the image tag are a godsend to UI development, but then I can't use PhantomJS. We'll see if I maintain interest in this or not.

See Full Post and Comments

Understanding opposing frameworks

I was reading about the ideological Turing test and Krugman's remark about not being able to explain what a Keynesian economic argument is struck me as interesting. Personally I don't have too much respect for Krugman -- he has made what I think are really stupid statements (especially on bitcoin) in the past.

I admit I don't really get what a "Keynesian economic argument" should look like; my econ knowledge and opinions are acquired in my spare time. I admit I don't know the underlying framework of the theory that generates various statements. All I know is that when I encounter certain statements, the framework I'm reasoning from disagrees with them. For some cases (like some things Objectivists say) I do understand the underlying framework, because I used to be there, but I reexamined the foundations and found them lacking, so I moved on. For unfamiliar cases, the fact of disagreement may give me pause to consider reevaluating my foundations again, or if I'm particularly interested to evaluate the other person's foundations (if they even have any).

Should I spend more time understanding an opponent's framework? I'm not so sure I should. Imagine someone comes to me and proclaims 2+2=5. Well, reasoning under PA (and ZFC et al.) I know that's false. I'm very confident in PA answering this sort of question correctly, so I'm not very inclined to double-check the axioms and arithmetic functions. I'm also not too inclined to understand what sort of madness led the other person to proclaim such a wrong fact, even if their madness is a coherent logical system (e.g. PA with one additional axiom that special-cases 2+2 to be 5, but 1+3 is still 4 and so on).

See Full Post and Comments

Child Labor

I'll come right out with it -- I don't think child labor is evil. For reference, I think you're a child if you're under the age of 14. Aspects of child labor I think are evil are unsafe working conditions and a trade of a child's education for a small amount of family income. That last aspect is easiest to explain: education is important, especially in the early years. Kids should be acquiring knowledge and having fun during this time, and if any of them are working it should be because they want to (for the work itself or for the money in order to buy something they want), not because their parents are poor. Any money a child earns should legally be theirs -- banks should make it easy to open an account entirely in the child's name with no adult supervision or access. I think work hours generally ought to be part time only (less than 25 hours a week), and between 14-16 that restriction is lifted during the summer months between school years. At the age of 16 I don't really see an important distinction with an 18 year old in terms of being able to join any area of the adult work force.

There are areas in the adult workforce that are unsuitable for children, and arguably for that transition period between 14-16 as well. Coal mines are by their nature unsafe. (As such it's actually not that bad compensation-wise, and even as a laborer you can still expect benefits.) Besides the safety concerns, the various jobs coal mining entails also typically require adult intelligence and adult physical fitness. Indeed the laborer position linked to wants candidates 21 years or older. (I have no problem with companies having age restrictions for their jobs -- if they want to exclude a certain segment of the market by choice, fine. But I think a lot of companies refuse to hire less-than-18 year olds (and especially less-than-16 year olds) simply due to legal complications.)

WW2-style sweat shops with lots of dangerous finger-chopping machines are also no place for a child. Even modern assembly plants aren't really suitable from a safety perspective. Simpler assembly line jobs like sorting or picking out defective food products requires an ability to focus on such an uninteresting activity for hours which most children simply do not have. (Also an awareness of one's cleanliness.)

See Full Post and Comments

Correlation is evidence of causation

I've been bringing the title line out frequently for the past few years in response to people saying the somewhat true phrase "correlation does not imply causation", or the true phrase "correlation is not causation" which they've been indoctrinated by fraudsters protecting Big Tobacco.

When asked for a proof, I often just link to this page: http://oyhus.no/CorrelationAndCausation.html It's the simplest and easiest to understand version I've come across. But I think it's sort of missing a final step, and a longer proof will fill that in.

In order to prove the title statement, we have to back up a bit and ask about what evidence is, and before we do that we have to ask about what belief is. Or rather, we don't really need to define what they are so much as how to measure them. Bets are a way of measuring your confidence and certainty of your beliefs, and odds ratios and other aspects of betting can be expressed through probability theory, so your beliefs being true can be expressed using probability theory as well. (If you're interested in non-betting-based foundation for probability theory governing beliefs, see Jaynes. If you're interested in representing uncertainty of several "flavors", see Goertzel.) So if we have a probability for a belief, and we encounter a new piece of evidence, then that will either raise or lower the probability of the belief depending on whether it's evidence for or against. Formally, if some fact A is evidence for belief B being true, that means that the probability of B being true is greater if A is true than if A is false. In math, $$P(B|A) \gt P(B|\overline{A})$$ means A is evidence of B.

See Full Post and Comments

My preference for dynamic typing

Alternatively: why I lost all excitement about Clojure's core.typed library after learning it makes no speed improvements.

There's a little-known paper published a few years ago called "An experiment About Static and Dynamic Type Systems: Doubts About the Positive Impact of Static Type Systems on Development Time".

Go read the paper, it's short. But since I know you're lazy, I'll give a brief overview of the experimental setup and its results in my own biased words. The authors made a programming language and IDE and had two versions of it: one with static typing and one with dynamic typing. They took a group of students and separated them into dynamic/static groups and trained them respectively -- the training for the static version took a little longer since they had to cover the type system. Then they were asked to implement a scanner and parser.

See Full Post and Comments

Mixing Python with C

A common point of rhetoric up the sleeve of any Pythonista is this: "...and you can always write the slow parts in C if you have to!" It's typically said off-to-the-side and rarely elaborated on.

It's not a bad piece of rhetoric, I even use it from time to time. But it's only useful on programmers who haven't stepped much beyond their own narrow interest in technology--anyone who's done work across a variety of languages ought to realize that "can interface with C" isn't a feature that's supposed to be marketable, it's a hard requirement. They may have never had to do this themselves, but they should at least know in principle it can be done. In practice it's often a lot more difficult than it should be. If Python's C-interfacing capabilities were as slick as Clojure's Java interfacing ones, I wouldn't want to write about it.

What do I mean by "can interface with C"? A language that can interface with C is a language that can directly call functions in a compiled shared object that was written in C, and also where C can get at the language's internals as well to call its code and have interactions. This is distinct from using the other language to instruct the operating system to run a compiled C program and give it the results, and vice versa. Java interfaces with C, and Python interfaces with C.

See Full Post and Comments

Older Posts Newer Posts