No subject

A more subtle problem arises in protocols that rely on
the"freshness"of their random number source e.g. for generating
session keys or nonces. Consider a virtual machine that has been
rolled back to a point after a random number has been chosen, but
before it has been used, then resumes execution. In this case,
randomness that must be"fresh"for security purposes is reused. With a
stream cipher, two different plaintexts could be encrypted under the
same key stream, thus expos- ingtheXORofthe two messages. This could
in turn expose both messages if the messages have sufficient
redundancy, as is common for English text. Non- cryptographic
protocols that rely on freshness are also at risk, e.g. reuse of TCP
initial sequence numbers can allowTCP hijacking attacks[2].

Zero Knowledge Proofs of Knowledge (ZKPK), by their very nature, are
insecure if the same random nonces are used multiple times. For
example, ZKPK authentication protocols, such as Fiat-Shamir
authen-tication[5]or Schnorr authentication[12], will leak the user's
private key if the same nonce is used twice. Similarly, signature
systems derived from ZKPK protocols,  e.g. the Digital Signature
Standard (DSS), will leak the secret signing key if two signatures are
generated using the same randomness[1].

These seem to me to be large problems.