> We have been using older version of Openssl (0.9.8c) and this one has > same problem.
Even though 0.9.8c is more sensitive to endianness (sha256_block function accepts additional 'host' flag, which caller can get wrong), it should have worked as long as -DB_ENDIAN is passed. Later versions work even without [LB]_ENDIAN. But in either case endianness was always taken into account and code was actually tested on both big- and little-endian platforms. > Used compiler is not perfect and often has prolem with O3 so i > already tried Os (doesn't work) and O2 - thats work ok. So I suppose > that optimalisations are not the issue. You don't know that till you pass -O0. Please do test. > I tested both SMALL FOOTPRINT and normal code and both has same > problem. > > I also have own SHA256 implementation ( implemented as defined in > standard ) from another project. So when I replace the core of SHA256 > computation (sha256 hash update ) with my implementation it works ok. > Then all tests (make tests) passed without errors. So it's not > exactly endian problem, but SHA256 implementation on SH architecture. Does it mean that we agree that it looks more like compiler problem than problem with OpenSSL source code? > Our implementation is using rotation as defined in standart but > Openssl uses opposite. I find it hard to believe that rotation direction is responsible. > SH3 architecture in Big endian is not so > common so there could be some unexpected bahaviour in compiler. SH processors are capable of operating in either endianness. So that formally you can't say "SH *architecture* is big-endian", you can only say "this particular SH-based system is big-endian." As far as I understand endianness is determined by logical level fed to specific CPU pin at power-up. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
