Encrypting the header in a logon message

, ,
1

Imported from previous forum

2

How do I get out of the contradiction implied by the following:
Portions of the standard header can be encrypted.
Nothing can be encrypted before the encryption method is specified.
The encryption method is specified in the body of the logon message.
The body of a fix message comes after the header of a fix message.

Thanks

3

[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> How do I get out of the contradiction implied by the following:
> Portions of the standard header can be encrypted.
> Nothing can be encrypted before the encryption method is specified.
> The encryption method is specified in the body of the logon message.
> The body of a fix message comes after the header of a fix message.

You’re right, you can’t encrypt header fields in the Logon message, since you haven’t defined the encryption method, and you haven’t exchanged keys (if using PGP-DES-MD5). However, the Logon contains little business content.

But this isn’t contradictory. After the initial Logon exchange, you can encrypt almost all of the header in all of the subsequent messages. Any fields that can’t be encrypted are clearly indicated in the spec.

PGP-DES-MD5 is only as strong as a 56-bit DES key. Yes, the key gets changed at each Logon (i.e. usually daily), but 56 bit technology is getting obsolete.

An entire FIX session can be wrapped in SSLv3 and/or TLS. This is probably the best way to secure a FIX session without relying on anything external (i.e. encrypting VPN routers) assuming both parties can do it. Even if they can’t, something like stunnel (open source) can, if properly configured, provide FIX session security.

4

Hi Scott,

I have got the task to see the FIX implementation for one of exchange here.

We need to implement it in VC++ , I need your advise on what is the best approach to start with and I have few questions

  1. how the message are encrypted
  2. if we are going to build FIX server, what are the major features it should have
  3. Is the data transmitted is in xml format

I am very new to this protocol, need some initial guide line

Thanks
m. hassan

5

> How do I get out of the contradiction implied by the following:
> Portions of the standard header can be encrypted.
> Nothing can be encrypted before the encryption method is specified.
> The encryption method is specified in the body of the logon message.
> The body of a fix message comes after the header of a fix message.
>
> Thanks
>
>

Joe,

Since the connection has not been established between engines, there really is no way to do this.

Engine 1 sends encryped logon; Engine 2 gets logon, Engine 2 cannot understand Engine 1’s message. Connection not created

However, a direct VPN-to-VPN connection or an STUNNEL would be best to encrypt the initial logon message …

Regards,

Nick