#+TITLE:     Easy GnuPG
#+AUTHOR:    Dashamir Hoxha
#+EMAIL:     dashohoxha@gmail.com
#+OPTIONS:   H:3 num:nil toc:nil \n:nil @:t ::t |:t ^:nil -:t f:t *:t <:t
#+OPTIONS:   TeX:nil LaTeX:nil skip:nil d:nil todo:t pri:nil tags:not-in-toc
#+OPTIONS:   org_reveal_title_slide:<h1 class="title">Easy GnuPG</h1>
#+OPTIONS:   reveal_title_slide:nil
# #+REVEAL_ROOT: http://cdn.jsdelivr.net/reveal.js/3.0.0/
#+REVEAL_HLEVEL: 1
#+REVEAL-SLIDE-NUMBER: t
#+REVEAL_THEME: serif
#+REVEAL_TRANS: linear

* FOSDEM 2018

#+begin_export html
<h1 class="title">Easy GnuPG</h1>
<h2 class="author">Dashamir Hoxha</h2>
<h3 class="email">dashohoxha@gmail.com</h3>
<h4>https://github.com/dashohoxha/egpg</h4>
#+end_export


* What is GnuPG

  + *GnuPG (GNU Privacy Guard)* is a complete and free implementation of
    the *OpenPGP* standard. It allows you to encrypt and sign your data
    and communications.

  + *GnuPG* has _scads of options_ which make it a _flexible_ and _powerful_
    encryption framework. However this also makes it _extremely
    complicated_ to get started with, and that quite reasonably puts
    people off.

** GnuPG is difficult

  + I have tried to use GnuPG since a long time ago, spent a lot of
    time reading detailed and complicated tutorials, manuals etc. and
    still I find myself lost when trying to use GnuPG.


** Problems with GnuPG (in my opinion)

  + The *gpg* command is monolithic, bloated with functionality and options.
  + The docs are not clearly structured.
  + The number of commands and options is huge.
  + There is no clear distinction between the commands and the options.
  + The supported use cases are not so clear (it tries to support everything).
  + The terminology is a bit confusing and counter-intuitive.

* What is EasyGnuPG

  + *EasyGnuPG* is a _wrapper script_ that aims to _simplify_ the process of
    using GnuPG.
  + The more people using strong encryption, the better for everyone.

** What is EasyGnuPG

  + It tries to offer:
    - a simpler interface
    - with much less commands and options
    - better organized and structured
    - with a more intuitive terminology
    - with a modular construction
    - that is also easy to customize, adapt and extend


* EasyGnuPG is opinionated

  + In order to simplify things, *EasyGnuPG* is opinionated about the
    "right" way to use GnuPG. This means that while *GPG* offers lots of
    options and flexibility to perform a certain task, *EGPG* uses just
    a sensible default way, in order to keep things simple and not to
    bewilder the user with countless choices.

** EasyGnuPG is opinionated

  + For example, when you create a new key in GPG you have to specify
    a lot of options, most of which make no sense for a beginner, so
    they will just use the defaults anyway.
  + EGPG on the other hand, just asks for a name and an email address,
    filling up the rest with reasonable default values.
  + Not only that, but it also goes on and generates automatically the
    needed subkeys, according to well known recommendations and best
    practices of using GPG.

** EasyGnuPG is opinionated

  + Or, when encrypting a file, it also automatically signs it,
    encrypts it to the author as well, and generates the output in the
    text format (ASCII armored), which is more universal than the
    binary format.

** EasyGnuPG is opinionated

  + This simplicity makes it easier for the beginners to get started.
  + At the same time, the selected subset of operations and features
    covers most of the common cases of usage, so hopefully it should
    be sufficient for the everyday needs of most of the users.


* EGPG integrates seamlessly with GPG

  + In case users need to use some advanced features or commands which
    are not supported by EGPG, they can go on and use GPG itself at
    any time, because EGPG also integrates seamlessly with GPG.
  + So, the reduced set of supported operations and features, while
    being convenient for everyday usage, does not limit or prevent
    users for doing more advanced or complex things.

** EGPG integrates seamlessly with GPG

  + For example, if you want to do some extra editing to the key,
    which can't be done with EGPG due to its limited set of
    functionality, you can do it like this:
    #+begin_example
    egpg gpg --edit-key 562AC309C01D2DBD
    #+end_example
    Running =gpg= as a subcommand of =egpg= will ensure
    that it uses the same environment (=GNUPGHOME=) as =egpg=.

** EGPG integrates seamlessly with GPG

  + Also, when initiating a new EGPG environment (with =egpg init=), you
    can migrate all the data from an existing GPG or EGPG environment
    (with =egpg migrate=).
  + Or you can fetch (pick up) only certain keys or contacts (public keys).
  + For example:
    #+begin_example
    egpg key fetch -k 01D532A283DC1CBF
    egpg contact fetch 01D532A283DC1CBF
    #+end_example


* EGPG has a clear and intuitive terminology

  + One of the things that confuses people while using GPG is the
    overloaded and unclear terminology about keys, about signatures,
    etc.
  + EGPG tries to improve this by making a clear distinction between
    the private keys and the public keys.

** EGPG has a clear and intuitive terminology

  + In EGPG there is only one primary *key*, which is used for
    signing, and a subkey which is used for decryption.
  + All the public keys are called *contacts*, since they contain the
    names and email addresses of the people that you use to
    communicate (either send them encrypted messages or verify their
    signatures).

** EGPG has a clear and intuitive terminology

  + If you say *public key* to a beginner, you will also have to
    explain to him some cryptographic details and how public keys
    should be used.
  + But if you say *contact* everybody gets that it contains details
    that enable and facilitate communication.
  + Also, it makes more sense when you certify and trust a contact,
    rather than editing a key and changing its certification and trust
    levels.


* EGPG is transparent and auditable

  + Being built as a set of shell scripts, EGPG is quite transparent
    and auditable (different from a GUI for example, or a web
    service).
  + If you are concerned about what it does, open up the files and
    read them, or have someone you trust read them.

** EGPG is transparent and auditable

  + The size of the main script is less than 250 lines, well within
    the reach of most of the users.
  + Most of the commands are implemented on their own script, and
    these scripts are about 50 lines long on average.


* EGPG commands

  + The set of commands and options of EGPG is well structured and
    intuitive.  There are commands for:
    - working with files (for signing and encryption)
    - managing the key
    - managing contacts
    - other extra commands

** EGPG file commands

  + The commands for working with files are these:
    #+begin_example
    egpg seal <file> [<recipient>...]
        Sign and encrypt a file. The resulting file will have the
        extension '.sealed'. The original file will be erased.

    egpg open <file.sealed>
        Decrypt and verify the signature of the given file.
        The file has to end with '.sealed' and the output will have
        that extension stripped.

    egpg sign <file>
        Sign a file. The signature will be saved to <file.signature>.

    egpg verify <file.signature>
        Verify the signature. The signed file must be present as well.
    #+end_example

** EGPG key commands

  + There are commands to:
    - generate a new key or fetch an existing one
    - to backup and restore the key
    - to split and join the key
    - to generate a revocation certificate
    - to revoke the key
    - to delete the key
    - etc.

** EGPG contact commands

  + The commands about contacts include:
    - commands to search and receive contacts from the keyserver
      network
    - to export and import from files
    - to fetch from existing GPG/EGPG directories
    - to certify and trust
    - etc.


* Managing the keys

  + To keep things simple, EGPG supports only one private key per
    directory.
  + But there are ways to use several keys if needed.  For example it
    can be done by using several EGPG directories/configurations,
    which can work in parallel and independently of each-other.

** Managing the keys

  + This is a design decision and is on purpose, not only for
    simplicity, but also because when you need more than one key, you
    usually use them in different contexts. So, it makes more sense to
    keep and manage them separately and independently of each-other,
    which could also help to avoid any confusion or mistakes when
    using them.


* EGPG extends the features of GPG

  + EGPG combines the features of GPG with external tools/commands in
    order to achieve better results or to be more user-friendly.

  + For example, when making the backup of the key, the output is
    produced as a _PDF file_ with a _2D barcode_, which can be printed on
    paper and stored away on a safe place. Later this can be easily
    scanned back to digital format and restored.

** EGPG extends the features of GPG

  + This is achieved by exporting the key from GPG in ASCII armor
    format, then using a bunch of Linux commands and tools, like
    *qrencode* and *convert*, to convert it to the proper PDF format.

  + There is nothing that cannot be done manually or with a shell
    script, but EGPG already automates things for you in a single
    command, so that you can immediately take advantage of best
    practices and recommendations.

** EGPG extends the features of GPG

  + Another example is printing the fingerprint of the key as a 2D
    barcode and picking it up from the camera.
  + This can simplify the exchange of keys in mobile phones, if people
    have physical contact.
  + For example in a meeting one of them can show the code on the
    screen, and the other one can scan it from the camera, and
    automatically fetch the details from a keyserver.
  + Or the fingerprint can be printed as a 2D barcode on a business
    card, and scanned from there.

** EGPG extends the features of GPG

  + Yet another example is moving the main key (that is used for
    signing and certification) to a dongle (USB flash drive), for
    portability and security (the USB flash drive should be
    encrypted).
  + This is done with the external command:
    #+begin_example
    egpg key2dongle
    #+end_example

* Splitting the key

  + You can split a key into 3 partial keys, so that any 2 of them can
    be combined to recreate the original key (but a single one is not
    enough).
  + EGPG takes advantage of this to save a partial key on the local
    machine and another partial on a dongle (USB flash drive,
    removable device).
  + The third partial key is used as a backup, to recover the full key
    in case that the dongle or the computer is lost, and it can be
    stored for example on a cloud account.

** Splitting the key

  + Splitting the key into partial keys makes key management safer and
    more robust.
  + In case that you loose the dongle, the key is not deconspired,
    because a single partial key is not enough to reconstruct the full
    key.
  + The same goes for the backup partial key; you can store it on
    cloud and if somebody manages to get it, they still cannot get
    your key.
  + Similarly, if you loose the dongle or change the PC, you still can
    recover the key using the remaining partial key and the backup
    partial key.

** Splitting the key

  + EGPG manages all this with simple commands:
    #+begin_example
    egpg key split [-d,--dongle <dir>] [-b,--backup <dir>]
        Split the key into 3 partial keys and store one of them on the
        dongle (removable device, usb), keep the other one locally,
        and use the third one as a backup. Afterwards, whenever the
        key needs to be used, the dongle has to be present.

    egpg key join
        Join two partial keys into a full key and delete the partials.

    egpg key recover <backup-partial.key.xyz>
        Recover the key from the backup partial key and from the
        partial key of the home or the dongle. This is useful when
        either the dongle or the home partial key is lost.
    #+end_example


* EGPG can work on any platform

  + The file *platform.sh* contains a couple of functions that can be
    platform dependent.
  + The platform is detected automatically and these functions are
    overridden with the right implementation for the current platform.
  + So, EGPG is flexible enough to potentially work on any platform.
  + However, currently it has been tested only on Ubuntu and Debian.


* EGPG is customizable and extensible

  + If EGPG doesn't fit your workflow, you can adapt and extend it to
    fit your way of doing things.
  + You can also share your extensions with the others, in the form of
    external commands.

** EGPG is customizable and extensible

  + The file *$EGPG_DIR/customize.sh* can be used to redefine and
    customize some functions, without having to touch the code of the
    main script.
  + External command *example* can be overridden (or defined) by adding
    the file *$EGPG_DIR/cmd_example.sh*, which contains the function
    *cmd_example() { . . . }*.

** EGPG is customizable and extensible

  + For an external command the script will look:
    - first for *$EGPG_DIR/cmd_example.sh*
    - then for *$LIB/ext/$PLATFORM/cmd_command.sh*
    - and finally for *$LIB/ext/cmd_command.sh*
    The first that is found is loaded and used.
  + For commands about the key the name of the file must be
    *cmd_key_example.sh*
  + For commands about contacts it must be *cmd_contact_example.sh*


* EGPG enables scripting

  + I think that it is time to stop writting detailed tutorials with
    best practices on how to use GPG on certain situations.

  + Write instead scripts (in EGPG or some other framework) that
    automate these processes.

  + GPG itself does not facilitate writing such scripts and EGPG tries
    to improve this.


* EGPG criticism

  + The EGPG critics have expressed their concerns that since EGPG is
    just a wrapper script to GPG, it is too fragile.
  + This is so because the GPG command line was meant to be an
    interactive tool, not a streamline tool that can be easily
    combined with other tools.
  + As such, its output format can change at any time, and even small
    changes can break EGPG.

** EGPG criticism

  + A possible defense argument can be that EGPG should be used only
    with stable releases of Linux distributions, which by definition
    don't change the major versions of their supported tools and
    utilities and allow only for bug and security fixes.
  + So, the chances of EGPG being broken are small, and it needs to be
    updated/fixed only for every next stable release (which does not
    occur too frequently).

  + Nevertheless the problem still exists and the recommended solution
    is to re-implement parts of EGPG with Python bindings of GPGME
    (which is a library for doing GPG stuff).


* EGPG improvements

  + There is a proposed project on GSoC about possible improvements to
    EGPG: https://wiki.debian.org/SummerOfCode2018/Projects/EasyGnuPG

  + I am looking for co-mentors, and of course for interested
    students.

** EGPG improvements

  + Some of the potential improvements are:
    - Rewrite EasyGnuPG (or parts of it) so that it is built with
      Python and GPGME (https://www.gnupg.org/software/gpgme/)
    - Implement a GUI to EasyGnuPG (maybe with Python).
    - Extend EasyGnuPG with scripts/commands that automate other
      common usage scenarios (for example keeping the master key on a
      card).
    - Make a Debian package for installing EasyGnuPG.

* Thank you for your attention

  + Any questions or comments?
    - dashohoxha@gmail.com

  + Links:
    - https://github.com/dashohoxha/egpg
    - https://wiki.debian.org/SummerOfCode2018/Projects/EasyGnuPG

#  LocalWords:  Dashamir Hoxha
