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 wi
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
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 Mt
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? Eith
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
>> wrote:
>> > Why not just use the kernel crypto API? Then the user can just specify
>> > any hash the kernel supports.
>>
>> One reason is that crytograph
John Williams wrote:
> On Mon, Dec 1, 2014 at 4:15 PM, Alex Elsayed 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.
>
> An
On Mon, Dec 1, 2014 at 4:15 PM, Alex Elsayed 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 applied the transitiv
On Sat, 2014-11-29 at 13:00 -0800, John Williams wrote:
> On Sat, Nov 29, 2014 at 12:38 PM, Alex Elsayed 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
> slow
John Williams wrote:
> On Mon, Dec 1, 2014 at 3:46 PM, Alex Elsayed 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 mentio
On Mon, Dec 1, 2014 at 4:06 PM, Alex Elsayed 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%)
> # Cortex-A57 2.35
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 3:46 PM, Alex Elsayed 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 achieve less than 1
John Williams wrote:
> On Mon, Dec 1, 2014 at 3:05 PM, Alex Elsayed 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 -
On Mon, Dec 1, 2014 at 3:46 PM, Alex Elsayed 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
UltraSPARC CPU, an
John Williams wrote:
> On Mon, Dec 1, 2014 at 3:05 PM, Alex Elsayed 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, wh
On Mon, Dec 1, 2014 at 3:05 PM, Alex Elsayed 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 Sandy
> Bridge o
John Williams wrote:
> On Mon, Dec 1, 2014 at 3:05 PM, Alex Elsayed 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, wh
On Mon, Dec 1, 2014 at 3:05 PM, Alex Elsayed 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
> unequivocally simp
John Williams wrote:
> On Mon, Dec 1, 2014 at 12:35 PM, Austin S Hemmelgarn
> 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 co
John Williams wrote:
> On Mon, Dec 1, 2014 at 12:08 PM, Alex Elsayed
> 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
John Williams wrote:
> On Mon, Dec 1, 2014 at 12:08 PM, Alex Elsayed
> 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
On Mon, Dec 1, 2014 at 12:35 PM, Austin S Hemmelgarn
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 the
> likely-hood o
On Mon, Dec 1, 2014 at 12:08 PM, Alex Elsayed 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,
> you're not goi
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. E
On 2014-12-01 14:34, Alex Elsayed wrote:
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 has
Alex Elsayed wrote:
> John Williams wrote:
>> Again, irrelevant. The Spooky2, CityHash256, and Murmur3 hashes that I
>> am talking about can and do take advantage of CPU architecture. For
>> 128- and 256-bit hashes, one (or more) of those three will be
>> significantly faster than any crypto hash
John Williams wrote:
> On Mon, Dec 1, 2014 at 11:28 AM, Alex Elsayed
> 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.
>
> Irrelev
On Mon, Dec 1, 2014 at 11:28 AM, Alex Elsayed 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 talking about speci
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 mul
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
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
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 d
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 UltraS
On 2014-12-01 12:22, John Williams wrote:
On Mon, Dec 1, 2014 at 4:39 AM, Austin S Hemmelgarn
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 prefer
On Mon, Dec 1, 2014 at 4:39 AM, Austin S Hemmelgarn
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 an fs used s
On 2014-11-29 16:21, John Williams wrote:
On Sat, Nov 29, 2014 at 1:07 PM, Alex Elsayed 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-str
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 s
On 30 November 2014 at 22:59, Christoph Anton Mitterer
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 names. SHA-2 2
>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
John Williams wrote:
> On Sat, Nov 29, 2014 at 1:07 PM, Alex Elsayed
> 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
>> alg
On Sat, Nov 29, 2014 at 1:07 PM, Alex Elsayed 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 looked. What 12
John Williams wrote:
> On Sat, Nov 29, 2014 at 12:38 PM, Alex Elsayed
> 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-cryptograph
On Sat, Nov 29, 2014 at 12:38 PM, Alex Elsayed 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 for filesystem
chec
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 col
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.
> >
>
On Wed, Nov 26, 2014 at 4:50 AM, Holger Hoffstätte
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:
> https://code.google.com/p/farmhash/
>
It s
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 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 obv
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 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-btrf
On Tue, Nov 25, 2014 at 2:30 AM, Liu Bo 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.
>>
>> http://burtleburtle.net/bob/hash/spooky.htm
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 wrote:
>>> This brings a strong-but-slow checksum algorithm, sha256.
>>>
>>> Actually btrfs used sha256 at the early time, but then moved to
>>> crc3
On Mon, Nov 24, 2014 at 03:07:45PM -0500, Chris Mason wrote:
> On Mon, Nov 24, 2014 at 12:23 AM, 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.
> >
> > A
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 stron
On Mon, Nov 24, 2014 at 03:07:45PM -0500, Chris Mason wrote:
> On Mon, Nov 24, 2014 at 12:23 AM, 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
2014-11-25 11:30 GMT+01:00 Liu Bo :
> 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
>> 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
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
> 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
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.
> >
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 wrote:
> > >This brings a strong-but-slow checksum algorithm, sha256.
> > >
> > >Actually btrfs used sha256 at the early time, but
Original Message
Subject: Re: [RFC PATCH] Btrfs: add sha256 checksum option
From: Hugo Mills
To: Chris Mason
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 wrote:
This brings a strong-but-slow
On Mon, Nov 24, 2014 at 03:07:45PM -0500, Chris Mason wrote:
> On Mon, Nov 24, 2014 at 12:23 AM, 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 12:23 AM, 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
algorithm
On Mon, Nov 24, 2014 at 12:23 AM, Holger Hoffstätte
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.
http://burtleburtle.net/bob/hash/spooky.html
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
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
>
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
algorithm as an alternative.
Users can choose sha256 from mkfs.
67 matches
Mail list logo
