All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christophe Leroy <christophe.leroy@c-s.fr>
To: Pascal Van Leeuwen <pvanleeuwen@insidesecure.com>,
	Eric Biggers <ebiggers@kernel.org>
Cc: "linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>
Subject: Re: another testmgr question
Date: Fri, 24 May 2019 10:46:37 +0200	[thread overview]
Message-ID: <907eb6a5-dc76-d5ee-eccf-e7bd426a0868@c-s.fr> (raw)
In-Reply-To: <AM6PR09MB3523CFCFE42A33621FE4ACC3D2020@AM6PR09MB3523.eurprd09.prod.outlook.com>



Le 24/05/2019 à 10:44, Pascal Van Leeuwen a écrit :
>>> Valid? A totally fabricated case, if you ask me. Yes, you could do that,
>>> but is it *useful* at all? Really?
>>> No, it's not because a file of length 0 is a file of length 0, the length
>>> in itself is sufficient guarantee of its contents. The hash does not add
>>> *anything* in this case. It's a constant anyway, the same value for *any*
>>> zero-length file. It doesn't tell you anything you didn't already know.
>>> IMHO the tool should just return a message stating "hashing an empty file
>>> does not make any sense at all ...".
>>>
>>
>> Of course it's useful.  It means that *every* possible file has a SHA-256
>> digest.  So if you're validating a file, you just check the SHA-256 digest;
>> or
>> if you're creating a manifest, you just hash the file and list the SHA-256
>> digest.  Making everyone handle empty files specially would be insane.
>>
> As I already mentioned in another thread somewhere, this morning in the
> shower I realised that this may be useful if you have no expectation of
> the length itself. But it's still a pretty specific use case which was
> never considered for our hardware. And our HW doesn't seem to be alone in
> this.
> Does shaXXXsum or md5sum use the kernel crypto API though?

The ones from libkcapi do (http://www.chronox.de/libkcapi.html)

Christophe

  reply	other threads:[~2019-05-24  8:46 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <AM6PR09MB3523CED0B1587FCBDE4095A0D2010@AM6PR09MB3523.eurprd09.prod.outlook.com>
     [not found] ` <20190523185833.GA243994@google.com>
2019-05-23 19:32   ` another testmgr question Pascal Van Leeuwen
2019-05-23 20:05     ` Eric Biggers
2019-05-23 21:43       ` Pascal Van Leeuwen
2019-05-23 23:48         ` Eric Biggers
2019-05-24  8:44           ` Pascal Van Leeuwen
2019-05-24  8:46             ` Christophe Leroy [this message]
2019-05-24  8:49               ` Jeffrey Walton
2019-05-24  9:42                 ` Pascal Van Leeuwen
2019-05-24  9:21               ` Pascal Van Leeuwen
2019-05-24  9:25                 ` Ard Biesheuvel
2019-05-24  9:34                   ` Pascal Van Leeuwen
2019-05-24  9:45                     ` Ard Biesheuvel
2019-05-24  9:57                       ` Pascal Van Leeuwen
2019-05-24 11:09                         ` Ard Biesheuvel
2019-05-27  9:52                           ` Pascal Van Leeuwen
2019-05-24 10:13                       ` Pascal Van Leeuwen
2019-05-24 10:43                         ` Kamil Konieczny
2019-05-24 10:54                           ` Christophe Leroy
2019-05-27  9:44                       ` Pascal Van Leeuwen
2019-05-27  9:49                         ` Ard Biesheuvel
2019-05-27 10:04                           ` Pascal Van Leeuwen
2019-05-27 10:28                             ` Ard Biesheuvel
2019-05-27 10:43                               ` Pascal Van Leeuwen
2019-05-27 10:57                                 ` Ard Biesheuvel
2019-05-27 12:22                                   ` Pascal Van Leeuwen
2019-05-27 14:59                                     ` Ard Biesheuvel
2019-05-27 15:56                                       ` Pascal Van Leeuwen
2019-05-27 16:21                                         ` Ard Biesheuvel
2019-05-27 20:15                                           ` Pascal Van Leeuwen
2019-05-27 12:41                                   ` Pascal Van Leeuwen
2019-05-27 14:45                                     ` Ard Biesheuvel
2019-05-27 15:16                                       ` Pascal Van Leeuwen
2019-05-27 15:24                                         ` Ard Biesheuvel
2019-05-27 20:46                                           ` Pascal Van Leeuwen
2019-05-25  1:22                   ` Eric Biggers
2019-05-27  9:55                     ` Pascal Van Leeuwen
2019-05-24  9:27                 ` Stephan Mueller
2019-05-24  5:24         ` Ard Biesheuvel
2019-05-24  7:04           ` Kamil Konieczny
2019-05-24  7:47           ` Pascal Van Leeuwen
2019-05-24  9:15             ` Ard Biesheuvel
2019-05-24  9:28               ` Pascal Van Leeuwen
2019-05-24  6:21         ` Christophe Leroy
2019-05-24  8:04           ` Pascal Van Leeuwen
2019-05-24  6:14       ` Jeffrey Walton
2019-05-24  8:00         ` Pascal Van Leeuwen

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=907eb6a5-dc76-d5ee-eccf-e7bd426a0868@c-s.fr \
    --to=christophe.leroy@c-s.fr \
    --cc=ebiggers@kernel.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=pvanleeuwen@insidesecure.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.