[contingencies]

The chosen-prefix collision attack used in signing the Windows Update malware (FLAME) also suspected of being from the US was a never before published variant.

Is anyone aware of a somewhat comprehensive auto-update cryptography survey anywhere?

I am often alarmed by the number of updates pushed through desktop software, often with little explanation. (I'm looking at you, Adobe.) .. not just for security, but for bandwidth management too.

Many open source products seem to just query a URL and direct you to go download stuff. With SSL essentially broken, that's gotta be a bit risky vs. MITM.

Gentoo for one combines pre-distributed SHA256, SHA512 and Whirlpool checksums with file size, which feels secure enough against collisions. But the pre-distribution is decentralized through potential MITM (non-trusted parties), and the cryptography around that process - if any - is less than transparent, and integrity checking is apparently not made upon locally extracted package database.

Perhaps we need a standard, cross-platform solution in the software update query space that is cryptographically paranoid and well-reviewed enough by multiple parties to be considered secure, meets the generalised need and has some OS-level integration features more advanced than "secretly do things in the background".

[sneak]

> Many open source products seem to just query a URL and direct you to go download stuff. With SSL essentially broken, that's gotta be a bit risky vs. MITM.

There's nothing stopping one from linking against their own copy of an SSL lib, and supplying their own list of trust anchors/trusted CAs. I've been wondering for a while why lots of apps (e.g. mobile apps) don't do this more often.

[Shank]

I believe the best way to do it is something like ECDSA to verify and sign update packages - but I'm not familiar enough with the crypto field to understand how the entire mechanism works.

[contingencies]

Sure, signatures are ideal. The problem for distribution maintainers, I guess, is that really they can't sign off on things; only the actual package developers can. Further, you'd wind up providing a key distribution service which may rapidly become more complex than the software packaging itself.

Given the above, perhaps all distribution maintainers can realistically do is say "it hasn't changed since I first saw it" which is what happens when they provide multiple checksums of a file, which is probably lower CPU and software library overhead than performing a cryptographic signature check.