Preach on. I recently witnessed a company's legal council make an opinion that they did not consider some encrypted data to be encrypted because of a key management deficiency a vendor had implemented in their software. In this particular case, a vendor had hard-coded a key to be used with a symmetric algorithm as a string in their code. Thus, every install of their product used the same key. And of course, any backup of that particular product's "encrypted data" could be restored by simply downloading their freely available eval version.
Ow. This is the problem with keys, especially with symmetric encryption. It is so confusing (a little knowledge can be a very dangerous thing), that even after 10 years of dealing with this side of the industry I still have to return to basics on a regular basis. Anyone just "dipping in" every so often really doesn't stand much of a chance of making a balanced decision.
Encryption and key management are quite topical with third part, Section 49 of the Regulation, of Investigatory Powers Act (RIPA) coming into force. Giving rights for law enforcement officers to demand encryption keys during an investigation.
All very reminiscent of the Clipper / Capstone era and the talk of enforced key escrow. Do Ingrian products support duress passwords and plausible deniability? 
Hi Interested,
It's always interesting to see the 'man versus machine' debate once in a while.
Duress passwords in an Ingrian environment would be redundant - access is based on user credentials. As long as a duress password program has been written for the OS you are using alongside your Ingrian deployment, then yes.
Plausible deniability is just weak security really. Something QSAs are responsible for in my opinion.
Commenting by HaloScan
