0
$\begingroup$

I have a chat server which uses public keys to identify their clients. But if the public key is known, then everyone can send a direct message (DM) to each other, which is annoying. The clients should choose who should DM them.

So I decided to get two hashes of the public key, one for user authentication and one for identifying the public key used to encrypt the direct messaging.

My question is: does having two hashes affect the probability of successfully guessing the original data?

Improve this question
$\endgroup$
13
  • 2
    $\begingroup$ You don't need to use different hash algorithms. You can use the same hash, as long as include an identifier in the hash input. BLAKE2 supports native "personalization values". Anyway, by Falcon1024, are you talking about the lattice signature? Also, there are probably better ways to solve your issue than with cryptography... $\endgroup$
    – forest ♦
    Aug 27, 2019 at 9:45
  • $\begingroup$ Also, if no one has access to the public key, then what's the point? If only the server knows the public key, then the server is in the position to perform a MITM attack, which is not good. But no, a hash of a public key does not reveal anything about that public key. A public key can only be broken if you have access to it and sufficient processing power to derive the private key (which is generally thought to be impossible for realistic key sizes). $\endgroup$
    – forest ♦
    Aug 27, 2019 at 9:47
  • $\begingroup$ @forest Okay, the thought of using the same hash algorithm with a salt never crossed my mind. I'll do that. Also, I'm using cryptography because I don't want to store anything other than the public and private key in the client side (and the config). I guess I'll make the client calculate the hash, and send the hash to the server. That way, only the client knows the public key. I'll figure the MITM attack part later, as this is just a pet project for me and my friends to communicate. You know, because normal high school students communicate in post quantum. $\endgroup$
    – Krey Lazory
    Aug 27, 2019 at 10:11
  • 2
    $\begingroup$ Finding public keys is not necessarily difficult and relying on public keys to be secret is a very dangerous position. Some signature schemes (e.g. bitcoin) allow you to extract the public key from signatures, for instance; making it impossible to find the public key is not a pre-requisite for any crypto-system. So although the given problem is not much of an issue (and actually is a solution searching for a problem to solve) I think the general direction you are moving to is dangerous. Your solution should probably involve signatures and white-lists of public keys of senders. $\endgroup$
    – Maarten Bodewes ♦
    Aug 27, 2019 at 15:58
  • 1
    $\begingroup$ And, in case you are thinking I'm exaggerating: here is the public key calculation for RSA keys given a signature. $\endgroup$
    – Maarten Bodewes ♦
    Aug 27, 2019 at 16:14

1 Answer 1

Reset to default
0
$\begingroup$

IMO it depends on what you mean by the probability of successfully guessing the original data. Since hashing functions turn input of any size to a fixed-size output, there are (infinitely) many collisions. That may pose a problem with passwords, where any collision results in successful authentication. However, you only care about the correct preimage, as any other input, that produces the same output, (most likely) does not reveal Bob's valid public keys.

Suppose there is an attacker who knows your public keys format and is able to brute-force all possible keys. Then it is likely that more than one candidate will appear (depending on the length of your hash and public keys). The attacker then gets more information from the second hash as to distinguish which candidate is the correct one.

In that sense, you increase the probability of guessing the original data by providing a second hash.

But. I don't think that scenario is much to worry about - as you need the collisions of the first function to feed into the second function to gain advantage (or vice versa) and these are hard to get if the hashing function is well-chosen. Moreover, given that the number of such candidates might not be too high, the attacker might just as well try to DM using candidate keys rightaway.

If you worry about someone finding correct preimage of a given hash (or two), use properly-sized and random salt, different for each user. Ultimate booster: use different salts for each hash.

Improve this answer
$\endgroup$
4
  • 1
    $\begingroup$ "That may pose a problem with passwords" ... why? For any cryptographic hash it should be impossible to find a collision by a targeted search, and just iterating passwords is will only find one with the same hash with negligible probability. "Then it is likely that more than one candidate will appear", no, not really, not in any time that is computationally feasible. "In that sense, you increase the probability of guessing the original data by providing a second hash." Using salts is OK, but really not necessary to solve this non-issue. $\endgroup$
    – Maarten Bodewes ♦
    Aug 27, 2019 at 16:05
  • 1
    $\begingroup$ In other words: The direct use of cryptographic hashes over passwords are rainbow tables and such. The use of a cryptographic hash is not wrong because collisions may occur: with the correct hash that should not be an issue at all. $\endgroup$
    – Maarten Bodewes ♦
    Aug 27, 2019 at 16:08
  • $\begingroup$ @MaartenBodewes I meant it generally - for passwords, where you need any collistion, it is more of a problem than in case when you're looking for the original input (and that input only). I agree that the computational complexity of finding one is prohibitive, but that was not the question (plus see "Suppose there is an attacker who ... is able to brute-force all possible keys"). Theoretically, providing a second hash of the same data gives you extra information that you can use to pick the right preimage. Whether it's feasible is another question entirely, which I also covered. $\endgroup$
    – zajic
    Aug 28, 2019 at 8:01
  • $\begingroup$ The fact remains that for any cryptographically secure hash: if you find a password that matches then you can be sure that is was the one that created the hash. If that's not the case then you've found a collision, which of course means that the hash is not secure, as you should not be able to find one. $\endgroup$
    – Maarten Bodewes ♦
    Aug 28, 2019 at 8:12

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