[Intelmq-dev] IntelMQ Data Harmonization (DHO) - malware.hash key (issue 732)

[Sebastian Wagner]

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

-- 
// Sebastian Wagner <wagner at cert.at> - T: +43 1 50564167201 
// CERT Austria - http://www.cert.at/
// Eine Initiative der nic.at GmbH - http://www.nic.at/
// Firmenbuchnummer 172568b, LG Salzburg


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://lists.cert.at/pipermail/intelmq-dev/attachments/20170111/5bb51a04/attachment.sig>