Results

**1 - 4**of**4**### Trusted Computing and Information Assurance Laboratory,Institute of Software,Chinese Academy of Sciences,Beijing,China

"... Abstract. K. Yoneyama et al. introduces the Leaky Random Oracle Model at ProvSec2008, which only considers the leakage of the hash list of a hash function used by a cryptosystem due to various attacks caused by implementation or sloppy usages. However, an important fact is that such attacks not only ..."

Abstract
- Add to MetaCart

(Show Context)
Abstract. K. Yoneyama et al. introduces the Leaky Random Oracle Model at ProvSec2008, which only considers the leakage of the hash list of a hash function used by a cryptosystem due to various attacks caused by implementation or sloppy usages. However, an important fact is that such attacks not only leak the hash list of a hash function, but also leak other secret states outside the hash list of a cryptosystem (e.g. the secret key). In most cases, an adversary may be more interesting in revealing these secret states. Therefore, the Leaky Random Oracle Model is very limited because it only considers the leakage of the hash list and does not consider the leakage of other secret states. In this paper, we present a new leakage model based on the Leaky Random Oracle Model. In our new model, both the secret states (secret key) and the hash list can be leaked. Furthermore, the secret key can be leaked continually. Hence, our new model is more universal and stronger than the Leaky Random Oracle Model and some other leakage models. Furthermore, we give a provable security public key encryption scheme which is IND-CCA secure in our new model.

### Impossibility Results for Leakage-Resilient Zero Knowledge and Multi-Party Computation

"... In [AGP14] Ananth et al. showed that continual leakage-resilient non-transferable interactive proofs exist when a leak-free input-encoding phase is allowed and a common reference string is available. They left open the problem of removing the need of a common reference string. In [BGJK12] Boyle et a ..."

Abstract
- Add to MetaCart

In [AGP14] Ananth et al. showed that continual leakage-resilient non-transferable interactive proofs exist when a leak-free input-encoding phase is allowed and a common reference string is available. They left open the problem of removing the need of a common reference string. In [BGJK12] Boyle et al. showed that for some interesting functionalities continual leakage-resilient secure computation is possible when leak-free interactive preprocessing and input-encoding phases are allowed. They left open the problem of removing the interactive pre-processing. In this work we study the above questions. Our main contribution shows that leakage-resilient black-box zero-knowledge is impossible when relying on a leak-free input-encoding phase only (i.e., without CRS/preprocessing). Additionally, we also show that leakage-resilient multi-party computation for all functionalities is impossible (regardless of the number of players assuming just one corrupted player) when relying only on a leak-free input-encoding phase (i.e., without CRS/preprocessing). Our results are achieved by extending a technique of [NVZ13] to prove lower bounds for leakage-resilient security. Indeed as in [NVZ13] we use leakage queries to run an execution of a communication-efficient protocol in the head of the adversary. Moreover, to defeat the black-box simulator we connect the above technique for leakage resilience to security against reset attacks.

### Cryptosystems Resilient to Both Continual Key Leakages and Leakages from Hash Functions

"... Abstract. Yoneyama et al. introduced Leaky Random Oracle Model (LROM for short) at ProvSec2008 in order to discuss security (or inse-curity) of cryptographic schemes which use hash functions as building blocks when leakages from pairs of input and output of hash function-s occur. This kind of leakag ..."

Abstract
- Add to MetaCart

(Show Context)
Abstract. Yoneyama et al. introduced Leaky Random Oracle Model (LROM for short) at ProvSec2008 in order to discuss security (or inse-curity) of cryptographic schemes which use hash functions as building blocks when leakages from pairs of input and output of hash function-s occur. This kind of leakages occurs due to various attacks caused by sloppy usage or implementation. Their results showed that this kind of leakages may threaten the security of some cryptographic schemes. How-ever, an important fact is that such attacks would leak not only pairs of input and output of hash functions, but also the secret key. There-fore, LROM is rather limited in the sense that it considers leakages from pairs of input and output of hash functions alone, instead of taking into consideration other possible leakages from the secret key simultaneously. On the other hand, many other leakage models mainly concentrate on leakages from the secret key and ignore leakages from hash functions for a cryptographic scheme exploiting hash functions in these leakage mod-