0
$\begingroup$

This is the PSKC standard

https://tools.ietf.org/rfc/rfc6030.txt

In Section 6.1

  6.1.  Encryption Based on Pre-Shared Keys

They have the following

Plain Text = 3132333435363738393031323334353637383930
Algo = aes-128-cbc 
pkcs#5 padding
Encryption Key = 12345678901234567890123456789012
IV = 000102030405060708090a0b0c0d0e0f
Encrypted text = ESIzRFVmd4iZABEiM0RVZgKn6WjLaTC1sbeBMSvIhRejN9vJa2BOlSaMrR7I5wSX

How do they get this? I tried using openssl command line

echo 3132333435363738393031323334353637383930 | openssl enc -aes-128-cbc  -nosalt -iv 000102030405060708090a0b0c0d0e0f -a -pass pass:12345678901234567890123456789012 

I get the following

HgFUJvBN9ztHcsIXNjvoTJJfOsoIq7XlOpdYCn+nk2TxQFrOJGhN+dYOHpFuIBQn

Likewise for the hmac-sha1

key = 1122334455667788990011223344556677889900
hmac-sha1 = Su+NvtQfmvfJzF6bmQiJqoLRExc=

I do it with openssl command line

echo  3132333435363738393031323334353637383930 | openssl sha1 -hmac 1122334455667788990011223344556677889900 | openssl enc -base64

(stdin)= eb6093578fdb69477f9a3322dcda28ce28b8aa1e

echo eb6093578fdb69477f9a3322dcda28ce28b8aa1e  | openssl enc -a -e 

I get

ZWI2MDkzNTc4ZmRiNjk0NzdmOWEzMzIyZGNkYTI4Y2UyOGI4YWExZSAgDQo=

What am I doing wrong?

$\endgroup$
1
$\begingroup$

0: you have the wrong CipherValue. The one you show is in MACMethod/MACKey and is the encryption of the MAC key, see 6.1.1. The encryption of the subject key is in Key/Data/Secret/EncryptedValue and is AAECAwQFBgcICQoLDA0OD+cIHItlB3Wra1DUpxVvOx2lef1VmNPCMl8jwZqIUqGv.

1: openssl enc in most cases, including the one you used, does password-based encryption. This does not encrypt or decrypt with the "key" you specify, instead it considers that a password and runs it through a "stretching" or "derivation" function to produce the actual key. See https://stackoverflow.com/questions/22085107/perl-cbc-des-equivalent-in-java and https://stackoverflow.com/questions/11783062/how-to-decrypt-an-encrypted-file-in-java-with-openssl-with-aes . For "direct" encryption and decryption you must use -K (uppercase) with the key in hex.

2: the example data in the RFC is in hex, although it doesn't say so. For the key and IV this is okay because enc -K -iv take hex, but the data must be binary. Hex 313233...30 is ASCII 12345678901234567890 but with no terminating newline which echo automatically adds; preventing this varies depending on your system and/or shell, which you don't specify, so I use perl instead.

3: XMLenc data for block/CBC contains the (actual binary) IV concatenated with the ciphertext, with the combined result encoded in base64.

Thus (with binmode because I tested partly on Windows): echo $k 12345678901234567890123456789012 echo $i 000102030405060708090a0b0c0d0e0f echo $i |\ perl -ne "open O,'>temp';binmode O;print O map{pack('H2',$_)} ($_=~/(..)/g)" # that puts the binary IV at the beginning of temp perl -e "print '12345678901234567890'" |\ openssl enc -aes-128-cbc -K $k -iv $i >>temp # that APPENDS the encryption of the data to temp openssl base64 <temp AAECAwQFBgcICQoLDA0OD+cIHItlB3Wra1DUpxVvOx2lef1VmNPCMl8jwZqIUqGv

4: MAC is computed on the encrypted value; also dgst -hmac takes the key as actual bytes (not hex) in a C string, but the MAC key in this example contains a null byte which is impossible in a C string. If you really want, you can do the HMAC as two hashes with tweaks of the key: echo $h |\ perl -ne "open O,'>pad1';binmode O;$_=~s/[[:space:]]//g;\ $_.='0'x(128-length($_));print O map{pack 'C',hex($_)^0x36}($_=~/(..)/g)" echo $h |\ perl -ne "open O,'>pad2';binmode O;$_=~s/[[:space:]]//g;\ $_.='0'x(128-length($_));print O map{pack 'C',hex($_)^0x5C}($_=~/(..)/g)" cat pad1 temp |openssl sha1 -binary -out tmp1 cat pad2 tmp1 |openssl sha1 -binary -out tmp2 openssl base64 <out2 Su+NvtQfmvfJzF6bmQiJqoLRExc=

And there you are.

| improve this answer | |
$\endgroup$
  • $\begingroup$ Just FYI - I could also avoid the binmode/perl stuff by using the following for %i in (000102030405060708090a0b0c0d0e0f) do (echo/|set /p="%i") | xxd -p -r temp I have xxd from my vim install on windows $\endgroup$ – user93353 Dec 29 '14 at 10:22
  • $\begingroup$ that's actually xxd -p -r > temp $\endgroup$ – user93353 Dec 29 '14 at 10:29
  • $\begingroup$ I have another similar question (actually the opposite) - crypto.stackexchange.com/questions/21084/… - please take a look if you get the time. $\endgroup$ – user93353 Dec 30 '14 at 7:21
  • $\begingroup$ For a hex value you shouldn't need to drop the newline (or other whitespace) xxd -r should discard it anyway. For the value(s) where newline matters, set /p is indeed a clever way to omit newline in Windows, but you don't need the for just echo/ | set /p="12345678" >file; you do need the quotes! I commented on #21084. $\endgroup$ – dave_thompson_085 Dec 30 '14 at 9:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.