<div>Please check also this old issue: <a href="https://github.com/certtools/intelmq/issues/394">https://github.com/certtools/intelmq/issues/394</a><br></div><div class="protonmail_signature_block "><div class="protonmail_signature_block-proton protonmail_signature_block-empty"><br></div></div><div><br></div><blockquote class="protonmail_quote" type="cite"><div>-------- Original Message --------<br></div><div>Subject: Re: [Intelmq-dev] IntelMQ Data Harmonization (DHO) - malware.hash key (issue 732)<br></div><div>Local Time: February 1, 2017 7:50 AM<br></div><div>UTC Time: February 1, 2017 7:50 AM<br></div><div>From: synchroack@protonmail.ch<br></div><div>To: L. Aaron Kaplan <kaplan@cert.at><br></div><div>Sebastian Wagner <wagner@cert.at>, intelmq-dev@lists.cert.at<br></div><div><br></div><div>Pavel, can you confirm in which "message" format are you currently using URN? Is it like the following?<br></div><div><br></div><div>{<br></div><div>    "malware.hash": [<br></div><div>        "urn:hash::md5:5307d294b6ccd9854f2deed8c1628b72",<br></div><div>        "urn:hash::sha1:LBPI666ED2QSWVD3VSO5BG5R54TE22QL"<br></div><div>    ]<br></div><div>}<br></div><div><br></div><div>The current issue on IntelMQ is the fact that we cannot add list as values but if it was that case, the proposal would suit perfectly.<br></div><div><br></div><div><br></div><div><br></div><div>Aaron and Sebastian, I see one issue:<br></div><div><br></div><div>If I have a bot like Virustotal which use malware.hash field to query the API, how should I create the bot since the hashes are in one field comma separated as you guys mentioned...? IMHO we should add one field per each hash type (it does not change so quickly) and before the next hash type, I expect that we as community have a final answer about Full-JSON support or "single value" formats like we are currently supporting.<br></div><div><br></div><div>I think it's time to decide regarding the malware keys. How do you guys want to proceed in the end?<br></div><div><br></div><div class="protonmail_signature_block "><div class="protonmail_signature_block-user "><br></div><div class="protonmail_signature_block-proton protonmail_signature_block-empty"><br></div></div><div><br></div><blockquote type="cite" class="protonmail_quote"><div>-------- Original Message --------<br></div><div>Subject: Re: [Intelmq-dev] IntelMQ Data Harmonization (DHO) - malware.hash key (issue 732)<br></div><div>Local Time: January 17, 2017 11:08 AM<br></div><div>UTC Time: January 17, 2017 11:08 AM<br></div><div>From: kaplan@cert.at<br></div><div>To: Sebastian Wagner <wagner@cert.at><br></div><div>intelmq-dev@lists.cert.at<br></div><div><br></div><div><br></div><div>> On 11 Jan 2017, at 10:36, Sebastian Wagner <wagner@cert.at> wrote:<br></div><div>> <br></div><div>> I also think that adding one field per hash type is not feasible as<br></div><div>> there are a lot of hash types and they change over time. That's why we<br></div><div>> used malware.hash and the Crypt (C) names.<br></div><div>> I wasn't aware of URN at this time and it is definitely better - easier<br></div><div>> to understand and supports more hash types. Consequently malware.hash<br></div><div>> needs to be a list (could be made comma separated for postgres?).<br></div><div>> <br></div><div><br></div><div>agreed<br></div><div><br></div><div>> Sebastian<br></div><div>> <br></div><div>> <br></div><div>> On 01/06/2017 09:47 AM, Pavel Kácha wrote:<br></div><div>>> Hi,<br></div><div>>> <br></div><div>>>   again, just speaking based on our experience - in a year or two there<br></div><div>>> will be another set of popular hashes, and you will probably start<br></div><div>>> considering adding another explicit keys (malware.hash.newone) - requiring<br></div><div>>> changing the harmonization in the process.<br></div><div>>>   We have also found out that types hashes of hashes, which are not in<br></div><div>>> standard format, but have their own intrinsic unextractable properties,<br></div><div>>> appear over the time.  This could validate adding its own "name", for<br></div><div>>> example bittorrent BTIH hash.<br></div><div>>>   We also thought that hash type is part of information, and thus should be<br></div><div>>> part of data field, not key name.<br></div><div>>>   So, we have just used one key, using solely URN namespace for adding new<br></div><div>>> hash types.<br></div><div>>> <br></div><div>>>   (It is also necessary to say that one contents can be identified by more<br></div><div>>> hashes, so you may find out over time that just single scalar field may not<br></div><div>>> be enough. But I digress here. :) )<br></div><div>>> <br></div><div>>> Cheers<br></div><div>>> -- Pavel<br></div><div>> <br></div><div>> --<br></div><div>> // Sebastian Wagner <wagner@cert.at> - T: +43 1 50564167201<br></div><div>> // CERT Austria - http://www.cert.at/<br></div><div>> // Eine Initiative der nic.at GmbH - http://www.nic.at/<br></div><div>> // Firmenbuchnummer 172568b, LG Salzburg<br></div><div>> <br></div><div>> <br></div><div>> _______________________________________________<br></div><div>> Intelmq-dev mailing list<br></div><div>> Intelmq-dev@lists.cert.at<br></div><div>> http://lists.cert.at/cgi-bin/mailman/listinfo/intelmq-dev<br></div><div><br></div><div><br></div><div>--<br></div><div>//  CERT Austria<br></div><div>//  L. Aaron Kaplan <kaplan@cert.at><br></div><div>//  T: +43 1 505 64 16 78<br></div><div>//  http://www.cert.at<br></div><div>//  Eine Initiative der nic.at GmbH<br></div><div>//  http://www.nic.at/ - Firmenbuchnummer 172568b, LG Salzburg<br></div><div><br></div><div>_______________________________________________<br></div><div>Intelmq-dev mailing list<br></div><div>Intelmq-dev@lists.cert.at<br></div><div>http://lists.cert.at/cgi-bin/mailman/listinfo/intelmq-dev<br></div></blockquote><div><br></div></blockquote><div><br></div>