0
$\begingroup$

Provided that:

  • $AES(plaintext, key)$ is the standard AES block cipher for a 128 bits block.
  • $\oplus$ is the standard XOR operation.
  • $K$ is a constant 128 bits pseudorandom value, which is used as the key for AES operations, unknown to the attacker.
  • $A$ is another constant 128 bits pseudorandom value, unknown to the attacker.
  • $B$ is a variable 128bits pseudorandom value, unknown to the attacker.
  • $C$ is a 128bits value which is known and can be chosen freely by the attacker.

An attacker can:

  • Obtain the value of $AES(A, K)$ (which is constant).
  • Obtain the value of $AES(B, K)$, for as many different $B$'s as he wants (note that the attacker cannot choose the value of $B$).
  • Test if $C = AES(A \oplus B, K)$; he can also obtain the value of $AES(B, K)$ being these 2 $B$'s the same value.

Can the attacker take advantage of this knowledge? For instance, could he guess a value for $C$ that is equal to $AES(A \oplus B, K)$, or recover $K$, $A$ or $B$?

$\endgroup$
2
$\begingroup$

I'm guessing from your description that you are describing a mode of operation where $A$ is the message and $B$ is an IV/nonce for a specific block. However you seem to have made an exception where the attacker can know the ciphertext both with and without the $B$ involved. As such, you have a rather weird use of the cipher. To generalize to an arbitrary block cipher:

  • $ENC(A, K)$ reveals the ECB mode ciphertext
  • $ENC(B, K)$ reveals the uniqueness of $B$
  • $ENC(A \oplus B, K)$ reveals the ciphertext using a proper mode of operation.

As such, you essentially have an overcomplicated ECB mode with random inputs. The value $B$ becomes irrelevant to an attacker knowing $ENC(A, K)$. If an attacker needs to find $B$, however they can use the same ECB breaking since they also know $ENC(B, K)$.

This system is strengthened by the fact that $A$ and $B$ are both pseudo-randomly generated (hopefully in a secure manner), and as such normal attempts to break ECB would be useless. Your system also is indistinguishable from random for any number of encrypted blocks, since your input is actually random.

With your system it is impossible, assuming you use a secure encryption algorithm (AES is generally accepted to be secure) to obtain any useful information about the inputs faster than brute-force, even with ECB mode; except in the case of repeating inputs, at which point statistical analysis becomes possible. But for random inputs no statistical analysis is possible.

The only issue I see with this model is the sketchiness of your system - why would your system ever need to reveal $ENC(A, K)$, $ENC(B, K)$ and $ENC(A \oplus B, K)$? I'll leave that for you to decide.

I'm thinking you mean a kind of OTP where $A$ and $K$ make a private key used to generate authentication codes verified by a server also knowing $A$ and $K$... It doesn't really matter, I'm just trying to see if I can guess your intentions.

| improve this answer | |
$\endgroup$
  • $\begingroup$ You got your guessings partially right. This is the behaviour of a system that I'm currently testing and your thoughts mostly match with my previous intuition about this, but I am no expert on crypto. For clarification, A and K are two secrets shared by both parties (for authentication), B is used as an OTP destined to "protect" the current message exchange session between both parties. Indeed is sketchy, but I guess it has no security problems as long as the pseudorandom algorithm is secure. Thank you for your insightful answer. $\endgroup$ – n1ce Sep 24 at 18:47
  • $\begingroup$ Since this is an authentication scheme, I might suggest using a hashing algorithm instead is an encryption algorithm? For your case behave the same way since there's no need to decrypt. Also I might suggest encrypting multiple blocks (using unique $B$ for each block) to increase the security. A 128 block only provides you with 64 bits of security, so expanding $A$ and $B$ to 512 bits could help security significantly (providing a full 256 bits of security in the authentication). You might consider expanding $K$ to 256 bits, as well. $\endgroup$ – Serpent27 Sep 24 at 19:58
  • $\begingroup$ Those are very valid points, as more than 64 bits of security would be advisable. $\endgroup$ – n1ce Sep 24 at 21:48
  • $\begingroup$ A hashing algorithm also eliminates the need for $K$ as long as $A$ is large enough to provide sufficient security. $\endgroup$ – Serpent27 Sep 24 at 22:18

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.