[marshray]

I give it maybe a week or two against a good cryptographer. You never, ever invent your own encryption algorithm.

Don't rule out the possibility that the botnet code was written by a good cryptographer. It may be that they're using a well-designed algorithm that these researchers didn't happen to recognize.

Even if the encryption algorithm happens to be secure against differential/linear/slide/boomerang attacks, I bet there will be an implementation flaw. It's really hard to get implementation right on those things, even if you have an almost perfect algorithm.

Sometimes something that would be bad as a standard building block can hold up in a specific use case. Maybe this thing really only needs to obfuscate the communications.

Not that that all really matters -- anything that it's encrypted can be decrypted since they key lives on the computer -- but the fact that they created their own encryption algorithm gives some insight in to their minds. Namely, that they they they are smarter than they really are, and that despite all of that, they don't know enough about security to stick with AES.

I wouldn't underestimate the Russians and Eastern Europeans like that.

[...] Either (1) this botnet is really weak or (2) the writers of this article have distorted the truth.

Probably both, at least (2).

It's really really hard to write technically accurate descriptions of these things that are also accessible to a wide enough audience that you reach the people you need to reach.

[tptacek]

Has any botnet ever been written by a good cryptographer? I remember Vern Paxson getting a whole paper out of supposedly-skillful botnet authors not even being able to generate random numbers securely.

[marshray]

Undoubtedly there has been, the question is whether or not it's been released from the lab.

I don't know about its cryptography specifically, but Stuxnet, for example, is a botnet regarded as a game-changer precisely because it was such a professional hit.

BTW, I'm trying to see if there's any interest in a collaboration on the cryptanalysis of this custom encryption system. Anyone with an interest please ping me. It may turn out to be nothing.

[Xk]

(1) You should put your email in your "about" section so the rest of us can see it.

(2) Do you have the source of it? Do you have a non-obfuscated version?

(3) Even if the answer to both questions in (2) is "yes", I still doubt any serious cryptographers would take a look at it. They (mostly) do things to write papers, and you don't get a paper out of "we broke a really weak encryption algorithm in a botnet". The chances that the paper is instead "this botnet has a reasonable encryption algorithm" are so slim, they won't consider it.

(4) That said, there are a number of non-serious cryptographers who would find it an interesting challenge, but if they can't break it, it still doesn't mean it's any good.

[marshray]

(1) done.

(2) No, I haven't heard of anyone getting the source. There are 4.5M PCs with an obfuscated binary, so that should be obtainable. We can de-obfuscate it ourselves (it obviously has to load into memory at some point), or we can also ask other researchers who have already done this. The latter is likely to be successful according to 'who' and 'how serious' we have interested.

(3) You never know and it never hurts to ask. Don't forget, they also often have students looking for projects. Anti-botnet ops is an active research topic in data security.

(4) Yep. I doubt anyone would consider using it for anything else.

[JoachimSchipper]

I'd be interested in a look at a readable source, too.

[icey]

I'm not saying that's the case here, but surely cryptographers are just as corruptible as everyone else.

There's nothing preventing a scenario where someone with nefarious intent and a large pile of money convinces a skillful cryptographer into building a cipher robust enough be resistant to cryptanalysis.

(I'm not your downvoter by the way)

[JoachimSchipper]

To condense a long reply: AES works just fine. If you're really paranoid, use SALSA-after-Blowfish-after-AES or something like that. Designing your own cipher is a bad idea, and I'm pretty sure you couldn't buy a sufficient number of the handful of truly competent people in this area (and even if you could, you should prefer a battle-tested algorithm.)

[marshray]

SALSA-after-Blowfish-after-AES or something like that

Still you could easily end up with something much less secure than any of them used independently. For example, read about the "meet-in-the-middle" attack.

[JoachimSchipper]

We obviously use three independent keys. The security of the composition is then at least as good as the security of the best of these algorithms. (You're right that it's not much better, but it doesn't need to be; I don't see how you get "much less", were you thinking of using the same key for each algorithm?)

If you somehow convince yourself that the NSA can break many well-known encryption algorithms and that it's willing to risk exposing this ability to shut down your botnet (which is the counterfactual I'm working off in this thread), this may give you some peace of mind: Blowfish and AES are well-tested designs by separate teams and SALSA is a very simple, very different design that you can easily implement yourself and that's pretty resistant to side-channel attacks. It seems likely that any agency that can break all three can break anything you can come up with.

[marshray]

When you said "something like that" I began imagining the type of liberties a well-meaning developer might take with that advice. For example, he might use the same key for all algorithms. He might use two block ciphers with two keys. The effective security you get from these constructions is notoriously counterintuitive.

We obviously use three independent keys. The security of the composition is then at least as good as the security of the best of these algorithms.

That's not obvious at all to an implementer. For example, there are NIST standards for 1-, 2-, and 3-key variations on triple-DES. http://en.wikipedia.org/wiki/Triple_DES#Keying_options