0

[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.

Community
  • 1
Anon2000
  • 341
  • 1
  • 9
  • 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. – SEJPM May 24 '15 at 16:48
  • @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. – Anon2000 May 24 '15 at 16:53
  • 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. – SEJPM May 24 '15 at 16:59
  • @SOJPM That's OK, no problem, for some reason I though this would work - not because I was ignorant - but because I thought this (turned out to be flawed) technique could evolve to something more interesting if it was given a chance. Well, $C_k = P_k \oplus E(P_{k-1} \oplus Random())$ might work, for example (assume the IV is encrypted and the seed is secret), for example. That's an interesting, constructive observation. The question is would a crypto-RNG be needed? – Anon2000 May 24 '15 at 17:17
  • 2
    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. – J.D. May 24 '15 at 18:20
  • @MaartenBodewes I'm not a mathematician or a computer scientist. I don't really have the ability to look at this from a theoretical perspective. The input I get from the experts so far has been extremely useful. If I open multiple questions - (as in the case of the non-malleable encryption, that would be literally more than 10 questions with similar titles spamming the search results), and I might get banned. I can change the title though to something like "question" [Updated to version 2] though. I think you guys are being too harsh for me literally trying to be polite here! – Anon2000 May 24 '15 at 18:49
  • @MaartenBodewes Anyway if you think the new scheme is flawed, then just explain why. So far you and J.D. are mostly criticizing the way I ask questions, but not the ideas themselves - you're concentrating on minor things. – Anon2000 May 24 '15 at 18:52
  • 1
    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. – J.D. May 24 '15 at 19:23
  • @MaartenBodewes I opened a different question for the new version. – Anon2000 May 24 '15 at 19:25
  • @J.D. That's actually proven to be an awesome, natural, highly motivating way to learn! Sure some people here are a bit negative, but most of the response have been highly positive! Your answer was very comprehensive and useful, and I was aware of flaws like this on other schemes I tried to design (for fun! this is not my job! I'm just a programmer). My mind was a little incoherent when I asked this, I should have figured it out myself. I do think, though, these questions, however silly they might look to you, would prove useful to some people who are interested in crypto to some degree.. – Anon2000 May 24 '15 at 19:29
  • @Anon2000 I have removed the [flawed] tag from the title of this question (and of your other questions). There is no need to put the status of the question in its title, since it's already at the top of the question body, and the square bracket suffix notation is already used on the stackexchange network to signal duplicates/closed questions, so it's a bit confusing. – Thomas May 25 '15 at 13:14

2 Answers2

2

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.

cpast
  • 3,587
  • 1
  • 15
  • 27
  • 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. – Anon2000 May 24 '15 at 18:02
1

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.

J.D.
  • 4,445
  • 16
  • 21
  • 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. – Anon2000 May 24 '15 at 18:04