Google Crypto-js AES encryption
I'm trying to use Google's crypto-js package to AES encode data for submission to a payment portal (Sagepay using AES-128-CBC-PKCS5). The specifications of the software exactly match Sage's requirements EXCEPT they specify AES-128 encryption. The submissions are being rejected by Sage as gobbledygook however it's not clear why. The only thing I can think is that Sage provide a passphrase rather than a Hex string and it says in Google's documentation that use of a passphrase causes the software to default to AES-256 - does anyone know any way to force it to use AES-128 even with a passphrase? Also, crypto-js doesn't support PKCS5 however I've read elsewhere that PKCS7 is compatible, which is the crypto-js default.
Do more with
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
PKCS5 itself required also a salt together with the passphrase, e.g. encryption key=KDF2(password, salt, iterationCount, keySize). Note that I indicate KDF2 (PBKDF2) which is the recommended but in fact there is another based on the older KDF1 - PBKDF1. This old project but still applicable since it is using the crypto of interest to verify the scheme
http://www.di-mgt.com.au/properpassword.html#vbnet2vb6
As for the padding, indeed it can be PKCS5 (this is referring more to padding scheme per se, ignore the PDKDF above) or PKCS7 based which are two common ones used. For info, The difference between these padding mechanisms is the block size
- PKCS5 padding is defined for 8-byte block sizes,
- PKCS7 padding is defined to work for any block size from 1 to 255 bytes.
Hence, fundamentally PKCS5 padding is a subset of PKCS7 padding for 8 byte block sizes. Therefore, PKCS5 padding cannot be used for AES. PKCS5 padding was only defined with 3DES in mind instead. ome cryptographic libraries such as the SUN provider in Java indicate PKCS#5 where PKCS#7 should be used - "PKSC5Padding" should have been "PKCS7Padding".
Ref - PKCS #5: Password-Based Cryptography Specification V2.0
https://www.ietf.org/rfc/rfc2898.txt
http://www.di-mgt.com.au/properpassword.html#vbnet2vb6
As for the padding, indeed it can be PKCS5 (this is referring more to padding scheme per se, ignore the PDKDF above) or PKCS7 based which are two common ones used. For info, The difference between these padding mechanisms is the block size
- PKCS5 padding is defined for 8-byte block sizes,
- PKCS7 padding is defined to work for any block size from 1 to 255 bytes.
Hence, fundamentally PKCS5 padding is a subset of PKCS7 padding for 8 byte block sizes. Therefore, PKCS5 padding cannot be used for AES. PKCS5 padding was only defined with 3DES in mind instead. ome cryptographic libraries such as the SUN provider in Java indicate PKCS#5 where PKCS#7 should be used - "PKSC5Padding" should have been "PKCS7Padding".
Ref - PKCS #5: Password-Based Cryptography Specification V2.0
https://www.ietf.org/rfc/rfc2898.txt
have to opt for pkcs7 then. I supposed you see the below to state it as default instead in crypto-js
http://stackoverflow.com/questions/15547584/crypto-js-cant-decrypt-what-it-encrypted
In fact, that is documented in official Google Crypto-js - so probably there is some setting or the package version used. But I am not savvy into this programming space though, so pardon me.
https://code.google.com/p/crypto-js/#Block_Modes_and_Padding
http://stackoverflow.com/questions/15547584/crypto-js-cant-decrypt-what-it-encrypted
In fact, that is documented in official Google Crypto-js - so probably there is some setting or the package version used. But I am not savvy into this programming space though, so pardon me.
https://code.google.com/p/crypto-js/#Block_Modes_and_Padding
Premium Content
You need an Expert Office subscription to comment.Start Free Trial