https://bugs.documentfoundation.org/show_bug.cgi?id=114939
--- Comment #2 from JimF <[email protected]> ---
Looking at the endMD5(), I am almost certain it has the same bug.
the bug comes from incrementing the i variable to point past the end of the
non-null data in the limb, and then comparing it to make sure there are still 8
bytes (to place the bit count into). But since 'i' was already incremented,
then you can not compare to equal that offset. It is a pretty simple off by 1
bug, but hard to spot because just looking at the code, it 'appears' to be
right.
NOTE, I am not sure of all the ways SHA1 is used within the software, so
'fixing' this may not be trivial. Data which was saved using the buggy hashes
will fail to checksum the same, IF this code is fixed.
If all that the code is doing, is providing a stored checksum to later be used
to make sure that a password is correct, or to check for things like the
document being unmodified, then if you change this code, those checks will no
longer succeed and that being on existing files / data.
If that is the case, it is possible that this bug should be left intact. There
is NO data security issues, it simply does not match the FIPS results.
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Libreoffice-bugs mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
