DES (option 2)

, ,
1

Imported from previous forum

2

[ original email was from Andrew Smith - asmith@redfishgroup.com ]
Hello,

I’m looking at plain DES encryption (option 2) and seem to be finding somewhat conflicting information. The Security Protocol Application Note appears to describe not just PGP-DES-MD5 and PEM-DES-MD5, but DES as well. For example, it says “… if the EncryptMethod is DES (i.e. option 2), the [LOGON] buffer is encrypted using the DES master key… the DES master key is used only for encrypting LOGON messages.” If this app note is indeed the documentation for DES encryption, it seems to imply or state the following:

  1. Logon message contains a SessionInfo struct in the RawData field.

  2. Logon message is encrypted with master key in ECB mode (not stated, but implied since no initialization vector seems to be available at initial logon time.)

  3. Non-logon messages are encrypted in CBC mode using the procedure given.

However, I’ve read postings in this forum that state for DES all messages should be encrypted in ECB mode. The app note never mentions ECB mode.

So if anyone can help me with the following questions, I would certainly appreciate it.

  1. Which is it - ECB only, ECB/CBC, or other?

  2. If ECB only, which key is used for non-Logon messages, the master key or the key given in SessionInfo? If the SessionInfo key, what about the IVec? Should it be included but empty, or excluded? If the master key, should SessionInfo then not be included?

  3. Also if ECB only, why? The app note seems to make sense and to be more secure.

Thanks for your help.

Andrew Smith

3

The App Note you’re referring to was written to define PGP-DES-MD5 (tag 98, value 5) and PEM-DES-MD5 (no one uses to the best of my knowledge). The author of that document was not very familiar with the implementation of “standard DES” in FIX (tag 98, value 2) which pre-dated PGP-DES-MD5 and unfortunately attempted to partially document its behavior. I would recommend only using that App Note as a reference for PGP-DES-MD5.

For EncryptMethod (tag 98), value 2 (standard DES):

  1. DES in ECB (only) mode
  2. a. Key is exchanged out of band and does not change on any sort of regular basis
  3. b. There is no RawData or SessionInfo block in the Logon to facilitate 98=2.
  4. That’s just the way everyone implemented it back in the early-to-mid 1990s. The “improved” implementation was PGP-DES-MD5 (98=5) was documented in 1996 is more secure, provides a reference implementation, and a better description.

> Hello,
>
> I’m looking at plain DES encryption (option 2) and seem to be finding somewhat conflicting information. The Security Protocol Application Note appears to describe not just PGP-DES-MD5 and PEM-DES-MD5, but DES as well. For example, it says “… if the EncryptMethod is DES (i.e. option 2), the [LOGON] buffer is encrypted using the DES master key… the DES master key is used only for encrypting LOGON messages.” If this app note is indeed the documentation for DES encryption, it seems to imply or state the following:
>
> 1. Logon message contains a SessionInfo struct in the RawData field.
>
> 2. Logon message is encrypted with master key in ECB mode (not stated, but implied since no initialization vector seems to be available at initial logon time.)
>
> 3. Non-logon messages are encrypted in CBC mode using the procedure given.
>
> However, I’ve read postings in this forum that state for DES all messages should be encrypted in ECB mode. The app note never mentions ECB mode.
>
> So if anyone can help me with the following questions, I would certainly appreciate it.
>
> 1. Which is it - ECB only, ECB/CBC, or other?
>
> 2. If ECB only, which key is used for non-Logon messages, the master key or the key given in SessionInfo? If the SessionInfo key, what about the IVec? Should it be included but empty, or excluded? If the master key, should SessionInfo then not be included?
>
> 3. Also if ECB only, why? The app note seems to make sense and to be more secure.
>
> Thanks for your help.
>
> Andrew Smith
>
>

4

[ original email was from Ryan Pierce - rpierce@taltrade.com ]
I would recommend against using this form of DES security.

DES is a 56-bit cipher. Brute force attacks are becoming easier and cheaper.

The EFF was able to design and build a machine for under $250,000 USD in 1998 that could try 92 billion keys / second. And most of that was one time R&D work which has been released to the public, thus making future machines cheaper.

Hence I think it is fair to say that, for a few hundred thousand dollars, you could stand a fair chance at breaking the DES key of a FIX session within the same trading day.

But if firms use the same DES key without changing it for years, as is often done with 98=2, I would imagine that one could use much less expensive hardware, leave it chugging away in a closet for a few months, and finally find the secret key between two parties, which likely will be valid from that point forward until the parties discover the compromise.