[pcap-ng-format] Does anyone actually generate the epb_hash field today?

[Michael Haney]

On Thu, Aug 27, 2015 at 9:27 AM, Jasper Bongertz <jasper at packet-foo.com>
wrote:

> on Donnerstag, 27. August 2015 at 17:05 you wrote:
>
> > Howdy,
> > I'm not suggesting we get rid of the option, but does any code out
> > there actually generate the EPB's epb_hash option?
>
> not mine - I was thinking about it but saw no real use for it. Anyone
> modifying the packet contents can always recalculate the hash, so it's
> not protecting against tampering with the packet. And protection
> against file damage seems a bit unspectacular as well. Packet
> comparison also seems far-fetched as you'll almost never run into the
> situation of comparing packets from the exact same capture.
>
>
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.


> > I have not found any code which does, and it's under-specified in
> > terms of what the "algorithms" cover and how their values are encoded.
> > (and some of the algorithms seem ludicrous to me - in particular the
> > 2's complement and XOR "algorithms")
>
> Agree on 2's complement and XOR; not useful at all.
>
>
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.)


> > I propose we remove them from the draft, but reserve their number
> > codes (not re-use them) just in case.
>
> I  have no real objection; I wouldn't mind keeping the real ones (MD5,
> SHA) either. As you said we should reserve the number codes at least.
>
>
>
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.

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.


-Michael


>
>
> _______________________________________________
> pcap-ng-format mailing list
> pcap-ng-format at winpcap.org
> https://www.winpcap.org/mailman/listinfo/pcap-ng-format
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winpcap.org/pipermail/pcap-ng-format/attachments/20150827/cfc16e80/attachment-0001.html>