Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#5221 sha256 output is wrong on 32bit Linux

current: 8.6.0
closed-duplicate
5
2013-04-02
2013-03-30
Anonymous
No

I am using ActiveState Tcl for 32bit and 64bit Linux.
The command is:
sha2::sha256 -hex tk

The output is:
32bit Linux:
0b9422c2ca451b24fea81114412fb2c61e2ced68889466119b72d36c4ec3c337

64bit Linux:
1ec22d56dbbc91e849b00643bc4f10eb764441c93bde5c6090fe81db55cf6932

When using any web based sha256 generators the output is:
1ec22d56dbbc91e849b00643bc4f10eb764441c93bde5c6090fe81db55cf6932

Therefore, 32bit sha256 output seems to be incorrect.

Discussion

    • assigned_to: hobbs --> andreas_kupries
    • status: open --> pending-invalid
     
  • That's probably a bug in the sha256 code, which is part of tcllib (and not part of tcl properly). Assigning to the master of tcllib for confirmation...

     
  • A cursory look at the code reveals the use of constants like this:

    expr {int(0xc1059ed8)}

    But since int() is the tricky, platform-dependent "truncate to machine word" operator, its result (and sign extension thereof, in this specific case) will suffer when moving from 32 to 64 bits architectures.
    I'd risk that using wide() instead of int() throughout the package should make it robustly behave like the 64-bit version (which is supposed to be the good one according to this report).

     

  • Anonymous
    2013-03-31

    • status: pending-invalid --> open-invalid
     

  • Anonymous
    2013-03-31

    The sha256 package uses the accelerated compiled code from the tcllibc package. When forced to plain Tcl, the output is correct, changing int() to wide() does not make any difference. So, the problem is within the tcllibc package.

     
  • Thanks for this critical precision, will dig ;)
    Also note that both the pure-Tcl and the accelerated variants are part of the tcllib package.

     
  • Alexandre, thanks for looking into this.
    And thanks to the OS for clearing up that tcllibc is involved.
    If possible please shift this bug over to the Tcllib Tracker.
    (I.e. create a bug there with all the info, then close this one).

     

  • Anonymous
    2013-04-02

    • status: open-invalid --> closed-duplicate