gxti

How about criticizing the article instead of the person? Hero worship gets us nowhere.

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.

Apple adopted H.264 years ago -- it's basically all they use.

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?

> 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.