Does partial known plaintext weaken a hash?

Question

This is a question about an authentication scheme.

Say I have a shared secret string S, and two computers, C1 and C2

• Computer one (C1) sends a random string (R) to computer two (C2)
• C2 hashes (say SHA256) the concatenation of S and R (SR)
• C2 sends the hash of SR to C1, along with some instructions
• C1 compares the received hash of SR with it's own hash of SR and executes the instructions if they match
• Wash, rinse, repeat with different values of R

Now, what I want to know is if someone intercepts a whole bunch of R values, and a whole bunch of SR hashes, can they use that as a "crib" to work out what S is, thus allowing them to forge instructions?

I'm already aware of the potential for a MITM attack here (attacker intercepts response, changes the instructions and forwards it on).

I honestly don't know what I'm dealing with here, I only have a bit of historical knowledge about encryption but that included the use of cribs to break them. I'm not a theorist, so anything you can definitively tell me about specific strong hashes would be great.

Alternate authentication schemes are also welcome, assuming the constraints of an existing shared secret string like in this example. Would I be better off just using S as a key for AES? If I do that, can I still use this in the encrypted message to prevent replay attacks?

Any and all advice welcome, I sort of deviated from my question at the end, so feel free to deviate in your answers!

Answer 1

Answering your question:

No, the only way to break a hash is brute force, as small diferences in the origin mean big differences in the output of the hashing algorithm (given that the algorithm has been proben to be unbroken). You must to know S to perform a MITM here.

But, Byron Withlock is correct:

Using a homemade encryption scheme when there are sooo many better schemes available is crazy. Leave encryption to the experts. – Byron Whitlock 4 mins ago

I'm with Byron. Just use something off-the-shelf and tested by people with a clue. How about SSL? – Steven Sudit 57 secs ago

Answer 2

What you're talking about is called a message authentication code - a MAC. If the secret is sufficiently large (such that it cannot be brute forced in reasonable time) and the MAC is properly implemented, then no, knowing the plaintext doesn't help the attacker.

The key, however, is that it has to be properly implemented. The problem is that crypto is hard. Really hard. Unless you're an expert or have an expert to review your work in context, it's extremely easy to make a mistake. Even worse, it's very easy for people to write crypto that they don't know how to break, but which can be broken quite easily by someone in the know.

The advice you got in the comments is the correct advice: use a proven scheme like SSL or TLS instead of creating your own.

Answer 3

Many cryptographic hash functions are vulnerable to a lengt extension attack. That means if an attacker knows hash(S) but not S, then he may still be able to compute hash(S || M) for some messages M. For example, the attacker might try to get hash(S), by sending the challenge string "" to one of the parties. Your scheme does not have a detailed description. So it is not clear if such a length extension attack is possible. To avoid these kind of attacks you might consider to use for example HMAC instead of the more simple hashing scheme that you propose.

Answer 4

This scheme is weak because the instructions themselves aren't authenticated. You want to send the MAC of R + instructions - and ensure that R is fixed length so that an attacker can't shuffle about between R and instructions.

I take it the purpose of the random value is to ensure the "freshness" of the instructions sent?

You could also look into using gpg, if SSL doesn't meet your needs. That's likely to be a lot better than homegrown crypto.