On 2020-04-20 19:08:07 +0200, Gero Treuner wrote: > On Mon, Apr 20, 2020 at 05:57:00PM +0200, Vincent Lefevre wrote: > > But why not using a cryptographic hash for the full local part, then? > > This could be based on the full message (including the generated > > headers at this point) + some random number. If there is a collision, > > this would mean that the messages are the same, so that I don't think > > this is an issue in practice... Or that cryptographic protocols are > > broken, which would be a much more important issue than Message-Id > > collisions. > > Yes, for space considerations when using hashes it is best to > exclusively use the hash output for the part before "@". > > With hash algorithms the concern is not about collisions. I assume all > established algorithms (even older ones) are acceptable in this > discipline. > > The concern is that the inputs based on local and/or private information > can be leaked. To achieve this the search space must be big enough.
Note that my proposal above is based on *only* information that is sent to the recipient. And if only the Message-Id is divulged (e.g. in logs), it is impossible to guess anything, except in very particular cases (say, a system that would return a yes/no answer, but the attacker would also need to know the headers and guess the random number...). > For hiding our pid etc. all data which can be found in the same email > or maybe related emails is of no use for feeding to the hash, because > it can easily be inserted as constants in brute-force searchs. Only > the random number remains as secret besides the data. > > We need data which is unrelated to the email but - to be deterministic > with regard to other Mutt instances - is equal to all Mutt instances on > the same machine (even if generated from different sources - every Mutt > developer has a separate "head" version, right? ;-) I don't understand why you need data that "is equal to all Mutt instances on the same machine". -- Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
