 Hi everyone, this is Yuchen, I am very happy to present our paper entitled Hierarchy Integrated Signature and Encryption. This is a joint work with Qiangtang and Yu Yu Wang. We will start with the background. Then introduce our new notion called Hierarchy Integrated Signature and Encryption. Then discuss its extension with global SQL property. Finally, we make a comparison between related schemes. PKE and signature workhorse primitives that are typically used simultaneously to secure communication, namely public encryption protects confidentiality, while signature protects authenticity. Examples including secure communication software such as PGP and WhatsApp and privacy-preserving cryptocurrencies such as Zcash, ZZ and PGC. A subtle issue is that when PKE and signatures are used together, we need to consider joint security. More precisely, we stipulate that EUFC main security for the signature component still holds even in the presence of an additional decretion oracle. While the INDC security for the PKE component still holds even in the presence of an additional signing oracle. Basically, there are two principles when using PKE and signature together. The key separation principle is best illustrated by the Cartesian product combined public key scheme, namely signature and public encryption use independent key pairs. This is also a widely accepted engineering folklore using different key pairs for different cryptographic operations. The advantages of key reuse is that the joint security is immediate, the construction is off-the-shelf and it naturally admits individual key escrow, which is a vital practice that helps to achieve a balance between users' authenticity requirement and the society's auditing requirement. The disadvantage of key reuse is it doubles key management complexity and certificate cost and makes the design of high-level protocol more sophisticated. We highlight that certificate cost includes but not limited to registration, ensuing, storage, transmission, verification and building and recurring fees. The key reuse principle stipulates that signature and public encryption components use the same key pair. We refer to such a scheme as integrated signature and encryption abbreviated as ISE, the advantage of key reuse is it reduces key measurement complexity, certificate cost and cryptographic footprint and simplifies the design of high-level protocol. The disadvantage of key reuse is that joint security is not immediate and thus requires careful design and it does not admit individual key escrow and classified protection of secret keys. In the real world, ISE that adheres to key reuse principle has been employed in EMV standard pin identity and equivalent currencies such as ZZ and PGC. As discussed above, we are facing a dilemma between key reuse that brings performance benefit and key separation that supports individual key escrow. An intriguing question is can we enable individual key escrow mechanism while retaining the merits of key reuse? To address this question, we propose a new cryptographic primitive called hierarchy integrated signature and encryption. In ISE, a single public key serves as verification and encryption key. While there is a hierarchy between the signing key and the decryption key, the signing key serves as the master secret key and can derive decryption key used only for decryption in a one-way manner. As to security, we require strong joint security. We require the INDCC security for the PK component remains even in the presence of a signing oracle, while the EFCM security for the signature component remains even the adversary got to see the entire decryption key rather than merely access to decryption oracle. ISE enjoys compact public key size. It helps to reduce key measurement complexity and simplifies the design analysis of high-level protocols. These merits make ISE suitable for scenarios that simultaneously require privacy, authenticity, and a key escrow. For example, INSISA and PGP individual user may need to delegate the decryption capability to a third party to outsource, cost operation, or for auditing purpose. If using ISE such a delegation will also compromise the security of signature. But if using HIC, the strong joint security of HIC ensures that one can safely delegate the decryption capability without breaching the security of signature. Next, we present two generic constructions of HIC. On Azure Crypt 2011, Pearson et al. gave an elegant ISE construction from IBE. Their main idea is to apply the NOR and theatrical transform to IBE simultaneously to achieve joint security. They use bit prefix trick to partition the identity space used to encode a message and tag. However, ISE from IBE does not lend itself to IHIC. This is because the master secret key plays the role of both secret signing key and the decryption key, and thus does not satisfy strong joint security. Our first HIC construction is largely inspired by the formation ISE construction from IBE. The main idea is still to apply the NOR and theatrical transform to IBE. The difference is that we set the master secret key as the signing key, while using secret keys for identities in space I1 as the decryption key. A technical hurdle is that the decryption key should be shot, thus all secret keys for identities in space I1 must have a succinct representation. To guarantee this, we propose a new type of IBE called Constraint IBE for prefix predicates as the underlying primitive, which in turn can be built from binary tree encryption, which keeps the rest technical details here. The above general construction from Constraint IBE enjoys strong joint security in the standard model. But so far, there is no efficient construction of Constraint IBE in applications where INTCP security surface. A Y is willing to accept INTCP security. In the RAN work model, we have a much simpler and more efficient construction of IHIC from any IBE. As to instantiation, we can choose the Bonnet Franklin identity-based encryption as the starting point. Our second generic construction of IHIC is from PGE and ONI ZKPOK. The goal is to add signing functionality to PGE in a generic manner. In this way, we can bootstrap PGE in use to IHIC in a seamless manner. The idea is to create a hierarchy key structure via one-way function, as shown by this figure. We first pick a random B3 as the signing key, then maps it to the randomness R via a uniform one-way function. Finally, runs PGE's key generation algorithm with the randomness R to generate the public key and the decryption key. The encryption component of IHIC is simple, which is the same as the underlying public encryption. But we are facing the following technical hurdle when designing signature. First, note that the secret key is an unstructured B3. How to create a signing functionality? Second, to test strong joint security. The signature should remain secure even in the presence of the decryption key. Our solution is using general purpose public calling ZKPOK to prove knowledge of secret key with respect to public key. To make the security proof go through, we require relation R key to be leakage resilient one-way, given leakage R and thus certainly the decryption key. The minimal requirement on G of PGE's catching algorithm is target collision resistant. Now we can attend strong joint security. The security of signature component is implied by sigma protocol for leakage resilient one-way function. The security of public encryption component is based on the factors that the additional signing oracle is useless and the uniformity of F admits security reduction to the underlying public encryption. As to instantiation, we can choose ZK friend per se don't hash to realize uniform one-way function. Choose L gamma encryption to realize public key encryption and choose Spartan to realize ZKPOK. We notice that the bound construction is still less practical for real-world applications. The bottleneck lies at general purpose ZKPOK. They left more efficient instantiation as an interesting open problem. Then we describe an important extension of HIC with global SQL property. Nowadays, large scale collaborative working apps such as Slack is getting popular. Encrypted communication may contain proprietary information. On one hand, employers may have the right to get access to all private communication for various reasons. A nice solution is to collect the individual decryption key one by one. Clearly, this is impractical and inefficient. On the other hand, employees need to be assured that even a malicious employer cannot slander them by forging, launching signatures for fabricated communications. We further expected global SQL property. Namely, there is a super key that can decrypt any subtext encrypted under any public key. While signature remains secure even in the presence of the super key. To obtain global SQL property for HIC in a generic manner, we first take a detour to revisit global SQL public key encryption. In global SQL public key encryption, SQL Engine holds a global SQL decryption key that can decrypt subtext encrypted under any public key. Global SQL public key encryption is long overdue for formal definition and generic construction. The only practical scheme is the SQL Algamma PKE proposed by Bonet and Franklin from Bilania Maps. Here is the formal definition of global SQL public key encryption. It is basically the same as the ordinary public key encryption, except that there is an SQL agent to generate a key pair, in which the SQL public key is a part of global public permits. The SQL decryption key is the super key. The correctness stipulates, honest generated subtext decrypting to the same plaintext under the decryption key of SQL Center and Re-Receiver. We also require consistency, which stipulates no PPD adversaries can generate and uniform the subtext decrypting to different plaintext under EDK and SKR. One may think the construction of global SQL public key encryption is trivial, however, several attempts fail. For example, IBE does not directly lend itself to global SQL PKE, since in public key encryption, users must be able to generate the key pairs themselves. Broadcast encryption also fails, since in global SQL PKE, senders could be malicious, especially when they have incentive to invade oversight. Next, we present two generic constructions of global SQL PKE. Our first construction is from any public key encryption on EDK. The SQL Center simply generates a key pair himself to encrypt a plaintext AM, send encrypt it under Re-Receiver's public key and SQL Center's public key, respectively. Then a panel on EDK proved to prove that the two subtexts indeed encrypt the same plaintext. The above construction is exactly a new application of the Noyan transform beyond CC security. It gives a general approach to compile any public encryption to global SQL public key encryption. When it comes to instantiation, we can realize PKE with L-Gama PKE in EC groups and realize on EDK with Grocerhub Proof and Sigma Proof. Particularly, when PKE satisfies the RANDMIS fusion property, we can safely reuse RANDMIS and then apply twisted Noyan transform. Our second generic construction is from three-party N-IKE, namely non-intensive key exchange. The SQL Center simply generates a key pair himself to send a plaintext to Re-Receiver with PKE beta. The center runs three-party N-IKE in his head, namely first generate a temporary key pair PKE alpha SK alpha, then compute the shared key among PKE alpha, PKE beta, PKE gamma, and finally encrypt the plaintext with the shared key. Upon receiving the subtext, the receiver first recovers the shared key with his secret key, SK beta, then decrypt it with the shared key. The semantic security of global SQL PKE is implied by the security of N-IKE. The consistency is guaranteed if the public space of the underlying N-IKE is efficiently recognizable. Feastfully realized above generic construction with Rook's three-party N-IKE, we recover the only known player scheme, Bonnet Franklin SQL Agama. This is nice cause we can explain it in theory now. However, this scheme is rather efficient cause symmetry pairing is too slow. The original Rook's protocol inherently relies on symmetry pairing, thus a second attempt to improve efficiency is adapting Rook's protocol with asymmetry pairing. However, in the resulting global SQL public encryption, key and subtext size get doubled and the decryption is very expensive. Our insight is that a relaxed version of N-IKE surface for the construction of global SQL PKE. That is, the key pairs of N-IKE could be of different types and shared key could be agreed from different types key pairs. In light of this observation, we obtain an efficient global SQL PKE from asymmetry pairing. This is a technology roadmap of global SQL HIC. One can freely take any path from leaf node to the root node. Combine previous result. We present two instantiations. By applying twisted Noyan transform to HIC scheme 1, we obtain global SQL HIC scheme 1. By combining Poseidon hash and Spartan with global SQL PKE scheme 2, we obtain global SQL HIC scheme 2. At last, we make a comparison between combined public key scheme, IAC and global SQL HIC. From the table, we can see that global SQL HIC not only enjoys the benefit of key reuse, but also supports richer functionality, such as individual and global key SQL. We implement our concrete schemes in C++. The experimental result demonstrates our global SQL HIC scheme have comparable efficiency with the most efficient combined public key scheme and enjoying compact key size as well. As a product, we also obtain the most efficient global SQL PKE scheme to date, which beats the best previous known scheme with 12 to 13 times speed up. Let's summarize our talk. In this work, we put forward a new notion called HIC with formal definition and the generic constructions. Our notion hates a sweet balance and thus reconciles the apparent conflict between key separation and key reuse, resolving an open program left open in Eurocrypto 2001. It can be used as a chopping replacement of PKE plus signature in scenarios that require authenticity, confidentiality, and auditability simultaneously, and both users and authorities have incentives to deploy. We also extensively revisit global SQL public key encryption. Our results indicates a new application of the celebrated Noyan paradigm and also establish a novel connection from 3-part in IKE. That's the end of our talk. Thanks for your attention. Any questions?