A question about IESEngine key material usage

[pscz]

I'm trying to transmit a message from a server to a client using Bouncycastle's ECIESwithSHA256 encryption on the server-side.

Specifically, the server is using code similar to the following, to encrypt the message (along with some error-checking I did not include here):

private byte[] encrypt(PublicKey publicKey, byte[] message) {
    Cipher c = Cipher.getInstance(ECIES_WITH_SHA256, BouncyCastleProvider.PROVIDER_NAME);
    c.init(Cipher.ENCRYPT_MODE, publicKey);
    return c.doFinal(message)
}

I've been attempting to decrypt the ciphertext in a client application, written in Golang, for some time, and only succeeded after
I finally reimplemented ECIES manually and discovered the following Bouncycastle code:

From IESEngine.java:187 - encryptBlock():

            if (V.length != 0)
            {
                System.arraycopy(K, 0, K2, 0, K2.length);
                System.arraycopy(K, K2.length, K1, 0, K1.length);
            }
            else
            {
                System.arraycopy(K, 0, K1, 0, K1.length);
                System.arraycopy(K, inLen, K2, 0, K2.length);
            }

In the above code (in my case), the K variable contains 32 bytes of derived key material.
K1 is expected to hold 16 bytes of encryption key
K2 is expected to hold 16 bytes of MAC key

It seems, in my case, I end up in the first branch of the conditional, and this appears to be the only place in the code where the first 16 bytes of the derived key material are used as the MAC key instead of encryption key. In all other cases, the first 16 bytes of the derived key material are used as the encryption key. So, I tried to swap which bytes were read as encryption key and MAC key in my client, and suddenly the MAC validated.

Given that this behavior exists in the IESEngine.decryptBlock() code as well, I assume there's a reason for this reversal, that I'm just not aware of. That said, we've been getting reports from third parties, attempting to write their own clients, also failing to validate the MAC. So far, only one third party has been able to successfully validate it, and they are using Bouncycastle.

So, I'm wondering if this is intended behavior, or if we've stumbled onto a bug. Has the Bouncycastle implementation been tested against any other ECIES implementations?