Schneier on Security
A blog covering security and security technology.
« Cyber-Attack |
| RU Sirius Interview »
April 5, 2007
The Doghouse: Brutuslib
It's 2007, and I can't believe that people are still using homebrewed encryption algorithms. This one looks pretty easy to break.
Posted on April 5, 2007 at 1:32 PM
• 30 Comments
To receive these entries once a month by e-mail, sign up for the Crypto-Gram Newsletter.
Maybe the goal is just to have something to host Google ads with.
One ad has a check signer gizmo for 2 G's.
Sounds similar to the cipher the Romans used way back in the barbarian days ;)
If the Romans used it, it's good then?
It is remarkable given the proliferation of good free APIs out there but the default behavior for many programmers is to just to throw something together quickly. It looks secure which pleases their boss and sounds secure which pleases the marketing folks. The worst offender from my experience comes in database password storage. People have slowly come to realize you can't store your passwords in plain text but the solutions they come up with are just silly. A couple employers ago at a firm selling financial services software I had to fight with the development department to get them to replace their beloved "encryption" (which consisted of a substitution cipher with a key value of the total ASCII value of the password) with a publicly available free implementation of SHA-256. They were convinced that if the passwords looked secure no attackers would bother trying to test them.
It's important to remember that this might be a first-year programming student of some kind. When I was in college, I often came up with something as quickly as possible that would still fulfill the requirements, and this might have been an exercise in building a free library or something.
A good way to learn about encryption is to try building your own (very insecure) algorithm and then having classmates analyze or try to crack it.
When I was a TA for a security class, we sponsored a "security hacking" competition. One of the winners just bought off another TA with pizza, making the exercise a valuable example of real-world social hacking.
If, on the other hand, this is a professional software engineer, he should be dragged out into the street and soundly clubbed.
Do you think it's called Brutus because it's a caesar shift that's been stabbed in the back with an XOR?
Even making allowance for the fact that it's written by Czechs, the web site announces to the world that it's written by near-illiterate people. I don't think 'Brutuslib' is plausible enough to be worth putting in the doghouse. Save that distinction for something that a naive person might actually be fooled into buying.
I don't know what kind of a cipher it is. I couldn't make sense of how it works from the examples, no part of which was particularly consistent with any other, and some of which (like step 3) made no sense to me at all.
Well everybody is a cryptographer nowadays, as soon as they learn about XOR =)
Also, wasn't one of the basic ideas for a strong algorithm to compress the ciphertext as much as possible? This seems to actually output 1.5 times the size of the plaintext.
Interesting (scary) points:
- keylength from 32-bit up to 65KByte
- 3X data expansion
- written in PHP
- uses PHP's built-in rand() function for key generation
- published by a company called YAN Design & Development
- it is synchronous ?!? (maybe the mean its symmetric?)
It all comes down to security economics. Teaching computer security isn't a key part of programming classes. Entry level people are much cheaper than seasoned professionals. Nobody wants to spend money on security unless they absolutely have to. For most applications, you can get away with the first idea for an encryption algorithm written by an intern.
There is no business case for security in most organizations. I'm constantly amazed how low standards can be set and still be sustainable. I work in a bank where I can't get anyone to pay more than lip service to version control or backing up large databases. When people can get away with that kind of reckless disregard for data and business continuity, do you really think security concerns have any hope at all?
Gabriel - there's lots of room for improvement over some hokey home brewed encryption routine, but I can guarantee you that a manager somewhere said to store the password in plain text in the publicly readable file if the encryption algorithm would take more than 15 minutes to write. I support an application that has exactly this level of security for exactly that reason. For automated processes to run, they have to be able to decrypt the password somehow without user intervention. It's not an easy problem to solve in a secure manner.
Unfortunately, the author of that software is hardly unique. Take a look at this thread on comp.lang.c++: http://groups.google.ca/group/comp.lang.c++/...
I tried to point him in the right direction, but have no faith that he followed my suggestions. Personally, I'd reccomend avoiding his "nBinder" and other products.
I give the publisher some credit in the license agreement:
"If you use Brutuslib in your application of any kind (incl. www presentation), you have to place the link for this web site clearly on the application home page or in the part, where is your copyright located. The link can be text or graphical and must contain text "Encrypted by Brutuslib" or its literal translation."
Phew! They were conscientious enough warn me about any product or service dumb enough to use this.
I appear to have missed entering my name on that last post.
Being mentioned here is likely giving his site far more attention, and thus more revenue, than he would have received otherwise. Ironically, we could actually be sponsoring bad crypto.
As I noted in my blogpost, I never stop getting amazed by how saving a few bucks may become very expensive.
Someone who knows nothing about encryption, and still need a good algorithm may be intrigued by saving time and cash by using such a solution.
The key be up to "65 600 bytes" or "65 500 bytes". Well, isn't that nice. I've always wanted ambiguity in my security.
So this is pretty much as easy as breaking any XOR'ed message. The key length in this case is not particularly significant since it might not cover the entirety of the message.
Well, clearly it isn't even CPA-secure, that is hardly any news.
There is one main thread in all these foolish algorithms, making them both common and insecure: Crypto is hard. It is hard to understand, it is harder to build and it is even harder to break. Haven't seen a popular book (such as Dan Brown's Digital Fortress) which isn't filled with horrible mistakes. Problem is, because it is so hard, people do not even understand they are making fools of themselves.
Security through obscurity? More like security through Ambiguity
The site you linked to looks like it could almost be someone's computer science project that they decided to brush up make available on the web.
Now if they were selling that software, I'd be FAR more worried.
Out of curiosity I searched for "Encrypted by BrutusLib" in Google and got back only one result.
> I work in a bank where I can't get anyone to pay more than lip service
I'l look you up in the directory next day I'm in work - unless there are multiple banks like that.
I'm pretty sure they're all like that, but drop me an email if you're in the same one. I would like to find a senior position in the group that audits the business technology projects. I know a lot of the things the business groups do to hide from and mislead the auditors. I'm just glad that as a contractor, I have all of the legal accountability of a stapler. =)
You *do* know about the Federal Stapler Accountability Act working it's way through Congress?
And next year, I've heard rumors of a No Staple Left Behind, which should further increase stapler accountability.
Classy website - the online encryption demo is full of XSS bugs (including the message you type in just being dumped into a JS block for no reason).
Typical PHP programmer.
I know from experience that not all banks are nearly that bad.
Well crack it and show us how much expertice and master you are bruce, dont be afraid it is not too much for you or not??????????
Let me assist slightly: from the description, "decrypted previous block is key for other blocks" means the creator got CBC completely wrong. Even if this encryption algorithm was worthwhile, only the first block would be properly encrypted. Every other block in the entire message would be trivially decrypted in a known plaintext attack. My guess is the high order byte of the 16 bit random number of bytes would be 0, as a starting point.....
Also, where are the values for the transposition in step 2 stored?
Schneier.com is a personal website. Opinions expressed are not necessarily those of BT.