# What is “serial concatenation”? [closed]

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

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.

-

## closed as off-topic by rath, tylo, Gilles, e-sushi, D.W.Dec 9 '13 at 3:10

• This question does not appear to be about cryptography within the scope defined in the help center.
If this question can be reworded to fit the rules in the help center, please edit the question.

Serial concatenation sounds a lot like concatenation to me. Expressed in PHP code (because it has the easiest concatenation opearators), $var=$a . \$b –  rath Dec 6 '13 at 6:14
This question appears to be off-topic because it is about programming issues and not cryptography. –  rath Dec 6 '13 at 6:15
@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. –  Remy Lebeau Dec 6 '13 at 6:18
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? –  rath Dec 6 '13 at 6:21
@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. –  Remy Lebeau Dec 6 '13 at 6:33