Question:
Is it possible to encrypt a file/querystring using .NET and decrypt it on the other end using a C++ COM object?
Answer:
According to Microsoft, .NET will be cross-Windows-platform compatible, so I am assuming that, yes, you will be able to encrypt using .NET and decrypt using COM, since they should eventually have access to the same software libraries.
That said, I feel somewhat negligent in publishing my last column without this warning: Encryption is extremely difficult to implement correctly. Microsoft’s .NET provides some simple, easy-to-use methods for accessing crypto on their platform, but the best and safest way to utilize them is to follow their examples and structure exactly.
Encryption technology is not easy. It takes years of study to be able to implement the math involved in some of today’s algorithms. Most encryption products, however, fail in their implementation. Not in the encryption itself, but in how the encryption is used.
 |
If I wanted to break an encrypted message, I could capture it and then set up a team of computer processors in a Belkin-like environment running brute force attacks to try and decrypt the message. This could work, or it may take me years. If I was smart, instead I would look for what could be a key exchange and attack that, not necessarily by trying to decrypt the keys, but instead looking for where in the implementation they aren’t encrypted. At some point the key exchange has to drop into the clear, and that’s where I want to be.
A good introduction to cryptographic theory is Bruce Schneier’s Applied Cryptography. John Viega and Gary McGraw’s co-authored Building Secure Software makes some good recommendations and outlines strengths and weaknesses of some of the most used cryptographic libraries.
| When the Java byte code interpreter is run, it looks for the system policy first, then the user policy, and if it finds neither it defaults to the sandbox policy. |
Although .NET has an easy C# interface for encrypting a file, developing an actual secure software product is extremely difficult, and as the encryption piece grows in complexity, so does the chances of it failing, or becoming a security hole. Misapplications may be the most common form of encryption failure. My advice is to keep your solution as simple as possible, use a common, tried and true methodology, and use the same development platform if possible.
Question:
In Java, can I use a subclass of SecurityManager to override an applet’s checkTopLevelWindow?
Answer:
Frankly, custom security managers are highly discouraged, and being able to subclass security manager was deprecated in Java 1.2. You can customize your applet class security locally, but normally this is done by:
- Editing the default system policy
- Editing the user policy file
- Changing the class used to implement the security policy.
When the Java byte-code interpreter is run, it looks for the system policy first, then the user policy, and if it finds neither it defaults to the sandbox policy. However, these changes will only apply to users of the modified JDK installation. The normal route to changing applet security and have it apply non-locally is using a signed applet and/or certificate authority.
Have a security related question you want answered in a future Tacit Records column? E-mail the author at tschmidt@13floors.com.
About the Author
Thomas Gutschmidt is a freelance writer, in Bellevue, Wash., who also works for Widevine Technologies.
