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



RSA (AES ( BASE64( response ) ) ),

where RSA - RSA- private-key encryption

AES - Symmetric key encryption

response – server response


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.

  • $\begingroup$ Serial concatenation sounds a lot like concatenation to me. Expressed in PHP code (because it has the easiest concatenation opearators), $var= $a . $b $\endgroup$ – rath Dec 6 '13 at 6:14
  • 4
    $\begingroup$ This question appears to be off-topic because it is about programming issues and not cryptography. $\endgroup$ – rath Dec 6 '13 at 6:15
  • 1
    $\begingroup$ @rath: i tried that kind of simple concatenation before and it did not work. I'm not asking for programming help, I'm asking for help understanding a cryptography concept I have never heard of before. I have seen references to ”serial concatenation” and ”parallel concatenation” in my searches but do not know what they actually are, let alone how to implement them in code. $\endgroup$ – Remy Lebeau Dec 6 '13 at 6:18
  • $\begingroup$ I'm not sure it's a crypto concept, but I may be wrong. Would you mind adding a link to the relevant API page? $\endgroup$ – rath Dec 6 '13 at 6:21
  • 1
    $\begingroup$ @rath: the API is for a private service and the tech document I have was given to me by a client I am writting the software for and has the client's personal info in it. I will copy the relevant portions tomorrow, but they are very minimal in detail. $\endgroup$ – Remy Lebeau Dec 6 '13 at 6:33

"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.


Not the answer you're looking for? Browse other questions tagged or ask your own question.