So AT&T says that VoIP requires "faster speeds". Even using G.711 (i.e., uncompressed toll-quality), and including the overhead of the other layers, VoIP requires only ~120kbps. The thing about VoIP is not that it requires high speed, but that it requires low latency.

g.711 requires 64kbit/s in both directions, also high latency is not really a problem with VoIP (at least anything below 300ms), but the really important thing is low jitter.

If you presume a custom processor that will only execute code signed by an election commission, that would be a first step - the system won't run anything that hasn't been specifically approved for installation on the machine.

If you had RTFPDF, you would have noticed they actually used a clever technique called return based programming, to reuse small parts of trusted code and implement their hack using them.

Nobody in their right mind is using both MD5 and SHA-1 together, and even if they do they are both standardized hash methods. Combining hash methods is dangerous at least and should not be done haphazardly. It would be much better to use SHA-2 256 instead, if only because it is a standardized hash and not some weird combination of two.

I think the author doesn't mean to combine SHA-1 and MD5 to make one hash, but instead using both hashes. This may be weaker for preimage attacks, but a lot stronger against collisions, so if it's what you're after it's one of the best ways to achieve it.

Alas, it was a terrible disappointment. hdparm -t showed 16.65 MB/s on a single drive, 20+ for two, 22+ for three and four drives, and 22.75 for all five.

You're obviously doing it wrong. Did you plug the 5 drives on the same hub / port ?

I have 4 SATA drives in USB2 enclosures (no RAID), and this is what I get :

  Timing cached reads: 3616 MB in 2.00 seconds = 1809.14 MB/sec
  Timing buffered disk reads: 96 MB in 3.01 seconds = 31.93 MB/sec

Once you've reverted the hash back to salt+plaintext, it's *much* easier to remove the salt (often some string concatenated with the plaintext).

Binary executable files contain a lot of addresses (variables, jump locations, ...) that are generated by the assembler at compile time.

Now consider you just add one 1-byte instruction somewhere in the middle of your program (let's say "nop"). When you compile it again, all the code that reference addresses beyond the insert point will have changed because the address has been incremented. So these 4 bytes added to your source code could mean addresses that get incremented in the compiled file in thousands of places.

What they do basically is take the binary file, disassemble it back to pseudo source code (not real asm I guess), and diff that against old version. The patch engine on the client end does the same disassembling, applies the patch, and reassembles the patched source code to an executable file.

This means diffs gets much smaller (4 bytes vs. 1000s in my extreme example), but also makes the diff/patch process much more complex, slower, and not portable.

their technique is specifically geared towards executable binary files, it doesn't make sense to use it, and also won't work at all with any other type of file.

so yes the 9x thing is quite unfair, that's like comparing bzip2 vs. lame for compressing music.

Simple answer: no

statistically, I think rsync has very few binary files to deal with, at least the way I'm using it.

also, their technique may make the diff data smaller, but it also makes the diffing/patching process a LOT slower, something many rsync users don't want because on a LAN you don't care much about bandwidth usage.

announced a new compression technique called Courgette geared towards distributing really small updates

I just RTFA, this has nothing to do with a compression technique.

What they developed is a technique to make small diffs from *executable binary files* and it doesn't look like it's portable to anything other than x86 because the patch engine has to embed an architecture specific assembler + disasembler.

various software patents owned by various entities.

theora is 100% patent free

For all I know they may have been at it all along, probing other parts of the Internet

I don't think so, my firewall has many public adresses in distant subnets, and I've seen the exact same patterns as the OP.

So my (informed) guess is that's actually a second run.

root DNS != Backbone

You can DDOS a server, a network, even big routers, but you can't DDOS the internet.

Cutting random cables here and there won't work either, at most you're going to isolate parts of the net.

The only way to take down the internet in 30 minutes is to exploit vulnerabilities in the BGP core routing protocol and announce netblocks that somehow (that's where something has to be exploited, bypassing filters, smaller blocks and routing costs considerations) takes the priority over other routes for every router that receives the announce.

Not saying that's impossible, but still tough ...