Page 3 of 3 FirstFirst 123
Results 61 to 66 of 66

Thread: SHA3 winner announced

  1. #61
    Expert
    Matt Mahoney's Avatar
    Join Date
    May 2008
    Location
    Melbourne, Florida, USA
    Posts
    3,257
    Thanks
    307
    Thanked 795 Times in 488 Posts
    > Why not to use blake2s or even blake2sp? They will be 3-10 times faster than SHA256.

    BLAKE2 has not received the same security analysis as BLAKE did because it was not a SHA-3 finalist. BLAKE2 is faster because it uses fewer rounds and drops the round constants.

    Also, the speed advantage is only on 64 bit processors. SHA-1 and SHA-256 use 32 bit operations. Of course 32 bit processors are dinosaurs, but the fact is a lot of people are still running 32 bit operating systems on their 64 bit processors. About 30% of people are even still using Windows XP. http://www.netmarketshare.com/operat...10&qpcustomd=0

    That said, SHA-1 was probably a poor choice for ZPAQ. I would change it if I wasn't worried about compatibility. I'm not so worried about error detection (CRC32 would be good enough) as much as the possibility of deduplication collisions. I already use SHA-256 for the encryption related functions.

  2. #62
    Member
    Join Date
    Jun 2013
    Location
    USA
    Posts
    98
    Thanks
    4
    Thanked 14 Times in 12 Posts
    Quote Originally Posted by Bulat Ziganshin View Post
    latency? you probably means throughput - it's about 8GB/s, i.e. much faster than SHA1 computation speed
    To use the result of a hash computed on a GPU in a normal program, you must first memcpy it to main memory. Unless you're working strictly with a GPU kernel.

    Multiple datatreams are not a problem for brute-force.

  3. #63
    Member
    Join Date
    Jan 2014
    Location
    Russia
    Posts
    24
    Thanks
    0
    Thanked 2 Times in 2 Posts
    Quote Originally Posted by Matt Mahoney View Post
    Also, the speed advantage is only on 64 bit processors. SHA-1 and SHA-256 use 32 bit operations.
    Sorry, you are not quite right. Blake2s upon sse4.1 is much faster than sha-256, and blake2sp upon multicores such as i5 and i7 is much faster than sha1. At least, until one have not got SHA-extended CPU. But sse2 and sse4.1 is more common than SHA-extension.

  4. #64
    Member m^2's Avatar
    Join Date
    Sep 2008
    Location
    Ślůnsk, PL
    Posts
    1,611
    Thanks
    30
    Thanked 65 Times in 47 Posts
    Quote Originally Posted by Matt Mahoney View Post
    Of course 32 bit processors are dinosaurs.
    Uhm....no. 32-bit is where most of the cool stuff happens.
    * Heterogenous SMP mixing slim and fat cores in OMAP / Vybrid / ...
    * super-lighthweight SMP in XMOS
    * general-purpose 72-core Tilera (that also happens to expose message passing to the software)
    * VLIW+SIMD in Fujitsu FR-V

    I dare say that AMD64 is a dinosaur.

  5. #65
    Member
    Join Date
    Jun 2009
    Location
    Kraków, Poland
    Posts
    1,488
    Thanks
    26
    Thanked 130 Times in 100 Posts
    64-bit will become widespread among architectures other than x86 in few years I think. Maybe except very low power CPUs, but if we're talking about such very low power CPUs then probably they are coupled with hardware hash engines or something like that if they spend a lot of time hashing.

    Anyway, ZPAQ is not optimized for non-x86 architectures, maybe even won't run, I don't know. Looks like performance of ZPAQ on non-x86 architectures is not a top priority for the moment for Matt

  6. #66
    Expert
    Matt Mahoney's Avatar
    Join Date
    May 2008
    Location
    Melbourne, Florida, USA
    Posts
    3,257
    Thanks
    307
    Thanked 795 Times in 488 Posts
    I know that zpaq (an earlier version) has run on an ARM processor. zpaq compiles ZPAQL code into 32 or 64 bit x86 but for other processors it interprets the ZPAQL code which is 2-3 times slower.

Page 3 of 3 FirstFirst 123

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •