Description
Tous les programmeurs s'attendent à ce que les compilateurs et autres outils de génération de code produisent du code exécutable qui se comporte exactement comme prescrit par le programme source. Ce n'est malheureusement pas toujours le cas : des bugs dans le compilateur peuvent conduire à la production de code machine incorrect à partir d'un source correct. Ce cas de figure est particulièrement préoccupant dans le cas de code critique qui a été vérifié (au niveau source) à l'aide de méthodes formelles (analyse statique, model checking, preuve de programme) : tout bug dans le compilateur peut potentiellement invalider les garanties obtenues à grand-peine grâce aux méthodes formelles.<br/> Après une introduction aux méthodes formelles et aux différentes manières de renforcer la confiance que l'on peut avoir dans un compilateur, l'exposé détaillera l'une de ces manières : la preuve de programme appliquée directement au compilateur lui-même, avec pour but de prouver que le comportement du programme source est préservé par toutes les passes du compilateur. Je présenterai les premiers résultats du projet Compcert : une expérience de développement et de preuve de correction, utilisant l'assistant de preuves Coq, d'un compilateur modérément optimisant pour un sous-ensemble du langage C. Ces premiers résultats sont encourageants et suggèrent, à plus long terme, que la vérification formelle d'outils intervenant dans la production et la certification de codes critiques est faisable.
Next sessions
-
On the average hardness of SIVP for module lattices of fixed rank
Speaker : Radu Toma - Sorbonne Université
In joint work with Koen de Boer, Aurel Page, and Benjamin Wesolowski, we study the hardness of the approximate Shortest Independent Vectors Problem (SIVP) for random module lattices. We use here a natural notion of randomness as defined originally by Siegel through Haar measures. By proving a reduction, we show it is essentially as hard as the problem for arbitrary instances. While this was[…] -
Attacks and Remedies for Randomness in AI: Cryptanalysis of PHILOX and THREEFRY
Speaker : Yevhen Perehuda - Ruhr-University Bochum
In this work, we address the critical yet understudied question of the security of the most widely deployed pseudorandom number generators (PRNGs) in AI applications. We show that these generators are vulnerable to practical and low-cost attacks. With this in mind, we conduct an extensive survey of randomness usage in current applications to understand the efficiency requirements imposed in[…]-
Cryptography
-
-
Lightweight (AND, XOR) Implementations of Large-Degree S-boxes
Speaker : Marie Bolzer - LORIA
The problem of finding a minimal circuit to implement a given function is one of the oldest in electronics. In cryptography, the focus is on small functions, especially on S-boxes which are classically the only non-linear functions in iterated block ciphers. In this work, we propose new ad-hoc automatic tools to look for lightweight implementations of non-linear functions on up to 5 variables for[…]-
Cryptography
-
Symmetrical primitive
-
Implementation of cryptographic algorithm
-
-
Algorithms for post-quantum commutative group actions
Speaker : Marc Houben - Inria Bordeaux
At the historical foundation of isogeny-based cryptography lies a scheme known as CRS; a key exchange protocol based on class group actions on elliptic curves. Along with more efficient variants, such as CSIDH, this framework has emerged as a powerful building block for the construction of advanced post-quantum cryptographic primitives. Unfortunately, all protocols in this line of work are[…] -
Endomorphisms via Splittings
Speaker : Min-Yi Shen - No Affiliation
One of the fundamental hardness assumptions underlying isogeny-based cryptography is the problem of finding a non-trivial endomorphism of a given supersingular elliptic curve. In this talk, we show that the problem is related to the problem of finding a splitting of a principally polarised superspecial abelian surface. In particular, we provide formal security reductions and a proof-of-concept[…]-
Cryptography
-