TGSLC Testing Report

[sfullerton@glhec.org]

     Following is the report summary by Dennis Alley on testing done by 
     TGSLC on the AT&T Information Security Corporation encryption toolkit. 
      
     Any formatting errors more than likely are my fault.  I added one 
     comment, each line of which is prefixed with ">>".
     
     Brian Wilson
     
     
     
     
     Texas Guaranteed Student Loan Corporation 20 July 1998
     
     Testing log of AT&T SA432 and SA4CLI32 encryption engine DLL.
     
     
     The following items were performed on a closed platform:
     
     Except for the two domain exceptions noted below, all functions 
     exhibited in the AT&T 'Testcli.cpp' example program were duplicated in 
     a stand-alone Delphi program.  Unless otherwise noted, the engine 
     performed as expected.  Those functions included:
     
     1.      Seeking, returning and displaying the SA4 version number.
     
     
     2.      Key generation:
     
     Generating a 512-bit DSA public encryption key.
     
     Generating a 1024-bit DSA public encryption key.
     
     Generating 512-bit RSA public encryption key and accompanying 512-bit 
     private decryption key.
     
     Generating 1024-bit RSA public encryption key and accompanying
     1024-bit private key.
     
     
     3.      Encrypting, decrypting and sight checking (ASCII text) test 
     documents for each type of generated key listed in item 2.
     
     
     4. Encryption/decryption of packets to single recipients.
     
     
     5. Encryption/decryption of packets to multiple recipients in one 
     transaction.
     
     
     6.      Verification, on decryption, that a "signed" transmittal was 
     recognized as originating with a user whose public key was NOT in the 
     public-key ring.
     
     
     7.      Verification, on decryption, that a "signed" transmittal was 
     or was not actually encrypted by the proclaimed user. This was 
     accomplished by testing valid encryptions and then by physically 
     altering the encrypted packet.  
     
     [NOTE:  Test results were inconsistent on this item and additional 
     testing is scheduled to isolate the cause.  When multiple decryptions 
     were attempted in one process loop, the tampered file was recognized 
     on the first recipient of the set but the process did not seem to 
     identify the tampering on succeeding recipients.  It will have to be 
     determined whether this is a local programming/logic) error or a 
     legitimate flaw in the product.]
     
     [NOTE 2:  In working with the numerous combinations of public key, 
     private key, user Ids and passwords it appeared that there may be a 
     problem in decrypting a message that had not been signed.  Since the 
     AT&T sample did not exhibit this anomaly I expect that the error was 
     the result of either program logic or process flow.  Additional 
     testing is planned to reconstruct the error.]
     
     
     8.      In items 1 through 7, numerous planned errors in syntax and 
     parameter passing to the various command line calls to the SA4CLI32 
     interface were executed to test the engine's error handling.  
     All errors were handled acceptably.
     
     
     9. Encryption and decryption of ASCII text, Windows BMP images 
     (binary) and Windows executable programs (binary) were tested 
     successfully on the local client.
     
     
     10.     The DLL's ability to locate (generate to and retrieve from) 
     either the Public Key file or individual Private Key files, in logical 
     directories other than the 'home' directory in which the executable or 
     the DLL were located, was successfully tested in various combinations.
     
     
     11.     The DES CBC algorithm, the DES3 CBC algorithm and the 
     proprietary AT&T EA2-CBC algorithm were all tested successfully using 
     1024-bit RSA keys.  These tests were based on the available options 
     listed in AT&T's 'readme' file that accompanied the developers' kit.  
     
     [Note:  Since I have not heard any discussion of this topic in our 
     teleconferences, I'll take this opportunity to make note of the 
     following:  AT&T documentation frequently uses the abbreviation 
     "RSA" and refers to both 512-bit and 1024-bit encryption keys (common 
     to RSA) but I have NOT seen any literal reference to the actual RSA 
     (Rivest-Shamir-Adleman) algorithm.  It seems to me that we may have 
     available only DES, DES3 or a proprietary AT&T algorithm.  Am I 
     mistaken
     
     and/or are our members all aware of this?  This point may have been 
     settled before I joined the discussions so please forgive me if I have 
     missed something.  Please note also that I do not have access to the 
     shrink-wrapped SecretAgent user package and its documentation.]
     
     >> RESPONSE:  The AT&T toolkit does indeed use RSA the algorithm.  The 
     >> basic encryption/decryption technique has the message encrypted 
     using >> one of the three algorithms listed(DES CBC, DES3 CBC, 
     EA2-CBC) which >> are all symmetric key algorithms.  Then, the 
     symmetric key that 
     >> algorithm used for the message is encrypted using the 1024 bit >> 
     RSA public key.  The decryption process starts by using the RSA >> 
     private key to decrypt the symmetric key, and then using that to >> 
     decrypt the message (This explanation ignores signature issues)  >> 
     The reason for the dual encryption technique is efficiency and 
     >> security.  The symmetric key algorithms work well on steams of 
     data, >> where the public key/private key algorithms work well on 
     defined size >> chunks.
     >> The reason for any confusion here was more than likely the 
     >> documentation provided with the toolkit.  It never clearly stated 
     how >> the encryption worked at a low level.
     
     Test items 3, 4, 5, 6, 7 and 9 were again executed at a remote site 
     after transmitting encrypted packets via SMTP to a remote TCP/IP mail 
     server, offloading the packets via POP3 and validating the results by 
     decrypting with the AT&T engine.  All tests successfully matched the 
     results encountered on the local closed platform.
     
     
     
     
     Exceptions:
     
     As discussed in previous correspondence we initially encountered
     difficulties in establishing links to the WRITEDSAPK and WRITERSAPK 
     export handles in the AT&T DLL.  It was determined that the 
     handles had been declared using all upper-case letters.  We did 
     establish successful links with the two handles, however, due to time 
     constraints, we have not yet pursued testing on the operations of 
     those two functions.  Additional testing of key management and key 
     exchange mechanics is scheduled.
     
     
     Dennis Alley