Return to Answer

In this case we get 5 bytes (40-bit) output, the symmetric key we need. The input was PKCS#1 v1.5 padded (see §8.1) for various reasons, hence the size disparity.

Now here's the slightly tricky bit, for RC2 refer to section 6 of RFC 2268:

In this case we get 5 bytes (40-bit) output, the symmetric key we need. The input was PKCS#1 v1.5 padded (see §8.1) for various reasons, hence the size disparity.

Now here's the slightly tricky bit, for RC2 refer to section 6 of RFC 2268:

Yes you can. This example uses openssl smime with the default RC2 CBC with a 40-bit key. The newer cms sub-command behaves slightly differently, and uses 3-DES by default. You probably shouldn't be using either of those algorithms to encrypt important data ;-)

The en/decryption is along the lines of most RSA-using methods: use (slow, expensive) RSA to en/decrypt a symmetric key, and use the fast symmetric key to en/decrypt the real data. (See this question or this for more background).

In this case we get 5 bytes (40-bit) output, the symmetric key we need. The input was PKCS#1 v1.5 padded (see §8.1) for various reasons, hence the size disparity.

Yes you can. This example uses openssl smime with the default RC2 CBC with a 40-bit key. The newer cms sub-command behaves slightly differently, and uses 3-DES by default. You probably shouldn't be using either of those algorithms to encrypt important data ;-)

The en/decryption is along the lines of most RSA-using methods: use (slow, expensive) RSA to en/decrypt a symmetric key, and use the fast symmetric key to en/decrypt the real data. (See this question or this for more background).

In this case we get 5 bytes (40-bit) output, the symmetric key we need. The input was PKCS#1 v1.5 padded (see §8.1) for various reasons, hence the size disparity.

$ dumpasn1 -a -203 smime.p7m | tail -qn +2 | xxr -r -p > rsa.bin

$ dumpasn1 -a -203 smime.p7m | tail -qn +2 | xxd -r -p > rsa.bin