F★ for the massesNews from the F★ team! This blog covers new language features, general discussions, theoretical roadblocks, engineering challenges, and pretty much the daily life of any language implementor.
https://fstarlang.github.io/
Wed, 17 May 2017 09:30:44 +0000Wed, 17 May 2017 09:30:44 +0000Jekyll v3.4.3Teaching F*<p>Having to teach F* provides strong motivation to dust off the cobwebs
and tidy away long forgotten bread crumbs hidden deep down in
remote directories to make the language easier to
install and use. It is thus no coincidence that major releases have
been aligned with some of us going back to school after a long
summer of coding to step out there and present the newest features of
the language to a crowd of rowdy students.</p>
<p>The latest two occasions:</p>
<ul>
<li>
<p>a <a href="https://www.cs.bris.ac.uk/cryptoschool/">Summer School on Computer Aided Analysis of Cryptographic
Protocols</a> in Bucharest,
Romania, 13-14 September 2016 in which we had two days to teach
<a href="http://prosecco.gforge.inria.fr/personal/hritcu/teaching/bucharest-school-2016/">Verifying Cryptographic Protocol Implementations with
F*</a>.</p>
<p>Who would have thought that F* can be used to introduce students of
varying backgrounds to functional programming. This lead to the
<a href="http://prosecco.gforge.inria.fr/personal/hritcu/teaching/mpri-jan2017/slides/out/01/slides01.html#/sec-a-gentle-introduction-to-f-">Gentle introduction for F*</a>.</p>
<p>This was the first time we used the <a href="https://github.com/FStarLang/FStar/releases/tag/V0.9.4.0">universes
version of F*</a> for teaching and we thus had to updated the <a href="https://fstar-lang.org/tutorial/">F* tutorial</a>. We also played with docker builds to provide students with a preconfigured interactive mode, but most students stuck to the tutorial.</p>
</li>
<li>
<p>a MPRI course on <a href="https://wikimpri.dptinfo.ens-cachan.fr/doku.php?id=cours:c-2-30">Cryptographic protocols: formal and computational
proofs</a>
in which we could spend more time teaching <a href="http://prosecco.gforge.inria.fr/personal/hritcu/teaching/mpri-jan2017/">Program Verification with
F*</a>.</p>
<p>We for the first time taught low-Level stateful
programming with hyperStack. Warning, this is so new that it’s not
yet covered by the tutorial.</p>
</li>
</ul>
<p>It is no coincidence that both courses had a decidedly cryptographic
focus given that F* is the language of choice of
the <a href="https://project-everest.github.io/">Everest project</a>.</p>
<p>What features would you like to see included in future research
schools? And what do you think are the biggest stumbling blocks when
learning and teaching a hot-off-the-press research language like F*?</p>
Thu, 09 Feb 2017 21:40:00 +0000
https://fstarlang.github.io/general/2017/02/09/teaching-fstar.html
https://fstarlang.github.io/general/2017/02/09/teaching-fstar.htmlgeneralF* v0.9.4.0 released<p>The F* team is pleased to announce the release of
<a href="https://github.com/FStarLang/FStar/releases/tag/V0.9.4.0">F* v0.9.4.0</a>.
This is the culmination of exactly one year of hard work from a very
quickly expanding F* team. We’re not very good at keeping precise
change lists, but here are the main highlights of this release:</p>
<ul>
<li>Predicative hierarchy of universes with universe polymorphism</li>
<li>Uniform syntax between expressions and types allowing rich type-level computation</li>
<li><a href="https://www.fstar-lang.org/papers/dm4free/">Dijkstra Monads for Free</a></li>
<li><a href="https://github.com/FStarLang/kremlin">Extraction to C via KreMLin</a></li>
<li>New parser based on Menhir</li>
<li>New pretty printer for surface syntax and <code class="highlighter-rouge">fstar --indent</code></li>
<li>Changed default effect to Tot</li>
<li>Strict positivity check for inductives</li>
<li>New synatax for inductive type projectors and discriminators</li>
<li>Better semantics for module open and support for local opens</li>
<li>Better dependency analysis</li>
<li>Better error locations for Z3 failures</li>
<li>Replaced Z3 timeouts with machine independent resource limits</li>
<li>Cleaned up libraries and examples (a bit)</li>
<li>Improvements to interactive mode</li>
<li>Docker builds</li>
<li>Fixed a ton of bugs (<a href="https://github.com/FStarLang/FStar/issues?page=3&q=is%3Aissue+is%3Aclosed+closed%3A%222016-02-02+..+2017-02-02%22&utf8=%E2%9C%93">262 closed GitHub issues</a>)</li>
</ul>
<p>Enjoy the best F* release ever!</p>
Thu, 09 Feb 2017 11:13:00 +0000
https://fstarlang.github.io/general/2017/02/09/fstar-v0.9.4.0-released.html
https://fstarlang.github.io/general/2017/02/09/fstar-v0.9.4.0-released.htmlgeneralIntroducing KreMlin<p>The work we do these days on F* is often in service of
<a href="https://project-everest.github.io/">Project Everest</a>. The goal of Everest is
to verify <em>and</em> deploy a drop-in replacement for the HTTPS stack, the protocol
using which you are probably reading this page, securely (hopefully). So far,
we’ve been focusing most of our efforts in Everest on <a href="https://tlswg.github.io/tls13-spec/">TLS</a>,
the protocol at the heart of HTTPS.</p>
<p>Right now, I’m stuck in the
Eurostar back from our week-long meeting in Cambridge, UK, so it feels like a
good time to write down some thoughts about KreMLin, a new compiler backend that we’re
using in Everest, that
several of us have been working on over the summer, at MSR and INRIA.</p>
<p>As a reminder, Everest sets out to verify <em>and</em> deploy secure cryptographic protocols, starting with TLS 1.3.
<strong>Deploy</strong> is the salient part: in order to see people adopt our code, we not
only need to write and prove our TLS library, but also to</p>
<ul>
<li>make sure it delivers a level of performance acceptable for browser vendors,
and</li>
<li>package it in a form that’s palatable for a hardcode Windows developer that
started writing C before I was born.</li>
</ul>
<p>A TLS library can, roughly speaking, be broken down into two parts: the
protocol layer that performs the handshake (“libssl”) and the cryptographic
layer that actually encrypts the data to be transmitted (“libcrypto”). The
handshake connects to the server, says hi, agrees on which algorithms to use,
and agrees on some cryptographic parameters. Once parameters have been setup,
the cryptographic layer is responsible for encrypting the stream of data.</p>
<!--excerpt-->
<p>Experience shows that the performance of a TLS library most often boils down to
the performance of the underlying cryptography. The handshake is network-bound,
but when transmitting a big file, encryption needs to be fast. This means that
for Everest, we need super efficient cryptography. Fortunately, many smart
people have spent a lot of time and energy writing super-neat C implementations
that squeeze the last bit of performance out of your compiler. However, we wish
to write and verify our programs in F*, not C.</p>
<p>This is where KreMLin comes in. The workflow is as follows: one takes a neatly
optimized cryptographic routine, then translates it into F* syntax (“shallow
embedding”); using KreMLin, one extracts it back to C, but gets a verified
version that pretty much looks like the original. For instance, here’s a bit of
F* that implements the main entry point of Chacha20.</p>
<div class="highlighter-rouge"><pre class="highlight"><code>let rec counter_mode key iv counter len plaintext ciphertext =
if len =^ 0ul then ()
else if len <^ blocklen
then (* encrypt final partial block *)
begin
let cipher = sub ciphertext 0ul len in
let plain = sub plaintext 0ul len in
prf cipher key iv counter len;
xor_bytes_inplace cipher plain len
end
else (* encrypt full block *)
begin
let cipher = sub ciphertext 0ul blocklen in
let plain = sub plaintext 0ul blocklen in
prf cipher key iv counter blocklen;
xor_bytes_inplace cipher plain blocklen;
let len = len -^ blocklen in
let ciphertext = sub ciphertext blocklen len in
let plaintext = sub plaintext blocklen len in
counter_mode key iv (counter +^ 1ul) len plaintext ciphertext
end
</code></pre>
</div>
<p>One goes great lengths to prove the following properties of this piece of F*
code.</p>
<ul>
<li><strong>Memory safety.</strong> We model stack allocation in F* using a new <code class="highlighter-rouge">Stack</code> effect;
one may only allocate local mutable variables, or buffers on the stack. Every
buffer operation needs to prove that the buffer is still live, and that the
index is within bounds. For instance, in the code above, the calls to <code class="highlighter-rouge">sub</code>
take a pointer <em>into</em> one of these buffers, and verification happens behind the
scenes.</li>
<li><strong>Functional correctness.</strong> We have written in this style a bignum library,
some elliptic curve operations, stream ciphers and mac algorithms, as well as
an AEAD construction. For the math part, for instance, the optimized curve
operations are shown to implement the correct mathematical operations.</li>
<li><strong>Cryptographic properties.</strong> By using a technique called “idealization”, one
can prove two versions of the same code: one that relies on cryptographic
assumptions, such as “this function can be replaced by a function
that returns random bytes”; and one that actually uses real cryptography
instead of <code class="highlighter-rouge">Random.bytes()</code>. The code branches on an <code class="highlighter-rouge">ideal</code> boolean; for
cryptographic proof purposes, we consider the <code class="highlighter-rouge">ideal</code> case; for extraction
purposes, we only consider the other, “real” case.</li>
</ul>
<p>F* already performs erasure and extraction for its OCaml backend; the tool I
wrote, <strong>KreMLin</strong>, takes it from there and performs further rewritings and
transformations so that the code ends up in a limited, first-order, monomorphic
subset of F* called Low*. If code falls within the Low* subset, then KreMLin
knows how to translate it to C. Here’s what comes out of the tool after
extraction:</p>
<div class="highlighter-rouge"><pre class="highlight"><code>void Crypto_Symmetric_Chacha20_counter_mode(
uint8_t *key,
uint8_t *iv,
uint32_t counter,
uint32_t len,
uint8_t *plaintext,
uint8_t *ciphertext
)
{
if (len == UINT32_C(0))
{
}
else if (len < Crypto_Symmetric_Chacha20_blocklen)
{
uint8_t *cipher = ciphertext + UINT32_C(0);
uint8_t *plain = plaintext + UINT32_C(0);
Crypto_Symmetric_Chacha20_prf(cipher, key, iv, counter, len);
Buffer_Utils_xor_bytes_inplace(cipher, plain, len);
}
else
{
uint8_t *cipher = ciphertext + UINT32_C(0);
uint8_t *plain = plaintext + UINT32_C(0);
Crypto_Symmetric_Chacha20_prf(cipher, key, iv, counter, Crypto_Symmetric_Chacha20_blocklen);
Buffer_Utils_xor_bytes_inplace(cipher, plain, Crypto_Symmetric_Chacha20_blocklen);
uint32_t len0 = len - Crypto_Symmetric_Chacha20_blocklen;
uint8_t *ciphertext0 = ciphertext + Crypto_Symmetric_Chacha20_blocklen;
uint8_t *plaintext0 = plaintext + Crypto_Symmetric_Chacha20_blocklen;
Crypto_Symmetric_Chacha20_counter_mode(key,
iv,
counter + UINT32_C(1),
len0,
plaintext0,
ciphertext0);
}
}
</code></pre>
</div>
<p>One can see that the tool goes great length to generate beautiful C: names and
control-flow are preserved, and everything is pretty-printed. This is to tackle
the second concern I mentioned initially: there is no hope of getting a browser
vendor to integrate code written in F*, which would be considered in that
setting “not a real language”. In constract, by offering an extracted C version
of our library, we have reasonable hope that reviewers can skim the code,
convince themselves that it’s legit, and take us a little bit more seriously.</p>
<p>We worked out a simulation between Low* and a simplified version of C we dubbed
“C*”; this grounds our translation in some theoretical basis. The simulation
covers trace preservation: if the program does not have side channels in the
first place, then the translation from Low* to C* does not introduce any new
side channels. The tool is unverified; we plan to extend the formalism to cover
more of the transformations performed by the tool; in the long run, I would like
to write KreMLin in F* and certify it, but that seems non-trivial.</p>
<p>We have adopted that style for an entire body of cryptographic code (> 10,000
lines of F*, including whitespace and comments), and obtain competitive
performance. Right now, the tool and formalism deal with one specific flavor
of code that performs stack-based allocation only. However, we are extending it
right now to deal with other patterns of allocation, such as allocation on the
heap.</p>
<p>KreMLin is currently written in OCaml; I re-used a fair number of tricks from my
earlier Mezzo project to make writing transformation passes on the internal AST
easier. These including monomorphization, inlining, hoisting and rewritings to
go from an expression language to a statement language, and some tricks to go
from the ML scoping rules to the C ones.</p>
<p>KreMLin is <a href="https://github.com/FStarLang/kremlin/">open-source</a>; we have an
<a href="https://jonathan.protzenko.fr/papers/ml16.pdf">ML’16 abstract</a> if you’re
curious, as well as some
<a href="https://jonathan.protzenko.fr/papers/talk-ml16.pdf">slides</a>.</p>
Fri, 30 Sep 2016 18:27:00 +0000
https://fstarlang.github.io/general/2016/09/30/introducing-kremlin.html
https://fstarlang.github.io/general/2016/09/30/introducing-kremlin.htmlgeneralWelcome to F*!<p>After many discussions, and in the spirit of the <a href="http://gallium.inria.fr/blog/">Gallium
Blog</a> (where I was a regular), the F* team is
happy to announce the F*-blog! Expect a variety of posts, ranging from technical
digressions about Dijkstra Monads to engineering discussions about parsing
technology, and pretty much anything in between.</p>
<p>One of our stated goals is to make F* more accessible to beginners; this
means making the setup easier, but also writing more documentation, so that
people who are <em>not</em> in the vicinity of the F* team can write programs, too.
We’ve started an effort on the <a href="https://github.com/FStarLang/FStar/wiki">wiki</a>;
the goal of this blog is to complement the wiki and make it easy for F*
enthusiasts to keep up with the development; be notified about breaking changes
on the <code class="highlighter-rouge">master</code> branch, and more generally make the development process more
open.</p>
<p>I expect that this blog will also cover related projects, such as
<a href="https://github.com/FStarLang/kremlin">KreMLin</a>, our F*-to-C translator, and
<a href="https://github.com/mitls/mitls-fstar/">miTLS</a>, our ongoing implementation of
TLS 1.3 in F*. Stay tuned! ☭</p>
Fri, 26 Aug 2016 20:36:05 +0000
https://fstarlang.github.io/general/2016/08/26/welcome.html
https://fstarlang.github.io/general/2016/08/26/welcome.htmlgeneral