GlowCode Success Story

I use GlowCode for profiling ObjectARX applications. As far as I know, this is the only profiler that works with AutoCAD. What makes GlowCode special is that it can instrument code on the fly, including a monster like AutoCAD. It has a clunky interface that takes some patience to figure out, but it’s a lifesaver when you need it.

Recently a CADLock customer sent us a drawing file that was apparently not very complicated, yet it took over 20 minutes to create a deep vault. To determine the cause, I used GlowCode to profile the vault creation process. I could see almost immediately that most of the time was being spent in AcDbObjectId::operator ==, which was being called from AcDbObjectIdArray::find.

This turned out to be a classic case of using the wrong type of container. Searching an AcDbObjectIdArray isn’t bad when the array is small, but this drawing contained a special case where the array was very large, and this special case exposed the flaw. I changed the array to a std::set and tested again. The new time was 30 seconds to create the vault — a slight reduction of approximately 95%.

[Full Disclosure: Electric Software has for many years provided me with a complimentary license of GlowCode in exchange for my testing and feedback.]

Design File Locking and Snake Oil Security

The increased sharing of electronic CAD data (ala BIM) holds a lot of promise, but it also exposes companies and individuals to additional liability and risk. This additional risk is coming into focus more and more as actual cases of costly legal battles confront engineers and architects.

The June 2008 AUGI wishlist results contain “Design File Locking” as the top wish by a substantial margin, and Shaan Hurley lists it as number 3 in the AU 2008 AutoCAD wish list. Clearly, interest in file and IP security has been growing steadily.

As demand for IP security grows, there are sure to be snake oil security vendors trying to cash in on it. I received a spam email a few days ago from SafeNet, Inc. promising “a cost-effective and easy to integrate solution that provides reliable and effective security through the use of digital signatures.” Whenever I see such statements with a long string of buzzwords, my snake oil alarm goes on alert. Digital signatures are for authentication and establishing trust — they cannot and do not provide “reliable and effective security”, although I suppose they could be used by a system that does.

In the last year or two, a number of companies have claimed to market software that “secures” AutoCAD DWG files. When I see such a claim, it invariably refers to software that creates an anonymous unequally scaled MINSERT entity. These can be created or “exploded” with a few lines of AutoLISP code. Frequently these companies claim to “encrypt” the drawing, which may sound sexy, but is an outright lie. If this is a level of “security” that meets your needs, at least use one of the many free versions posted throughout the internet (DETER.VLX from DotSoft is one I know of).

There are solutions, but they always require changes in the workflow process that involve difficult tradeoffs and careful evaluation of what is technically feasible and practical versus the costs of implementing the changes. There is no such thing as installing a single piece of software to instantly solve the problem. If you are looking for ways to protect intellectual property in your drawing files, don’t be fooled by snake oil security vendors.

Disclaimer: One of my hats is the president of CADLock, Inc., makers of CADVault for AutoCAD.

Digital Signatures: Prelude

For many, the word “encryption” has a mysterious quality that invokes images of math virtuosos in secret bunkers working feverishly during wartime to break the enemy’s coded communications. My first exposure to encryption came in 1996 when I began working with Paul Kohut on the first version of CADLock software for locking AutoCAD drawing files. After overcoming my initial struggle to understand the terminology and get a handle on the mathematics behind encryption, I realized that it wasn’t nearly as mysterious and complicated as it first appeared.

I knew it would take a long time for encryption terminology to become standardized and commonly understood by laypersons. From the first days of CADLock, we recognized that the key to success for our software was going to be our ability to educate consumers about our technology, it’s possibilities and its limitations, its strengths and its weaknesses, what it could do and what it could not do. I felt that we needed to be realistic and patient while we waited for the market to catch up with our technology at its own pace. In the meantime, we needed to resist any temptation to needlessly bandy about sexy buzzwords like “encryption” lest we delay our mission by further muddying the waters in an already crowded ocean of technical jargon.

This recognition of the need for patience and perseverance has led me on a personal crusade to prevent encryption terminology from being perverted or hijacked by overeager marketing departments and uninformed experts. I’ve also tried to nudge the learning process along by adding my two cents whenever the opportunity arises. With this last goal in mind, I have prepared the following three part essay about digital signatures, tailored for the CAD industry. This is not written to academic standards, nor do I claim to be the final authority on the subject. Let me be clear about my agenda: I hope that furthering the common understanding of encryption related technology such as digital signatures will indirectly help sell more CADLock software!