Cryptography Reference
In-Depth Information
we need a one-time signature scheme that can be used for signing mes-
sages that are longer than the verification-key. Here is where the hashing
paradigm comes into play. This paradigm refers to the common practice
of signing documents via a two-stage process: First the actual document
is hashed to a (relatively) short bit string, and next the basic signa-
ture scheme is applied to the resulting string. This practice (as well
as other usages of the hashing paradigm) is sound provided that the
hashing function belongs to a family of collision-free hashing functions
(i.e., loosely speaking, given a random hash function in the family, it
is infeasible to find two different strings that are hashed by this func-
tion to the same value; cf. (47)). (A variant of the hashing paradigm
uses the weaker notion of a family of Universal One-Way Hash Func-
tions (cf. (103)), which in turn can be constructed using any one-way
function (103; 114).)
Implementation details. In order to implement the aforementioned
(full-fledged) signature scheme one needs to store in (secure) memory
all the instances of the basic (one-time) signature scheme that are gen-
erated throughout the entire signing process (which refers to numerous
documents). This can be done by extending the model so to allow for
memory-dependent signature schemes. Alternatively, we note that all
that we need to store are the random-coins used for generating each
of these instances, and the former can be determined by a pseudoran-
dom function (applied to the name of the corresponding vertex in the
tree). Indeed, the seed of this pseudorandom function will be part of
the signing-key of the resulting (full-fledged) signature scheme.
6.3
Public-key infrastructure
The standard use of public-key encryption schemes (resp., signature
schemes) in real-life communication requires a mechanism for provid-
ing the sender (resp., signature verifier) with the receiver's authentic
encryption-key (resp., signer's authentic verification-key). Specifically,
this problem arises in large-scale systems, where typically the sender
(resp., verifier) does not have a local record of the receiver's encryption-
key (resp., signer's verification-key), and so must obtain this key in a
Search WWH ::




Custom Search