Imported from previous forum
FIX protocol version 4.2 description states:
"For more detail on implementation of various encryption techniques see the application notes section on the FIX Web Site".
But I failed to find such thing as "application notes" at the site! Could someone to help me to acquire comprehensive up-to-date information releated to encryption implementation in FIX?
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> FIX protocol version 4.2 description states:
> "For more detail on implementation of various encryption techniques see the application notes section on the FIX Web Site".
> But I failed to find such thing as "application notes" at the site! Could someone to help me to acquire comprehensive up-to-date information releated to encryption implementation in FIX?
On the FIX Web Site, click Specifications then click App Notes. There is an Encryption app note as well as a reference implementation for PGP-DES-MD5 which is currently the most utilized method of session security.
Although it is not yet acknowledged formally as an encryption method for FIX, firms are starting to take interest in encapsulating FIX inside SSLv3 or TLS.
This will likely be considerably stronger than PGP-DES-MD5, because SSLv3 and TLS both allow for 128 bit encryption, as opposed to a 56 bit session key for DES in PGP-DES-MD5. It is hopefully easier to implement in an existing FIX engine than PGP-DES-MD5 because SSL or TLS wraps around the outside of the session, as opposed to PGP-DES-MD5 which embeds itself in the middle of each FIX message.
Further, SSL and TLS can be added via an external proxy to engines that do not support them natively. One firm already is making such a FIX proxy freely available.
Unless other alternatives are deemed better, I consider it a goal for the Encryption Working Group to conduct a pilot of testing FIX over SSLv3 and/or TLS, publish an App Note, research vendors for SSL and/or TLS software, and possibly release reference implementation(s).
> > FIX protocol version 4.2 description states:
> > "For more detail on implementation of various encryption techniques see the application notes section on the FIX Web Site".
> > But I failed to find such thing as "application notes" at the site! Could someone to help me to acquire comprehensive up-to-date information releated to encryption implementation in FIX?
>
> On the FIX Web Site, click Specifications then click App Notes. There is an Encryption app note as well as a reference implementation for PGP-DES-MD5 which is currently the most utilized method of session security.
>
> Although it is not yet acknowledged formally as an encryption method for FIX, firms are starting to take interest in encapsulating FIX inside SSLv3 or TLS.
>
> This will likely be considerably stronger than PGP-DES-MD5, because SSLv3 and TLS both allow for 128 bit encryption, as opposed to a 56 bit session key for DES in PGP-DES-MD5. It is hopefully easier to implement in an existing FIX engine than PGP-DES-MD5 because SSL or TLS wraps around the outside of the session, as opposed to PGP-DES-MD5 which embeds itself in the middle of each FIX message.
I believe we are talking about two different things:
a) SSL3 encrypts the contents transmitted in a secured session
b) PGP encrypts the contents of a message. This encrypted message can be transmitted over SSL3 or just "in the clear" although the latter would still means that the contents are encrypted.
That being the case, we can use both for a double whammy approach… transmitting encrypted contents over a secured (meaning another encryption process using the session id) session.
>
> Further, SSL and TLS can be added via an external proxy to engines that do not support them natively. One firm already is making such a FIX proxy freely available.
>
> Unless other alternatives are deemed better, I consider it a goal for the Encryption Working Group to conduct a pilot of testing FIX over SSLv3 and/or TLS, publish an App Note, research vendors for SSL and/or TLS software, and possibly release reference implementation(s).
>
>
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> I believe we are talking about two different things:
> a) SSL3 encrypts the contents transmitted in a secured session
> b) PGP encrypts the contents of a message. This encrypted message can be transmitted over SSL3 or just "in the clear" although the latter would still means that the contents are encrypted.
> That being the case, we can use both for a double whammy approach… transmitting encrypted contents over a secured (meaning another encryption process using the session id) session.
PGP isn’t used for the purpose you describe. In PGP-DES-MD5 mode, PGP is used only to authenticate the exchange of a randomly generated 56-bit DES session key. DES is used to encrypt the body of each FIX message. MD5 is used to produce a “signature” for the message. Calling it a signature really is a misnomer because, unlike digital signatures using public-key crypto, both parties could generate the “signature” hence it does nothing to guarantee non-repudiation.
Encapsulating PGP-DES-MD5 FIX inside SSL or TLS is of absolutely no value. Both provide the same functionality; they allow the two parties to authenticate each other, allow for encrypted data exchange, and prevent man-in-the-middle attacks and data modification.
Now there has been some interest in having individually signed messages. This would involve true public key crypto. This is particularly of interest for very high dollar value transactions, where non-repudiation is more of an issue. For instance, it is possible for a party to falsely deny something that happened over an SSL session; they generally can’t deny it if the message in question was signed by their public key. This type of thing goes hand in hand with SSL or TLS; the signature guarantees the message’s origin, and SSL / TLS encrypts and authenticates the two FIX engines. However, it is going to be much harder to standardize upon message signatures, especially considering that they may need to be signed at an individual trader level, not by the FIX engine.
[ original email was from Chris Lambert - chris.lambert@emx.co.uk ]
EMX is currently trialling FIX over SSL with 14 UK Mutual Funds providers, distributors and software houses.
EMX is the UK mutual fund industry-owned "Electronic Message Exchange" - offering FIX/SSL and HTTPS messaging for Orders, Executions, Reconciliations & Valuations. We have approximately 50 product providers (over 70% FUM) signed up for EMX and 134 firms in total.
We have implemented an in-house Certificate Authority and Digital Signature scheme that allows FIX messages to be signed, validated centrally, forwarded to recipients (who can in turn copy/forward messages again) whilst allowing anyone along the way to check the message contents signature v the original sender.
We are happy to share experiences with those who are interested. There is quite a lot of information on our Web site (http://www.emx.co.uk)
Chris Lambert
EMX Project Manager
Tel : +44 1279 858 315
[ original email was from Chris Lambert - chris.lambert@emx.co.uk ]
Ryan Pierce wrote:
“Now there has been some interest in having individually signed messages. This would involve true public key crypto. This is particularly of interest for very high dollar value transactions, where non-repudiation is more of an issue. For instance, it is possible for a party to falsely deny something that happened over an SSL session; they generally can’t deny it if the message in question was signed by their public key. This type of thing goes hand in hand with SSL or TLS; the signature guarantees the message’s origin, and SSL / TLS encrypts and authenticates the two FIX engines. However, it is going to be much harder to standardize upon message signatures, especially considering that they may need to be signed at an individual trader level, not by the FIX engine.”
At EMX we are currently implementing this - documentation is on http://www.emx.co.uk/emx/documentation.htm.
In our case non-repudiation involves relaying all FIX messages via a third party’s FIX Hub (i.e. EMX’s) where signatures are checked and a copy of the message stored in a “vault” and is available to assist in resolving any later disputes between the parties. However the same algorithms could be applied to point-to-point FIX.
Chris Lambert
Project Manager
EMX Company Limited
chris.lambert@emx.co.uk
[ original email was from Dmitry Parkhomovsky - dmitry@viewtrade.com ]
> FIX protocol version 4.2 description states:
> "For more detail on implementation of various encryption techniques see the application notes section on the FIX Web Site".
> But I failed to find such thing as "application notes" at the site! Could someone to help me to acquire comprehensive up-to-date information releated to encryption implementation in FIX?
>
>
>
I have downloaded the FIX API from App Notes. I was able to compile it. I have a couple of questions.
- Is there a C++ Version of all this?
- Is there a test driver (main) for FIX API that I can use, or is it better to write my own.
If anyone knows, please e-mail me or reply to this posting. Thanks.