1

I'm sorry if I'm going horribly wrong - I am new to this stuff.
My question is：

  1. KDFC1,KDFC2,KDFC3 is defined by myself.
  2. Key1 is come from outside .

Is it possible to use the aes-ecb-256 decryption algorithm to generate an aes key?
If I'm going horribly wrong , Is there any relevant information that can be provided for me to learn. enter image description here

I try to use OpenSSL to simulate this process , but i got the error output.

lqb ➤ openssl enc -aes-256-ecb -d -nosalt -pass pass:ba8981fecfb3d3ce44d5e5fdefacb0c4f56981fecfb3d3ce44d5e5fdefacb03 -in key1                                                                                                                                          
*** WARNING : deprecated key derivation used.
Using -iter or -pbkdf2 would be better.

bad decrypt
140116363019584:error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt:../crypto/evp/evp_enc.c:610:
]XE9Sʻ^V)_X:uxY[n
                 +iZ%
qibinLi
  • 11
  • 1
  • I would avoid ECB for anything other than implementing AES-CTR. It immediately raises eyebrows because it should virtually never be used. You'd be better off with a KDF like HKDF or BLAKE2/BLAKE3 than AES. – samuel-lucas6 Aug 24 '22 at 07:45
  • 1
    Why do you want to run it in the decryption direction? – forest Aug 24 '22 at 22:09
  • @forest I am new to this stuff, I confuse also, as to why it's decryption, but the designed document I got was decryption. – qibinLi Aug 31 '22 at 01:37
  • @qibinLi Then your design document was written by someone who doesn't know much about cryptography. – forest Aug 31 '22 at 01:52
  • @forest I think so , this question blocks for a long time ，Thanks forest. – qibinLi Aug 31 '22 at 01:59

1 Answers1

2

I strongly suggest you do not try to roll your own system. Even if you are using standard and secure primitives, the design of a cryptosystem can be quite involved. You need to choose a threat model and adhere to it. The below is posted purely for informational purposes. I do not recommend you use this technique in production. While it may work in theory, it's not a good design.

Instead, you could use something like BLAKE2 or HKDF, as mentioned in a comment, which will accomplish the same thing more simply. It will furthermore allow you to derive an input of arbitrary size (you won't be limited to the AES block size, which is required for safety in ECB mode).

AES has a 128-bit block size, so although you could use AES with a 256-bit key for each of the three KDF operations, the key passing through the three AES operations itself must be only 128 bits. If you try to encrypt a 256-bit key, then the result will leak whether or not the first half of the key is identical to the second half (this is because ECB is not IND-CPA secure).

Assuming key1 is only 128 bits and at least 128 bits from key1 and the outputs of KDFC1, KDFC2, and KDFC3 are unknown to the attacker, then the resulting key will have 128 bits of security.

Below is a simple example script which shows how this can be done. A few notes about it:

  • The openssl command uses -nopad, otherwise ECB mode will require padding.

  • The key is fed directly to openssl using -K, which is preferred for raw keys.

  • The -d flag is removed, as there is no reason to run AES in the decryption direction here.

key1=96eb4681f1704693925718d8241a425b

kdf1=d17ecb9294631d1a235b392707a390a9ea4184dc30896b9bdeaa9cbc272764e4
kdf2=90da13583ae2e5cb6ef4d6484f5e1236d26a16043c927e31fa8ef02f0d455ad6
kdf3=6de5397c280d8ce09914c8639e20a3b302f75ea811c9e76bd8638333cfabc989


encrypt() {
    echo $(xxd -r -ps <<< $2 | openssl aes-256-ecb -nopad -K $1 | xxd -c32 -ps)
}


key2=$(encrypt $kdf1 $key1)
key3=$(encrypt $kdf2 $key2)
key4=$(encrypt $kdf3 $key3)


echo "result = $key4"
forest
  • 15,253
  • 2
  • 48
  • 103