64 lines
4.6 KiB
Text
64 lines
4.6 KiB
Text
---
|
||
title: Projects
|
||
---
|
||
|
||
# PGP {#PGP}
|
||
|
||
OpenPGP is a much-used standard of encryption and is widely used to encrypt text, files and emails, amongst other things.
|
||
|
||
Robur is implementing OpenPGP in OCaml, for use in MirageOS and any other compaitble platform or software that is looking for PGP written in a [secure language](/Technology-Employed#Ocaml).
|
||
|
||
This work is funded through donations and is still an ongoing project, which means that it may not currently possess all the features required for various use-cases. Currently our implementation can sign, verify, compress, encrypt and decrypt.
|
||
|
||
You can assist us in implementing more of the OpenPGP protocol through a [donation](/Donate). If you are interested hearing more about the project, require additional features to be implemented to accommodate your project’s needs, or are able to assist with a grant please [get in touch with us](/Contact)!
|
||
|
||
|
||
|
||
#### More technical information:
|
||
|
||
Robur maintains a partial, opinionated implementation of OpenPGP version 4 (RFC 4880) and the related standards, written in OCaml and compatible with MirageOS.
|
||
|
||
The software consists of a library, and various UNIX tools that make use of the library, and can be used to interact with systems that are currently using GnuPG or other OpenPGP implementations for file encryption or verification using OpenPGP signatures. Notably it can be used from within MirageOS applications without having to bundle a C implementation, and the UNIX binaries are separated from the library so that your applications can use the library directly, unlike GnuPG or libgpgme whose API translates to repeated executions of the gpg2 binary and parsing of the textual output from that.
|
||
|
||
Currently we have implemented signing/verification and encryption/decryption, but there is no support for elliptic curve cryptography. Decompression of ZLIB streams is supported through the use of a pure OCaml library called decompress. While some things are implemented with a streaming API, many operations make use of an in-memory buffer, which introduces memory constraints on the file handled (this is an area where there is definitely room for improvement).
|
||
|
||
The software is available [on Github](https://github.com/cfcs/ocaml-openpgp).
|
||
|
||
|
||
|
||
# Solo5 {#Solo5}
|
||
|
||
Solo5 is a sandboxed (separated) execution environment built using unikernels (a.k.a. library operating systems), including but not limited to MirageOS unikernels. It provides the interface between software and the operating system it runs on.
|
||
|
||
Conceptually, Solo5 provides the minimal set of "low level" building blocks and interfaces that a unikernel hosted on an operating system or hypervisor requires to be able to perform useful work.
|
||
|
||
Solo5's interfaces are designed in a way that allows us to easily port them to run on different host operating systems or hypervisors. Implementations of Solo5 run on Linux, FreeBSD, OpenBSD, the Muen Separation Kernel and the Genode Operating System Framework.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
#### More technical information:
|
||
|
||
|
||
Solo5 features include:
|
||
|
||
* a sandboxed environment (CPU, memory) to execute native code in
|
||
* clock interfaces to access system time
|
||
* network interfaces to allow the unikernel to communicate with the outside world
|
||
* block storage interfaces to allow the unikernel to store persistent data
|
||
* an output-only "console" interface for logging and debugging
|
||
|
||
Solo5 has been designed to isolate the unikernel as much as possible from its host, while making the best of the available isolation technologies that the host hardware, operating system or hypervisor provide, such as hardware-assisted virtualization, system call filtering and so on. Interfaces are intentionally designed to treat the unikernel as a "static system". In other words, the unikernel must declare its intent to make use of host resources (such as memory, network or storage) up front, and can not gain access to further host resources at run time.
|
||
|
||
Compared to existing technologies, such as traditional virtualization using KVM/QEMU, VMWare, crosvm and so on, Solo5 is several orders of magnitude smaller (around 10,000 lines of C) and is tailored to running unikernels in a legacy-free and minimalist fashion.
|
||
|
||
Our goal for Solo5 is to enable the use of unikernel technology to build hybrid, disaggregated systems where the designer/developer can choose which components are untrusted or security-sensitive and "split them out" from the monolithic host system. At the same time she can continue to use existing, familiar, technology as the base or "control plane" for the overall system design/deployment, or mix and match traditional applications and unikernels as appropriate.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|