<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 27, 2015 at 9:27 AM, Jasper Bongertz <span dir="ltr"><<a href="mailto:jasper@packet-foo.com" target="_blank">jasper@packet-foo.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">on Donnerstag, 27. August 2015 at 17:05 you wrote:<br>
<br>
> Howdy,<br>
> I'm not suggesting we get rid of the option, but does any code out<br>
> there actually generate the EPB's epb_hash option?<br>
<br>
</span>not mine - I was thinking about it but saw no real use for it. Anyone<br>
modifying the packet contents can always recalculate the hash, so it's<br>
not protecting against tampering with the packet. And protection<br>
against file damage seems a bit unspectacular as well. Packet<br>
comparison also seems far-fetched as you'll almost never run into the<br>
situation of comparing packets from the exact same capture.<br>
<span class=""><br></span></blockquote><div><br></div><div>That's true.  The hash option with the EPB is most useful (to me, anyway) if you encrypt it and keep it inside the encrypted block, then regenerate it after decryption and compare before and after.  That's where the integrity check comes in.  capinfos does a nice job of taking several hashes of an entire file for comparison before and after.  But I needed something more granular, and this was there.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> I have not found any code which does, and it's under-specified in<br>
> terms of what the "algorithms" cover and how their values are encoded.<br>
> (and some of the algorithms seem ludicrous to me - in particular the<br>
> 2's complement and XOR "algorithms")<br>
<br>
</span>Agree on 2's complement and XOR; not useful at all.<br>
<span class=""><br></span></blockquote><div><br></div><div>2's complement and XOR are almost useless in this setting.  They're most useful for hardware-based quick-and-dirty integrity checks.  I considered these "historical" and left them in place to prevent re-use, and then tried to more clearly define what they meant (e.g. proper listing of length, etc.)<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> I propose we remove them from the draft, but reserve their number<br>
> codes (not re-use them) just in case.<br>
<br>
</span>I  have no real objection; I wouldn't mind keeping the real ones (MD5,<br>
SHA) either. As you said we should reserve the number codes at least.<br>
<br>
<br></blockquote><div><br></div><div>I agree.  And to respond Hadriel's question about all the additional algorithms, I was going for completeness in the spec over practicality.  In case someone has a problem with MD5 and prefers RIPEMD, it ought to have a number assigned to avoid collision. <br><br></div><div>I use SHA-2-256 and Whirlpool (un-keyed) and HMAC-SHA-256 and HMAC-Whirlpool (keyed hashes).  NIST just released the approval of SHA-3 (Keccak) which I'll play with when/if BouncyCastle supports it. Otherwise, I stick to the basics.  SHA-1 is considered broken, and MD5 is considered vulnerable (some consider it broken).  The extended list of algorithms future-proofs the spec.<br><br><br></div><div>-Michael<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
<br>_______________________________________________<br>
pcap-ng-format mailing list<br>
<a href="mailto:pcap-ng-format@winpcap.org">pcap-ng-format@winpcap.org</a><br>
<a href="https://www.winpcap.org/mailman/listinfo/pcap-ng-format" rel="noreferrer" target="_blank">https://www.winpcap.org/mailman/listinfo/pcap-ng-format</a><br></blockquote></div><br></div></div>