OK I finally figured this out myself after much trial and error. (All of the above has been written assuming a Unix-like system, e.g. with od), and remove the padding bytes yourself (again, with dd). If padding seems to be an issue, try adding the -nopad option to the openssl enc command then you will have to inspect the obtained binary data (e.g. Thus, when OpenSSL will decrypt the data, it might find a padding which is not exactly what it would expect (it depends on whether OpenSSL insists or not on all padding bytes having value n, and on what padding byte values were used by whoever produced the encrypted data in the first place). SOAP, on the other hand, mandates something similar, except that they only require that the last added byte has value n the n-1 other bytes can have any value. the total padded length is a multiple of 16.n is between 1 and 16 (at least one, at most sixteen added bytes).OpenSSL, apparently, uses PKCS#7 padding, which means n bytes are appended to the data upon encryption, so that: The last remaining thorny issue is the padding. Openssl enc -aes-256-cbc -iv $ivhex -kfile c -nosalt -in edata.bin -out cdata.bin Ivhex=$(od -t x1 -w iv.bin | sed 's/^*//' | sed 's/ //g')ĭd if=messagebody.in of=edata.bin bs=16 skip=1Īpply decryption with explicit IV, and instructing OpenSSL not to play its own non-standard games with salts: This means that the following should work (I have not tried):ĭd if=messagebody.bin of=iv.bin bs=16 count=1Ĭonvert the IV to hexadecimal (real hexadecimal this time, not Base64): According to the specification, encryption with AES-256-CBC in SOAP simply adds the IV as the first 16 bytes, and there is no header and no salt. OpenSSL adds a specific header (that's the "magic number" it is complaining about) and some randomness (a "salt" - salts make a lot of sense when keys are passwords, but that's not the case here). When doing symmetric encryption, openssl enc, the command-line tool, uses its own non-standard, OpenSSL-specific format which does not match what SOAP uses. Not a critical point here, but if you get the terminology right then it becomes easier to search for solutions on the Web.) Openssl enc -aes-256-cbc -d -in messagebody.bin -out c -kfile cīut I get "bad magic number" on this last step when I try this. Openssl enc -in messagebody.hex -out messagebody.bin -d -aĭecrypt Message Body using openssl and session key: Openssl rsautl -decrypt -in sessionkey.bin -out c -inkey myprivatekey.keyįormat Encrypted Message Body to 64 chars max per line (hex format):Ĭonvert Message Body key to binary format for openssl:
Openssl enc -in sessionkey.hex -out sessionkey.bin -d -aĭecrypt session key using openssl and privatekey: My question is how do I decode this manually?Ĭonvert session key to binary format for openssl (as rsautl command only works with binary): So the body has been encoded in aes-256-cbc and then the session key that did this encoding has been encoded with my public key. So I have a SOAP message like this (key data and encrypted data has been truncated):
0 kommentar(er)
