Seriously. Write some code, publish it on Github. Spin up a single serving web page, does one interesting thing as soon as you arrive. Remember, everyone else with resumes could be pretending, you're actually doing stuff.

For work experience, sign up on freelancing sites like odesk. Take jobs just to do them. Nobody knows how old you are, there. Even if all you can do is sysadmin -- well, admin some cloud services!

I'm not seeing any data on what portion of those keys with bad moduli were actually attached to valid certificates.

It's damn fine survey work, but the conclusions are just strange. More detail here:

<a href="http://dankaminsky.com/ronwhit">Survey is good. Thesis is strange.</a>

http://arstechnica.com/apple/news/2012/01/82-percent-of-atts-q4-2011-sales-are-smartphones-66-percent-are-iphones.ars

Yeah. 66% of AT&T's 4th quarter sales were iPhones. I was on Verizon for years, switched to AT&T only for their iPhone, and stuck with them only for their GSM capabilities worldwide. Sure, your margins are less when you offer a better service. Would you prefer no sales though?

The platform that most successfully upgraded itself was the NES. One of the degrees of freedom they had, because there were chips in each cartridge, was to deploy new memory management units inside the games themselves. Quite literally, the NES became more powerful for games released later in its dev cycle. SNES did this too, with the SuperFX chip inside of Starfox (the most popular DSP in the world, for its era) but it wasn't quite the "all games ship upgrading hardware".

I suspect if there was ever to be upgradable hardware, it'd have to work by yearly subscription, and it'd have to be no more than $50 a year for the part. However, with guaranteed sales in the millions of units (as games would hard-require it) the logistics of making some pretty crazy stuff fit into $50/yr wouldn't be unimaginable. Remember that XBox Live is already pulling, what, $60/yr?

You realize this is completely unscientific garbage, right? None of http://www.fwi.co.uk/Articles/25/01/2011/125212/Handle-with-care.htm makes sense outside of a conscious entity.

Applications will never, ever tell you anything bad about DNSSEC.

They might tell you a TLS validation failed, but that an IP was good or bad? No.

We can do this incrementally, mostly because we're just *not* securing most things right now. So the conversion cost is lower than you'd think.

DNSSEC is an infrastructure shift, and you can't use it on .com domains for another few months. Have some patience.

At Black Hat this year, I actually demonstrated the endgame. Want federated authentication in OpenSSH that actually scales? Want servers able to autogenerate TLS keys that will be recognized and secured worldwide, even against broken certificate authorities?

Want secure email, without the mess that is PGP key management?

End to end secure key management via DNSSEC makes it all actually really easy. Code is here -- BSD licensed, feel free to play:

http://dankaminsky.com/phreebird

Also, I'm putting together a set of diaries on the subject:

http://dankaminsky.com/2010/12/13/dnssec-ch1/

Enjoy!

The problem is collateral damage. Legitimate actors can't get into the DDoS game, because if they legitimize DDoS, the network will *fry*.

The "good guys" cannot flood nearly as significantly as the bad guys. Worse, the good guys are significantly more exposed -- they have corpnets, they have partner nets, etc. Today it's the website, tomorrow it's Hulu.

There are paths on which the anti-piracy people have the high ground (not moral high ground, tactical high ground). DDoS, in no uncertain terms, is not one of them.

Fascinating! Looks like I got to spend the night being wrong myself. Serves me right for being so cocky.

It seems that the key to this question is that there are boy/boy pairs where neither boy was born on a Tuesday. That's why Tuesday matters:

If your first child was not a boy, you cannot pass.
If your first child was a boy born on Tuesday, your second child only needs to be a boy to pass.
If your first child was a boy born not on Tuesday, your second child both needs to be a boy, and needs to be born on a Tuesday to pass.

Given this complex constraint set, it's unsurprising that 50% doesn't actually show up.

OK, now with 3.13M families:

# echo 'select child1_gender,count(*) from families where child2_gender = "M" and child2_day=2 group by child1_gender;' | mysql test
child1_gender count(*)
F 111608
M 112037

50.095% male. If I remove the Tuesday constraint?

# echo 'select child1_gender,count(*) from families where child2_gender = "M" group by child1_gender;' | mysql test
child1_gender count(*)
F 783068
M 784087

50.03% male.

But you know, perhaps I'm being not literal enough. It's always possible to misencode a problem, and there's a lot of insistence that you have to handle the overlapping case of boy/boy. So, lets try a different mechanism. Lets literally do what the problem asks:

"I have two children, one of whom is a boy born on a Tuesday. What's the probability that my other child is a boy?"

For each family, if either of the children is male, return whether they are both male.

# echo 'select child1_gender=child2_gender from families where (child1_gender="M" and child1_day=2) or (child2_gender="M" and child2_day="2") ' | mysql test | sort | uniq -c | sort -n
1 child1_gender=child2_gender
207934 1
223445 0

...heh! That's kind of neat! I think I shall play with this some more.

Alright. It's 4:21AM, I'm in a random hotel room with a $400 voucher from Delta, and somewhere, someone on the Internet is wrong.

This sounds like a job for SQL.

First, lets start with a table:

# echo "describe families" | mysql test
Field Type Null Key Default Extra
child1_gender char(1) YES NULL
child1_day int(11) YES NULL
child2_gender char(1) YES NULL
child2_day int(11) YES NULL

Now, lets put a million records in it.

# echo "select count(*) from families" | mysql test
count(*)
1025537
# echo "select * from families limit 10" | mysql test
child1_gender child1_day child2_gender child2_day
F 1 M 0
F 4 M 3
M 1 F 1
F 5 M 1
M 0 M 3
F 0 F 3
M 0 M 2
M 4 F 1
M 6 M 3
F 3 F 1

(We're going to define 2 as Tuesday.) Now, lets look at the problem statement:

"I have two children, one of whom is a boy born on a Tuesday. What's the probability that my other child is a boy?"

We're going to translate that to, as in parent post.

Select the gender of all second children where the first child was born on a Tuesday and the first child was male.

Select the gender of all first children where the second child was born on a Tuesday and the second child was male.

Or, in actual SQL:

select child2_gender,count(*) from families where child1_gender = "M" and child1_day=2 group by child2_gender;
select child1_gender,count(*) from families where child2_gender = "M" and child2_day=2 group by child1_gender;

The results?

# echo 'select child2_gender,count(*) from families where child1_gender = "M" and child1_day=2 group by child2_gender;' | mysql test
child2_gender count(*)
F 36593
M 36617

# echo 'select child1_gender,count(*) from families where child2_gender = "M" and child2_day=2 group by child1_gender;' | mysql test
child1_gender count(*)
F 36811
M 37031

So, in the first set, we see 49.58% male for the other child. In the second set, we see 50.14% male for the other child.

And in myself, I find a renewed respect for numerical simulation. Happy Tuesday!

Take a thousand families, with two children, where one of the children was a boy born on a Tuesday.

I don't mean a thousand theoretical families. I mean, lets say you straight up took one thousand real families, that matched the above constraints, straight out of the census. No joke, you break out the SQL.

When you check the gender of the other child, you are going to see the breakdown of gender being 50% male, 50% female.

Now, I know there's a lot of fun handwaving going on. Here's the flaw, in a nutshell. There are indeed three possibilities, when one child is constrained to be a boy:

boy, girl
girl, boy
boy, boy

The mistake -- and it is a mistake, because when you actually run the experiment, the hypothesis is invalidated -- is thinking that each of the above cases is equally likely. Specifically, order of birth has been incorrectly elevated as a determining factor. So we see:

boy, girl: 33%
girl, boy: 33%
boy, boy: 33%

When we really should be seeing:

boy, boy: 50%
boy, girl: 25%
girl, boy: 25%

Or, more accurately:

same-gender, both male: 50%
different-gender: 50%
      boy first: 25%
      girl first: 25%

Another way to frame the query, with similar results, is to say:

Select the gender of all second children where the first child was born on a Tuesday and the first child was male.

Select the gender of all first children where the second child was born on a Tuesday and the second child was male.

You'll note the girl, girl families will show up in neither result set. So they can do nothing to skew the numbers.

The results of both queries will, predictably, be 50/50 male and female.

This is a good example of why framing a problem correctly is so difficult and critical. It's only because this problem is so amenable to experimental formulation that it's easily defensible.

(Note that the use of Tuesday was an excellent DoS against math geeks.)

(Note also, by the way, this is the exact opposite of the Monty Hall problem. In that problem, people are expecting:

Door 2: 50%
Door 3: 50% ...when, really, we have:

Host Told You Where The Car Was: 66%
      Was Behind 3, Therefore Exposed 2: 33%
      Was Behind 2, Therefore Exposed 3: 33%
Host Didn't Tell You Where The Car Was: 33%
      Randomly Exposed 2: 16.5%
      Randomly Exposed 3: 16.5%

If you modify the Monty Hall problem, such that he opens a random door *which might actually expose the car*, then when he opens the door and you see a goat, it doesn't matter whether you switch or not.)

[This is Dan]

So, if they're so great, why does the boss have to put a gun to people's head?