ok, well... first: it's a "just for fun" question. I don't have a project dealing with this... I've simply a bit time and would like to talk a bit about some (maybe stupid) possibilities and try to learn something...

I always thought (before I was looking at the algorithm) that algorithms like cbc provide security against modifications of the encrypted data (so the idea was -> if you can decrypt the last block, everything must be fine) ... obiousely that's not the case. And here are my questions:

a) why? ... why wasn't it designed like this? Today we need MAC's to confim the integrity. So, we need 2 different algorithms to achieve this goal... wouldn't it be easier if one algorithm would do all of it?

b) ... could CBC be modified in a way so that it would support it? In this case my "security Tag" could be ... well... don't know... maybe sending the first block again? If it matches, everything was fine? Or does it have a huge flaw I don't see right now? ... or, is it simply not practical because of the computational power it needs or... lack of parallelization... things like that...

(I modified the pictures from Wikipedia to show the first idea that crossed my mind)

$\begingroup$Heh, my Swiss family is called Meier too, bug I guess it's a common name.$\endgroup$
– Maarten Bodewes♦Feb 5 '17 at 13:04

$\begingroup$it is... you can find 13983 when you search for phone numbers ... the most common in our region is Müller and they can be found 21427 times (according to a study made in 2015)$\endgroup$
– user43687Feb 5 '17 at 13:28

$\begingroup$About the question; we can explain why a specific scheme is insecure, but creating a secure scheme isn't a guess / answer game. In the end you'll have to read up on MAC algorithms to understand why schemes are secure or not (study OCB, GMAC, HMAC, CBC-MAC etc.)$\endgroup$
– Maarten Bodewes♦Feb 5 '17 at 13:40

$\begingroup$Did you read the first paragraph I wrote? ... I said "and try to learn something" ... I'm not trying to invent a new algorithm. What I learned so far: it's important/good to make sure that the plaintext going into the encryption is as random as possible in order to make sure you cannot analyze the distribution in the output.$\endgroup$
– user43687Feb 5 '17 at 13:52

$\begingroup$Yes, I read that, but this is a Q/A site, we're not a class, textbook or course on cryptography.$\endgroup$
– Maarten Bodewes♦Feb 5 '17 at 13:54

1 Answer
1

why? ... why wasn't it designed like this? Today we need MAC's to confim the integrity. So, we need 2 different algorithms to achieve this goal... wouldn't it be easier if one algorithm would do all of it?

Yes, but the fact that a MAC is almost always required is simply an idea that surfaced later. MAC constructions themselves surfaced later than ciphers. Before them there was a focus on error propagation and cribs (checksum values also encrypted).

... could CBC be modified in a way so that it would support it? In this case my "security Tag" could be ... well... don't know... maybe sending the first block again? If it matches, everything was fine? Or does it have a huge flaw I don't see right now? ... or, is it simply not practical because of the computational power it needs or... lack of parallelization... things like that...

There are single pass algorithms such as OCB, but it is patented. GCM is another one which has a relatively cheap operation over all the blocks, so it is often called a 1,5 pass algorithm.

As you don't describe your algorithm well we cannot analyze it. Your altered CBC scheme obviously doesn't work. The way you XOR you can easily get repeat ciphertext for instance, leaking information about the plaintext. For instance, just encrypt all zero plaintext. A mode of encryption must be secure without any restrictions on the plaintext.

A MAC should be over all the data you need to protect (encrypted or not). I don't see that in your scheme (then again, I don't see any tag displayed in your scheme).

$\begingroup$the explanation that MACs were only used after the design was finished seems to be a good explanation for me... and for the leakage of plaintext: then... xor the input of the encryption additionally with the cyphertext like in normal cbc ... or use some very cheap hashing?$\endgroup$
– user43687Feb 5 '17 at 13:18

1

$\begingroup$I think you are trying different constructs by kind of guessing that they may be secure. This won't result in any secure scheme. You'd have to show - well, actually, prove - why they are secure. There is no such thing as a "cheap hash" - creating a fast, secure hash is a big challenge. There are MAC constructions though that are more efficient (such as GMAC in the GCM mode of operation already mentioned).$\endgroup$
– Maarten Bodewes♦Feb 5 '17 at 13:35

$\begingroup$a "cheap hash" for me is a hash that doens't need a lot of computational power... e.g. murmur ... it doesn't have to be "safe" ... maybe... as I told you: "learning" ... or... tell me, is this not allowed here? asking questions to learn something? ... if not, I will delete the question immediatelly...$\endgroup$
– user43687Feb 5 '17 at 13:54

$\begingroup$You'd be inventing cribs all over again, as murmur is not a cryptographically secure hash. It's right in the first sentence on Wikipedia.$\endgroup$
– Maarten Bodewes♦Feb 5 '17 at 13:55

1

$\begingroup$You're reinventing existing technologies that have been deprecated by the current cryptographic community. You don't know this because you lack the theoretical background. Pretty please with sugar on top, pick up a book. Last comment.$\endgroup$
– Maarten Bodewes♦Feb 5 '17 at 15:50