Re: Signature and BodyLength
Ryan Pierce / Townsend Analytics
30 Aug 2007 4:07PM ET
> My question is: Should signature be considered for bodylength
> calculation during encryption? If yes, during signature generation,
> body length may not represent correct value (as signature is not added
> to field collection) but while decrypting body length includes
> signature value which results in different md5 hash.
Wow.... It's been a very long time since I've had to answer implementation questions about PGP/DES-MD5. And it's also been a very long time since I've done anything with code that implements it.
I took a look at the original Morgan Stanley document, and it seems that, when "signing" a message (I use the term loosely since this is a message authentication, not an actual digital signature) one must:
1. Prepare the entire message up to that point (I.e. the unencrypted header fields + the encrypted data block. No trailer fields.)
2. Compute BodyLength just as you would for a normal FIX message, where all that is missing is the checksum. Ignore the signature fields in the trailer.
3. The signature is a fixed length; MD5 always outputs 16 bytes. The two tags used are each 2 bytes long, there are 2 "="'s, the number "16" (the length) takes up 2 bytes, and 2 <SOH>'s. So that's 26 bytes total. Add 26 to the message length computed in #2, and stick that in the message.
4. Take an MD5 hash of the DES key, the FIX message so far (which includes what will be the exact BodyLength once the signature is applied), and the DES key again.
5. Append to the end of the message the following 26 bytes:
93=16<SOH>89=XXXXXXXXXXXXXXXX<SOH>
(Where the X's are the 16 bytes of the MD5 signature)
6. Stick on a Checksum field, and the message is ready for transmission.
Of course I wonder why anyone is considering a new implementation using PGP/DES-MD5. DES is not secure against a determined adversary. Tunneling FIX through SSL or TLS via Stunnel, or building an SSL or TLS library directly into the FIX engine, provides for state of the art cryptography support, and, I would imagine, would be substantially easier to implement than PGP/DES-MD5.
The following draft paper will describe the new proposed recommendations regarding security in detail:
http://www.fixprotocol.org/documents/3556/FIX%20Security%20White%20Paper.pdf
