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

[Hadriel Kaplan]

On Thu, Aug 27, 2015 at 12:55 PM, Michael Haney
<michael-haney at utulsa.edu> wrote:
>
> 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.

Assigning them in advance could be viewed that way (and is sometimes
done that way for protocol specs), but just as often it's the
opposite: only assign the ones you know will be used now, and leave
everything else out. If someone wants some other algorithm in the
future, they can always ask for another code to be assigned at that
time. Because in practice new hash algorithms come out all the time,
so the list is already stale, and you need some process to deal with
that in the future... in which case you might as well use that process
to handle even known algorithms that no one uses at the time the spec
came out.

The benefit of not assigning codes for algorithms you don't know
someone will use is that you don't fill the spec with cruft that isn't
being used, and implementors don't have to guess which are the
"popular" ones will be that they need to implement and test.

Of course this means we need some process to deal with assigning new
codes, if we keep this epb_hash option, which means this hash
algorithm code number would be another thing to go in our IANA
registry. :)

-hadriel