Re: [PATCH 00/17] Add support for SHA-256 checksums

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 16.05.19 г. 9:30 ч., Paul Jones wrote:
> 
>> -----Original Message-----
>> From: linux-btrfs-owner@xxxxxxxxxxxxxxx <linux-btrfs-
>> owner@xxxxxxxxxxxxxxx> On Behalf Of David Sterba
>> Sent: Thursday, 16 May 2019 3:27 AM
>> To: Johannes Thumshirn <jthumshirn@xxxxxxx>
>> Cc: David Sterba <dsterba@xxxxxxxx>; Linux BTRFS Mailinglist <linux-
>> btrfs@xxxxxxxxxxxxxxx>
>> Subject: Re: [PATCH 00/17] Add support for SHA-256 checksums
>>
>>
>> Once the code is ready for more checksum algos, we'll pick candidates and
>> my idea is to select 1 fast (not necessarily strong, but better than crc32c) and
>> 1 strong (but slow, and sha256 is the candidate at the moment).
>>
>> The discussion from 2014 on that topic brought a lot of useful information,
>> though some algos have could have evolved since.
>>
>> https://lore.kernel.org/linux-btrfs/1416806586-18050-1-git-send-email-
>> bo.li.liu@xxxxxxxxxx/
>>
>> In about 5 years timeframe we can revisit the algos and potentially add more,
>> so I hope we'll be able to agree to add just 2 in this round.
>>
>> The minimum selection criteria for a digest algorithm:
>>
>> - is provided by linux kernel crypto subsystem
>> - has a license that will allow to use it in bootloader code (grub at
>>   lest)
>> - the implementation is available for btrfs-progs either as some small
>>   library or can be used directly as a .c file
> 
> 
> Xxhash would be a good candidate. It's extremely fast and almost crypto secure.  Has been in the kernel for ~2 yeas iirc.

Disclaimer: not a cryptographer. But according to the official site:
xxHash is non-cryptography hash. From the (draft) spec:

It is labelled non-cryptographic, and is not meant to avoid intentional
collisions (same digest for 2 different messages), or to prevent
producing a message with predefined digest.

This doesn't disqualify it, however we need to be aware its limitations.
Perhahps it could be used as a replacement for crc32c but definitely not
as secure crypto hash.

> 
> 
> Paul.
> 



[Index of Archives]     [Linux Filesystem Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux