I also think that adding one field per hash type is not feasible as there are a lot of hash types and they change over time. That's why we used malware.hash and the Crypt (C) names. I wasn't aware of URN at this time and it is definitely better - easier to understand and supports more hash types. Consequently malware.hash needs to be a list (could be made comma separated for postgres?).
Sebastian
On 01/06/2017 09:47 AM, Pavel Kácha wrote:
Hi,
again, just speaking based on our experience - in a year or two there will be another set of popular hashes, and you will probably start considering adding another explicit keys (malware.hash.newone) - requiring changing the harmonization in the process. We have also found out that types hashes of hashes, which are not in standard format, but have their own intrinsic unextractable properties, appear over the time. This could validate adding its own "name", for example bittorrent BTIH hash. We also thought that hash type is part of information, and thus should be part of data field, not key name. So, we have just used one key, using solely URN namespace for adding new hash types.
(It is also necessary to say that one contents can be identified by more hashes, so you may find out over time that just single scalar field may not be enough. But I digress here. :) )
Cheers -- Pavel