Yes, in order to validate the chain of trust the TLD must be signed but sibling 2LDs have nothing to do with whether a particular 2LD can be signed. If wikipedia.org wants to sign, they can do so, because their parent (.org) is signed, but it doesn't matter whether widgets.org is signed.
Phreebird isn't critical in any way to the arguments he makes, it's simply offered as an example of online signing with DNSSEC. It's right there in the first paragraph, mentioned alongside existing, well-known servers which are purportedly adopting more online-signing-like features.
Which would be only marginally more specific. Humans have been eating "artificial", "synthetic" foods for thousands of years, and all of these things are made from "natural" ingredients because matter can't be conjured from thin air. Can you really come up with a test to distinguish between a just-invented stabilizing agent with unknown long-term effects on health and, say, flour?
You could use a Diffie-Hellman exchange to get a shared secret so things are "obscured by default" but not trusted, then let higher layers deal with trust validation. For example, the TLS certificate handshake could just be a matter of constructing a blob containing the two endpoints' DH public keys and signing it to prove that a man-in-the-middle hasn't intercepted the channel. All the actual encryption would be handled by the IP stack and offloaded to hardware, while the application-layer TLS bits would be used once at startup (and maybe subsequently if the lower layer re-keys) then get out of the way.
Key and cipher negotiation could easily be shoehorned into the three-way-handshake already used to establish connections. AES with a CTR block mode would be the obvious cipher choice since each packet would be handled separately. With TCP you could even just use the sequence number as the counter, although this would be harder at the IP layer.
But yeah, none of this would have been available at the time. Still, given today's technology it would not be difficult to future-proof, especially if the trust machinery is left to the application.
I use my own MX rubber-banded together with Postfix, SpamAssassin, and dovecot IMAP. I also have bucket.mydomain pointed to mailinator.com so I can use addresses under that domain as throwaways without the site I'm signing up for knowing about it, although I also use Postfix aliases for long-term throwaways.
My coworker runs his own MX, but bounces all his mail through Google just for the spam filtering.
They're not sitting around a conference table in an underground bunker, stroking their beards and cackling maniacally while trying to screw the open source community as hard as possible. Microsoft is a business. What business sense does it make to release this plugin?
That is, until it starts taking over the target computers and clicking the links itself. Any naive utility function will produce undesired side effects:
> The author's whole premise is that dropping out is universally bad and should be discouraged, and that staying in school is universally good.
No, the entire premise is in the title: Don't encourage kids to drop out. If they want to do it, they'll do it, and good on them for it. The last paragraph even argues against "extreme points of view" which would suggest that interpreting the article as "they say drop out, don't do it" is totally wrong.
> Where might we be if some of the 'usual celebrity dropouts' hadn't dropped out?
Worthless speculation. We'd be somewhere different, yes, but no less interesting and no worse off.
Clarify? Collision attacks by definition do not feature an existing digest as input so they are not useful for breaking into a system secured with a digest.
You are right, of course. I wrote that as 'ideal digest' instead of MD5 then rewrote it. Specific digests always lose a few bits in real life, or in MD5's case, most of the bits...
Actually you can (almost surely) stop cracking at 16 bytes, because that's how long MD5 digests are and any more bits than that are going to give you hashes you've already seen. You won't get back the original string but you don't need the original string.
You can upgrade passwords when the user logs in. The sanest thing to do seems to be to store all the public variables (work factor, salt) alongside the digest so each password can be handled separately.
> is it possible, given the ciphertext, to know roughly how much work is required to test a password?
The work factor is an input to the digest function, both when creating and when validating the password. Normally it should be stored alongside the digest itself so you can increase the work factor over time without disrupting existing passwords. So you are correct. It might theoretically be possible to correctly balance the work factor to counter variation in password info entropy so that all passwords take about the same time to crack, and this would be very cool and impress members of the opposite sex, but it would not improve security at all.
Making a probabilistic password checker is also a superficially interesting idea. Maybe my mind is too small to explore it completely, but it seems that at best it would be no better than just increasing the work factor.
To nitpick, the topic at hand is pre-image attacks, not collision attacks. Pre-image is where you know the hash and want the plaintext, collision is where you create two plaintexts with the same hash but don't care about the actual hash value. The former is recovering information, the latter is falsifying trust and almost always involves signatures.
Collision attacks don't apply to many situations but are much easier to execute, for example a MD5 pre-image attack requires approximately 2^128 steps but a collision attack requires only about 2^64 steps. This is why MD5 is totally unsuitable for collision resistance, and in fact has already been successfully exploited to fabricate a real-world CA certificate, but still puts up mild resistance to password cracking. Not that I'm recommending you use it or anything -- do what the nice gentleman says and just use bcrypt already!
You didn't explain why rewriting local, private history breaks any of those things unless you keep your local, private branches around indefinitely in un-rewritten form. If I rebase, it replaces my previous branch, not extends it. `git rebase` only breaks bisection if you are using it incorrectly (on public commits).