Python's `str.__repr__()`
-Sometimes software is written using whatever built-ins you find in your programming language of choice. +
Sometimes software is written using whatever built-ins you find in your programming language of choice. This is usually great! However, it can happen that you depend on the precise semantics of those built-ins. This can be a problem if those semantics become important to your software and you need to port it to another programming language. diff --git a/articles/2024-08-21-OpenVPN-and-MirageVPN.html b/articles/2024-08-21-OpenVPN-and-MirageVPN.html index 0683731..b80adca 100644 --- a/articles/2024-08-21-OpenVPN-and-MirageVPN.html +++ b/articles/2024-08-21-OpenVPN-and-MirageVPN.html @@ -5,13 +5,13 @@
MirageVPN and OpenVPN
-At Robur we have been busy at work implementing our OpenVPN™-compatible MirageVPN software. -Recently we have implemented the server side. +
At Robur we have been busy at work implementing our OpenVPN™-compatible MirageVPN software. +Recently we have implemented the server side. In order to implement this side of the protocol I studied parts of the OpenVPN™ source code and performed experiments to understand what the implementation does at the protocol level. Studying the OpenVPN™ implementation has lead me to discover two security issues: CVE-2024-28882 and CVE-2024-5594. In this article I will talk about the relevant parts of the protocol, and describe the security issues in detail.
diff --git a/articles/2024-10-29-ptt.html b/articles/2024-10-29-ptt.html new file mode 100644 index 0000000..0c525a6 --- /dev/null +++ b/articles/2024-10-29-ptt.html @@ -0,0 +1,206 @@ + + + + + + +blog.robur.coop
++ The Robur cooperative blog. ++
Postes, télégraphes et téléphones, next steps
+As you know from our article on Robur's +finances, we've just received +funding for our email project. This project +started when I was doing my internship in Cambridge and it's great to see that +it's been able to evolve over time and remain functional. This article will +introduce you to the latest changes to our PTT +project and how far we've got towards providing +an OCaml mailing list service.
+A Git repository or a simple block device as a database?
+One issue that came up quickly in our latest experiments with our SMTP stack was +the database of users with an email address. Since we had decided to ‘break +down’ the various stages of an email submission to offer simple unikernels, we +ended up having to deploy 4 unikernels to have a service that worked.
+-
+
- a unikernel for authentication +
- a unikernel DKIM-signing the incoming email +
- one unikernel as primary DNS server +
- one unikernel sending the signed email to its real destination +
And we're only talking here about the submission of an email, the reception +concerns another ‘pipe’.
+The problem with such an architecture is that some unikernels need to have the +same data: the users. In this case, the first unikernel needs to know the user's +password in order to verify authentication. The final unikernel needs to know +the real destinations of the users.
+Let's take the example of two users: foo@robur.coop and bar@robur.coop. The +first points to hannes@foo.org and the second to reynir@example.com.
+If Hannes wants to send a message to bar@robur.coop under the identity of +foo@robur.coop, he will need to authenticate himself to our first unikernel. +This first unikernel must therefore:
+-
+
- check that the user
fooexists
+ - the hashed password used by Hannes is the same as the one in the database +
Next, the email will be signed by our second unikernel. It will then forward the +email to the last unikernel, which will do the actual translation of the +recipients and DNS resolution. In other words:
+-
+
- it will see that one (the only) recipient is bar@robur.coop +
- check that bar@robur.coop exists and obtain its real address +
- it will obtain reynir@example.com and perform DNS resolution on
+
example.comto find out the email server for this domain
+ - finally send the email signed by foo@robur.coop to reynir@example.com! +
So the first and last unikernels need to have the same information about our +users. One for the passwords, the second for the real email addresses.
+But as you know, we're talking about unikernels that exist independently of each +other. What's more, they can't share files and the possibility of them sharing +block-devices remains an open question (and a complex one where parallel access +may be involved). In short, the only way to ‘synchronise’ these unikernels in +relation to common data is with a Git repository.
+Git has the advantage of being widely used for our unikernels +(primary-git, pasteur, unipi and +contruno). The advantage is that you can track changes, modify +files and notify the unikernel to update itself (using nsupdate, a simple ping +or an http request to the unikernel).
+The problem is that this requires certain skills. Even if it's ‘simple’ to set +up a Git server and then deploy our unikernels, we can restructure our +architecture and simplify the deployment of an SMTP stack!
+Elit and OneFFS
+We have therefore decided to merge the email exchange service and email +submission into a unikernel so that this is the only user information requester.
+So we decided to use OneFFS as the file system for our database, +which will be a plain JSON file. This is perhaps one of the advantages of +MirageOS, which is that you can decide exactly what you need to implement +specific objectives.
+In this case, those with experience of Postfix, LDAP or MariaDB could confirm +that configuring an email service should be ‘simpler’ than implementing a +multitude of pipes between different applications and authentication methods.
+The JSON file is therefore very simple and so is the creation of an OneFFS +image:
+$ cat >database.json<<EOF
+> [ { "name": "din"
+> , "password": "xxxxxx"
+> , "mailboxes": [ "romain.calascibetta@gmail.com" ] } ]
+> EOF
+$ opam install oneffs
+$ oneffs create -i database.json -o database.img
+All you have to do is register this image as a block with albatross and launch +our Elit unikernel with this block-device.
+$ albatross-client create-block --data=database.img database 1024
+$ albatross-client create --net=service:br0 --block=database:database \
+ elit elit.hvt \
+ --arg=...
+At this stage, and if we add our unikernel signing incoming emails, we have more +or less the same thing as what I've described in my previous articles on +deploying an email service.
+Multiplex receiving & sending emails
+The PTT project is a toolkit for implementing SMTP servers. It gives developers +the choice of implementing their logic as they see fit:
+-
+
- sign an email +
- resolve destinations according to a database +
- check SPF information +
- annotate the email as spam or not +
- etc. +
Previously, PTT was split into 2 parts:
+-
+
- management of incoming clients/emails +
- the logic to be applied to incoming emails and their delivery +
The second point was becoming increasingly complex, however, and errors in +sending emails are legion (DMARC non-alignment, the email is too big for the +destination, the destination doesn't exist, etc.). All the more so since, up to +now, PTT could only report these errors via the logs...
+Hannes immediately mentioned the possibility of separating the logic of the +unikernel from the delivery. This will allow us to deal with temporary failures +(greylisting) as well. So a fundamental change was made:
+-
+
- improve the sendmail and
sendmail-lwtpackages (as well as proposing +sendmail-miou!) when sending or submitting an email
+ - improve PTT so that there are now 3 distinct jobs: receiving, what to do with +incoming emails and sending emails +
This finally allows us to describe a clearer error management policy that is
+independent of what we want to do with incoming emails. At this stage, we can
+look for the Return-Path in emails that we haven't managed to send and notify
+the senders!
All this is still in the experimental stage and practical cases are needed to +observe how we should handle errors and how others do.
+Insights & Next goals
+We're already starting to have a bit of fun with email and we can start sending +and receiving emails right away.
+We're also already seeing hacking attempts on our unikernel:
+-
+
- people trying to authenticate themselves without
STARTTLS(or with it, +depending on how clever the bot is)
+ - people trying to send emails as non-existent users in our database +
- we're also seeing content that has nothing to do with SMTP +
Above all, this shows that, very early on, bots try to usurp the identity linked +to your server (in our case, osau.re) in order to send spam, authenticate +themselves or simply send ‘stuff’ and observe what happens. In this case, for +all the cases mentioned, Elit (and PTT) reacts well: in other words, it simply +cuts off the connection.
+We were also able to observe how services such as gmail work. In addition, for +the purposes of a mailing list, email forwarding distorts DMARC verification +(specifically, SPF verification). The case is very simple:
+foo@gmail.com tries to reply to robur@osau.re. robur@osau.re is a mailing list
+to several addresses (one of them is bar@gmail.com). The unikernel will receive
+the email and send it to bar@gmail.com. The problem is the alignment between
+the From field (which corresponds to foo@gmail.com) and our osau.re server.
+From gmail.com's point of view, there is a misalignment between these two
+pieces of information and it therefore refuses to receive the email.
This is where our next objectives come in:
+-
+
- finish our DMARC implementation +
- implement ARC so that our server notifies us that, on our side, the DMARC +check went well and that gmail.com should trust us on this. +
There is another way of solving the problem, perhaps a little more problematic,
+modify the incoming email and in particular the From field. Although this
+could be done quite simply with mrmime, it's better to concentrate on
+DMARC and ARC so that we can send our emails as they are and never alter them
+(especially as this will invalidate previous DKIM signatures!).
Conclusion
+It's always satisfying to see your projects working ‘more or less’ correctly. +This article will surely be the start of a series on the intricacies of email +and the difficulty of deploying such a service at home.
+We hope that this NLnet-funded work will enable us to replace our current email +system with unikernels. We're already past the stage where we can, more or less +(without DMARC checking), send emails to each other, which is a big step!
+So follow our work on our blog and if you like what we're producing (which +involves a whole bunch of protocols and formats - much more than just SMTP), you +can make a donation here!
+ +Runtime arguments in MirageOS
-TL;DR: Passing runtime arguments around is tricky, and prone to change every other month.
+TL;DR: Passing runtime arguments around is tricky, and prone to change every other month.
Motivation
Sometimes, as an unikernel developer and also as operator, it's nice to have some runtime arguments passed to an unikernel. Now, if you're into OCaml, diff --git a/articles/dnsvizor01.html b/articles/dnsvizor01.html index a5cdafe..fbc488f 100644 --- a/articles/dnsvizor01.html +++ b/articles/dnsvizor01.html @@ -5,13 +5,13 @@
Meet DNSvizor: run your own DHCP and DNS MirageOS unikernel
-TL;DR: We got NGI0 Entrust (via NLnet) funding for developing +
TL;DR: We got NGI0 Entrust (via NLnet) funding for developing DNSvizor - a DNS resolver and DHCP server. Please help us by sharing with us your dnsmasq configuration, so we can diff --git a/articles/finances.html b/articles/finances.html index 6f75ade..6fd86aa 100644 --- a/articles/finances.html +++ b/articles/finances.html @@ -5,13 +5,13 @@
How has robur financially been doing since 2018?
-Since the beginning, robur has been working on MirageOS unikernels and getting +
Since the beginning, robur has been working on MirageOS unikernels and getting them deployed. Due to our experience in hierarchical companies, we wanted to create something different - a workplace without bosses and management. Instead, we are a collective where everybody has a say on what we do, and who gets how diff --git a/articles/gptar.html b/articles/gptar.html index aeba524..e7cad44 100644 --- a/articles/gptar.html +++ b/articles/gptar.html @@ -5,13 +5,13 @@
GPTar
-At Robur we developed a piece of software for mirroring or exposing an opam repository. +
At Robur we developed a piece of software for mirroring or exposing an opam repository. We have it deployed at opam.robur.coop, and you can use it as an alternative to opam.ocaml.org. It is usually more up-to-date with the git opam-repository than opam.ocaml.org although in the past it suffered from occasional availability issues. I can recommend reading Hannes' post about opam-mirror. diff --git a/articles/lwt_pause.html b/articles/lwt_pause.html index f9fe6b3..0306e51 100644 --- a/articles/lwt_pause.html +++ b/articles/lwt_pause.html @@ -5,13 +5,13 @@
Cooperation and Lwt.pause
-Here's a concrete example of the notion of availability and the scheduler used +
Here's a concrete example of the notion of availability and the scheduler used
(in this case Lwt). As you may know, at Robur we have developed a unikernel:
opam-mirror. It launches an HTTP service that can be used as an
OPAM overlay available from a Git repository (with opam repository add <name> <url>).
MirageVPN updated (AEAD, NCP)
-Updating MirageVPN
-As announced earlier this month, we've been working hard over the last months on MirageVPN (initially developed in 2019, targeting OpenVPN™ 2.4.7, now 2.6.6). We managed to receive funding from NGI Assure call (via NLnet). We've made over 250 commits with more than 10k lines added, and 18k lines removed. We closed nearly all old issues, and opened 100 fresh ones, of which we already closed more than half of them. :D
+Updating MirageVPN
+As announced earlier this month, we've been working hard over the last months on MirageVPN (initially developed in 2019, targeting OpenVPN™ 2.4.7, now 2.6.6). We managed to receive funding from NGI Assure call (via NLnet). We've made over 250 commits with more than 10k lines added, and 18k lines removed. We closed nearly all old issues, and opened 100 fresh ones, of which we already closed more than half of them. :D
Actual bugs fixed (that were leading to non-working MirageVPN applications)
In more detail, we had a specific configuration running over all the years, namely UDP mode with static keys (no TLS handshake, etc.). There were several issues (bitrot) that we encountered and solved along the path, amongst others:
-
@@ -35,7 +35,7 @@
To avoid any future breakage while revising the code (cleaning it up, extending it), we are now building several unikernels as part of our CI system. We also have setup OpenVPN™ servers with various configurations that we periodically test with our new code (we'll also work on further automation thereof).
New features: AEAD ciphers, supporting more configuration primitives
-We added various configuration primitives, amongst them configuratble tls ciphersuites, minimal and maximal tls version to use, tls-crypt-v2, verify-x509-name, cipher, remote-random, ...
+We added various configuration primitives, amongst them configuratble tls ciphersuites, minimal and maximal tls version to use, tls-crypt-v2, verify-x509-name, cipher, remote-random, ...
From a cryptographic point of view, we are now supporting more authentication hashes via the configuration directive auth, namely the SHA2 family - previously, only SHA1 was supported, AEAD ciphers (AES-128-GCM, AES-256-GCM, CHACHA20-POLY1305) - previously only AES-256-CBC was supported.
NCP - Negotiation of cryptographic parameters
OpenVPN™ has a way to negotiate cryptographic parameters, instead of hardcoding them in the configuration. The client can propose its supported ciphers, and other features (MTU, directly request a push message for IP configuration, use TLS exporter secret instead of the hand-crafted (TLS 1.0 based PRF), ...) once the TLS handshake has been completed.
diff --git a/articles/miragevpn-performance.html b/articles/miragevpn-performance.html index 591b8f9..b6160f8 100644 --- a/articles/miragevpn-performance.html +++ b/articles/miragevpn-performance.html @@ -5,13 +5,13 @@Speeding up MirageVPN and use it in the wild
-As we were busy continuing to work on MirageVPN, we got in touch with eduVPN, who are interested about deploying MirageVPN. We got example configuration from their side, and fixed some issues, and also implemented tls-crypt - which was straightforward since we earlier spend time to implement tls-crypt-v2.
+As we were busy continuing to work on MirageVPN, we got in touch with eduVPN, who are interested about deploying MirageVPN. We got example configuration from their side, and fixed some issues, and also implemented tls-crypt - which was straightforward since we earlier spend time to implement tls-crypt-v2.
In January, they gave MirageVPN another try, and measured the performance -- which was very poor -- MirageVPN (run as a Unix binary) provided a bandwith of 9.3Mb/s, while OpenVPN provided a bandwidth of 360Mb/s (using a VPN tunnel over TCP).
We aim at spending less resources for computing, thus the result was not satisfying for us. We re-read a lot of code, refactored a lot, and are now at ~250Mb/s.
Tooling for performance engineering of OCaml
@@ -40,7 +40,7 @@ To better guide the performance engineering, we also developed discussing it in the OCaml community, and are eager to find a solution to avoid unneeded computations.Conclusion
-To conclude: we already achieved a factor of 25 in performance by adapting the code in various ways. We have ideas to improve the performance even more in the future - we also work on using OCaml string and bytes, instead of off-the-OCaml-heap-allocated bigarrays (see our previous article, which provided some speedups).
+To conclude: we already achieved a factor of 25 in performance by adapting the code in various ways. We have ideas to improve the performance even more in the future - we also work on using OCaml string and bytes, instead of off-the-OCaml-heap-allocated bigarrays (see our previous article, which provided some speedups).
Don't hesitate to reach out to us on GitHub, or by mail if you're stuck.
We want to thank NLnet for their funding (via NGI assure), and eduVPN for their interest.
-
diff --git a/articles/miragevpn-server.html b/articles/miragevpn-server.html
index 2e1250a..4a96fd1 100644
--- a/articles/miragevpn-server.html
+++ b/articles/miragevpn-server.html
@@ -5,13 +5,13 @@
-
+
Postes, télégraphes et téléphones, next steps + https://blog.robur.coop/articles/2024-10-29-ptt.html ++ https://blog.robur.coop/articles/2024-10-29-ptt.html +Tue, 29 Oct 2024 00:00:00 GMT + -
Meet DNSvizor: run your own DHCP and DNS MirageOS unikernel https://blog.robur.coop/articles/dnsvizor01.html @@ -47,6 +54,13 @@https://blog.robur.coop/articles/tar-release.html Thu, 15 Aug 2024 00:00:00 GMT
+ -
+
Testing MirageVPN against OpenVPN™ + https://blog.robur.coop/articles/miragevpn-testing.html ++ https://blog.robur.coop/articles/miragevpn-testing.html +Wed, 26 Jun 2024 00:00:00 GMT + -
qubes-miragevpn, a MirageVPN client for QubesOS https://blog.robur.coop/articles/qubes-miragevpn.html diff --git a/images/smtp.jpg b/images/smtp.jpg new file mode 100644 index 0000000..c974dcc Binary files /dev/null and b/images/smtp.jpg differ diff --git a/index.html b/index.html index fa0ae79..f7a7526 100644 --- a/index.html +++ b/index.html @@ -5,13 +5,13 @@- Robur's blogIndex + Robur's blog - Index - - - - + + + +@@ -20,21 +20,34 @@ The Robur cooperative blog. -RSS The Robur blog.
+RSS The Robur blog.
Essays and ramblings
-
+ + ++ +
+
-
2024-10-25 - Meet DNSvizor: run your own DHCP and DNS MirageOS unikernel
+ Meet DNSvizor: run your own DHCP and DNS MirageOS unikernel
The NGI-funded DNSvizor provides core network services on your network; DNS resolution and DHCP.
- + -
@@ -44,10 +57,10 @@
2024-10-22 - Runtime arguments in MirageOS
+ Runtime arguments in MirageOS
The history of runtime arguments to a MirageOS unikernel
- + -
@@ -57,10 +70,10 @@
2024-10-21 - How has robur financially been doing since 2018?
+ How has robur financially been doing since 2018?
How we organise as a collective, and why we're doing that.
- + -
@@ -70,10 +83,10 @@
2024-08-21 - MirageVPN and OpenVPN
+ MirageVPN and OpenVPN
Discoveries made implementing MirageVPN, a OpenVPN-compatible VPN library
- + -
@@ -83,10 +96,23 @@
2024-08-15 - The new Tar release, a retrospective+
+ The new Tar release, a retrospective
A little retrospective to the new Tar release and changes
- + ++ -
+ + ++
+
+ 2024-06-26 + Testing MirageVPN against OpenVPN™
+Some notes about how we test MirageVPN against OpenVPN™
++ -
@@ -96,10 +122,10 @@
2024-06-24 - qubes-miragevpn, a MirageVPN client for QubesOS
+ qubes-miragevpn, a MirageVPN client for QubesOS
A new OpenVPN client for QubesOS
- + - @@ -109,10 +135,10 @@
-
@@ -122,10 +148,10 @@
2024-04-16 - Speeding up MirageVPN and use it in the wild
+ Speeding up MirageVPN and use it in the wild
Performance engineering of MirageVPN, speeding it up by a factor of 25.
- + - @@ -135,10 +161,10 @@
-
@@ -148,10 +174,10 @@
2024-02-13 - Speeding elliptic curve cryptography
+ Speeding elliptic curve cryptography
How we improved the performance of elliptic curves by only modifying the underlying byte array
- + -
@@ -161,10 +187,10 @@
2024-02-11 - Cooperation and Lwt.pause
+ Cooperation and Lwt.pause
A disgression about Lwt and Miou
- + -
@@ -174,10 +200,10 @@
2024-02-03 - Python's `str.__repr__()`
+ Python's `str.__repr__()`
Reimplementing Python string escaping in OCaml
- + -
@@ -187,10 +213,10 @@
2023-11-20 - MirageVPN updated (AEAD, NCP)
+ MirageVPN updated (AEAD, NCP)
How we resurrected MirageVPN from its bitrot state
- + -
@@ -200,10 +226,10 @@
2023-11-14 - MirageVPN & tls-crypt-v2
+ MirageVPN & tls-crypt-v2
How we implementated tls-crypt-v2 for miragevpn
- +
- Robur's blog + Robur's blog - Tags @@ -22,7 +22,7 @@Back to index - +Community
@@ -46,7 +46,7 @@MirageOS
- +MirageVPN @@ -56,7 +56,7 @@
OCaml
-- MirageVPN & tls-crypt-v2
- MirageVPN updated (AEAD, NCP)
- Python's `str.__repr__()`
- Cooperation and Lwt.pause
- Speeding elliptic curve cryptography
- GPTar
- Speeding up MirageVPN and use it in the wild
- MirageVPN server
- qubes-miragevpn, a MirageVPN client for QubesOS
- The new Tar release, a retrospective
- Runtime arguments in MirageOS
- Meet DNSvizor: run your own DHCP and DNS MirageOS unikernel
- MirageVPN & tls-crypt-v2
- MirageVPN updated (AEAD, NCP)
- Python's `str.__repr__()`
- Cooperation and Lwt.pause
- Speeding elliptic curve cryptography
- GPTar
- Speeding up MirageVPN and use it in the wild
- MirageVPN server
- qubes-miragevpn, a MirageVPN client for QubesOS
- Testing MirageVPN against OpenVPN™
- The new Tar release, a retrospective
- Runtime arguments in MirageOS
- Meet DNSvizor: run your own DHCP and DNS MirageOS unikernel
OpenVPN @@ -72,6 +72,11 @@ QubesOS
+++ SMTP +
+Scheduler @@ -96,7 +101,12 @@
cryptography
- + +++ emails +
+finances @@ -112,6 +122,11 @@ gpt
+++ mailing-lists +
+mbr @@ -131,12 +146,17 @@
security
- +tar
+++ testing +
+unicode @@ -151,7 +171,7 @@
vpn
- + -
+
MirageVPN server
-It is a great pleasure to finally announce that we have finished a server implementation for MirageVPN (OpenVPN™-compatible). This allows to setup a very robust VPN network on both the client and the server side.
-As announced last year, MirageVPN is a reimplemtation of OpenVPN™ in OCaml, with MirageOS unikernels.
+It is a great pleasure to finally announce that we have finished a server implementation for MirageVPN (OpenVPN™-compatible). This allows to setup a very robust VPN network on both the client and the server side.
+As announced last year, MirageVPN is a reimplemtation of OpenVPN™ in OCaml, with MirageOS unikernels.
Why a MirageVPN server?
Providing Internet services with programming languages that have not much safety requires a lot of discipline by the developers to avoid issues which may lead to exploitable services that are attacked (and thus will circumvent any security goals). Especially services that are critical for security and privacy, it is crucial to avoid common memory safety pitfalls.
Some years back, when we worked on the client implementation, we also drafted a server implementation. The reasoning was that a lot of the code was already there, and just a few things needed to be developed to allow clients to connect there.
diff --git a/articles/miragevpn.html b/articles/miragevpn.html index bb531fc..7486adb 100644 --- a/articles/miragevpn.html +++ b/articles/miragevpn.html @@ -5,13 +5,13 @@MirageVPN & tls-crypt-v2
-In 2019 Robur started working on a OpenVPN™-compatible implementation in OCaml. +
In 2019 Robur started working on a OpenVPN™-compatible implementation in OCaml.
The project was funded for 6 months in 2019 by prototypefund.
In late 2022 we applied again for funding this time to the NGI Assure open call, and our application was eventually accepted.
In this blog post I will explain why reimplementing the OpenVPN™ protocol in OCaml is a worthwhile effort, and describe the Miragevpn implementation and in particular the tls-crypt-v2 mechanism.
qubes-miragevpn, a MirageVPN client for QubesOS
-We are pleased to announce the arrival of a new unikernel: +
We are pleased to announce the arrival of a new unikernel: qubes-miragevpn. The latter is the result of work begun several months ago on miragevpn.
Indeed, with the ambition of completing our unikernel suite and the success of diff --git a/articles/speeding-ec-string.html b/articles/speeding-ec-string.html index ae8552b..aadfb42 100644 --- a/articles/speeding-ec-string.html +++ b/articles/speeding-ec-string.html @@ -5,13 +5,13 @@
Speeding elliptic curve cryptography
-TL;DR: replacing cstruct with string, we gain a factor of 2.5 in performance.
+TL;DR: replacing cstruct with string, we gain a factor of 2.5 in performance.
Mirage-crypto-ec
In April 2021 We published our implementation of elliptic curve cryptography (as mirage-crypto-ec opam package) - this is DSA and DH for NIST curves P224, P256, P384, and P521, and also Ed25519 (EdDSA) and X25519 (ECDH). We use fiat-crypto for the cryptographic primitives, which emits C code that by construction is correct (note: earlier we stated "free of timing side-channels", but this is a huge challenge, and as reported by Edwin Török likely impossible on current x86 hardware). More C code (such as point_add, point_double, and further 25519 computations including tables) have been taken from the BoringSSL code base. A lot of OCaml code originates from our TLS 1.3 work in 2018, where Etienne Millon, Nathan Rebours, and Clément Pascutto interfaced elliptic curves for OCaml (with the goal of being usable with MirageOS).
The goal of mirage-crypto-ec was: develop elliptic curve support for OCaml & MirageOS quickly - which didn't leave much time to focus on performance. As time goes by, our mileage varies, and we're keen to use fewer resources - and thus fewer CPU time and a smaller memory footprint is preferable.
diff --git a/articles/tar-release.html b/articles/tar-release.html index faf10bf..511fe66 100644 --- a/articles/tar-release.html +++ b/articles/tar-release.html @@ -5,13 +5,13 @@The new Tar release, a retrospective
-We are delighted to announce the new release of ocaml-tar. A small library for
+
We are delighted to announce the new release of ocaml-tar. A small library for
reading and writing tar archives in OCaml. Since this is a major release, we'll
take the time in this article to explain the work that's been done by the
cooperative on this project.
