I’ve had limited connectivity / time in the last couple of weeks, but I’m back baby!
The lesson of the day: you shouldn’t let your AV vendor provide general security. The lesson comes to us via Graham Cluley’s Sophos blog, which informs us that Sophos released a free encryption tool. So, what’s wrong with it?
- It uses symmetric crypto! Let me repeat that for you: it uses symmetric cryptography and recommends that you communicate the encryption password to the counterparty via an other communication channel. So much for ease of use and the asynchronous nature of email!
- The feature sheet starts out by declaring that PKI has failed us, and then it touts a proprietary centralized solution for managing passwords.
In conclusion: this is a software which shouldn’t have been made. It is simplistic, cumbersome to use and provides no added benefit over using something like 7-zip with encryption (which also uses AES, also does compression – most probably better compression – and it to can create SFX password protected archives).
Go and install Thunderbird with Enigmail.
For added fun: the brochure says “Protects against “brute force” attacks by increasing response times each time the user enters the wrong password”, and they then proceed to give you a CLI and COM interface to the program which can be used directly to bruteforce the archives and without these timeouts. Nice!
5 responses to “Back with a vengeance”
i heard about sophos' encryption tool but there wasn't anything to suggest it solved any problem i had with existing encryption products (i specifically remember thinking 'why should i trust this over truecrypt or similar tools?') so i never bothered digging into the details.
of course, i'm not about to put faith in any new cryptosystem. let it be scrutinized for a few years first, then maybe i'll consider it (depending on the results of that scrutiny).
The problem (IMHO) is not with the cryptosystem per-se (although there are many opportunities there too to f*** up – for example by using AES in ECB mode and not using integrity verification like HMACs), it is more that there are better technologies which are more usable and these types of products – by claiming to be "state of the art" – obscure the better solutions.
It also reflects badly on the company (the level of knowledge – or lack of it – in their architecture team).
I have to disagree in several points:
"Not asymmetric equals bad" is a bit simplistic. There is nothing wrong in using FIPS-validated symmetric crypto to store data in encrypted archives. Occasionally these archives get attached to email, yes. But that's not the only or foremost use of the tool.
Granted, there are other tools that do pretty much the same. So? No law against that.
Re the delay for wrong passwords and the scripting interface – did you really try that? I did. And guess what, the delay is there even when scripting.
But even if it wasn't, it wouldn't matter. The real security is in the key derivation from the password. The delay is just another layer, call it defense in depth. Relying on that only would be negligent.
@Jo:
"Re the delay for wrong passwords and the scripting interface – did you really try that? I did. And guess what, the delay is there even when scripting.
But even if it wasn't, it wouldn't matter. The real security is in the key derivation from the password. The delay is just another layer, call it defense in depth. Relying on that only would be negligent."
the delay is irrelevant when scripting because you can run things in parallel.
@Jo: my assertion isn't that symmetric crypto is bad (after all, it has a lot of desirable properties – like speed – and is used in all products which implement asymmetric crypto after the initial key exchange). My assertion is that presenting an inferior method for key exchange (centralized key server as opposed to PKI) as superior is irresponsible. There is already enough FUD and misinformation out there in the field of IT security, and responsible companies should work to reduce it, not create even more.
Second of all, there is almost surely nothing illegal about this tool (of course I can't say for sure because IANAL and also because the law is a highly malleable construction – fitness for purse and truthful advertising are two domains which come to mind). I was commenting from the ethical point of view.
Third of all, I didn't try the scripting interface, but I did try the command line interface and I observed no delay there. Also, as Kurt already said, even if there were such a delay, one could do multi-threaded (multi-process?) bruteforcing to counter that. Also, it is probably quite trivial to patch it out.
What you say about the password derivation: first the idea (of creating an encryption password and then encrypting that with the user password so that the later can be changed independently / multiple users can have access to it without re-encrypting) isn't new nor unique for this product. Also, I really, really hope that you didn't use something "proprietary" / "in-house" solution for this. There are well known (and analyzed) algorithms out there for this purpose, and if you did use your own algorithm, that's a definite sign of lack of crypto knowledge (which in turn would make the value of the product even more questionable).