Random Number Generator
The TPM offers a simple interface to a hardware random number generator. It's particularly useful when another source of entropy may not be available. Examples are embedded systems or early in a platform boot cycle.
The TPM can be considered a more trusted source of random numbers than the software generator. See the paper “Ron was wrong, Whit is right”  for a discussion of issues resulting from poor software random number generators.
TPM 2.0 offers two cryptographic digest primitive APIs. Both are hash agile, permitting the hash algorithm to be specified in the call.
The simpler but less flexible option is TPM2_Hash. The caller inputs the message, and
the TPM returns the digest. The message length is limited by the TPM input buffer size, typically 1 or 2 KB. The other API implements the usual start/update/complete pattern using TPM2_HashSequenceStart, TPM2_SequenceUpdate, and TPM2_SequenceComplete.
in this use case, assume that the tpM input buffer is 2 KB. the user desires to sha-256 hash a 4 KB file. the user uses the tpM because the sha-256 algorithm
isn't available in software. the user uses the sequence commands because the file is larger than 2 KB.
here are the steps:
1. TPM2_HashSequenceStart, specifying the sha-256 algorithm.
2. TPM2_SequenceUpdate two times, with a sequence of 2 KB buffers.
3. TPM2_SequenceComplete to return the result.
this api is similar to that of tpM 1.2, but it has several enhancements:
• it supports multiple hash algorithms.
• the start function returns a handle. More than one digest operation can be in progress at a time.
• the update function isn't restricted to a multiple of 64 bytes.
• the complete function can be more than 64 bytes.
• the complete function can return a ticket, which is used when signing with a restricted key. see the discussion of TPM_GENERATED for details.
CrtM software would like to verify a signed software update. Because it's resource constrained, it uses the tpM to digest the update, avoiding the need to implement the digest calculation in the CrtM.
tpM 2.0 offers TPM2_EventSequenceComplete as an alternative to TPM2_SequenceComplete. this command can only terminate a digest process where no algorithm was specified. this null algorithm causes the tpM to calculate digests over the message for all supported algorithms.
the command, an extension of tpM 1.2's TPM_SHA1CompleteExtend, has two enhancements:
• it permits the result of the digest operation to be extended into a pCr. One pCr index is specified, but all pCrs at that index (that is, all banks) are extended with a digest
corresponding to that pCr bank's algorithm. Multiple digests are returned, one for each supported algorithm.
• the sha-1 algorithm is being deprecated in favor of stronger algorithms such as sha-256. this command, which can do both algorithms simultaneously, permits a staged phase-out of sha-1, because it can return multiple results and extend multiple pCr banks.
TPM2_EventSequenceComplete allows software to measure (digest and extend) software using the tpM. it avoids the need for the measuring software to implement a digest algorithm.
in one pass, the software can measure into pCr banks for several algorithms. a tpM may be unlikely to support multiple simultaneous pCr banks (multiple sets of pCrs with different algorithms). the current pC Client tpM doesn't require this. But if one ever does, the tpM api supports it.
-  Arjen K. Lenstra, James P. Hughes, Maxime Augier, Joppe W. Bos, Thorsten Kleinjung, and Christophe Wachter, “Ron was wrong, Whit is right,” International Association for Cryptologic Research, 2012, https://eprint.iacr.org/2012/064.pdf.