2
$\begingroup$

I have this scenario:

The same plain text (that is part of an unkown bigger message) is being ecrypted multiple times using AES 128 CTR with a random key, the key is being transfered encrypted using RSA public key. For example:

(www.myBlog.com, some_random_text)

The location and the content of the plain text doesnt change.

Is there a way to break the AES? ( Assuming I know the plaintext)

I have full man in the middle.

Improve this question
$\endgroup$
3
  • 2
    $\begingroup$ Unless there is IV reuse, AES CTR is not vulnerable to known-plaintext attacks. $\endgroup$
    – otus
    Commented May 10, 2016 at 15:33
  • $\begingroup$ I have read "Why is AES resistant to known-plaintext attacks? " This situation is different, because you dont have 1 message with 1 plain text, you have n messages and in all them the same plain text. $\endgroup$
    – tooth
    Commented May 10, 2016 at 16:54
  • $\begingroup$ a) Is the key / IV pair re-used? b) how does the public RSA key move from the server to the client? $\endgroup$
    – SEJPM
    Commented May 10, 2016 at 19:16

1 Answer 1

Reset to default
4
$\begingroup$

This is a type of chosen-plaintext attack, where the adversary gets partial choice of plaintexts — they can cause the same substring to be encrypted multiple times.

AES-CTR, if used properly, is resistant to chosen-plaintext attacks.

Used properly, for CTR mode, means that the same counter value must not be reused for different messages. For example, if one message is 48 bytes (3 blocks) long and is encrypted with the starting counter value 12, this uses up counter values {12, 13, 14}. Other messages must never use those counter values; for example, another 3-block message may use {9, 10, 11}, but not {14, 15, 16}.

CTR encryption calculates $N_i \oplus P_i$ where $N_i$ is the counter value for the $i$th block of the message and $P_i$ is the plaintext. If a counter value is repeated ($N_i = N_j$ with $i \ne j$, whether within the same message or in different messages encrypted with the same key), the xor of the two ciphertexts is $(N_i \oplus P_i) \oplus (N_j \oplus P_j) = P_i \oplus P_j$; if the plaintext for one of the blocks is known or guessed then so is the plaintext for the other block.

Improve this answer
$\endgroup$
5
  • $\begingroup$ The Explanation of the counters is actually not correct - The IV in counter mode is used as a Nonce and gets another counter appended to it, which is then incremented. So, if you use the IV 0 to initialize the counter, there shouldn't be any problems with using the 1 next. $\endgroup$
    – malexmave
    Commented May 11, 2016 at 7:04
  • 1
    $\begingroup$ @malexmave I assure you that my explanation of counter values is correct. I took care to discuss counter values, not IV. I think you assume splitting counter values into a per-message IV part and a per-block subcounter; this is sometimes done, but it isn't standard. Most of the time CTR is used with a random 128-bit value for the initial counter value. Starting with a split like a 64-bit random IV and a 64-bit zero for the initial counter value is risky because it increases the probability that the IV will be repeated if a lot of messages are encrypted with the same key. $\endgroup$
    – Gilles 'SO- stop being evil'
    Commented May 11, 2016 at 7:25
  • $\begingroup$ Fair enough, I didn't notice the ctr value vs. IV thing. I was not aware that the split counter was not standard, especially since several tutorials actually recommended using a counter as IV for AES-CTR to avoid IV reuse, which would be extremely unsafe without split counters... $\endgroup$
    – malexmave
    Commented May 11, 2016 at 7:29
  • $\begingroup$ @malexmave Using a global unsplit counter for AES-CTR is safe, it's even the safest way to do it because it removes any dependency on the RNG, but it isn't always feasible: there has to be a single place where all the entities that use that encryption key can store the shared current counter value, and each encrypter has to finish updating the counter before another message can start being encrypted. A global split counter removes the concurrency problem: increment the global message counter, then increment the block counter at your leasure. $\endgroup$
    – Gilles 'SO- stop being evil'
    Commented May 11, 2016 at 7:34
  • $\begingroup$ It's safe if you increment by the number of encrypted blocks. It's not safe if you always increment by one (which is what the tutorials said), as you would end up with the overlap you describe in your answer. $\endgroup$
    – malexmave
    Commented May 11, 2016 at 7:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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