-2
$\begingroup$

You have a 2048 bit private key, which is 2,048 randomly generated bits. It is not an RSA or ECC key. It is the master key that is used for every message. You receive a message to encrypt and generate an IV for it. Next, you take the first block of plaintext and SHA256(IV + 2048 bit key). You use that hash as a key to encrypt the first block of plaintext using AES-256. Then, you SHA-256(IV + 2048 bit key + previous round key) and use that hash to encrypt the second block. This is done for every block afterwards, always generating each block key with SHA-256(IV + 2048 bit key + previous round key). When finished, you store the ciphertext and the IV.

Would the attacker have to brute force every block one at a time and would it make it more difficult for the attacker to, most importantly, recover the original key itself? You could parallelize and pre-emptively generate the keys because they are based on a hash of the IV, the 2048 bit key, and previous round key. You're only suffering the SHA-256 and AES key setup penalty every round in terms of performance.

Improve this question
$\endgroup$
5
  • 2
    $\begingroup$ Moderator note: this arguably falls under our policy that requests for analyzing cryptographic designs are off-topic, see Do we accept questions asking for cryptanalysis of your cipher design?. It forces sharing the private key, usually a no-no; does not have as strong a security argument as HMAC which allows something similar. $\endgroup$
    – fgrieu ♦
    Nov 9 '20 at 13:57
  • 2
    $\begingroup$ Also the use of a "2048 bit private key" seems like they're thinking of re-using a private RSA key for encryption. That's almost certainly a terrible idea. RSA keys should only be used for a single purpose, eg signing code or signing TLS sessions or for exchanging symmetric keys with systems that don't support ECDH. Never more than one thing at a time. And since SHA256 has 256-bit output, any entropy beyond 256 bits in the input is useless, so this slows things down for no reason. $\endgroup$
    – SAI Peregrinus
    Nov 9 '20 at 14:08
  • 2
    $\begingroup$ Basically you are implementing a ratchet using the private key (or at least the exponent, because an encoded private key certainly isn't 2048 bits) as secret key, then doing single block encryption. The SHA-256 operation can be seen as a poor man's KDF - cryptographers would probably use something like HKDF instead. Of course the word "only" made me chuckle. Hashing some 2560 bits of information for each round + AES key setup for something that can be solved by using a simple mode of operation is a huge amount of overhead. $\endgroup$
    – Maarten Bodewes ♦
    Nov 9 '20 at 15:06
  • $\begingroup$ The 2048 bit key is used for every message and would only be generated once.. It would be randomly generated, it could even be eight 256 bit AES keys concatenated. $\endgroup$
    – Abercrombie Dorfen
    Nov 10 '20 at 3:11
  • $\begingroup$ Randomization is very important in cryptography, but randomly throwing around algorithms in the hope to form a secure scheme or protocol is definitely not. Why would you need 8 keys in the first place? And that's a whole different scheme / idea. $\endgroup$
    – Maarten Bodewes ♦
    Nov 15 '20 at 1:34
-1
$\begingroup$

You'd only need to brute force the first block in order to run through the rest. And brute forcing any block would recover the private key.

It's seems like a waste of a large key, and if it's an asymmetric key then it is definitely a waste of a key.

It'd be better to use a stream cipher (eg ChaCha) and alternate through the 2048 bit key in 256 bit chunks for each block. Then brute forcing a single block wouldn't get near the key. It would probably be quicker too.

But there's really no reason for such a large symmetric key when it achieves so little, or possibly even nothing. Especially when you can do much better things with large asymmetric keys.

Improve this answer
$\endgroup$
4
  • $\begingroup$ The second key is generated by hashing the 2048 bit key with the IV and the first block's key. Recovering the first key won't help because you still do not have the 2048 bit key which is used to generate the second key. I believe you would have to brute force every block one at a time. The third key is a hash of the 2048 bit key, the IV, and the second key, and so on. $\endgroup$
    – Abercrombie Dorfen
    Nov 10 '20 at 3:09
  • 1
    $\begingroup$ @AbercrombieDorfen Brute forcing the first block will get you the hash. An attacker who wishes to obtain the 2048 bit private key will then try to get it by creating the SHA hash. Your proposal doesn't hide the key any more than ChaCha/Salsa. In your other comment you say the 2048 bit key will be used for every message and generated once so there's another big issue. I think with a 2048 bit ECC key you could create four unique 256bit keys for every message. And every user wouldn't need to store 2048 bit secret keys for every user, which if hacked would compromise all previous encryptions. $\endgroup$
    – Modal Nest
    Nov 10 '20 at 11:48
  • $\begingroup$ Let's say they brute forced the first AES key. How will they recover the 2048 bit key by brute forcing the SHA-256 hash? I'm not talking about RSA or ECC encryption keys. I'm talking about 256 randomly generated characters. $\endgroup$
    – Abercrombie Dorfen
    Nov 11 '20 at 2:48
  • $\begingroup$ They brute force the first AES key, which is a hash of the 2048 bit key and the IV. Then they work out what 2048bit key with the IV makes that hash. It's not feasible computationally, but neither is it feasible for a 256bit key. Or to break AES. Hence why I said it'd better to alternate through 256 bit keys, saving the user time and not the attacker (who'd need more time that life allows to brute force 8 blocks and their hash). $\endgroup$
    – Modal Nest
    Nov 11 '20 at 9:06

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.