Because MSMQ runs only on Microsoft's Windows NT Server and clients must likewise run NT or Windows95, MSMQ quickly lost its appeal when faced with the variety of client platforms in our network lab. According to Microsoft, a third-party called Level 8 (which also happens to be the company that is the originator of Candle's MQSecure) can supply MSMQ-compatible messaging security add-ons for non-Microsoft platforms.

Before we could use MSMQ, we had to install SQL Server 6.5 on the MSMQ server. MSMQ stores queue information (but not the messages themselves, which reside in memory-mapped files) in Microsoft's RDBMS (Relational Database Management System). The company says future versions of MSMQ will use the new Active Directory Service technology rather than SQL Server.

On an NT Server machine, we used Windows Explorer to set up ACLs for our message queues. These file-level and directory-level permission slips prevented unknown users from reading anything in a queue or sending messages to it, and also kept users without privileges from sending messages to a queue. Anyone who can administer rights and permissions on NT Server will be able to administer MSMQ. We used MSMQ's own Explorer interface to create message queues, assign priorities and monitor message delivery. We also configured MSMQ to record key events, such as a password rejection or the opening of a queue, in the NT Server Security Log. The MSMQ Explorer is a central console for administering MSMQ across a network.

In the lab, MSMQ used the Microsoft Crypto API to encrypt and digitally sign the messages in the queues. The encryption preserved the confidentiality of message queue entries, while the digital signatures prevented the spoofing of counterfeit messages. Selecting its encryption and digital signing features was simply a matter of clicking checkboxes on the property sheets displayed by the MSMQ Explorer interface.

MSMQ required no special programming to implement security across its messages and queues. MSMQ imposed the security we specified via the Explorer interface, and our test program used MSMQ's APIs to send and receive messages.

Note that MSMQ also offers what Microsoft calls Independent Clients --a separate, nonsecure messaging facility that relies on local queues instead of network communication. Independent Clients is a feature to avoid if security is going to be a primary consideration.

Barry Nance, a computer analyst and consultant for 25 years, is the author of Introduction to Networking, 4th Edition (Que, 1997) and Client/Server LAN Programming (Que, 1994). You can reach him via the Internet at barryn@erols.com.

MOM's Security Methods
The MOM security products we tested use different procedures to shield message content. MQSecure uses RSA's RC2, while MSMQ uses Microsoft's own Crypto API.

For comparison purposes, DES (Data Encryption Standard) is the encryption block cipher developed by IBM Corp., and defined and endorsed by the U.S. government in 1977 as a standard. DES is a symmetric crypto system, requiring both the encoder and decoder to know the same secret key. DES has a 64-bit block size and uses a 56-bit key during encryption. Its export is almost always blocked by the federal government.

RC2 is a variable key-size block cipher designed as a "drop-in" replacement for DES. It has a block size of 64 bits and is about two to three times faster than DES in software. Like DES, it's a symmetric encoding scheme. Some vendors have obtained permission to export RC2.

Microsoft Crypto API, the foundation for the company's Internet Security Framework, by default incorporates cryptographic algorithms licensed from RSA. Its open architecture, however, provides for the drop-in addition of other encoding technologies. Microsoft terms these implementations of encoding schemes cryptographic service providers (CSPs), of which RSA's algorithm was the first. The Microsoft Crypto API gives developers a single, consistent security interface regardless of the encryption engine's underlying encoding scheme. Microsoft designed its scheme to be exportable, but its status depends on which CSP a particular implementation uses.

Theoretically, RC2 is the most secure of these schemes. DES has been successfully hacked, and the default RSA algorithm in the Microsoft Crypto API isn't as strong as RSA's RC2.