What is "serial concatenation"? I have a third-party point-of-sale API (Speedflow Pay-N-Get) that I am trying to communicate with over HTTP, but I have a problem with it.

In a nutshell, a request is encrypted using RSA, and the response is encrypted using RSA followed by Rijndael/AES-128.  The RSA keys are provided by the vendor, the AES IV is a vendor-provided guid, and the AES key is the vendor-provided guid and a random requester-generated guid combined using "serial concatenation".  The random guid is included as a parameter of the request.

I am using OpenSSL to handle the encryption/decryption.

I have everything working except the AES portion.  I have no clue what "serial concatenation" is, online searches do not find any useful info about it, and the vendor has not replied yet.  Does anyone know what this is?

Update: Here is what the API doc says about the AES portion of the encryption:


  The server response — EDATA data in the body of the HTTP response.
  
  Formula: EDATA = Base64(Rj(RSA1(DATA)))
  
  Rj — symmetric algorithm Rijandel-128
  
  IV — Guid # 1 value, converted to a byte array
  
  Key — value Guid # 1 and Guid # 2 (serial concatenation)
  
  mode spacing — Zeroes


Also:


  -----Decryption.-----
  
  RSA (AES ( BASE64( response ) ) ),
  
  where RSA - RSA- private-key encryption
  
  AES - Symmetric key encryption
  
  response – server response
  
  -----AES-----
  
  use bouncyCastle: cipher= PaddedBufferedBlockCipher ( CBCBlockCipher ( RijndaelEngine(128)),
  ZeroBytePadding() );
  
  cipher.init (false, ParametersWithIV ( KeyParameter ( mykey ), iv )
  );
  
  where mykey- coding in hex string guid3
  
  iv- concatenation coding in hex string guid3 and coding in hex string guid2
  
  Encoding is performed on this algorithm by taking two character of a string is converted to hex and added to an array of bytes.


Guid#1 is the vendor-provided Guid, Guid#2 is the randomly generated Guid.  Both are included in a request.  I suspect the second paragraph actually meant the IV is Guid3 and the key is the concatenation of Guid3 and Guid2.  Guid3 is just Guid1 with its first 3 fields converted to big endian.

Since an AES-128 key is only 16 bytes in size, and a Guid is also 16 bytes in size, I suspect that "serial concatenation" would be somehow hashing them together, rather then simply appending them to each other, which would produce a 32-byte key instead.
"Serial concatenation" is not a standard term in cryptography.  Without any further information, I would guess that it probably refers to just concatenation.  If that's not what it refers to, then your spec is deficient and ambiguous; you'll need to consult with the author of the spec to ask for to clarify what they meant by that phrase.