Abstract
Lossy trapdoor functions (LTFs) were first introduced by Peikert and Waters (STOC’08). Since their introduction, lossy trapdoor functions have found numerous applications. They can be used as tools to construct important cryptographic primitives such as injective one-way trapdoor functions, chosen-ciphertext-secure public key encryptions, deterministic encryptions, et al. In this paper, we focus on the lossy trapdoor functions in the presence of continuous leakage. We introduce the new notion of updatable lossy trapdoor functions (ULTFs) and give their formal definition and security properties. Based on these, we extend the security model to the LTFs against continuous leakage when the evaluation algorithm is leakage resilient. Under the standard DDH assumption and DCR assumption, respectively, we show two explicit lossy trapdoor functions against continuous leakage in the standard model. In these schemes, using the technology of matrix kernel, the trapdoor can be refreshed at regular intervals and the adversaries can learn unbounded leakage information on the trapdoor along the whole system life. At the same time, we also show the performance of the proposed schemes compared with the known existing continuous leakage resilient lossy trapdoor functions.
Highlights
Lossy trapdoor functions (LTFs) were firstly introduced by Peikert and Waters (STOC 2008) [1].A collection of lossy trapdoor functions can be divided into two computationally indistinguishable families
We introduce the new notion of updatable lossy trapdoor functions
We focus on the lossy trapdoor functions in the presence of continuous leakage
Summary
Lossy trapdoor functions (LTFs) were firstly introduced by Peikert and Waters (STOC 2008) [1]. The feature of a leakage resilient cryptosystem is that it remains secure even when some secret internal information, including the secret key, is leaked to the adversary. (1) the functionality of the cryptosystem is preserved even after updating the keys an arbitrary number of times; (2) one can not combine the leaked values from different versions of the secret key to break the system Such a model of invisible key updates was formalized by Alwen et al [22], where one assumes that there exists a trusted and leak-free device who uses some updatable key uk to continuously refresh the secret key in a way that still satisfies the above two requirements. In [17], they informally refer to this CLR model of invisible key updates as the floppy model where there is assumed an external leak-free storage that is only present for refreshing operations
Sign-in/Register to view highlights & summary Sign-in/Register to access full text options 
Free) 
Talk to us
Join us for a 30 min session where you can share your feedback and ask us any queries you have
Schedule a call
