On Wed, 2017-07-05 at 11:18 -0400, Ken Goldman wrote: > On 6/28/2017 1:28 PM, Jarkko Sakkinen wrote: > > On Mon, Jun 26, 2017 at 08:33:59AM -0400, Mimi Zohar wrote: > >> On Sat, 2017-06-24 at 11:03 +0200, Jarkko Sakkinen wrote: > >>> On Wed, Jun 21, 2017 at 04:29:35PM +0200, Roberto Sassu wrote:
> >>> There's absolutely no need to pass digest size like you do BTW as > it >>> is defined by the standard. > >> > >> For algorithms known to the crypto subsystem, that is fine, but for > >> the unknown TPM crypto algorithms, we would need to somehow query the > >> TPM for the digest sizes to create the mapping. > >> > >> Mimi > > > > There's a TPM command to query TPM algorithms. > > This is true - one getcap to determine the number of algorithms, then a > pcr read, then parse the response structures and match the algorithms to > sizes. > > Alternatively, could you create a table mapping the algorithm to the > size? There are currently 8 approved algorithms, meaning the table is > 32 bytes, probably less code than the queries. > > As for an algorithm appearing in the TPM that's not in the table, it > takes a year or more for a new algorithm to appear. Is that enough time > to patch the device driver? > > FYI, the 8 algorithms are: > > sha1, sha256, sha384, sha512, sm3-256, sha3-256, sha3-384, sha3-512. > > I am only aware of sha1, sha256, and sm3-256 being used in production > hardware TPMs. New devices aren't being shipped with the most recent kernels. So even if the upstream kernel supports the newer crypto algorithms, that doesn't imply that it is available. A safer method would be to query the TPM for the digest sizes. Mimi