0
$\begingroup$

[This approach is flawed. A different speculative approach using an RNG instead of the cipher as a source of entropy was posted as a separate question]

Assume $E$ is a block cipher, $C_0 = IV$ and $P_0 = 0$

Encryption:

  1. Add an additional block to the message and store the key in it, ie. $P_n = Key$.
  2. Encrypt all non-final plaintext blocks $P_k, 0 < k < n$ in the following way:
    $C_k = P_k \oplus E(C_{k-1} \oplus P_{k-1})$
  3. Encrypt the final plaintext block $P_n$ (containing the key) in the following way:
    $C_n = E(P_n \oplus E(C_{n-1} \oplus P_{n-1}))$

Decryption:

  1. Decrypt all non-final ciphertext blocks:
    $P_k = C_k \oplus E(C_{k-1} \oplus P_{k-1})$
  2. Decrypt the final ciphertext block:
    $P_n = D(C_k) \oplus E(C_{n-1} \oplus P_{n-1})$

Authentication

  1. Verify $P_n = Key$

Note the number of encryption operations is actually $n+1$, so the title is slightly inaccurate (mentioning that would have made it too long). Also, it may not be completely essential to store the key - A non-secret value might work, but I'm being cautious for now..

Please try be constructive, as even if this is flawed in its current state it might be possible to fix it without adding a significant amount of expensive operations.

Improve this question
$\endgroup$
11
  • $\begingroup$ and one more time Schneier's law holds: Anyone, from the most clueless amateur to the best cryptographer, can create an algorithm that he himself can't break. And the result is always the same: Don't roll your own crypto. Chances are you're getting it wrong. $\endgroup$
    – SEJPM
    May 24, 2015 at 16:48
  • $\begingroup$ @SOJPM Please try be constructive, as even if this is flawed in its current state it might be possible to fix it without adding a significant amount of expensive operations. I would also appreciate your constructive criticism on the non-malleability question. $\endgroup$
    – Anon2000
    May 24, 2015 at 16:53
  • $\begingroup$ It was so tempting I just had to do it as within minutes two flaws have been found ;) Besides what is wrong with GCM(1.5 pass) / OCB(1pass, patented) / CAESAR(on-going)? I bet CAESAR will produce nice results. And your scheme kina reminds me of CBC-MAC which is known to be weak (length extension) and hated. $\endgroup$
    – SEJPM
    May 24, 2015 at 16:59
  • 2
    $\begingroup$ Just fyi, the preferred method of proposing authenticated encryption modes these days is to prove it is secure, rather than asking people to prove it is insecure and then 'fixing' it when they do. Trying to design a mode that you can prove attains the goal of authenticated encryption is challenging (especially if you are trying to minimize the number of expensive operations), but it can be quite rewarding and educational as well. $\endgroup$
    – J.D.
    May 24, 2015 at 18:20
  • 1
    $\begingroup$ My comment was not meant as criticism -- I am just suggesting that you try to design a provably secure mode (start by reading the proofs for more established modes). It's really the best way to learn what makes modes secure and why; even if you are not a mathematician and just want to understand and appreciate modes like OCB or GCM. Making unproven proposals and waiting until others point out the flaws is not going to deepen your understanding very much I'm afraid. $\endgroup$
    – J.D.
    May 24, 2015 at 19:23

2 Answers 2

Reset to default
2
$\begingroup$

This does not meaningfully authenticate the ciphertext. Your encryption is the same as OFB, meaning no block depends on the previous plaintext; for instance, $$C_2=P_2\oplus E(P_1\oplus (P_1\oplus E(IV\oplus 0)))=P_2\oplus E(E(IV)).$$ That means confidentiality should be fine; however, it provides no authentication except of the length of the message.

Improve this answer
$\endgroup$
1
  • $\begingroup$ Thanks for answering! I added another version to the algorithm that uses a random number generator instead of the ciphertext as a source of entropy. It might be flawed as well of course. You can answer (if you want) by editing and splitting your answer with a horizontal line to separate the two answers, just like I did with my question. $\endgroup$
    – Anon2000
    May 24, 2015 at 18:02
1
$\begingroup$

Consider what would happen if an attacker altered one of the ciphertext blocks, but kept the IV and all previous ciphertext blocks identical. i.e. Xor some difference $\Delta$ to ciphertext block $C_x$, so that the altered block $C''_x = C_x \oplus \Delta$. This will produce an altered corresponding Plaintext block, like so: $$P''_x = C''_x \oplus E(C_{x-1} \oplus P_{x-1})\\ P''_x = C_x \oplus \Delta \oplus E(C_{x-1} \oplus P_{x-1})\\ P''_x \oplus \Delta = C_x \oplus E(C_{x-1} \oplus P_{x-1})\\ P''_x \oplus \Delta = P_x\\ P''_x = P_x \oplus \Delta$$ And now consider what happens to the next block when it is decrypted (assuming without loss of generality that it and all subsequent blocks remain unchanged): $$P_{x+1} = C_{x+1} \oplus E(C''_x \oplus P''_x)\\ P_{x+1} = C_{x+1} \oplus E((C_x \oplus \Delta) \oplus (P_x \oplus \Delta))\\ P_{x+1} = C_{x+1} \oplus E(C_x \oplus P_x)$$ So in other words the next block (and hence all subsequent blocks, including the verification block $P_n$) remains unaltered despite the (arbitrary) difference $\Delta$ being xored into the message at block $P_x$. The attacker can alter the plaintext at will, and still produce a 'valid' message.

Improve this answer
$\endgroup$
1
  • $\begingroup$ Thanks for answering! I added another version to the algorithm that uses a random number generator instead of the ciphertext as a source of entropy. It might be flawed as well of course. You can answer (if you want) by editing and splitting your answer with a horizontal line to separate the two answers, just like I did with my question. $\endgroup$
    – Anon2000
    May 24, 2015 at 18:04

Your Answer

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

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