# Protection (nonce addition?) against key discovery in AES 256

I've got a situation where I need to send message ciphered with AES-256. However the content, and therefore length, of the message may be intercepted before (don't ask;)) and the question I was asked was "isn't a vulnerability allowing to discover the key?". My first approach was to estimate the brute force needed to crack the key and I ended up with number around 2^40 to 2^60 years.

It's a lot and comparing to the situation when the potential attacker doesn't know the content of the message interceptet, it doesn't look any better. However a though of adding some nonce came around and now I think how big it should be to if I'd like to add some.

Say, payload is 40 bit long. Since AES is working with 16 byte long block, would it make sense to add 11 bytes of random unique nonce or is this whole speculation not worth the effort?

• For breaking AES-256 your only problem is not time, you need immense power. How much would it cost in U.S. dollars to brute-force a 256-bit key in a year?. What is origin of this question Mar 17, 2022 at 10:12
• Scenario is basically describe above. We can't exclude the possibility of intercepting initial unencrypted 40-bit message. That message, encrypted later, will be used and the user is worrying that it may be eavesdropped on what could be a potential attack vector for the key cracking. I was trying to explain the effort of such brute force method in time but it seems that financial perspective may be more persuasive, thanks for this tip. Anyway to comfort my user I wanted to add some random payload hence my question about the nonce. Mar 17, 2022 at 12:13

The message may be intercepted before. Isn't it a vulnerability allowing to discover the key?

No, for proper choice of key (see 1 below). AES-256 is designed to resist such Known Plaintext Attack. That's a standard hypothesis, and indeed $$2^{256}$$ is so immensely large that there's no worry to have that the key can be found by searching it (to put things in perspective, the waste of resources known as bitcoin mining so far has performed work equivalent to less than $$2^{100}$$ AES encryption). We're safe even if we hypothesize Cryptographically Relevant Quantum Computers ever become a thing.

The only protections one needs against key discovery in AES-256 are

1. Choosing the key about uniformly randomly. A password won't do, key strechting won't cut it.
2. Not disclosing it; see obligatory XKCD.
3. Prevent it's extraction from any device it's inserted into. This is the hard part: how are you sure your PC is not infected by some trojan? And then there are side channel attacks and fault attacks.

Say, payload is 40 bit long. Since AES is working with 16 byte long block, would it make sense to add 11 bytes of random unique nonce or is this whole speculation not worth the effort?

There's another good reason to insert some randomness along the encrypted message: it's necessary to resist Chosen Plaintext Attack, and in particular prevent adversaries from testing if two plaintexts are identical merely by comparing their ciphertexts.

Also, notice that typical applications requiring confidentiality of the plaintext also require it's integrity, that is authenticated encryption, and straight AES encryption with common encryption-only block-cipher modes of operation won't give that even with random IV/nonce. Further, some applications require prevention against replay, and straight authenticated encryption won't give that.

Choosing a cryptographic algorithm is not something to do lightly. Sorry, but that should not be attempted by one having to ask the present question.

• Thank you for the answer! One who's asking the present question is aware of his ignorance and fortunately is not the only one responsible for the given problem (it would be extremally uncomfortable and unprofessional). Integrity protection was taken for consideration but thanks for mentioning that too. Mar 17, 2022 at 14:40