Hi, On Mon, Apr 20, 2020 at 05:03:00PM +0200, Matthias Andree wrote: > Am 20.04.20 um 15:51 schrieb Kevin J. McCarthy:
> > My time is a bit limited to continue on this right now. But later, I > > would appreciate others opinions about randomizing versus hashing > > Other than that, whatever makes prediction hard should fix the immediate > scenario. A strong hash or randomly generated UUID does not really 100% > prevent my attack scenario, but if we were using, say, RIPEMD160, SHA256 > or other, then I think we're safe for now. In our application we consider a hash algorithm to hide the source data, which is using system information to enable multiple Mutt instances providing different values to avoid collisions. Another typical application of hashes is to create signatures preventing manipulated documents (= sources) having the same signature. This is not an issue here, because - as already mentioned - it is easy to copy a message id due to the nature of SMTP. Performance calculations The strength of the hash is much less important than the amount of source data which is to be tried in a brute-force manner in this case. Currently we have 16-32 bits of process id + 5 bits of letters A-Z. I quickly found reports with SHA-256 performance of 300000 hashes/s. Let's say that a hash should not be broken in 1 year as average and assume that professional attackers manage 2000000 hashes/s (safe considerations would assume even more). This gives 1.26e14 hashes for probing the full range in 2 years equivalent to 47 bits. So to the 37 bits (often only 21) we need to add 10 or better way more bits af salting, otherwise it can be broken within short time. There are more options as repeated hash to increase costs for attackers. So for us it is important to find and add enough salt. Strength of the algorithm makes it harder to find collisions, but we don't care here as long as probablity of 2 Mutt instances generating the same outputs within the same second is neglectible - this should apply even for md5. Luckily an attacker can get minor personal information in the best case, but not of use for breaking a system. So one can assume that those are not spending many resources - there are better targets. > WRT UUID/GUID or fully random mentioned elsewhere, the birthday > "paradoxon" or attack needs to be taken into account, and I am not > sufficiently into cryptography to assess whether hashing will suffice to > steer clear of such attack vectors (but then again, my proposal doesn't > do that any better out of itself), and the addition of a domain or > hostname doesn't raise security because it's trivial to forge in a > malicious attack. The birthday paradoxon could help to find colliding documents (which means creating fakes), but this is not our scenario. Kind regards, Gero
