 Hi, everyone. I'm going to introduce our work in titled Between Authentication List and Applications. I'm Haowen. This is a joint work with Chiang Tang. I'll begin with background and our motivations. To say this, let's take a quick look at anonymous authentication, which is a major class of list applications. In general, it allows the user Alice to sign a message on behalf of a group and the fire will be convinced this message was signed by someone in this group, but he cannot figure out who signed it. The anonymity is usually formalized via indistinguishability, but in literature, anonymity indeed have many variants according to adversaries' knowledge. The simplest case consider outsider anonymity. It considers an adversary that does not has any secret key of a group members. A stronger form is sometimes called selfless anonymity, which enables the adversary to have all secret key except the victim's secret key. And finally, the full anonymity, which considers the strongest adversaries that could really have all secret keys, including Alice's secret key and Bob's secret key. On the other hand, the anonymous signing functionality is insufficient in many scenarios. It's necessary to provide other desirable functionalities as well to make them easy to use. For example, the user may wish to detect case closure, claim her authorship of a previously signed document or clear herself from accusation when some bad guy signed something illegal on behalf of a group containing her. In more concrete examples, for example, the EPID signature provided by Inters SGX is designed to support revoking users and to the verifier side and the many other features. And similarly, enormously blacklisting invalid users without trusted sort of party is also needed. There are more examples to list and all of them have to lead to a trade-off of anonymous. To explain this in more detail, we notice that all of our functionalities are essentially built upon a very simple identification function. Namely, given the secret key, it allows identifying whether an anonymous signature was created using this secret key. It's easy to say that when adversary has the secret key, has a secret key of both Alice and Bob, she can run this identification locally and decide the real signer. Therefore, the full anonymity is out of reach and the things the selfless anonymity does not give the victim's secret key to the adversary. The adversary's thus cannot leverage this identification. Self-alonymity is the best possible privacy definition that is compatible with identification. Besides those anonymous authentication schemes mentioned before, the privacy with identification style primitives appear in many other topics. In privacy paths, it is used to establish a covered channel between CDM priveters to identify invalid users. In encryptions, the identification functionality is essential to enable searching encrypted data using plain tests, which is crucial for fast searching. Moreover, if a commitment supports identification, opening can be done by just presenting committed messages only. Such a commitment is even useful for instantiating RAM recalls in some settings. From a ticker way point of view, these primitives are popular because the compatible privacy is philosophically meaningful. It's protecting a secret against those who don't know it. However, all those primitives are conceptually close. They were independently studied in many seemingly unrelated domains and lack the unified view. And each has to be established from scratch and some of them indeed faces difficulties in designing. This is not the case for achieving privacy alone. We have a fundamental primitive, non-interactive zero knowledge, which is considered to be a source of privacy. NISC is a core of many anonymous authentication schemes. It can also be applied to enhance the security of many other fundamental primitives like encryption and commitments. The elegant formulation of NISC enables easy design and analysis of its applications. So when these anonymous authentications, encryptions and the commitments need to be augmented with the identification functionality, it's nature to ask, can NISC support identification and be the source of identification? Such that we can design and analysis other primitives in much simpler manner. In this work, we initial the study of NISC with the identification functionality. First, we formalize it as a new primitive. Since we define the soundness of definition identification, which makes it look like a message authentication scheme that uses this witness as its secret key, we term it by witness authentication NISC. We then give three modular constructions from basic primitives. And finally, we show the surprising power of this new primitive. We show how to use this primitive to give a very simple construction of a group signature supporting verifier local revocation. And we use it to construct plain test checkable encryption. And more interestingly, we show how this primitive can advance the existing non-manable hash constructions, which were presented to in Slash 8 and run model calls in some settings. Okay, now let's model this new primitive. In standard NISC, assuming a common reference string, a prover with a witness can create a single string called a proof to convince the verifier the statement is true. The identification functionality we consider is to enable identifying whether a proof is generated using a specific witness. And the three forward formulation is to take both proof and witness as inputs. However, in many applications, the witness is structured, it consists of secret and RAM codes. And the user is only supposed to have the secret and does not have the whole witness. To make the identification more useful, we abstract the notion of identifier witness, which is a part of witness, and the proof can be identified as being generated from witness that has this identifier. As a forward model here is incompatible with standard with identification, standard terminology is also incompatible with this identification. To say this, in this definition, the adversary could receive proofs or simulated proofs that were generated without using a witness. And the statement and the witness is chosen by the prover after saying the CRS. So the identifier witness will be loaned to the adversary. If there is an identification functionality, the adversary can leverage this function to distinguish the real proofs and the simulated proofs. So the standard terminology is out of reach. We have to rule out the case that the adversary knows the identifier. So the only possible definition is to defend our adversaries without knowing the identifier. However, it's very tricky to model without knowing things in the context of NIST. First, as we consider long-uniform adversaries, they may already encode in arbitrary prior knowledge in their advisory strings. And we cannot decide whether this advisory has encoded some of the identifiers. Secondly, sending information about identifiers is always available to adversaries. And at least the statement itself can be considered as sending information about the identifier. And finally, and most importantly, NISTs usually consider adaptive adversaries which could choose the statement and witness after saying CRS. If we don't take adaptiveness into consideration, the result primitive may not be as useful as standard NISTs. We address above challenges by introducing unpredictable samples into their knowledge definition framework. The unpredictable sample is a randomized algorithm outputting a statement, an identifier part of witness and the non-identifier part. Since the statement is always available to adversaries, we require that the probability of finding the identifier given the statement is very small. We can measure the unpredictability using unpredictability entropy. Then the adversary can query the proven oracle using a sampler instead of a concrete statement and the witness. And the proven oracle will sample a statement and the witness using the sampler and generate real proofs or simulation proofs according to the sample result. Note that the adversary can affect the sampler after saying the CRS and she can know actually knowledge about the sampler as long as the final identifier is unknown is still unpredictable to her. So this formulation is compatible with identification functionality and it preserves the adaptiveness as much as possible. There are other subtleties to be addressed. The first question is how to model proofs from same or related statements. This question is due to then now adversaries can only issue samples that won't give the same statements in different invocations. Our solution is first to require a slip for proven oracle, which stores the previously sample result and allow the adversary to query with another extended sampler, which can send the previous samples into same or related ones. The second question is more subtle. That is some samplers are not unpredictable alone, but unpredictable with respect to external trust parameter generation procedure. This is due to NISCs is usually used and used as a building block in the larger crypto systems. And when we consider an average case definition, we have to take eternal procedures into consideration. So we introduce trust parameters generation procedures to model this and allow this kind of a samples. Putting all these discussions into our together, we can give the final definition for entropic zero-knowledges. To become compatible with identification, we have defined entropic zero-knowledge. And for identification itself, we also needed to augment some NISC to define the functionality in prints of malicious users. The first intuition we seek to capture is that no one can avoid being identified. That is, a valid proof must be identified by an identifier witness known to the prover. We model this by augmenting knowledge summaries and require the extractor to extract witness and the identifier witness from a valid proof. And the proof should be identified by the identifier. Therefore, authentication knowledge summaries clearly subsumes standard knowledge summaries. Next, what we want to capture is that no one can frame others. It's a message, authentication like definition. The adverse goal is to forge a proof being identified by an unknown witness if even after seeing many proofs from those witness. This is why we call this primitive witness authentication knowledge, NISCs. The last summary definition is the identifier units. The capture the invisibility of finding one proof identified by two distinct identifiers. This definition is useful when the adversary tries to generate a valid proof being identified by a string which is not even witness identifier. And we note for single applications, it may not need all these summaries definitions, but we provide them to enable various applications. We have formalized this new notion. Now let's construct it. The overall idea is to identify a tag to NISC proof. The NISC proof shows the truthfulness of the statement and the tag is honestly generated. For achieving properties of the witness authenticating NISC, the tag should satisfy many similar conflict properties. First, it should be identifiable and it also should be unfurgeable and dissimilatable even the input is just unpredictable. And if we need identifier uniqueness, this tag should also be unique. That is, it cannot be identified with respect to distinct distinct input. After all this all preservation, we find the remorocles match all this requirement. But unfortunately, we don't know how to prove in their knowledge that a remorocle based attack is honestly generated. So we have to find the other ways. We start with a simple case where the identifier is a pseudo-rand condition on all public information. We know it's possible in a non-rust authentication. And in this case, we can simply use a pseudo-rand function and all properties can be easily verified. For a general case that the identifier is non-uniform condition on all public information. We cannot directly use the identifier as a PRFK. A simple solution is using RAMListractor to convert the identifier into a PRFK by examining the properties. So identifiability and the uniqueness can be easily satisfied from underlying properties. But similitability and unfurgeability, which originally depend on through Vietnamese, now have to require the extractor to output a pseudo-rand string to be a PRFK. This requirement seems very trivial and first glance from the property of the RAMListractor, but it's not in this case. First, as we consider, as we allow adversaries to have multiple proofs from the same identifier, we have to require the extractor. And if we put the seed and the part of the tag, we have to require the extractor to be reusable. That is produce pseudo-rand least with many different states. However, reusability is a very long-travel property of a RAMListractor. And the unfurgeability considers malicious users it may not choose a seed from uniform distribution. So the output of the extractor cannot be guaranteed to be pseudo-random, but fortunately, as we are in the CRS model, we can leverage the CRS as a seed where put the seed into CRS. So we can use the same seed seed for all tags and the seed must be good for sure. And then we can give a secure tag generation. But however, the extractor needs seeds independent of source. Putting seed into CRS, we are all in work for CRS independent samples. Our goal is to have a full-fledged construction for CRS dependent samples. Let's recheck the challenges. For reusability, no one constructions require real entropy instead of unpredictability. Two against bad seeds. We don't even know how to define which seed is bad, which seed is good. This difficulty arises due to reuse RAMListractors to extract PRFK. And they may be solved, they might be solved if there is a strong variant of a RAMListractor. But however, we don't know how to achieve it yet. But from a takeaway point of view, we find we only need submitability instead of a pseudonymous. We don't really need to insist on using a PRF. We notice encryption is a large source of submitability and deterministic public encryption allows to identify. We can use a DPKE to construct the tag. And identifiability is easy to follow. Regarding submitability, we can use multi-user secure DPKE such that we can have the submitability across many different public case. But uniqueness and unfragability will require the goodness of public case. That is encryption algorithm with this public case should be an injection. But the public case is chosen by Provers. It left a question, how to deal with malicious PK? A solution is put into CRS, put the public case into the CRS, but it has to require the CRS independent samples again. Our observation is the goodness of public case, the algebraic. And we can enforce the goodness by cryptography instead of modeling. More precisely, we can ask needs proof, we can ask needs proof showing the goodness of the PK. And putting all together, we are putting a full-fledged construction. We remark our construction can be based on standard assumptions, including the linear assumptions. Finally, we show how to use our neutral to advance the state of the art of applications. We show concrete examples of long-malibar hash. It's a triplet. The caching algorithm outputs a public hash key. The evaluation algorithm maps an input to a hash value and the verification checks whether the hash value is from a specific input. The long-malibar hash should satisfy collision resistance perfectly one witness and the long-malibarity. The long-malibarity requires one can have more hash value into a really related hash value. The long-malibar hash is proposed to instantiate it in run work, but prior work, if the auxiliary information is leaked to the adversary, it had to use either long-standard assumptions or directly using run work. It left an interest question, can we have a long-malibar hash from standard assumptions? We give a simple construction for long-malibar hash using witness authentication risk. Intuitively, perfectly one witness is commitment with identification. We can add identification to commitment using witness authentication risk. And the long-malibar hash, the malibarity follows our unpredictability. We have these constructions and we just use a witness authentication need proof to demonstrate the commitment is well-formed and say to the committed message as identifier to support the identification functionality. Our construction can surely be from standard assumptions and for general and can handle general auxiliary information. We can also use witness authentication risk to prove well-formedness of public encryption separatists and set the message as identifier and obtain a plain test check of encryption, which is the first standard model construction for long-uniform messages. We can also use witness authentication proof to prove the group membership and to give a simple construction of a group signature with verify our local revocation. Our construction is the first to satisfy auxiliary input security. That is, the security properties are preserved even when the adversary have an arbitrary half-invert auxiliary information about secret case, which should provide a strong guarantee when the case leak. To have a conclusion, we carefully integrate identification functionality that has appeared in various primitives into NISC, one of the most fundamental primitives. We'll trace many subtle challenges to our secure constructions. As a result, we can give simple constructions to diverse applications and advance the state of the art in all these applications. We believe there are other features and functionalities that implicitly exist in seemingly unrelated domains and still lack a unified view. We left it to be explored how to study them in fundamental primitives like NISCs and the sex, that's all.