From: "Austin S. Hemmelgarn" <ahferroin7@gmail.com>
To: Johannes Thumshirn <jthumshirn@suse.de>,
Adam Borowski <kilobyte@angband.pl>
Cc: Diego Calleja <diegocg@gmail.com>,
dsterba@suse.cz, David Sterba <dsterba@suse.com>,
Linux BTRFS Mailinglist <linux-btrfs@vger.kernel.org>
Subject: Re: [PATCH 00/17] Add support for SHA-256 checksums
Date: Mon, 20 May 2019 07:34:34 -0400 [thread overview]
Message-ID: <6b6f85cd-ec77-a39f-8afa-2c0f093d77ec@gmail.com> (raw)
In-Reply-To: <20190520074750.GC4985@x250>
On 2019-05-20 03:47, Johannes Thumshirn wrote:
> On Sat, May 18, 2019 at 02:38:08AM +0200, Adam Borowski wrote:
>> On Fri, May 17, 2019 at 09:07:03PM +0200, Johannes Thumshirn wrote:
>>> On Fri, May 17, 2019 at 08:36:23PM +0200, Diego Calleja wrote:
>>>> If btrfs needs an algorithm with good performance/security ratio, I would
>>>> suggest considering BLAKE2 [1]. It is based in the BLAKE algorithm that made
>>>> to the final round in the SHA3 competition, it is considered pretty secure
>>>> (above SHA2 at least), and it was designed to take advantage of modern CPU
>>>> features and be as fast as possible - it even beats SHA1 in that regard. It is
>>>> not currently in the kernel but Wireguard uses it and will add an
>>>> implementation when it's merged (but Wireguard doesn't use the crypto layer
>>>> for some reason...)
>>>
>>> SHA3 is on my list of other candidates to look at for a performance
>>> evaluation. As for BLAKE2 I haven't done too much research on it and I'm not a
>>> cryptographer so I have to trust FIPS et al.
>>
>> "Trust FIPS" is the main problem here. Until recently, FIPS certification
>> required implementing this nice random generator:
>> https://en.wikipedia.org/wiki/Dual_EC_DRBG
>>
>> Thus, a good part of people are reluctant to use hash functions chosen by
>> NIST (and published as FIPS).
>
> I know, but please also understand that there are applications which do
> require FIPS certified algorithms.
Those would also be cryptographic applications, which BTRFS is not. If
you're in one of those situations and need to have cryptographic
verification of files on the system, you need to be using either IMA,
dm-verity, or dm-integrity.
next prev parent reply other threads:[~2019-05-20 11:34 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-10 11:15 [PATCH 00/17] Add support for SHA-256 checksums Johannes Thumshirn
2019-05-10 11:15 ` [PATCH 01/17] btrfs: use btrfs_csum_data() instead of directly calling crc32c Johannes Thumshirn
2019-05-10 16:16 ` Nikolay Borisov
2019-05-10 11:15 ` [PATCH 02/17] btrfs: resurrect btrfs_crc32c() Johannes Thumshirn
2019-05-10 16:16 ` Nikolay Borisov
2019-05-10 11:15 ` [PATCH 03/17] btrfs: use btrfs_crc32c() instead of btrfs_extref_hash() Johannes Thumshirn
2019-05-10 13:03 ` Nikolay Borisov
2019-05-10 11:15 ` [PATCH 04/17] btrfs: use btrfs_crc32c() instead of btrfs_name_hash() Johannes Thumshirn
2019-05-10 12:56 ` Chris Mason
2019-05-13 7:04 ` Johannes Thumshirn
2019-05-10 11:15 ` [PATCH 05/17] btrfs: don't assume ordered sums to be 4 bytes Johannes Thumshirn
2019-05-10 13:25 ` Nikolay Borisov
2019-05-10 13:27 ` Nikolay Borisov
2019-05-13 7:06 ` Johannes Thumshirn
2019-05-10 11:15 ` [PATCH 06/17] btrfs: dont assume compressed_bio " Johannes Thumshirn
2019-05-10 11:15 ` [PATCH 07/17] btrfs: use btrfs_crc32c{,_final}() in for free space cache Johannes Thumshirn
2019-05-10 13:27 ` Nikolay Borisov
2019-05-10 11:15 ` [PATCH 08/17] btrfs: format checksums according to type for printing Johannes Thumshirn
2019-05-10 13:28 ` Nikolay Borisov
2019-05-10 11:15 ` [PATCH 09/17] btrfs: add common checksum type validation Johannes Thumshirn
2019-05-10 13:37 ` Nikolay Borisov
2019-05-10 11:15 ` [PATCH 10/17] btrfs: check for supported superblock checksum type before checksum validation Johannes Thumshirn
2019-05-10 13:37 ` Nikolay Borisov
2019-05-10 11:15 ` [PATCH 11/17] btrfs: Simplify btrfs_check_super_csum() and get rid of size assumptions Johannes Thumshirn
2019-05-10 13:41 ` Nikolay Borisov
2019-05-10 11:15 ` [PATCH 12/17] btrfs: add boilerplate code for directly including the crypto framework Johannes Thumshirn
2019-05-10 16:28 ` Nikolay Borisov
2019-05-10 11:15 ` [PATCH 13/17] btrfs: pass in an fs_info to btrfs_csum_{data,final}() Johannes Thumshirn
2019-05-10 11:15 ` [PATCH 14/17] btrfs: directly call into crypto framework for checsumming Johannes Thumshirn
2019-05-10 13:45 ` Chris Mason
2019-05-10 13:54 ` Chris Mason
2019-05-13 7:17 ` Johannes Thumshirn
2019-05-13 13:55 ` Chris Mason
2019-05-14 12:46 ` Johannes Thumshirn
2019-05-13 13:00 ` David Sterba
2019-05-13 13:01 ` Johannes Thumshirn
2019-05-13 14:30 ` David Sterba
2019-05-10 11:15 ` [PATCH 15/17] btrfs: remove assumption about csum type form btrfs_csum_{data,final}() Johannes Thumshirn
2019-05-13 12:56 ` David Sterba
2019-05-10 11:15 ` [PATCH 16/17] btrfs: remove assumption about csum type form btrfs_print_data_csum_error() Johannes Thumshirn
2019-05-10 11:15 ` [PATCH 17/17] btrfs: add sha256 as another checksum algorithm Johannes Thumshirn
2019-05-10 12:30 ` Nikolay Borisov
2019-05-13 7:11 ` Johannes Thumshirn
2019-05-13 12:54 ` David Sterba
2019-05-13 12:55 ` Johannes Thumshirn
2019-05-15 1:45 ` Jeff Mahoney
2019-05-13 12:55 ` David Sterba
2019-05-13 12:58 ` Johannes Thumshirn
2019-05-15 17:27 ` [PATCH 00/17] Add support for SHA-256 checksums David Sterba
2019-05-16 6:30 ` Paul Jones
2019-05-16 8:16 ` Nikolay Borisov
2019-05-16 8:20 ` Johannes Thumshirn
2019-05-17 18:36 ` Diego Calleja
2019-05-17 19:07 ` Johannes Thumshirn
2019-05-18 0:38 ` Adam Borowski
2019-05-20 7:47 ` Johannes Thumshirn
2019-05-20 11:34 ` Austin S. Hemmelgarn [this message]
2019-05-20 11:57 ` Johannes Thumshirn
2019-05-20 11:42 ` Austin S. Hemmelgarn
2019-05-30 12:21 ` David Sterba
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6b6f85cd-ec77-a39f-8afa-2c0f093d77ec@gmail.com \
--to=ahferroin7@gmail.com \
--cc=diegocg@gmail.com \
--cc=dsterba@suse.com \
--cc=dsterba@suse.cz \
--cc=jthumshirn@suse.de \
--cc=kilobyte@angband.pl \
--cc=linux-btrfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).