IACR News
If you have a news item you wish to distribute, they should be sent to the communications secretary. See also the events database for conference announcements.
Here you can see all recent updates to the IACR webpage. These updates are also available:
27 July 2024
Input-Output Global
As a Cryptographic Engineer in Applied Cryptography, you will play a vital role in developing and implementing cryptographic solutions. You'll work alongside a team of talented individuals, contributing to various projects ranging from prototyping new cryptographic products to optimizing existing ones. You will collaborate closely with software architects, product managers, and other team members to successfully deliver high-quality cryptographic solutions that meet market demands.
You will need to have a strong foundation in engineering principles and a keen interest in cryptography. This role offers an exciting opportunity to work on cutting-edge technologies while continuously learning and growing in applied cryptography.
DutiesAs a Cryptographic Engineer, you'll play a pivotal role in implementing Zero-Knowledge (ZK) circuits tailored for integration within the Midnight chain. Your focus will involve leveraging recursive proof technologies, particularly those based on Halo2, to create proofs regarding the Midnight state. These proofs are designed to interface with other ecosystems, such as Cardano, providing a secure and efficient means to interact and exchange information across platforms. Your duties will include:
Closing date for applications:
Contact: Marios Nicolaides
More information: https://apply.workable.com/io-global/j/E68F9E4337/
University of Wollongong, Australia
Closing date for applications:
Contact: Prof. Willy Susilo
More information: https://www.uow.edu.au/about/jobs/jobs-available/#en/sites/CX_1/requisitions/preview/4659/?
Munich, Germany, 23 June - 26 June 2025
Submission deadline: 9 September 2024
Notification: 11 November 2024
Bhilai, India, 9 January - 11 February 2025
Submission deadline: 15 August 2024
Notification: 30 September 2024
Taipei, Taiwan, 8 April - 10 April 2025
Submission deadline: 25 October 2024
Notification: 6 January 2025
Toronto, Canada, 13 August - 15 August 2025
25 July 2024
JAIPUR, India, 16 December - 20 December 2024
Xinyi Ji, Jiankuo Dong, Junhao Huang, Zhijian Yuan, Wangchen Dai, Fu Xiao, Jingqiang Lin
Qianqian Yang, Ling Song, Nana Zhang, Danping Shi, Libo Wang, Jiahao Zhao, Lei Hu, Jian Weng
Peihan Miao, Xinyi Shi, Chao Wu, Ruofan Xu
We implement our protocols and compare them with the two-server PPML protocols presented in SecureML (Mohassel and Zhang, S&P'17) across various settings and ABY2.0 (Patra et al., Usenix Security'21) theoretically. We demonstrate that with the assistance of untrusted clients in the training process, we can significantly improve both the communication and computational efficiency by orders of magnitude. Our protocols compare favorably in all the training algorithms on both LAN and WAN networks.
Jianming Lin, Chang-An Zhao, Yuhao Zheng
Rafael Carrera Rodriguez, Emanuele Valea, Florent Bruguier, Pascal Benoit
Hugues RANDRIAMBOLOLONA
Since its introduction in 1978, this is the first time an analysis of the McEliece cryptosystem breaks the exponential barrier.
Amin Abdulrahman, Felix Oberhansl, Hoang Nguyen Hien Pham, Jade Philipoom, Peter Schwabe, Tobias Stelzer, Andreas Zankl
Zhengjun Cao, Lihua Liu
Nan Cheng, Aikaterini Mitrokotsa, Feng Zhang, Frank Hartmann
The Espresso Sequencing Network: HotShot Consensus, Tiramisu Data-Availability, and Builder-Exchange
Jeb Bearer, Benedikt Bünz, Philippe Camacho, Binyi Chen, Ellie Davidson, Ben Fisch, Brendon Fish, Gus Gutoski, Fernando Krell, Chengyu Lin, Dahlia Malkhi, Kartik Nayak, Keyao Shen, Alex Xiong, Na ...
S. M. Dehnavi, M. R. Mirzaee Shamsabad
Yaacov Belenky, Hennadii Chernyshchyk, Oleg Karavaev, Oleh Maksymenko, Valery Teper, Daria Ryzhkova, Itamar Levi, Osnat Keren, Yury Kreimer
In this study, we introduce a scheme, denoted STORM, that synergizes RAMBAM's methodology with the utilization of look-up-tables (LUTs) in memory (ROM/RAM) in a redundant domain. STORM, like RAMBAM, is as fast as a typical unprotected implementation and has the same latency, but has a significantly higher maximal clock frequency than RAMBAM, and consumes less than half the power. RAMBAM and STORM are code-based schemes in the sense that their set of representations is a code in the vector space $GF(2)^{8+d}$. RAMBAM requires a richer structure of a ring on $GF(2)^{8+d}$ and a ring homomorphism whereas STORM utilizes a simple vector space. In code-based-masking (CBM), as in all masking schemes, non-interference based notions (t-S/NI) are fundamental for establishing provable security. RAMBAM and STORM diverge from this approach. While CBM employs codes in vector spaces over $GF(2^8)$ for AES protection, RAMBAM and STORM use codes over $GF(2)$ without the need for t-S/NI-gadgets, leaving them both smaller and more efficient.
Independence in security proofs typically means that in each individual computation (in a clock-cycle), at least one share does not participate. This approach does not work for RAMBAM where several field multiplications are executed sequentially in a cycle. However, in STORM no multiplications are performed due to its memory based tables, leaving only (independent) bitwise-XORs. Therefore, the reasoning necessary for proving security is different and STORM, unlike RAMBAM, enjoys provable security. We consider two distinct scenarios, \emph{both with provable security}: (1) STORM1 --- ``leakage-free’’ memory reads, demonstrating (1,1,0)-robustness for LUTs with redundancy 2 in the 1-probe model and for LUTs with redundancy 6 in the 2-probe model, and (2) STORM2 --- leaky memory reads, where additional protection mechanisms and a notion of memory-read robustness are introduced.
STORM can be implemented not only in HW, but in SW as well. However, this paper and the proofs in it relate to STORM's HW implementations.
Roberto Avanzi, Orr Dunkelman, Kazuhiko Minematsu
MATTER is a 512-bit wide balanced Feistel network with three to six rounds, using the ASCON permutation as the round function. The Feistel network defines a keyed, non-tweakable core, which is made tweakable by using the encryption of the tweak as its key. Key and tweak are 320-bit inputs.
MATTER is particularly suitable for use in an OCB-like mode of operation, with an encrypted checksum for authentication.