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.