Virtual File Hash Always computed using SHA1

When sending to a customer that uses mendelson oftp solution, we always get an EERP with the virtual file hash computed using the SHA1 digest algorithm, regardless of the cipher suite selected (i.e. 3DES + SHA-256/512)
I have tested locally and it seems to be indeed the case. Excerpts from log:
Sep 29, 2017 3:37:32 PM] [Transmission 20] Generating virtual file hash for [C:\mendelson\opensource\oftp2\messages\customer\inbox\pending\FILE.TEST201709291537320420]
[Sep 29, 2017 3:37:32 PM] [Transmission 20] Virtual file hash generated successfully [1a 9c 77 fa 84 db c1 75 b1 14 0b 1d 03 c2 26 ac 53 50 b2 ca]
[Sep 29, 2017 3:37:32 PM] [Transmission 20] Decrypting transfer data [C:\mendelson\opensource\oftp2\messages\customer\inbox\pending\FILE.TEST201709291537320420]
[Sep 29, 2017 3:37:32 PM] [Session 20170929153731-220] Received command:
| CD Change direction [Inbound]
| 0 | X(1) | CDCMD | CD Command | 'R' | [52]
[Sep 29, 2017 3:37:32 PM] [Session 20170929153731-220] Send command:
| CD Change direction [Outbound]
| 0 | X(1) | CDCMD | CD Command | 'R' | [52]
[Sep 29, 2017 3:37:32 PM] [Transmission 20] The transfer data has been decrypted using the key with the alias "Key2"
[Sep 29, 2017 3:37:32 PM] [Transmission 20] Transfer data is signed, verifying signature
[Sep 29, 2017 3:37:32 PM] [Transmission 20] The signature has been successful verified using the certificate "test-server", hash algorithm is "SHA-256"
Judging by the size of the hash generated (20bytes) it seems to be SHA-1, while SHA-256 is reported as hash algorithm.
Is this a known issue? Or could there be a mistake in configuration?




without investigating it: is there a partner who complained about this?


I am :) Our OFTP solution verifies that the hash included in EERP matches the hash of the virtual file sent. If it doesn't, the acknowledgement of the transfer does not happen.
And while for our partner everything seems ok, in our system the processing of EERP fails.


You are right :)

Looking into the RFC I found the following:, Page 48:

SFIDCIPH Cipher suite selection Numeric(2)

Value: '00' No security services
'01' See Section 10.2

Indicates the cipher suite used to sign and/or encrypt the
file and also to indicate the cipher suite that should be
used when a signed EERP or NERP is requested.

As you can see, there is a "should" in the RFC - means you could test it but it is no error if the cipher suite is another. I think that is the reason no system complained about it so far.

Anyway we will check it and fix it for the next version if our system does ignore the requested cipher suite for the EERP signature.



I checked the issue in the current version of the mendelson OFTP2 and everything seems to work fine, the cipher suite is recognized during EERP signature. Please have a look at this log:

[Oct 5, 2017 9:46:58 AM] [Transmission 314] The signature has been successful verified using the certificate "Key1", hash algorithm is "SHA-256"
[Oct 5, 2017 9:46:58 AM] [Transmission 314] Transfer data is signed, removing signature
[Oct 5, 2017 9:46:58 AM] [Transmission 314] The signature has been removed using the certificate "Key1"
[Oct 5, 2017 9:46:58 AM] [Transmission 314] Data postprocessing finished successfully, waiting for outbound acknowledgement send process
[Oct 5, 2017 9:46:58 AM] [Transmission 314] A signed acknowledgement (EERP) has been requested
[Oct 5, 2017 9:46:58 AM] [Transmission 314] The acknowledgement (EERP) has been signed using the algorithm SHA-256, transmission file hash has been added
Means from the logging perspective everything seems to be fine. Afterwards I checked the signature generator after the generation process in debug mode and asked for the OID of the generated signature, the result is OID 2.16.840. which is SHA-256. Means this seems to be fine, too.

Which version are you using, is it older than 2015, then SHA-2 signature was not even in the OFTP2 RFC?


Thank you for your answer. I guess I did not make myself understood. The signature contained in the EERP is correct and we can verify that. The signature of the EERP in itself only proves that the EERP message has not been tampered with. I want to verify that this EERP message is indeed referring to the correct file it claims it references.
More exactly, I am talking about the EERPHSH Virtual File hash field from the EERP message, whose description is at page 60 from the rfc. I will copy it here:

Hash of the transmitted Virtual File, i.e., not the hash of the original file.
The algorithm used is determined by the bilaterally agreed
cipher suite specified in the SFIDCIPH.

It is an application implementation issue to validate the
EERPHSH to ensure that the EERP is acknowledging the exact
same file as was originally transmitted.
As it says, the verification we are doing is not mandatory, though I consider it should be done, as it proves that the original files has arrived untampered at the destination.
This hash I believe is computed using SHA-1 (because it has 20 bytes=160 bits, that is the size of the sha-1 digest).
Thanks again for your reply and best regards.


ah ok, got you. Yes, this is signed with SHA-1 always, you are right. We will fix this.

Anyway you just have found one of the problems of all these protocols AS2, OFTP2, AS4: The verification of any signature of the message acknowledge makes no sense because all these protocols have no idea how to deal with a failed verification - they all know about this problem and write that the sulution should be an "implementation issue" (which makes no sense). You cannot set the transmission state to wrong because the protocol defines no way to inform your partner that there has been a problem in the acknowledgement verification - and you must not just set the transaction state to wrong without informing your partner because then both partners would have different states of the transaction with is the worst idea. Means for OFTP2, AS2 (async) and AS4 (ENTSOG, e-sens) you must ignore these kind of problems. The only protocol that defines such an error message that refers to older transactions are RosettaNet 1.1, RosettaNet 2.0 and AS4 in the (seldom used) ebXML profile.


Hi, thanks for the reply.
You are right, if you ever get into one of these situations, you need to pick up the phone which kind of defeats the purpose of automatic data transfer.
Looking forward for a new version.

Best regards,

..and having 40000 messages a day will result in several calls :)

We have fixed it but the community users will get it first in the next derived open source version which will at the beginning of 2018.

Thank you for your feedback!