This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.

(In reply to comment #0)
> Description of problem:
> sha512hmac passes comparison between differently truncated sums of files. That
> means when I run 'sha512hmac' with some truncation (>= 256) on some file and
> then use for comparison smaller truncation (>= 256) it will pass that shouldn't
> happened.
> 
> 
> Version-Release number of selected component (if applicable):
> hmaccalc-0.9.6-3.el5
> 
> How reproducible:
> Always
> 
> Steps to Reproduce:
> 1. Run test: /CoreOS/nss/Sanity/simple-hmaccalc-test
> OR
> 1. sha512hmac -t 260 -k <key_file> some_dir/* > sums.txt
> 2. sha512hmac -t 256 -k <key_file> -c sums.txt
> 
> Actual results:
> 1. test FAILED
> 2. command PASSED
> 
> Expected results:
> 1. test should PASS
> 2. command should FAIL

Does this work correctly with 0.9.12?

> Additional info:
> I've done some tests and I've got different result on RHEL5 and RHEL6. See how
> generated string was changing:
> $ for I in `seq 256 1 512`; do echo -n "Bits ${I}: "; sha512hmac -t ${I}
> files/big | sed 's/\s\+.*//'; done
> 
> RHEL5:
> - snip -
> Bits 340:
> 48b4f55ffd692c7b89ab5741a7e3d4342ca26a7d8258ff71193b2a85fa9c6b682d86a8bb099bfdd7bd201
> Bits 341:
> 48b4f55ffd692c7b89ab5741a7e3d4342ca26a7d8258ff71193b2a85fa9c6b682d86a8bb099bfdd7bd2018
> Bits 342:
> 48b4f55ffd692c7b89ab5741a7e3d4342ca26a7d8258ff71193b2a85fa9c6b682d86a8bb099bfdd7bd2018
> Bits 343:
> 48b4f55ffd692c7b89ab5741a7e3d4342ca26a7d8258ff71193b2a85fa9c6b682d86a8bb099bfdd7bd2018
> Bits 344:
> 48b4f55ffd692c7b89ab5741a7e3d4342ca26a7d8258ff71193b2a85fa9c6b682d86a8bb099bfdd7bd2018
> Bits 345:
> 48b4f55ffd692c7b89ab5741a7e3d4342ca26a7d8258ff71193b2a85fa9c6b682d86a8bb099bfdd7bd20188
> Bits 346:
> 48b4f55ffd692c7b89ab5741a7e3d4342ca26a7d8258ff71193b2a85fa9c6b682d86a8bb099bfdd7bd2018c
> - snip -
> 
> 
> RHEL6:
> - snip -
> Bits 340:
> 83b486e8ef1b6a467f0bc97a63ff55733621a359ebee64267a2f2dc342842f593184d5aff18242c2ef84a
> Bits 341:
> 83b486e8ef1b6a467f0bc97a63ff55733621a359ebee64267a2f2dc342842f593184d5aff18242c2ef84a0
> Bits 342:
> 83b486e8ef1b6a467f0bc97a63ff55733621a359ebee64267a2f2dc342842f593184d5aff18242c2ef84a4
> Bits 343:
> 83b486e8ef1b6a467f0bc97a63ff55733621a359ebee64267a2f2dc342842f593184d5aff18242c2ef84a6
> Bits 344:
> 83b486e8ef1b6a467f0bc97a63ff55733621a359ebee64267a2f2dc342842f593184d5aff18242c2ef84a7
> Bits 345:
> 83b486e8ef1b6a467f0bc97a63ff55733621a359ebee64267a2f2dc342842f593184d5aff18242c2ef84a70
> Bits 346:
> 83b486e8ef1b6a467f0bc97a63ff55733621a359ebee64267a2f2dc342842f593184d5aff18242c2ef84a74
> - snip -

Is the bug here that the sums are different, or that increasing the number of bits doesn't always change the last hex digit?  If the bit no longer being chopped off is 0, the last hex digit won't change, because the sum is zero-filled to an even multiple of 4 bits for display purposes.

Hi Nalin,
hmaccalc-0.9.12-1.el6 works perfectly but this issue is about RHEL5. I've posted additional info about generating hashes because there are differences, as you can see. On RHEL5 I got same hash for truncation of 342 - 344 bits. On RHEL6 I got different hash with each truncation. The test is failing (on RHEL5) because of these different results. According to me hmaccalc works correctly on RHEL6 but not on RHEL5 (hmaccalc-0.9.6-3.el5).

(In reply to comment #3)
> Hi Nalin,
> hmaccalc-0.9.12-1.el6 works perfectly but this issue is about RHEL5. I've
> posted additional info about generating hashes because there are differences,
> as you can see. On RHEL5 I got same hash for truncation of 342 - 344 bits.

If bits 341, 342, 343, and 344 are 1000, then yes, truncating at 342, 343, and 344 will give you same hex output as truncating at 341, because in order to produce a hex digit, you have to supply four bits, and when it has to, it assumes that rightmost bits are zero.  That's not a bug.

> On
> RHEL6 I got different hash with each truncation. The test is failing (on RHEL5)
> because of these different results. According to me hmaccalc works correctly on
> RHEL6 but not on RHEL5 (hmaccalc-0.9.6-3.el5).

The contents of files/big were generated from /dev/urandom in both cases, so the two test runs aren't directly comparable.  Please run truncation comparison tests using the same input files.

If the bug is that telling hmaccalc to truncate values causes it to truncat both the values it computes and the values it reads from a file (so sums which are longer than the truncation length are fine so long as the initial portion matches), then yes, that's something that later versions rejected, and we can pull that fix in.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2011-1462.html