On Mon, Dec 01, 2014 at 03:23:03PM -0800, Alex Elsayed wrote:
I have not seen any evidence that combining hashes like that actually
reduces the chances of collision, but if we assume it does, then
again, the non-crypto hashes would be faster. For example, 128-bit
Spooky2 combined with
On 2014-11-29 16:21, John Williams wrote:
On Sat, Nov 29, 2014 at 1:07 PM, Alex Elsayed eternal...@gmail.com wrote:
I'd suggest looking more closely at the crypto api section of menuconfig -
it already has crc32c, among others. Just because it's called the crypto
api doesn't mean it only has
On Mon, Dec 1, 2014 at 4:39 AM, Austin S Hemmelgarn
ahferro...@gmail.com wrote:
Just because it's a filesystem doesn't always mean that speed is the most
important thing. Personally, I can think of multiple cases where using a
cryptographically strong hash would be preferable, for example:
On 2014-12-01 12:22, John Williams wrote:
On Mon, Dec 1, 2014 at 4:39 AM, Austin S Hemmelgarn
ahferro...@gmail.com wrote:
Just because it's a filesystem doesn't always mean that speed is the most
important thing. Personally, I can think of multiple cases where using a
cryptographically strong
On Mon, Dec 1, 2014 at 9:42 AM, Austin S Hemmelgarn Except most of
the CPU optimized hashes aren't crypto hashes (other than the
various SHA implementations). Furthermore, I've actually tested the speed
of a generic CRC32c implementation versus SHA-1 using the SHA instructions
on an
On Wed, Nov 26, 2014 at 08:58:50AM -0500, Austin S Hemmelgarn wrote:
On 2014-11-26 08:38, Brendan Hide wrote:
On 2014/11/25 18:47, David Sterba wrote:
We could provide an interface for external applications that would make
use of the strong checksums. Eg. external dedup, integrity db. The
On Thu, Nov 27, 2014 at 11:52:20AM +0800, Liu Bo wrote:
There are several checksum algorithms that trade off speed and strength
so we may want to support more than just sha256. Easy to add but I'd
rather see them added in all at once than one by one.
Another question is if we'd like to
John Williams wrote:
On Mon, Dec 1, 2014 at 9:42 AM, Austin S Hemmelgarn Except most of
the CPU optimized hashes aren't crypto hashes (other than the
various SHA implementations). Furthermore, I've actually tested the
speed of a generic CRC32c implementation versus SHA-1 using the SHA
Alex Elsayed wrote:
* He was comparing CRC32 (a 32-bit non-cryptographic hash, *via the Crypto
API*) against SHA-1 (a 128-bit cryptographic hash, via the Crypto API),
and SHA-1 _still_ won. CRC32 tends to beat the pants off 128-bit non-
cryptographic hashes simply because those require
On Mon, Dec 1, 2014 at 11:28 AM, Alex Elsayed eternal...@gmail.com wrote:
I think there's a fundamental set of points being missed.
That may be true, but it is not me who is missing them.
* The Crypto API can be used to access non-cryptographic hashes. Full stop.
Irrelevant to my point. I am
John Williams wrote:
On Mon, Dec 1, 2014 at 11:28 AM, Alex Elsayed eternal...@gmail.com
wrote:
I think there's a fundamental set of points being missed.
That may be true, but it is not me who is missing them.
* The Crypto API can be used to access non-cryptographic hashes. Full
stop.
On 2014-12-01 13:37, David Sterba wrote:
On Wed, Nov 26, 2014 at 08:58:50AM -0500, Austin S Hemmelgarn wrote:
On 2014-11-26 08:38, Brendan Hide wrote:
On 2014/11/25 18:47, David Sterba wrote:
We could provide an interface for external applications that would make
use of the strong checksums.
On Mon, Dec 1, 2014 at 12:08 PM, Alex Elsayed eternal...@gmail.com wrote:
Actually, I said Sure here, but this isn't strictly true. At some point,
you're more memory-bound than CPU-bound, and with CPU intrinsic instructions
(like SPARC and recent x86 have for SHA) you're often past that. Then,
On Mon, Dec 1, 2014 at 12:35 PM, Austin S Hemmelgarn
ahferro...@gmail.com wrote:
My only reasoning is that with this set of hashes (crc32c, adler32, and
md5), the statistical likely-hood of running into a hash collision with more
than one of them at a time is infinitesimally small compared to
John Williams wrote:
On Mon, Dec 1, 2014 at 12:08 PM, Alex Elsayed eternal...@gmail.com
wrote:
Actually, I said Sure here, but this isn't strictly true. At some
point, you're more memory-bound than CPU-bound, and with CPU intrinsic
instructions (like SPARC and recent x86 have for SHA) you're
John Williams wrote:
On Mon, Dec 1, 2014 at 12:08 PM, Alex Elsayed eternal...@gmail.com
wrote:
Actually, I said Sure here, but this isn't strictly true. At some
point, you're more memory-bound than CPU-bound, and with CPU intrinsic
instructions (like SPARC and recent x86 have for SHA) you're
John Williams wrote:
On Mon, Dec 1, 2014 at 12:35 PM, Austin S Hemmelgarn
ahferro...@gmail.com wrote:
My only reasoning is that with this set of hashes (crc32c, adler32, and
md5), the statistical likely-hood of running into a hash collision with
more than one of them at a time is
On Mon, Dec 1, 2014 at 3:05 PM, Alex Elsayed eternal...@gmail.com wrote:
Incidentally, you can be 'skeptical' all you like - per Austin's message
upthread, he was testing the Crypto API. Thus, skeptical as you may be, hard
evidence shows that SHA-1 was equal to or faster than CRC32, which is
John Williams wrote:
On Mon, Dec 1, 2014 at 3:05 PM, Alex Elsayed eternal...@gmail.com wrote:
Incidentally, you can be 'skeptical' all you like - per Austin's message
upthread, he was testing the Crypto API. Thus, skeptical as you may be,
hard evidence shows that SHA-1 was equal to or faster
On Mon, Dec 1, 2014 at 3:05 PM, Alex Elsayed eternal...@gmail.com wrote:
hard evidence shows that SHA-1 was equal to or faster than CRC32, which is
unequivocally simpler and faster than CityHash (though CityHash comes
close).
And the CPUs in question are *not* particularly rare - Intel since
John Williams wrote:
On Mon, Dec 1, 2014 at 3:05 PM, Alex Elsayed eternal...@gmail.com wrote:
Incidentally, you can be 'skeptical' all you like - per Austin's message
upthread, he was testing the Crypto API. Thus, skeptical as you may be,
hard evidence shows that SHA-1 was equal to or faster
On Mon, Dec 1, 2014 at 3:46 PM, Alex Elsayed eternal...@gmail.com wrote:
And I'm not sure what is convoluted or incorrect about saying Look,
empirical evidence!
No empirical evidence of the speed of SpookyHash or CityHash versus
SHA-1 was cited. The only empirical data mentioned was on an
John Williams wrote:
On Mon, Dec 1, 2014 at 3:05 PM, Alex Elsayed eternal...@gmail.com wrote:
hard evidence shows that SHA-1 was equal to or faster than CRC32, which
is unequivocally simpler and faster than CityHash (though CityHash comes
close).
And the CPUs in question are *not*
On Mon, Dec 1, 2014 at 3:46 PM, Alex Elsayed eternal...@gmail.com wrote:
And that _is_ the case; they are faster... *when both are software
implementations*
They are also faster when both are optimized to use special
instructions of the CPU.
According to this Intel whitepaper, SHA-1 does not
Alex Elsayed wrote:
So CityHash is - at best - half as fast as SHA1 with acceleration.
In fact, on the Apple A7, it would likely be slower than _software_ SHA-1.
Argh, ignore this. The CityHash readme is in bytes/cycle, which I missed on
first readthrough (why on earth they are not using
On Mon, Dec 1, 2014 at 4:06 PM, Alex Elsayed eternal...@gmail.com wrote:
https://github.com/openssl/openssl/blob/master/crypto/sha/asm/sha1-armv8.pl
# hardware-assisted software(*)
# Apple A72.31 4.13 (+14%)
# Cortex-A53 2.19 8.73 (+108%)
#
John Williams wrote:
On Mon, Dec 1, 2014 at 3:46 PM, Alex Elsayed eternal...@gmail.com wrote:
And I'm not sure what is convoluted or incorrect about saying Look,
empirical evidence!
No empirical evidence of the speed of SpookyHash or CityHash versus
SHA-1 was cited. The only empirical data
On Sat, 2014-11-29 at 13:00 -0800, John Williams wrote:
On Sat, Nov 29, 2014 at 12:38 PM, Alex Elsayed eternal...@gmail.com wrote:
Why not just use the kernel crypto API? Then the user can just specify any
hash the kernel supports.
One reason is that crytographic hashes are an order of
On Mon, Dec 1, 2014 at 4:15 PM, Alex Elsayed eternal...@gmail.com wrote:
There's a thing called the transitive property. When CRC32 is faster than
SpookyHash and CityHash (while admittedly weaker), and SHA-1 on SPARC is
faster than CRC32, there are comparisons that can be made.
And yet you
John Williams wrote:
On Mon, Dec 1, 2014 at 4:15 PM, Alex Elsayed eternal...@gmail.com wrote:
There's a thing called the transitive property. When CRC32 is faster than
SpookyHash and CityHash (while admittedly weaker), and SHA-1 on SPARC is
faster than CRC32, there are comparisons that can be
Christoph Anton Mitterer wrote:
On Sat, 2014-11-29 at 13:00 -0800, John Williams wrote:
On Sat, Nov 29, 2014 at 12:38 PM, Alex Elsayed eternal...@gmail.com
wrote:
Why not just use the kernel crypto API? Then the user can just specify
any hash the kernel supports.
One reason is that
On Mon, 2014-12-01 at 16:43 -0800, Alex Elsayed wrote:
including that MAC-then-encrypt is fragile
against a number of attacks, mainly in the padding-oracle category (See: TLS
BEAST attack).
Well but here we talk about disk encryption... how would the MtE oracle
problems apply to that? Either
Christoph Anton Mitterer wrote:
On Mon, 2014-12-01 at 16:43 -0800, Alex Elsayed wrote:
including that MAC-then-encrypt is fragile
against a number of attacks, mainly in the padding-oracle category (See:
TLS BEAST attack).
Well but here we talk about disk encryption... how would the MtE
Alex Elsayed wrote:
Christoph Anton Mitterer wrote:
On Mon, 2014-12-01 at 16:43 -0800, Alex Elsayed wrote:
including that MAC-then-encrypt is fragile
against a number of attacks, mainly in the padding-oracle category (See:
TLS BEAST attack).
Well but here we talk about disk encryption...
Agree with others about -C 256...-C sha256 is only three
letters more ;)
Ideally, sha2-256 would be used, since there will be (are) other
versions of sha which have 256 bits size.
Cheers,
Chris.
smime.p7s
Description: S/MIME cryptographic signature
Agree with others about -C 256...-C sha256 is only three
letters more ;)
Ideally, sha2-256 would be used, since there will be (are) other
versions of sha which have 256 bits size.
Cheers,
Chris.
smime.p7s
Description: S/MIME cryptographic signature
On 30 November 2014 at 22:59, Christoph Anton Mitterer
cales...@scientia.net wrote:
Agree with others about -C 256...-C sha256 is only three
letters more ;)
Ideally, sha2-256 would be used, since there will be (are) other
versions of sha which have 256 bits size.
Nope, we should use standard
On Sun, 2014-11-30 at 23:05 +, Dimitri John Ledkov wrote:
Nope, we should use standard names.
Well I wouldn't know that there is really a standardised name in the
sense that it tells it's mandatory.
People use SHA2-xxx, SHA-xxx, SHAxxx and probably even more
combinations.
And just because
David Sterba wrote:
On Mon, Nov 24, 2014 at 01:23:05PM +0800, Liu Bo wrote:
This brings a strong-but-slow checksum algorithm, sha256.
Actually btrfs used sha256 at the early time, but then moved to crc32c
for performance purposes.
As crc32c is sort of weak due to its hash collision
On Sat, Nov 29, 2014 at 12:38 PM, Alex Elsayed eternal...@gmail.com wrote:
Why not just use the kernel crypto API? Then the user can just specify any
hash the kernel supports.
One reason is that crytographic hashes are an order of magnitude
slower than the fastest non-cryptographic hashes. And
John Williams wrote:
On Sat, Nov 29, 2014 at 12:38 PM, Alex Elsayed eternal...@gmail.com
wrote:
Why not just use the kernel crypto API? Then the user can just specify
any hash the kernel supports.
One reason is that crytographic hashes are an order of magnitude
slower than the fastest
On Sat, Nov 29, 2014 at 1:07 PM, Alex Elsayed eternal...@gmail.com wrote:
I'd suggest looking more closely at the crypto api section of menuconfig -
it already has crc32c, among others. Just because it's called the crypto
api doesn't mean it only has cryptographically-strong algorithms.
I have
John Williams wrote:
On Sat, Nov 29, 2014 at 1:07 PM, Alex Elsayed eternal...@gmail.com
wrote:
I'd suggest looking more closely at the crypto api section of menuconfig
- it already has crc32c, among others. Just because it's called the
crypto api doesn't mean it only has
On Tue, 25 Nov 2014 15:17:58 -0800, John Williams wrote:
2) CityHash : for 256-bit hashes on all systems
https://code.google.com/p/cityhash/
Btw this is now superseded by Farmhash:
https://code.google.com/p/farmhash/
-h
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs
On 2014/11/25 13:30, Liu Bo wrote:
This is actually inspired by ZFS, who offers checksum functions ranging
from the simple-and-fast fletcher2 to the slower-but-secure sha256.
Back to btrfs, crc32c is the only choice.
And also for the slowness of sha256, Intel has a set of instructions for
it,
On 2014/11/25 18:47, David Sterba wrote:
We could provide an interface for external applications that would make
use of the strong checksums. Eg. external dedup, integrity db. The
benefit here is that the checksum is always up to date, so there's no
need to compute the checksums again. At the
On 2014-11-26 08:38, Brendan Hide wrote:
On 2014/11/25 18:47, David Sterba wrote:
We could provide an interface for external applications that would make
use of the strong checksums. Eg. external dedup, integrity db. The
benefit here is that the checksum is always up to date, so there's no
need
On Wed, Nov 26, 2014 at 4:50 AM, Holger Hoffstätte
holger.hoffstae...@googlemail.com wrote:
On Tue, 25 Nov 2014 15:17:58 -0800, John Williams wrote:
2) CityHash : for 256-bit hashes on all systems
https://code.google.com/p/cityhash/
Btw this is now superseded by Farmhash:
On Tue, Nov 25, 2014 at 05:39:05PM +0100, David Sterba wrote:
On Mon, Nov 24, 2014 at 01:23:05PM +0800, Liu Bo wrote:
This brings a strong-but-slow checksum algorithm, sha256.
Actually btrfs used sha256 at the early time, but then moved to crc32c for
performance purposes.
As crc32c
On Mon, Nov 24, 2014 at 08:23:25AM +, Holger Hoffstätte wrote:
On Mon, 24 Nov 2014 13:23:05 +0800, Liu Bo wrote:
This brings a strong-but-slow checksum algorithm, sha256.
Actually btrfs used sha256 at the early time, but then moved to crc32c for
performance purposes.
As crc32c
On Mon, Nov 24, 2014 at 11:34:46AM -0800, John Williams wrote:
On Mon, Nov 24, 2014 at 12:23 AM, Holger Hoffstätte
holger.hoffstae...@googlemail.com wrote:
Would there be room for a compromise with e.g. 128 bits?
For example, Spooky V2 hash is 128 bits and is very fast. It is
2014-11-25 11:30 GMT+01:00 Liu Bo bo.li@oracle.com:
On Mon, Nov 24, 2014 at 11:34:46AM -0800, John Williams wrote:
On Mon, Nov 24, 2014 at 12:23 AM, Holger Hoffstätte
holger.hoffstae...@googlemail.com wrote:
Would there be room for a compromise with e.g. 128 bits?
For example, Spooky
On Mon, Nov 24, 2014 at 03:07:45PM -0500, Chris Mason wrote:
On Mon, Nov 24, 2014 at 12:23 AM, Liu Bo bo.li@oracle.com wrote:
This brings a strong-but-slow checksum algorithm, sha256.
Actually btrfs used sha256 at the early time, but then moved to
crc32c for
performance purposes.
As
On Mon, Nov 24, 2014 at 01:23:05PM +0800, Liu Bo wrote:
This brings a strong-but-slow checksum algorithm, sha256.
Actually btrfs used sha256 at the early time, but then moved to crc32c for
performance purposes.
As crc32c is sort of weak due to its hash collision issue, we need a stronger
On Mon, Nov 24, 2014 at 03:07:45PM -0500, Chris Mason wrote:
On Mon, Nov 24, 2014 at 12:23 AM, Liu Bo bo.li@oracle.com wrote:
This brings a strong-but-slow checksum algorithm, sha256.
Actually btrfs used sha256 at the early time, but then moved to
crc32c for
performance purposes.
On 2014-11-25 17:47, David Sterba wrote:
On Mon, Nov 24, 2014 at 03:07:45PM -0500, Chris Mason wrote:
On Mon, Nov 24, 2014 at 12:23 AM, Liu Bo bo.li@oracle.com wrote:
This brings a strong-but-slow checksum algorithm, sha256.
Actually btrfs used sha256 at the early time, but then moved to
On Tue, Nov 25, 2014 at 2:30 AM, Liu Bo bo.li@oracle.com wrote:
On Mon, Nov 24, 2014 at 11:34:46AM -0800, John Williams wrote:
For example, Spooky V2 hash is 128 bits and is very fast. It is
noncryptographic, but it is more than adequate for data checksums.
On Mon, 24 Nov 2014 13:23:05 +0800, Liu Bo wrote:
This brings a strong-but-slow checksum algorithm, sha256.
Actually btrfs used sha256 at the early time, but then moved to crc32c for
performance purposes.
As crc32c is sort of weak due to its hash collision issue, we need a stronger
Holger Hoffstätte posted on Mon, 24 Nov 2014 08:23:25 + as excerpted:
Users can choose sha256 from mkfs.btrfs via
$ mkfs.btrfs -C 256 /device
Not sure how others feel about this, but it's probably easier for
sysadmins to specify the algorithm by name from the set of supported
ones,
On Mon, Nov 24, 2014 at 12:23 AM, Holger Hoffstätte
holger.hoffstae...@googlemail.com wrote:
Would there be room for a compromise with e.g. 128 bits?
For example, Spooky V2 hash is 128 bits and is very fast. It is
noncryptographic, but it is more than adequate for data checksums.
On Mon, Nov 24, 2014 at 12:23 AM, Liu Bo bo.li@oracle.com wrote:
This brings a strong-but-slow checksum algorithm, sha256.
Actually btrfs used sha256 at the early time, but then moved to
crc32c for
performance purposes.
As crc32c is sort of weak due to its hash collision issue, we need a
On Mon, Nov 24, 2014 at 03:07:45PM -0500, Chris Mason wrote:
On Mon, Nov 24, 2014 at 12:23 AM, Liu Bo bo.li@oracle.com wrote:
This brings a strong-but-slow checksum algorithm, sha256.
Actually btrfs used sha256 at the early time, but then moved to
crc32c for
performance purposes.
As
Original Message
Subject: Re: [RFC PATCH] Btrfs: add sha256 checksum option
From: Hugo Mills h...@carfax.org.uk
To: Chris Mason c...@fb.com
Date: 2014年11月25日 04:58
On Mon, Nov 24, 2014 at 03:07:45PM -0500, Chris Mason wrote:
On Mon, Nov 24, 2014 at 12:23 AM, Liu Bo bo.li
On Mon, Nov 24, 2014 at 08:58:25PM +, Hugo Mills wrote:
On Mon, Nov 24, 2014 at 03:07:45PM -0500, Chris Mason wrote:
On Mon, Nov 24, 2014 at 12:23 AM, Liu Bo bo.li@oracle.com wrote:
This brings a strong-but-slow checksum algorithm, sha256.
Actually btrfs used sha256 at the early
64 matches
Mail list logo
