ńņš. 2
(āńåćī 2)


of the (master) initial witnesses committed to in Step 2 of the issuing protocol, while
the other proof may make use of freshly generated initial witnesses and need not be
a signed proof.

5.5 Security improvements
In this section we introduce techniques to improve security, without resorting to
smartcards or other tamper-resistant devices for certiļ¬cate holders. Among others,
we show how to discourage lending, copying, and discarding of certiļ¬cates, and how
to achieve non-repudiation for limited-show certiļ¬cates. Most of these software-only
techniques are based on the limited-show certiļ¬cation technique of Section 5.4. We
also provide measures to protect against leakage and misuse of the CAā€™s secret key.

5.5.1 Beneļ¬ts of encoding identiļ¬ers
Certiļ¬ed key pairs that do not contain information that can be uniquely traced or
linked to one person or to a select group are sometimes called digital bearer cer-
tiļ¬cates. They are the digital equivalent of paper-based bearer certiļ¬cates, such as
currency and bearer bonds. Anyone may obtain them, show them, and pass them
around. Bearer certiļ¬cates are the opposite of personal certiļ¬cates, which are gen-
erally issued only to parties that meet certain criteria. The simplest way for the CA
to create digital bearer certiļ¬cates is to issue blind signatures on public keys. An
improved approach is to use restrictive blinding, to enable the CA to encode basic
attributes (such as use limitations, expiry dates, and veriļ¬er policies) and to provide
the ability of selective disclosure.
By deļ¬nition, non-personal certiļ¬cates must be limited-show certiļ¬cates; other-
wise everyone could simply use the same certiļ¬cate. This requirement is at odds with

the ability of computers to instantaneously copy digital certiļ¬cates in large numbers
at virtually no cost, and to freely distribute them over electronic networks at the speed
of light. Fraud with digital bearer certiļ¬cates and other limited-show certiļ¬cates im-
plemented in software-only devices can be prevented only by clearing all showing
protocol executions online with a central party. For each authorization request, this
party (typically the CA) must consult an online database that keeps track of the num-
ber of times a presented certiļ¬cate has already been shown. Online clearing suffers
from the drawbacks in Section 1.1.3. The scalability problem is even worse, since
the process of checking the occurrence of a certiļ¬cate in the database is inherently
sequential; queries may not be performed in parallel, and the online database may
not be distributed. In many PKIs, though, it sufļ¬ces for the CA to strongly discour-
age fraud and to be able to quickly contain it. Using our technique in Section 5.4,
it is possible to realize these security goals and to do away with the need for online
clearing. Hereto the CA must personalize all limited-show attribute certiļ¬cates by
encoding into each certiļ¬ed key pair an attribute identifying the certiļ¬cate applicant.
Consider the security beneļ¬ts:

ā€¢ A certiļ¬cate holder who shows a limited-show certiļ¬cate more times than al-
lowed can be traced by computing the built-in identiļ¬er from the transcripts
of the showing protocol executions. This enables the CA to stop the fraud
by listing the abused certiļ¬cate on a CRL and by blocking further retrieval
of certiļ¬cates from account. In addition, if the identiļ¬er can be linked to the
identity of the certiļ¬cate holder, it may be possible to sue for damages and to
prevent the perpetrator from continuing to participate in the system. Of course,
traceability of perpetrators often also serves as a powerful deterrent.

ā€¢ This technique can be made to work even for anonymous accounts. Traced
perpetrators can be prevented from opening new anonymous accounts, from
which new limited-show certiļ¬cates can be retrieved, by limiting the number
of anonymous accounts to one per certiļ¬cate applicant. Hereto a special entity
should issue digital pseudonyms with an embedded identiļ¬er, that can each
be used to open one anonymous account. If personal account pseudonyms are
issued in such a manner that the recertiļ¬cation technique described in Sec-
tion 5.2.1 applies, the limited-show property remains intact.

ā€¢ The number of anonymous accounts need not be limited to one per certiļ¬cate
applicant. In case a traced perpetrator refuses to reveal any other anonymous
accounts he or she may have opened, the CA can require all system participants
(e.g., the next time they retrieve certiļ¬cates) to demonstrate that the identiļ¬er
built into their account pseudonym is not that of the perpetrator. Hereto the
showing protocol technique in Section 3.4 can be used. This is not an extra
burden, since applicants must use their account pseudonym anyway to authen-
ticate account access requests.

ā€¢ In the same manner, a perpetrator can be stopped from using any other digital
certiļ¬cates that may have been issued to him or her. For example, an adminis-
trator of a pseudonymous chat box can require each participant to digitally sign
his or her next message in such a manner that the signed proof demonstrates
that the pseudonym is not that of an identiļ¬ed misbehaving participant. (The
alternative of issuing only one-show certiļ¬cates is not always desirable.)

ā€¢ More generally, to verify that t public keys, h 1 , . . . , ht , are not all owned by
the same certiļ¬cate applicant, the veriļ¬er generates t numbers, Ī± 1 , . . . , Ī±t at
random from a set V that is a subset of Z q , subject to the condition i=1 Ī±i =

0 mod q. Let attribute x1 be unique to the certiļ¬cate applicant. A cheating
prover can prove knowledge of a DL-representation of g 1 with respect to a
tuple that contains t hĪ±i with success probability at most 1/|V |, but an
i=1 i
honest group of provers can always (jointly) convince the veriļ¬er. (The same
technique applies to the RSAREP-based constructions.)

Stronger fraud discouragement without resorting to online clearing requires the use
of smartcards or other tamper-resistant devices; for details, see the next chapter.
In sum, even though in regular communications and transactions there may be no
need for certiļ¬cate holders to show identiļ¬ers, it is beneļ¬cial the CA for to encode
them anyway into their certiļ¬ed key pairs.
There is no need for the CA to encode globally unique identiļ¬ers; they should
merely be unique within the domain of the PKI. Identiļ¬ers need not even be deter-
mined using an out-of-band method: an identiļ¬er may be a random number or a
pseudonym known to the CA. In cases where a true name is to be used, the CA may
require registrants to present an X.509 or other identity certiļ¬cate; the CA can copy
and paste the subject names from these certiļ¬cates into the certiļ¬cates it issues.
The current standards for identity certiļ¬cates can easily be encapsulated. To en-
capsulate an X.509v3 certiļ¬cate, for instance, the CA can take x 1 to be (a collision-
intractable hash of) the concatenation of all the ļ¬elds except the subjectā€™s X.500 name
(i.e., the format version, serial number, the CAā€™s certiļ¬cation algorithm identiļ¬er, the
CAā€™s X.500 name, the validity period, and the certiļ¬cate holderā€™s public key and the
algorithm with which it is to be used), and x 2 the certiļ¬cate holderā€™s X.500 name.
The remaining x i ā€™s can specify additional attributes, such as X.509v3 extensions. In
the certiļ¬cate showing protocol, the certiļ¬cate holder must disclose (the preimage
of) x1 , and may be required to demonstrate properties about the other attributes. To
ensure that the data encoded into x 1 does not serve as a unique identiļ¬er, the entropy
of at least the validity period and any extension ļ¬elds must be restricted. Further-
more, the serial number should be set to a hash of the (certiļ¬ed) public key, since this
is what is posted on a CRL; alternatively, it is set to zero, since veriļ¬ers can compute
the hash themselves if needed. 3
3 ANSI draft standard X9.68 for mobile devices proposes to shorten X.509 certiļ¬cates by assigning to
each certiļ¬cate an implicit serial number formed by hashing the certiļ¬cate; this matches our approach.

A non-technical objection to the inclusion of identiļ¬ers into certiļ¬ed key pairs is
that organizations and other veriļ¬ers may incite certiļ¬cate holders to disclose their
built-in identiļ¬ers, for example by giving discounts to customers who disclose their
identiļ¬ers or by refusing to serve anonymous certiļ¬cate holders. Privacy legislation
should be adopted that prohibits such discrimination in PKIs where there is no strict
need for identiļ¬cation; PKI legislation is needed anyway, so this is not an unrea-
sonable course of action. In Section 6.5.5 we will show how to make it technically
infeasible for certiļ¬cate holders to disclose their identiļ¬er attributes.

5.5.2 How to discourage lending
It should not be possible for certiļ¬cate holder to lend (i.e., distribute copies of) their
personal certiļ¬cates, such as driverā€™s licenses and diplomas, to others. To discourage
lending of certiļ¬ed key pairs for personal certiļ¬cates that are used in face-to-face
situations, the CA could encode biometric identiļ¬ers into certiļ¬ed key pairs, such
as digitized photographs, ļ¬ngerprints, or retina scans. Privacy legislation should
specify when identity disclosure may be required; preferably, veriļ¬ers may require
disclosure of visual identiļ¬ers only in rare cases, sampled at random. Fairness can
be enforced by using a cryptographic (biased) coin ļ¬‚ipping protocol to determine
whether a biometric identiļ¬er must be disclosed.
For improved security and privacy, the CA could encode into each certiļ¬ed key
pair a plurality of personal characteristics, such as eye color, gender, height, and skin
type. Each of these by itself is not a person identiļ¬er, but sufļ¬ciently many taken
as a group are. In the showing protocol the veriļ¬er could then request the certiļ¬cate
holder to disclose a random subset of the built-in personal characteristics. Again,
fairness can be achieved by means of (biased) coin ļ¬‚ipping, to determine the size
and the elements of the subset that must be disclosed.
Another measure for the CA to discourage lending of certiļ¬ed key pairs is to
encode into each certiļ¬ed key pair an attribute that the certiļ¬cate holder wants to
remain conļ¬dential. Examples are the identity of the certiļ¬cate holder (his or her
reputation may be damaged when the borrower discloses the attribute), the secret key
of a key pair used to sign messages (such as a PGP secret key), or a redeemable elec-
tronic token of signiļ¬cant value. (It should not be possible, though, for a certiļ¬cate
holder to revoke a key or a token within the period that lending is to be discour-
aged.) According to Proposition 3.6.1(b), the demonstration of any Boolean formula
requires knowledge of the entire secret key. Consequently, the lender must reveal to
the borrower all the attributes, including the conļ¬dential attribute, even though the
borrower may be interested only in some of the other attributes. This measure may be
combined with the previous measure, but applies also to personal certiļ¬cates that are
not restricted to face-to-face situations. By way of example, consider digital gender
certiļ¬cates needed to gain access to certain online discussion groups, or ā€œover 18ā€
certiļ¬cates to gain access to adult-oriented Web sites. By encoding along the credit

card data of the legitimate receiver into his or her certiļ¬cates, the issuer can ensure
that the receiver cannot lend (or give out copies of) the certiļ¬cate without disclosing
the credit card data; at the same time, privacy is not compromised because the re-
ceiver itself can hide the data when showing the certiļ¬cate. 4 The CA need not know
the conļ¬dential attributes it encodes: it can apply our updating or (re)certiļ¬cation
technique described in Section 5.2.1 to a public key presented by the certiļ¬cate ap-
plicant (corresponding to the secret the applicant wants to remain conļ¬dential).
Yet another measure to discourage lending is for the CA to issue all personal
certiļ¬cates in the form of limited-show certiļ¬cates. 5 This subjects a lender to the
risk that the borrower uses his or her certiļ¬ed key pair more times than allowed,
which would result in the lender being traced (and held responsible). It also reduces
the number of times the certiļ¬cate holder can continue to use the certiļ¬ed key pair
him or herself. This measure may be applied in conjunction with the measure in the
previous paragraph, applies also to certiļ¬cates that by their nature may be shown an
unlimited number of times (before expiry), and works particularly well in conjunction
with short validity periods (which are more natural for limited-show certiļ¬cates; see
Section 1.1.5).
Stronger protection against lending requires smartcards; see Section 6.5.3.

5.5.3 Non-repudiation
To prevent the CA from framing certiļ¬cate holders by falsely claiming abuse of
limited-show certiļ¬cates, consider a variation of the DLREP-based scheme described
in Section 4.5.2. Before issuing certiļ¬ed key pairs to V 0 , P0 requires V0 to provide
hāˆ— := g1 , for a random I āˆˆ Z q , and to prove knowledge of log g1 hāˆ— without reveal-

ing I; V0 can apply the Schnorr proof of knowledge or its zero-knowledge variation.
In addition, V 0 may be required to sign a statement to agree to the consequences of
the use of hāˆ— ; this can be combined with the proof of knowledge by giving a signed
proof of log g1 hāˆ— . If the proof is convincing (it need only be performed once), P 0
multiplies the desired g i -powers into h āˆ— , and uses the result as the number h in the
issuing protocol to issue to V 0 one or more limited-show certiļ¬cates. If a certiļ¬cate
is shown more times than allowed, I can be computed. Assuming that (q, g 1 , I) has
been generated by an invulnerable instance generator, I serves as compact undeniable
evidence of fraud.
The evidence can be made unconditionally convincing. Hereto the CA should
4 This valuable property cannot be ensured by simply certifying a one-way hash structure of the at-
tributes (such as the concatenation of one-way images of all the attribute values). The resulting certiļ¬cates
can be shown without needing to know all the attribute values themselves.
5 To prevent linkability of showing protocol executions, certiļ¬cate holders must use their certiļ¬cates

only a limited number of times anyway, and the CA might as well exploit this by issuing limited-show
certiļ¬cates with built-in identiļ¬ers. The burden of issuing 100 copies (and new ones when needed) is
hardly greater than the burden of issuing a single copy, especially if the CA uses a DLREP-based issuing
protocol that admits preprocessing of all exponentiations.

require V0 to register using a number h āˆ— of the form g 1 g2 , for an arbitrary I and a

random Ī² āˆˆ Zq . V0 must prove knowledge of a DL-representation of h āˆ— with respect
to (g1 , g2 ); again, this need only be done once. In case of fraud, the CA can compute
I, Ī², which serve as unconditionally undeniable evidence; assuming that g 1 , g2 = 1,
the CA cannot frame V 0 , no matter how it generates the system parameters and its
public key.
This non-repudiation technique works also in conjunction with anonymous ac-
counts: hāˆ— serves as the account pseudonym, which the certiļ¬cate applicant must
acquire from an account pseudonym issuer (possibly by showing an X.509 certiļ¬cate
or another type of identity certiļ¬cate) and uses to authenticate account requests.
To apply the non-repudiation technique to an RSAREP-based certiļ¬cate scheme,
V0 should preferably register using a number h āˆ— of the form g 1 Ī² v .

5.5.4 How to discourage discarding
To discourage certiļ¬cate holders from discarding certiļ¬ed key pairs that encode unfa-
vorable attributes, the CA can encode favorable attributes into the same certiļ¬ed key
pairs. For instance, information on late payments could be encoded into a member-
ship certiļ¬cate for a health club or the like, and marks for drunk driving into a driverā€™s
license certiļ¬cate. Note that the updating technique described in Section 5.2.1 can be
put to use here.
This measure does not work when the attributes encoded into the certiļ¬ed key
pairs of a certiļ¬cate applicant change over time and become less favorable to the
applicant. To limit the ability of certiļ¬cate holders to reuse old certiļ¬ed key pairs
that encode attributes that are more favorable, the CA should encode short validity
periods. Alternatively, or preferably in addition, the CA could issue only limited-
show certiļ¬cates.
The strongest possible protection in software-only implementations is to issue
only one-show certiļ¬cates, and to ensure that certiļ¬cate holders cannot show more
than one certiļ¬cate at any time. This can be achieved by having the CA recertify (and
update) one-show certiļ¬cates only when they are shown in executions of the showing
protocol. This requires all veriļ¬ers to have an online connection with the CA, and
applies only to certiļ¬cates for which the decision as to how to update attributes relies
solely on the data disclosed in the showing protocol.
Stronger protection requires the use of smartcards or other tamper-resistant de-
vices. These can be programmed to show certiļ¬cates in the order in which they were
retrieved, and can enter a suspension mode in case of tampering.

5.5.5 Guarding the secret key of the Certiļ¬cate Authority
In this section we describe measures to guard the CAā€™s secret key. Whether any or all
of these measures are actually necessary depends on the PKI at hand.

Elementary measures

To enforce personnel to behave according to guidelines, organizational controls are
needed. Examples are security clearance and background checks for new employees,
auditing, strict manufacturing and software development procedures, separation of
staff responsibilities, frequent change of assignments, and controlled initialization,
personalization, and distribution of devices. A discussion of these and other controls
is outside the scope of this book.
To raise the barrier to gaining access to the CAā€™s secret key, it is best generated
and stored within the conļ¬nes of a tamper-resistant device and never revealed to the
outside world (including the legitimate operators). This prevents CA personnel from
being extorted or tempted to misuse the key themselves. 6 The device could even be
programmed such as to restrain the rate of certiļ¬cate issuing to a single person or
location in a given time frame.
For CA devices, it is entirely cost-effective and feasible to achieve very strong
tamper-resistance, because in contrast to smartcards there are no tight size and cost
constraints. CA devices can be made tamper-evident, can be riveted at a secured
location, and can maintain unmodiļ¬able audit logs revealing the exact date and time
of each task performed. Preferably, they meet at least security level 3 of FIPS 140-
2 [275], a U.S. federal standard on the security of cryptographic modules and a de
facto industry standard for commercial devices. Adherence to the Common Criteria
for Information Technology Security Evaluations (a voluntary international process
for developing test requirements, intended to replace ITSEC and other like standards)
is recommendable as well.
In addition, it may be desirable to distribute the CAā€™s secret key across multiple
tamper-resistant devices, and to use secret-sharing techniques to enable designated
subsets to perform the required cryptographic actions without leaking their respec-
tive shares.7 Techniques for shared signature generation are well-known in the cryp-
tographic literature, and can readily be adapted to the issuing protocols described in
Chapter 4; see also Section 4.2.3. The secret key of each tamper-resistant device is
best generated in a mutually random and veriļ¬able manner between the device and
its legitimate operators; this can be accomplished through standard cryptographic
To cope with cryptanalytic attacks on the CAā€™s secret key, the system design
should be based on strong underlying cryptographic primitives that have been pub-
licly scrutinized by experts for decades (such as factoring or computing discrete log-
6 Jakobsson and Yung [220], in the context of electronic cash, proposed to make each certiļ¬cate fully
traceable and clear each certiļ¬cate showing online with a central party whenever the CAā€™s secret key
has leaked or coins have been extorted. This approach leads to severe system disruption, destroys privacy,
does nothing to make extortion less attractive or to prevent it from reoccurring, and does not protect against
insider abuse.
7 CertCo and Spyrus, contracted in May 1997 by MasterCard and Visa to manufacture the CA system

for SET [257], were the ļ¬rst to adopt this technique in practice.

arithms). The techniques in this book are believed to meet this criterion. Rather than
using key sizes that are just a little beyond reach of currently known algorithms, key
sizes should be as large as possible without causing a serious performance devalua-
tion. In this respect, an elliptic curve implementation with keys that are not too short
offers a distinct advantage. The CA should update to larger key sizes on a regular
basis, and be prepared to do so in short term.

Stronger measures
When much is at stake, the CA should (in addition to the previous measures) enforce
deposit of all showing protocol transcripts (not necessarily online), and continuously
compare the number of certiļ¬cates issued against that of certiļ¬cates deposited. It
appears that none of todayā€™s commercial certiļ¬cate systems offer this provision, but
this will likely change once the parallels between digital certiļ¬cate systems and elec-
tronic cash systems are widely acknowledged.
This measure is not very effective in a large-scale PKI, because suspicion of
forgery does not arise until the number of forged certiļ¬cates approaches the number
of issued certiļ¬cates that have not yet been shown. The situation can be improved
by taking into account the issued and disclosed attributes of each certiļ¬cate. That
is, for each attribute property disclosed the CA should maintain a separate category
and compare a running count of each category with the number and combination of
attributes issued. In an electronic coin system, for instance, the bank should monitor
per coin denomination and per coin version.
In high-risk PKIs, the CA could encode random numbers from small sets into the
attribute certiļ¬cates it issues. Certiļ¬cate holders are in full control over the secrecy
of these attributes, but in case of strong suspicion of forgery, the CA can turn up the
heat by requiring veriļ¬ers to demand certiļ¬cate holders to reveal (part of) the encoded
random numbers; the CA should then announce that it will no longer honor deposits
from veriļ¬ers that do not abide by these rules. (Legislation should specify the condi-
tions under which such a revision of deposit rules is legitimate.) In this way, the CA
can dynamically shift between a positive list and a negative list approach; in the worst
case, certiļ¬cate holders are required to disclose a built-in identiļ¬er each time. (In this
fashion, our techniques cover the entire range between privacy-protecting certiļ¬cates
and identity certiļ¬cates.)
In a similar manner, the CA can dynamically set conditions for which types of
certiļ¬cates may be accepted off-line and which require its on-line approval.

Even stronger measures
In the presence of an attacker with ā€œinļ¬niteā€ computing power, these measures are
insufļ¬cient. A quantum computer, for instance, would be able to compute discrete
logarithms and factorize in about the same time as it takes to exponentiate large

numbers; see Shor [350]. Since forgery by an attacker with unlimited computing
power can never be prevented, the primary defense line is to contain the damages.
The ultimate containment measure, if all else fails, is system suspension. The CA
should make sure either that its certiļ¬cate issuance is no longer accepted or that it
can recognize and reject forged certiļ¬cates during online certiļ¬cate validation. The
CA can still accept online executions of the certiļ¬cate showing protocol by requir-
ing certiļ¬cate holders to disclose the identiļ¬ers that have been encoded into their
In addition, depending on the nature of the PKI, it may be necessary that all au-
thentic outstanding digital certiļ¬cates can be securely redeemed, to prevent a melt-
down scenario. This fall-back mechanism must be secure even in the presence of an
attacker with unlimited computing power. Preferably the fall-back mechanism can
be implemented by means of a protocol that does not require certiļ¬cate holders to
show up in person at the CA. To this end, the software-only return protocol that will
be described in Section 6.5.2 can be used.

5.6 Bibliographic notes
The techniques in Section 5.1.1 originate from Brands [54]. For an application, see
Brands [46, 48]; here, the issuing protocol serves to issue electronic coins that encode
an attribute representing the coin denomination (and possibly also an expiry date and
other data that must always be disclosed to payees) and an identiļ¬er attribute that
can be computed if and only if the coin is double-spent (using the static one-show
blinding technique).
The discussion of the delegation strategy in Section 5.1.2 is based on Brands [53].
The parallel delegation strategy described for the case of the immunized DLREP-
based scheme I in Section 4.4.2 was discovered by Schoenmakers [341, footnote 1];
the proposed measures to make this strategy ineffective are new, though. (In light of
this Schoenmakersā€™ remark on the insecurity of the second method of Brands [47]
for exchange rates must be nuanced. In fact, in the issuing and showing protocol de-
scribed by [47] the problem does not arise in the ļ¬rst place because parallel protocol
executions by different account holders are excluded.)
The anonymous recertiļ¬cation and updating techniques in Section 5.2.1 were in-
troduced by Brands [54], together with an application of the updating technique to
anonymous accounts in the off-line electronic cash system of Brands [46, 48]. Subse-
quently, Brickell, Gemmell, and Kravitz [62, 240] applied the anonymous updating
technique for the purpose of online change-making in the off-line electronic cash
system of Brands [48].
The techniques described in Section 5.2.2 are all based on Brands [54]. The ap-
plication to credential systems predates a credential system proposed by Chen [113],
which has many drawbacks over our proposal: Chenā€™s system offers only compu-

tational unlinkability, does not handle attribute certiļ¬cates and selective disclosure,
does not offer traceability of fraud with limited-show credentials, does not provide
for smartcard extensions (whereas we can apply the techniques that will be developed
in the next chapter), and uses an issuing protocol that is inferior to that described in
Section 4.5.2.
The techniques in Section 5.3 appear here for the ļ¬rst time.
The static and dynamic limited-show certiļ¬cation techniques in Section 5.4 are
based on Brands [45]. Some details have been ļ¬lled in, and the formal security
statements and their proofs are new.
Most of the security improvements in Section 5.5 originate from Brands [54].
The idea of discouraging lending of certiļ¬ed key pairs by encoding a special secret
that the certiļ¬cate holder wants to remain conļ¬dential (see Section 5.5.2) was in-
spired by the following remark by Garļ¬nkel [180] about identity certiļ¬cates: ā€œWhile
a few dozen guys might get together and share a single username and password for
a cybersex site, there is no way that any of these clowns will let the others share his
digital IDā€™s secret key, which will also unlock his bank account and credit cards.ā€ The
same observation has been used by Dwork, Lotspiech, and Naor [142], by Goldreich,
Pļ¬tzmann, and Rivest [192], by Sander and Ta-Shma [333] (to discourage lending in
the electronic cash system of Brands [46, 48]), and by Lysyanskaya, Rivest, Sahai,
and Wolf [253] 8 in the context of digital pseudonyms. However, none of these pub-
lications consider the remote lending problem that we will address in Section 6.5.3.
The non-repudiation technique in Section 5.5.3 originates from Brands [46, 48],
where it was applied in the context of off-line electronic cash.

8 The techniques in this book offer a much better solution; the advantages are the same as the advantages
over the credential system of Chen [113].


ńņš. 2
(āńåćī 2)