3 ms·

>For one, a sha256 hash of 50kB would take a good quarter of a second (possibly more, I just ). You're probably thinking 50MB. Hashing 50kB should be almost in

by eMSF 6y ago

>For one, a sha256 hash of 50kB would take a good quarter of a second (possibly more, I just ). You're probably thinking 50MB. Hashing 50kB should be almost instantaneous.

franga2000 6y ago
The graph I looked at (that I was supposed to link in parentheses, but apparently failed) comes from [0] and actually shows crypt() performance as a function of key length, comparing different hashing alorigthms. Admittedly, not purely a sha256 benchmark, but possibly even more relevant to passwords. It looks pretty linear to me, so extrapolating to 50kB gives me 0.3625 seconds. That being said, I just ran a very simple test with just sha256sum and broke 0.3s only at 32MiB, so either crypt() is doing much more than I tought (is salting _that_ expensive?) or I am reading that post completely wrong. [0] https://stackoverflow.com/a/32909765 https://stackoverflow.com/a/32909765
- eMSF 6y ago
  >extrapolating to 50kB gives me 0.3625 seconds It should give you much more than that, considering that the green (SHA256) graph hits almost 0.1s at just 1000 bytes of input. >either crypt() is doing much more than I tought (is salting _that_ expensive?) glibc crypt() is probably doing more than you thought, but it's not salting: in SHA256 mode, various combinations of the key and intermediate hash digests are repeatedly hashed in a certain pattern for 5000 times, although the number of rounds can be changed just like the hashing algorithm. (This is a glibc implementation detail; not all crypt() implementations support extensions like SHA256 mode.) In general, all general purpose cryptographic hash functions are reasonably fast.
  - franga2000 6y ago
    You're right, it looks like I somehow read the number on the bottom axis wrong three times in a row (though it was 20 000). Thanks for the info on what crypt() actually does. I definitely need to look into that some more...

by eMSF 6y ago

>For one, a sha256 hash of 50kB would take a good quarter of a second (possibly more, I just ). You're probably thinking 50MB. Hashing 50kB should be almost instantaneous.

franga2000 6y ago

The graph I looked at (that I was supposed to link in parentheses, but apparently failed) comes from [0] and actually shows crypt() performance as a function of key length, comparing different hashing alorigthms. Admittedly, not purely a sha256 benchmark, but possibly even more relevant to passwords. It looks pretty linear to me, so extrapolating to 50kB gives me 0.3625 seconds. That being said, I just ran a very simple test with just sha256sum and broke 0.3s only at 32MiB, so either crypt() is doing much more than I tought (is salting _that_ expensive?) or I am reading that post completely wrong. [0] https://stackoverflow.com/a/32909765 https://stackoverflow.com/a/32909765

eMSF 6y ago
>extrapolating to 50kB gives me 0.3625 seconds It should give you much more than that, considering that the green (SHA256) graph hits almost 0.1s at just 1000 bytes of input. >either crypt() is doing much more than I tought (is salting _that_ expensive?) glibc crypt() is probably doing more than you thought, but it's not salting: in SHA256 mode, various combinations of the key and intermediate hash digests are repeatedly hashed in a certain pattern for 5000 times, although the number of rounds can be changed just like the hashing algorithm. (This is a glibc implementation detail; not all crypt() implementations support extensions like SHA256 mode.) In general, all general purpose cryptographic hash functions are reasonably fast.
- franga2000 6y ago
  You're right, it looks like I somehow read the number on the bottom axis wrong three times in a row (though it was 20 000). Thanks for the info on what crypt() actually does. I definitely need to look into that some more...