WO2000064088A1

WO2000064088A1 - Optimistic authenticator systems

Info

Publication number: WO2000064088A1
Application number: PCT/US2000/010398
Authority: WO
Inventors: David Chaum
Original assignee: David Chaum
Priority date: 1999-04-15
Filing date: 2000-04-17
Publication date: 2000-10-26
Also published as: AU4467200A; EP1163752A1

Abstract

A digital authentication system that can be used in place of signature schemes is disclosed. Instead of allowing the provider of the message to become convinced upon receipt that an authenticator is valid (2.4), as with signature schemes, it is optimistically assumed that the authenticating party does not cheat. Parties may wait until periodic audit during which the validity of all authenticators asserted to be valid, at showing and even at issuing, can be established with high probability. Nevertheless conventional digital signature techniques can be used to sign the authenticators at issuing, at least in batches, to provide a kind of proof for use if an authenticating party does cheat. One example application is for electronic cash protocols, for which additional techniques are disclosed. Another example application is for untraceable credentials systems, and again further techniques are also disclosed in the context of such credential applications.

Description

OPTIMISTIC AUTHENTICATΌR SYSTEMS

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to authentication and transaction systems, and more specifically to secure and/or privacy protecting techniques suitable for electronic 3 commerce and including credential mechanisms.

2. Description of Prior Art

Priority is hereby claimed based on the United States Provisional Application, β by the present applicant, titled "Blind Authenticators," U.S. PTO 60/129380, dated 4/15/99.

Public-key digital signatures, being well known in the art, have the property that s anyone can verify them. In particular, when such a signature is received, it is almost always verified, often in the process of "recovering" the message content signed. The self-authenticating property of such signatures, that allows anyone to verify a 2 signature, has the known disadvantage for many applications of preventing the signer from exercising control over the verification of signatures. This problem has been addressed by so called "undeniable" and "private" signature schemes, which allow the s party "providing" the message signed to be convinced upon receiving the signature that it is valid and cannot later successfully be refuted. All these prior art techniques in effect "front-load" verification, by performing it at the time the signature is first s issued, either unilaterally by the provider of the message to be signed or, in the case of undeniable signatures, by an interaction between the provider and the authenticating party. In many applications, it may be sufficient and preferable to proceed 1 "optimistically" assuming that the authenticating party is not cheating, at least until problems arise or an efficient batch audit is conducted. Naturally, the ability to later construct irrefutable evidence of cheating by the authenticating party gives further 3 protection.

Applications, such as electronic cash and credential systems, as will be detailed later, have been imperfectly addressed by previous signature blinding techniques. For β instance, the showing of a blind signature coin has either required presentation of a unique public key and corresponding signature for each coin, or has been open to various cheating and inefficiencies. Similarly, known credential mechanisms have g been based on inefficient constructions and were unable to provide some desired functionality.

Accordingly, one object of the present invention is to allow an "authenticating 2 party" to issue authenticators without interaction with a "provider party", apart from any request that may be used, and for the provider party obtaining the authenticator to simply verify an ordinary digital signature on one or preferably a collection of s messages.

Another object of the invention is protocols that make it difficult for authenticators to be verified without the cooperation of the authenticating party. 8 Yet another object of the present invention is to offer the possibility of functionality related to that of blinding in blind signature schemes, where the supplier party can hide the correspondence between values supplied initially for authentication 1 and the subsequent verification of their authenticity.

Still another object of the invention is to allow the showing protocol of an electronic cash system to be secure and robust without the need for public keys and signatures per coin.

Yet a further object of the invention is to provide for so-called "credential" mechanisms, allowing the otherwise untraceable exchange of authenticators between 7 digital pseudonyms and without the need for cumbersome so called "cut-and-choose" protocols used in prior art systems.

And yet a further object of the invention is to allow users in a credential system o to have multiple pseudonyms of the same type. Still further objects of the invention include practical, efficient, and secure methods and means for achieving the other objects of the invention. 3 Other objects, features, and advantages of the present invention will be appreciated when the present description and appended claims are read in conjunction with the drawing figurers.

BRIEF DESCRIPTION OF THE DRAWING FIGURES

β FIG. 1 shows a combination flow-chart, block diagram, functional diagram, cryptographic and communication protocol diagram, and transaction processing schema for an exemplary embodiment in accordance with the teachings of the present 9 invention.

FIG. 2 shows a flowchart related to the embodiment of Fig. 1 and in accordance with the teachings of the present invention. 2 FIG. 3 shows a protocol notation for an exemplary credential system establishment protocol in accordance with the teachings of the present invention. FIG. 4 shows a flowchart for an audit mass proof of authenticator validity in s accordance with the teachings of the present invention.

FIG. 5 shows a set of flowcharts, 5a, 5b, and 5c for the overall function of an embodiment of a system in accordance with the teachings of the present invention.

BRIEF SUMMARY OF THE INVENTION

s This section introduces some of the basic ideas of the invention, but makes significant simplifications and omissions for clarity and should not be taken to limit its scope in any way; the next section presents a more general view. i In an optimistic authenticator system, an "authenticating party" is said to

"issue" items of information called "authenticators" to parties called "providers". Later, these authenticators, or values derived from them, are returned to the authenticating party and each is either "agreed" by the authenticating party to be a valid authenticator or not agreed. In a preferred embodiment, the authenticators are elements in a group where the so-called "discrete-log" problem is believed to be hard, such groups being well known in the cryptographic art. Also in these embodiments,

3 authenticators are formed by raising provided elements to a power secret to the authenticating party. Moreover, digital signatures are preferably used to commit the authenticating party to the authenticators issued and also those that are agreed or not e agreed. Also part of such embodiments are techniques allowing the authenticating party to convince others that digitally-signed sets of pair are in fact properly formed. Also shown are techniques for "blinding" authenticators, such techniques being

9 related to those known for various types of signatures, but also being unique in this context because of the lack of verification when received. To prevent multiple types of authenticators from being recognized when they are shown, novel blinding is 2 applied. The process for accepting a blinded authenticator, such as a coin in an electronic cash system, is also detailed in a way that could be adapted to blind signatures and overcomes problems with existing blind signature accepting protocols. s (One such problem is that the known technique of timeouts for supply of precursors to one-way functions can be abused by the system simply itself, or in collusion, requesting such intervals continually to the exclusion of the legitimate holder of the s signature.) Another exemplary embodiment shows how the values to be authenticated need not contain apparent redundancy, as is typical with signature schemes, but rather can be made known to the authenticating party in advance through a mix system 1 preserve privacy and unlinkability. (Improvements over known prior art functionality and efficiency are detailed later.)

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

A blind signature-like system, called a "blind authenticator" system, comprises a

"authenticating party" party that can compute a secret function, exponentiation by a secret power s in a group where discrete log is believed hard. A "payer" can obtain 7 such an s power on any group member by providing the number to be exponentiated to the authenticating party and compensating the authenticating party to make the authenticator (such as by allowing corresponding withdrawal from a checking account). A redundancy scheme is fixed for the system, such as the familiar one where valid numbers are the result of applying a fixed agreed function "h" to a "pre- image" number "p", where such h(p) is a member of the group. Before submitting a number to the authenticating party, it is first raised to a "blinding" power "b", yielding h(p)^b, where the payer can also readily compute the corresponding inverse power "c", such as the multiplicative inverse of b modulo the order of the group. When after payment this residue is received by the authenticating party, the authenticating party returns the result of applying the secret exponent s, h )¹^. Now the payer can remove the blinding by applying c, thus: (h(p)^bs)^c = h(p)^s.

At this point, the payer may wish to protect itself against the authenticating party claiming that the authenticator had already been received. One example known way to do this is to provide first a "commitment" to the values of p and/or the authenticator to the authenticating party; then the authenticating party is to provide a "conditional acceptance" or acknowledgement that this particular value has not been previously spent. Such a commitment might include other transaction data, such as the payee. Typically this conditional acceptance would carry a time "window" associated with it, being a range of times during which the payment will be accepted if sufficient additional information is supplied and it is verified. The window is used to prevent the authenticating party from permanently blocking a valid payment by claiming that it has already been committed. (There are many ways the amount and form of information can be varied between the "first phase" during which the initial payment message is sent and the "second phase" during which additional information is sent by the payer that allows the authenticating party to protect itself against false claims that it is falsely claiming authenticators have been spent previously.) Nevertheless, the timing approach does not actually work as detailed in the prior art. However, a novel inventive approach presented here works nicely by ensuring that payment can only be made to the desired payee without incurring any delay or using timeouts. This is detailed later with reference to the detailed preferred embodiment.

Now the payer wishes to convince the authenticating party that he has a valid "authenticator." This could be done, while preserving privacy, by simply showing both p and h(p)^s. (Another way to proceed would be to show only part of h(p)^s, a "restriction", such as some truncation or other type of information reduction based on the representation or another one-way function with a smaller image. In fact it is believed that only enough effective bits worth of the power would have to be shown to convince the authenticating party that a guessed value was sufficiently unlikely to succeed. If the bits are chosen carefully, such as being a prefix of a hash function applied to the usual encoding of the group element, then it might be that twenty to fifty bits might suffice, giving a corresponding low probability of successful cheating per attempt, depending on the penalty, up-front cost, or probability of penalty, of attempted cheating. Of course it should also be pointed out that the values of p, the p;, used could be generated cryptographically from a seed by the payer, and so would require almost no storage. Transmission costs could also be reduced — and storage size as well if regeneration is not used — simply by taking p from a set that is of sufficient size to reduce collision probabilities to an acceptable level.)

When a p, h(p)^s pair is shown in a "payment" transaction, the secret exponent s can immediately be applied by the authenticating party to h of the first component, and compared for equality with the second component. If they are equal, the authenticating party is believed to be able to be confident that the "coin" is validly signed. To prevent the same coin from being accepted in payment more than once, the authenticating party, in known fashion, can simply keep a list of those coins already accepted, referred to as "marking" the coin, and mark new coins atomically as they are accepted. Typically, the value p would be associated with the marked coin, which itself would be indexed (i.e. searchable by) the information readily deduced from the form shown in phase one. The payer may be concerned, in some settings, that the authenticating party will falsely claim that a authenticator is not valid or that it has been previously spent. If the claim is that the authenticator is not valid, then it will be possible in principle to prove that it is not valid without revealing the true authenticator, such as by using techniques developed in the context of undeniable signatures. An alternative would be simply to show the authenticator. This authenticator can then be verified, by known "zero-knowledge" or "minimum disclosure" proof techniques for instance. Of course this procedure assumes that the coin is marked as spent before the authenticator is revealed, so that the authenticator revealed cannot simply be spent. 3 Effective countermeasure to the threat that the authenticating party would falsely claim that a coin had already been spent, are known. For instance, instead of revealing p initially, the payer reveals k(p), a public one-way function applied to p; e the authenticating party commits to the fact that such an k(p) has not been previously accepted, and gives a time window during which no other such value will be accepted but during which the payer must provide the value of p and the authenticator. One 9 potential improvement on this would be that a prefix of the bit representation of p is provided first, and this is what is used as the key in the search for double spent coins where the whole value of p is stored. Later, once the authenticating party commits, 2 such as with a digital signature, to accepting the coin, then the full value of p can be revealed, and the transaction completed. Thus, if the authenticating party is presented with a prefix of p for an already spent coin, then all it has to do is make the full value s of p known at that point. Another potentially improved approach would be that the one-way function is applied to both p and the signature, f(p, h(p)^s). This way, if the authenticator is later revealed by the authenticating party in showing that the one 8 presented is invalid, the commitment signature by the authenticating party contains in effect a commitment, in the form of f(p, h(p)^s), to the purported authenticator. Of course a single one-way function need not be used, but this may be more convenient 1 and efficient and prevent certain attacks.

Of course the specific example of payments is arbitrary, and all the sorts of applications involving what could otherwise be accomplished by blind signatures could be envisioned. In fact, the result of the protocol can be a full digital signature. Similarly, the particular choice of a discrete-log underlying cryptosystem is just an example: any scheme where there is a commutative property sufficient to allow the 7 limited kind of "blinding" required here could readily be adapted. As has been pointed out in some examples, but would be generally appreciated by those of skill in the art, there are all kinds of ways to form one-way functions and/or restrictions and/or o commitments, to arrange message parts into messages, to combine and/or separate message parts, and/or to create protocols from these elements. Turning now to a detailed description of an exemplary preferred embodiment, reference is made to the protocols diagram Fig. 1 and the flow chart Fig. 2. The large

3 arrows in Fig. 1 show messages between the payer on the left and the authenticating party on the right. The notations in the margins show actions by the party on that side, those on the right for the payer and those on the left for the authenticating party. β Square brackets enclose the message numbers, to be described in more detail. The equal sign "=" is also used to denote the assignment operator. Most values are shown implicitly as residues modulo a prime, as in much of the description.

9 Initially, the payer produces two values potentially at random, which may be physical, algorithmic, or a combination of random sources, involving one or more parties and/or keys. The first is p, the pre-image and payment number, which is a 2 group element as already mentioned. The second, b, is actually used as an exponent, and should ideally be chosen uniformly from the set of such exponents, related to the order of the group. This preparation shown in the left margin of Fig. 1 is not shown s for clarity as a step in Fig. 2.

The first message [1] in Fig. 1 is formed by the payer in two operations. First the public, fixed one-way function h is applied to the pre-image p. Second, the result of s the first operation is raised to the b power, of course within the group as is implicit and already mentioned. This message is sent to and received by the authenticating party (as with all such right-pointing arrows). Again, as this is a computation by the i provider, it is not shown in Fig. 2.

The authenticating party may expect to receive something additional not shown for clarity as compensation for making the authenticator, as already mentioned. The authenticating party proceeds in two parts. First, the message [1] is raised to the authenticating party's secret power s, as already mentioned. Second, the resulting number is signed, denoted by the "sig" function application, by the authenticating 7 party using a public key or undeniable signature scheme, as are well known in the art, and not shown in Fig. 2 for clarity. The authenticating party typically knows the private key used to make the authenticator; the corresponding public key is typically 0 made public in an authenticated way. The resulting authenticator is provided by the authenticating party to and received by the payer, as with all such left-facing large arrows of Fig. 1.

3 At this point the payer may wait an arbitrary amount of time before proceeding.

As will be appreciated, multiple p's could signed in parallel as a batch, and the single signature could apply to all of them. Also, hash or compressing functions can be e applied to the message content before signing as is well known. The payer may also wish to verify the signature received. Of course, for the comfort of the payer, it would be possible for the authenticating party to prove, in the zero-knowledge or minimum 9 disclosure sense, that the s power was really applied. But the protocols here create other kinds of protection for the authenticating party, to encourage the authenticating party not to require such proofs in ordinary operation. Of course the payment could 2 also simply be made instead to the payer's own account, and then new authenticators obtained later if the wait is too long. In particular, as will be appreciated, if the authenticating party is later able to send a valid [6b], as will be explained, the payer s may show the signature [2] and a pre-image under a one-way function (not shown or mentioned before for clarity) of b; this would substantiate the bad authenticator by the authenticating party. s At some point before making the payment, the payer must compute the inverse of b, which will be called c, such that applying c as an exponent to something that has b applied results in the cancellation of the two exponents. It is believed that this is 1 reasonably accomplished in the exemplary setting of a discrete log system of known prime order by computing c as the multiplicative inverse of b modulo the group order. This is indicated in the left margin as a computation made by the payer. The next 4 computation made by the payer shown is that the one-way and/or hash function f is applied to a pair of arguments. The first argument is simply p. The second is the "unsig" of message [2], the quantity raised to the c power. The "unsig" notation refers 7 to the widely known property of message recovery from signatures, where, for certain signature schemes, in checking the signature or otherwise the value signed can be readily obtained. Also implicit is that the payer can, at its option or even based on 0 probabilities it assigns, verify and retain the signature by the authenticating party. This signature, if valid and retained, can be used later in case the authenticating party shows that the authenticator issued in message [2] was invalid, as mentioned above.

3 Message [3J] is the result of the last margin computation by the payer. It is the public one-way function f applied to the pair p and what should be the s power of h(p). Of course, if the authenticating party has returned an improper authenticator as β message [2], the form may differ, but this may be detected earlier or later, as has been mentioned. Message [3.2] is simply f applied to the pair p, "payee", where payee could, for instance, be the account identifier of the party to be paid. The intention is

9 that the payer is requesting that the authenticator is accepted with that value of payee. When [3J] is sent by the payer to the authenticating party, the authenticating party first makes a test. The authenticating party maintains a list of "marked" 2 messages; in other words these are the [3J]'s that have been received in payment or that are, as will be explained further below, blocked from being so accepted because the corresponding authenticators have been released without compensation. If the s message [3J] is already marked, i.e. it is not un-marked, then a fork in the flow of actions by the authenticating party is taken, as shown in box 2.2. Following this fork, two actions are taken. First the value of p associated with the marked message, as will s be described also later, is recovered from storage, as indicated in box 2.5. Second, two messages are sent by the authenticating party to the payer: [4b.1] and [4b.2], as indicated in box 2.6. As shown in Fig. 1, the first is simply the value of p associated 1 with the marked message and the second is the actual s power on the f of the associated p, that the authenticating party could store, but could also simply regenerate at this point (assuming authenticators are unique). The payer receiving this 4 message pair basically gives up: either the payer is honest, and then the payer becomes convinced that someone else has already chosen the same p; or the payer is trying to cheat and has sent the number in previously, hoping that the authenticating 7 party would forget, which it has not. The payer has essentially no recourse because no [4a] is held, as will be described. The flowchart of Fig. 2 ends at this point.

The main branch, of course, is that message [3J] has not been marked and the 0 authenticating party enters the next phase towards accepting the payment. First the authenticating party creates a "temp mark" for message [3J], as indicated in box 2.3. Such a temp mark, as will be appreciated, is completely separate from a mark. The temp mark is, as the name implies, temporary. It prevents any temp marked message

3 [3 J ] from being accepted as a message [3 J ] by the authenticating party without being so recognized and having certain cumulative [3.2] data associated with it. When the authenticating party will issue a [4a], as will be described, all associated [3.2]'s β will be included (preferably in a hashed form) within it. The temp mark is maintained by the authenticating party for a [3 J] until the corresponding [5] is accepted The main path continues in box 2.4 with message [4a] being formed and

9 returned by the authenticating party to the payer. This message is shown in Fig. 1 as a signature on two items. The first is the message [3J] submitted. The second is the corresponding [3.2]. 2 At this point, following the main path, the payer is to provide, as shown in Fig.

1, the value of p, the authenticator h(p)^s, and payee, as [5J] and [5.2], and [5.3] respectively. s Now the authenticating party in effect executes a three-way branch, as indicated in box 2.7. One fork is the main path, another corresponds to an invalid coin, and the third to an invalid f(p, payee). This last possibility, the "no" exit of box 2.8, results in 8 the process stopping, because the payer can clearly be seen by anyone to have failed to provide a consistent set of messages. The second path is where [5J] and [5.2] are seen by the authenticating party to be inconsistent, because the authenticating party 1 can take [5.1] and apply h and the secret power s and see that the result is not [5.2]. What is done in this case, as indicated in box 2.9, is that a proper value for [5.2] is generated (by the authenticating party from p, by again applying h and then raising to 4 the s power) and this value is used to create a proper [3J], by pre-pending p and applying f, and this value is marked and p is associated with it. This procedure prevents p from ever being accepted in payment again. Also, as shown in box 2J0, 7 [6b] is sent to the payer to prove that [3J] is invalid by showing the actual [3J], called x, is valid. Such a proof could, as mentioned earlier, be the known sort of zero- knowledge or minimum disclosure type of proof that f [5.2]) is related to x by the 0 same exponent as a public generator g is related to the authenticating party's public key g^s. (Where such public generators and public keys are well known in the art, such as with the ElGamal signatures).

3 The main path continues when all of [5.1], [5.2], and [5.3] pass the tests above, by following the "yes" branch from box 2.7. Then all that remains to do is to re-create the [3J] by applying f to [5J] concatenated with [5.2], to mark this, associating p e from [5 J], all as shown in box 2.11, and to send the receipt signature [6a], as depicted in box 2.12. This signature includes, for instance, the [5.2], the payee, and a time stamp.

9 Of course the specific example of payments is arbitrary, and all the sorts of applications involving what could otherwise be accomplished by blind signatures could be envisioned. Similarly, the particular choice of a discrete-log underlying 2 cryptosystem is just an example: any scheme where there is a commutative property sufficient to allow the limited kind of "blinding" required here could readily be adapted. As has been pointed out in some examples, but would be generally s appreciated by those of skill in the art, there are all kinds of ways to form one-way functions and/or restrictions and/or commitments, to arrange message parts into messages, to combine and/or separate message parts, and/or to create protocols from s these elements.

Another type of blinding is preferably also included, but has not been shown in the figures or described in detail yet for this embodiment in the interest of clarity in 1 exposition. This second type of blinding enters multiplicatively in the base, as opposed to in the exponent as with the first type already shown. The second type also uses an exponent, called c, which is preferably at least substantially or practically 4 independent of the other blinding key b, but could be related, such as by a one-way function where c = f(b). A pair of values g and g^s are typically and preferably made public by the authenticating party initially, to serve as a kind of public key. The 7 second type of blinding comprises multiplying the value supplied for authenticating by g^c and then dividing the result returned by the authenticating party by (g^s)^c. Thus, the preferred blinding, being the combination of the two types, would give an initial o message of the form g h(p)^b and the value returned by the authenticating party then would be of the form (g^ch(p)^b)^s, and the unblinding operation would include dividing out the (g^s)^Q factor, by multiplying by its multiplicative inverse, and raising the result to the power that is the inverse of b.

3 One reason this combined blinding is preferred is that it is believed to make it difficult, if not infeasible, for the authenticating party to in effect mark a value by using an exponent different from s in such a way that it can later be recognized. The e group structure preferably is known to be cyclic. If the authenticating party knows that the blinding is only of the first type, then it can "mark" a value provided for authentication simply by using an exponent different from s, and then it can recognize

9 the marked value simply by testing for the marking exponent when s does not work. Similarly, if only the second type of blinding is known to be used, then the authenticating party can simply multiply in a constant after the authenticator is made, 2 and test for this factor when it is checked. But it is believed that the combination of the two types of blinding, using different keys as already mentioned, can make such marking substantially infeasible. s Turning now to Fig. 3, a credential mechanism based on Mix networks will now be presented. Mix networks were proposed by the present applicant in "Untraceable Electronic Mail, Return Addresses, and Digital Pseudonyms," Communications of the 8 ACM vol. 24 no. 2, February, 1981, which is widely known in the cryptographic and computer security art and is included here by reference. The notation used in Fig. 3, is a way to formalize such techniques and related techniques. Although a description 1 using conventional formulas is often used, the more visual graphic notation used here is believed to convey as much, and in practice more, useful information and at the same time to be more clear and avoid unnecessary repetition and symbols. Anyone of 4 ordinary skill in the art could translate between the two.

Thus the present figure 3 will be considered as a formalism, like a formula, and for clarity will not be labeled with callouts. When uppercase letters denote public 7 keys, the corresponding lower-case letters denote the corresponding private keys. For instance, B is the public key related to private key b. Lowercase letters additionally denote temporary variables, such as random padding doubling as blinding keys like 0 "r". The downward arrows denote the direction of flow of the message shown immediately to their right. A message is shown mainly as a set of nested rectangles, each corresponding to a layer of encryption. The key used to form the encryption is shown in the circle on the right side of the message; the content of the message is

3 shown as the content of the rectangle. The variable appearing outside of the rectangles and circles denote those that would, or at least could, be known to the entities that send and/or receive the messages. In particular, the values on the left of the boxes are e carried along with the boxes and serve as the input, at the top, and output, at the bottom, of whole cascade. On the right are the public keys of the mixing parties.

What this figure depicts is the flow of a single "digital pseudonym" from a

9 person to a roster at organization y. As will be readily appreciated, many such digital pseudonyms would be established, with plural for each of plural people. One for each person might end up at each organization, thus establishing a single pseudonym for 2 each individual with each organization. (And the innermost block might also contain, not shown for clarity, a public key to be used by the pseudonym owner to authorize such things as showings of various predicates.) This is readily achieved by placing s one initial message from each person in the batch for each organization. Another simple case would be that each person obtains k pseudonyms, but all the pseudonyms are mixed up and indistinguishable as to owner, in a single huge batch (this may be s referred to as an "indistinguishable multiplicity"). More generally, then, for each class of organization, each individual would obtain a the same number of indistinguishable pseudonyms. For instance, each person might be able to have three pseudonyms with 1 banks, but only one with the driver license organization.

The first message shown, at the top of Fig. 3, as per the notation, indicates three nested layers of encryption, one to be stripped off by each of three organizations A, B, and Y, using their respective private keys a, b, and y, as the message travels through them, all as well known and described in the referenced article on Mixes. As each layer is stripped off, a blinding value is revealed. A pair of values is passed between 7 the successive stages of the mix, with the left-hand value being a single residue class or group element in the discrete log system. The initial value of this first component is simply the root value that would be present for all the pairs corresponding to the same o individual. The letter p is used, as in the payment system already described, simply for notational convenience. The first mix A uses its private key a to remove the outer layer and recover the blinding key r. Since this is the first mix, by convention, it applies the one-way 3 function to p (although this could have been done in advance, and would have made the operations by each mix the same). Then A applies the blinding key in the exponent and also a related key as the exponent on the public generator g, used in β establishing the public key of the system, as already described. The related key, shown as r', could be simply and preferably is an independent key sent concatenated with r, or the two could be algorithmically related, such as r' being a one way function 9 of r. Passed on to the second mix B are both this residue and the remainder of the nested encryption once the layer and the value r have been removed.

Much as with A, B removes the outermost layer of encryption using private key 2 b (unrelated to the blinding key used in Fig. 1 and Fig. 2, but denoted by the same letter for clarity) and recovers the blinding key s. The output of this second mix is then the nested block stripped back one more layer than received by B, and the s residue modified using the blinding key s. First the residue received is raised to the s power, and then this value is multiplied by g, as already described, raised to the other blinding key s' (which is related to s and r' is to r). 8 Again, in a similar way to B, Y transforms the input pair. This time, however, there is nothing left of the nested encryptions that can be passed on, only the blinding key t, which is of course not sent but used to further blind the residue. In particular, 1 the input residue is raised to the t power, and the result is multiplied by g raised to the t' power.

Now the person, who has presumably chosen r, s, and t, and formed the layered 4 mix message from them, can construct the output digital pseudonym as a power of g and a power of h(p), as would be obvious to those of skill in the art, just as described for the mixes. Thus, when the user receives a secret power authenticator on one such 7 pseudonym, used with one organization Y, the user can transform it into the same secret power on a second pseudonym, possibly used with a different organization Y'.

The exponent used to transform the h(p) power is calculated modulo the order of the 0 group as the inverse of the blinding exponent on the h(p) in the first pseudonym times the exponent on the h(p) in the second pseudonym. The factor formed as a power of g, including the secret exponent of the authenticating party, can be transformed by multiplying by the public key raised to the multiplicative inverse of the blinding

3 exponent used on the source pseudonym times the blinding exponent used on the destination pseudonym.

Turning now to Fig. 4, the way the correctness of a set of pairs is shown. The e pairs can be from the issuing side or the showing side. Issuing-side pairs comprise the raw value supplied by the provider as a first component and the authenticator issued by the authenticating party as the second component. Similarly, showing-side pairs

9 comprise the unauthenticated value as first component and the authenticator as second component. Both kinds of pairs can be combined in a single process, and including the public generator g and the public key that is the private power of it can be 2 included, but the example embodiment shown does not do so.

To "prove" to or convince anyone observing that the pairs are properly formed, first, as shown in box 4J, a hash value H is computed as a cryptographic function of s all the elements of all the pairs. This way, the authenticating party cannot manipulate any element without causing an unpredictable and large change in the hash H. The value H is then used to determine exponents for each component, as indicated in step s 4.2. This, as will be appreciated, would be done in a way that resembles each exponent being an independent random value, except that they are all chosen as disjoint parts of a suitable cryptographic sequence that is an expansion of H. Next, as 1 provided in box 4.3, each first element is raised to its power and the product of these is determined; similarly, each second component is raised to its power and their product is formed. As will be appreciated, there are known techniques for computing 4 such powers of products in substantially more efficient ways. Finally, in box 4.4, a conventional "proof can be given that the exponent relating the two products is the same as the exponent relating the generator g and the public key. Such proofs are well 7 known in the art.

Turning now to Fig. 5, the overall structure of an exemplary embodiment will be described. In particular, Fig 5a shows an overview for completeness of the 0 authenticator issuing process, already described in detail. First, in box 5Ja the provider party is shown supplying the raw value to be authenticated to the authenticating party. Not shown for clarity is a potential step during which the provider blinds the raw value responsive to blinding key information. Then, in box

3 5.2a, the authenticating party is shown, using its private key information to produce a corresponding authenticator. This is then returned to and received by the provider in box 5.3a, and, preferably at the same time, some way to hold the authenticating party e accountable for having issued the particular authenticator responsive to the particular raw value is used. One example, illustrated, is by means of a public key digital signature on the pair issued by the authenticating party. Another technique, also

9 known in the art, would be any of the various technologies known for notarization. Referring now to Fig. 5b, the first box 5Jb indicates that the provider may, if blinding has been applied in box 5Ja as already mentioned but not shown, then 2 unblinding would be performed by the provider after the authenticating operation by the authenticating party. When, as in box 5.2b, an authenticator is shown to the authenticating party, it is provided along with the raw value by the provider or an s intermediary party and received by the authenticating party or an agent having the needed keys. Then, and not shown for clarity, the authenticating party determines whether the authenticator is in fact valid a valid authenticator corresponding to the 8 raw value. In box 5.3b, the authenticating party makes its decision known regarding the purported authentic pair. Finally, in box 5.4b, the authenticating party commits somehow, such as by signature or by whatever notary technique, to the fact of 1 agreement or lack of agreement to the purported authentic pair.

Referring finally to Fig. 5c, various showings of validity and invalidity by the authenticating party are shown. For instance, one embodiment would have all three 4 types of proofs applied periodically: that the issued pairs are valid, 5Jc, that the agreed pairs are valid, 5.2c, and that the disagreed pairs are invalid, 5.3c. Of course, and as already mentioned, the first two could be combined and the last could be only on demand. Moreover, some embodiments might not require proofs without a party wishing them, or only partial or random audit might be used.

All manner of variations, equivalents, and adaptations can readily be conceived o by those of skill in the art. For instance, schemes in which no public key is used are possible, although blinding might be subject to detectable tracing. Or, all manner of multiple parties sharing or relying on other parties for use of keys can be substituted for single parties as described here. 3 While these descriptions of the present invention have been given as examples, it will be appreciated by those of ordinary skill in the art that various modifications, alternate configurations and equivalents may be employed without departing from the β spirit and scope of the present invention.

Claims

What is claimed is:

1. An optimistic authenticator method comprising the steps of:

3 supplying, by a supplier party to an authenticating party, a message to be authenticated; transforming said supplied message by the authenticating party using at least a e key secret to the authenticating party and the transformed; receiving the transformed plaintext authenticator by the supplier party; checking by the authenticating party that the authenticator corresponds to an ₉ acceptable plaintext and the authenticating party informing at least another party of the result.

2. In the optimistic authenticator method of claim 1: 2 transforming responsive to a secret key by the supplier a value before supplying it to the authenticating party; and re-transforming the transformed value by the supplier party applying at least s what should be an inverse transformation to the value received from the authenticating party before supplying the result to the authenticating party for checking. s 3. In the optimistic authenticator method of claim 1, forming by the authenticating party a public key digital signature on at least one pair of raw input value and purported authenticator value. 1 4. A coin spending protocol, comprising the steps of: providing, by a provider party to an authenticating party, in a first message, combined under a substantially one-way function, at values 4 depending on at least part of an authenticated form and a raw form of a coin; committing by a signature to accept at least one of potentially plural related 7 said first messages by the authenticating party conditional on at least part of both forms of the coin being revealed and the authenticator being valid; 0 supplying by the provider at least part of said raw and said authenticated form of the coin; and agreeing to accept the coin, by the authenticating party, once the authenticating party has verified the authenticator and raw coin. 3 5. In the coin spending protocol of claim 4, the authenticating party storing commitments to the raw coin combined with the designation of payee for each instance of the coin supplied, including: β retaining a list of all said kept coin and payee combinations related to each raw and said authenticated form of the coin received before said agreeing to accept the coin combination; 9 including in said commitment at least a compressed form of said list; and in said agreeing, including a determined one of the payees of the properly formed payees in the list. 2 6. A credential system comprising the steps of: establishing a set of values with an authenticating party such that plural users each have plural values and where which values corresponding to s which users is substantially hidden from the authenticating party; and receiving an authenticator related to one of the values by a user and the user s transforming it into an authenticator on one of the other values associated with that user and the authenticating party verifying that it is a valid authenticator on the other value. 1 7. In the credential system of claim 6, including partitioning the set of values into disjoint partitions such that for at least one of the partitions each user has the same number of values in that partition as every other user. 4 8. In the credential system of claim 6, including plural authenticating transformations, at least some of which correspond to particular credential types.

7