Skip to content
  1. Feb 14, 2018
    • Viktor Dukhovni's avatar
      Avoid fragile aliasing of SHA224/384 update/final · babab8e7
      Viktor Dukhovni authored
      
      
      This is purported to save a few cycles, but makes the code less
      obvious and more brittle, and in fact breaks on platforms where for
      ABI continuity reasons there is a SHA2 implementation in libc, and
      so EVP needs to call those to avoid conflicts.
      
      A sufficiently good optimizer could simply generate the same entry
      points for:
      
              foo(...) { ... }
          and
              bar(...) { return foo(...); }
      
      but, even without that, the different is negligible, with the
      "winner" varying from run to run (openssl speed -evp sha384):
      
          Old:
          type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes 16384 bytes
          sha384           28864.28k   117362.62k   266469.21k   483258.03k   635144.87k 649123.16k
      
          New:
          type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes 16384 bytes
          sha384           30055.18k   120725.98k   272057.26k   482847.40k   634585.09k 650308.27k
      
      Reviewed-by: default avatarRich Salz <rsalz@openssl.org>
      babab8e7
  2. Feb 13, 2018
  3. Feb 12, 2018
  4. Feb 11, 2018
  5. Feb 10, 2018
  6. Feb 09, 2018