11 ms·

Sequoia-PGP – A new OpenPGP implementation in Rust

305 points by 1wilkens 8y ago

alain_gilbert 8y ago
I wish gpg had a decent cli/"api" At work, we use it to store shared secrets. We can encrypt a file that can be decrypted by multiple keys. It's a bit hard to remember all the commands so I made a webUI to manage everything. The feature I like the most is that I can list which files you can access and which files you cannot. The thing is, to do that, I need to pass tons of obscure and magic nonsense parameters IE: gpg --list-only --no-default-keyring --secret-keyring /dev/null ops.gpg and then parse the completely un-parsable output to know which keys can decrypt the file. So far so good. The problem is that; this magic trick only work with gpg 2.0.30 or lower. If you have the latest version, you can see every keys that can decrypt a file... except yours. There is no way to know if "You" can decrypt a file anymore ! (how great is this) I now have to tell people that if they want to use the nice UI they cannot have the latest version of gpg, which is troubling. I can't believe that in 27 years, it is still impossible to know which keys can decrypt a file. Or even just have some parsable output instead of the pile of crap the gpg tool can vomit out. So I'm pretty excited about Sequoia :)
- sgift 8y ago
  > then parse the completely un-parsable output to know which keys can decrypt the file. This reminds me so much about a tip in Effective Java .. 'Always provide an option for users to access every relevant part of your object. If not people will start to parse your toString output and you will have created an inofficial API that you have to support whether you want or not' (paraphrased from my faulty memory). That programmers make that mistake again and again is just sad. :(
  - speedplane 8y ago
    This is what I love about Python. Every method is public, but methods that start with an underscore mean "use at your own risk". It suggests that the programmer use a preferred way, without strictly requiring it. Private methods treat programmers like infants.
    - sgift 8y ago
      IME if you allow someone to use your private API you can be sure they will do at some point. And then they will be unhappy when you change it. Sure, you can go with "I said it was private, your problem", but that is the road to zero users.
      - tjohns 8y ago
        So much this. I've seen it happen time and time again. At least in Java, the reflection API serves as a "break glass" barrier to make sure folks understand they're doing something they shouldn't. Someone will still do it, and they'll still blame you when their app breaks later... but I like to believe it at least scares some folks away.
        speedplane 8y ago
        Honestly, I don't see people getting unhappy at breaking private API functionality. Most grab a library when they need and never upgrade it. They only do so when there's a necessary security risk or some wiz-bang new feature they need. The common example: programmer grabs a library to solve a problem; a few weeks later they realize it doesn't really solve the problem and requires modifications to the library to do some custom job; they make the modifications. That's normally the end of the story for several years. No point in upgrading the library unless it really solves a business problem. That constitutes the vast majority of developers. Of course there are other organizations that always want the latest and greatest version and are constantly upgrading. To them, I'd say sure, stick to the public methods, otherwise you're creating a big headache down the road. But I wouldn't require it of them.
    - simias 8y ago
      IMO there's a difference between "use at your own risk" and "this is actually not meant to be called from the outside and if it is it will violate some invariant in the code". Those are two different concepts and it makes sense to distinguish them. Of course in high level highly managed languages like python it makes sense that the difference between the two can be rather fuzzy at times but in low level code there's often a clear difference. Take for instance a socket class in C++, you might have a private method that deals with the low level details of the libc's socket calls. It's called at construction time and never later, and calling it would cause the current socket to be replaced by the new one (leaking the fd in the process) because it's only meant to be used at init time. Clearly it's not "use at your own risk", it's "code that calls this from the outside is fundamentally broken". Having the compiler enforce this invariant is a useful feature. Meanwhile you can also have "use at your own risk" methods, for instance "get_raw_fd" if you want to be able to access the underlying socket. It makes it easy to break things but has legitimate use cases. Of course you could say that you could just tag these private in a certain way and let coder discipline do the rest, but then again you could say that of pretty much all static validation (which, I suppose, makes sense if you like very dynamic languages like Python).
  - zaarn 8y ago
    GPG is largely just this toString output parsing. Which has been the source of a number of bugs in various GPG clients in the past (a few even on the HN frontpage for a few moments) and probably will into the future until GPG is no longer used. tbh, GPG should just provide an RPC option so applications can securely pass data back and forth and receive proper error messages and codes. But I bet this won't happen because GNU fears that sort of things considering they won't split up the GCC compiler.
    - scandox 8y ago
      Well there is GPGME: https://gnupg.org/software/gpgme/index.html https://gnupg.org/software/gpgme/index.html But yes I mostly parse colon separated text.
    - admax88q 8y ago
      > But I bet this won't happen because GNU fears that sort of things considering they won't split up the GCC compiler. That's unfounded, there are plenty of GNU projects that have an API.
      - zaarn 8y ago
        It's not unfounded. The GCC compiler isn't splitting up because they fear someone would build a proprietary compiler using either backend or frontend API if they did it. I can see that the same reasoning here would be valid; someone could write a proprietary GPG frontend.
        admax88q 8y ago
        You have one example of a project not providing an API, however there are tons of other GNU projects which do. Furthermore the GCC decision is well documented in mailing list posts, have you ever seen anyone involved in GPG development claim that they won't allow a library/frontend split for fear of someone writing a proprietary frontend?
  - doesnt_know 8y ago
    Hyrum's Law With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody. http://www.hyrumslaw.com/ http://www.hyrumslaw.com/ I'm in a team where all the consumers are only other internal teams and yet this still happens. I've found that it doesn't matter if you explicitly state to not rely on a particular behavior in your documentation, clients still will. It's always your fault if you break it because "it was your change that broke this client" and "it was working fine yesterday".
    - Nae3Au5x 8y ago
      Some people may depend on them, but the difference between API guarantees and implementation details is that developers are far less reluctant to break your legs... I mean your application if you depend on the latter. For example in java the iteration order of hash maps or the behavior of sorts in presence of non-reflexive comparators changed and people did depend on that. Sun was able to change it because it was not part of the API contract.
      - pure-awesome 8y ago
        Man, depending on sort order with a non-reflexive comparator is a TERRIBLE idea. Almost on the level of https://xkcd.com/1172/ https://xkcd.com/1172/
- Freak_NL 8y ago
  Have you had a look at pass¹? It's a bash script that uses gnupg to encrypt secrets as gpg-encrypted plain text files. It has a very nice feature that allows you to specify a list of keys for all secrets in a specific directory (using a .gpg-id file). Once set up, accessing the secrets is a matter of using the pass command line tool: pass edit some/secret # Copy the first line of a secret; by convention # this is meant for a password: pass -c some/secret # Show the whole secret file: pass some/secret # Combined with git: pass git pull # Generate a 24-character random password: pass generate some/othersecret 24 pass git push We use pass to maintain a set of shared secrets with a small team. The (encrypted) files are pushed to private git repository (pass supports this out of the box). 1: https://www.passwordstore.org/ https://www.passwordstore.org/
  - wuschel 8y ago
    Out of interest: How big of a threat is keeping diff files/versioned encrypted containers around when it comes to preventing breaking the encryption? I could imagine that the additional information will reduce the security of the information.
    - simias 8y ago
      The only problem I can foresee (assuming that the encryption scheme itself has no weaknesses to things like known plaintext attacks) is that it makes it harder to retire an old, potentially compromised key. You need to expunge the git history and any copies.
      - wuschel 8y ago
        Makes sense. Thank you.
  - esseti 8y ago
    can you elaborate or point me to a resource how to use it to share secret for projects? i tried the pass, but it sotres the credentials in my home, i would rather prefer to have them in a file in the project, moreover, can also it encrypt .env files or some sort of it?
- eterps 8y ago
  Looking at the `sq` command line client doesn't instill hope to me that it is going to be friendly: https://docs.sequoia-pgp.org/sq/index.html https://docs.sequoia-pgp.org/sq/index.html But if it's at least going to be consistent that would already be a big win.
  - dmoreno 8y ago
    Now it needs a --output=json option to make it awesome and usable from scripts and programs.
    - nwalfield 8y ago
      We've been considering this, but we'd rather have people use the library. We already have the start of a Python interface, which is pretty easy to use, IMHO. But, I suspect that some people will insist on a shell script. So, we'll probably go this route sooner rather than later to avoid developers trying to parse the output of sq in an ad-hoc manner.
  - nwalfield 8y ago
    What would make a friendly interface in your opinion? The sq frontend uses git style subcommands to clearly separate actions from options. This is something that gpg doesn't do too well. For instance, commands (e.g., -e) look like options (e.g., -r). If no command is given, gpg tries to guess what you meant, which is perhaps good for users, but bad for programmers. And if an option isn't relevant to a command, it is often just ignored, which again, is perhaps reasonable for users, but bad for programmers.
    - eterps 8y ago
      I have nothing against the git style subcommands, in fact I think they are great. A friendly interface would in my opinion be from the perspective of an end user. In the case if GPG the end user can have a couple of goals in mind, to encrypt, decrypt or sign data. Although you could do a lot more things, for most users those would be secondary goals. I guess the average user doesn't necessarily know about autocrypt, ASCII armor, OpenPGP packets etc. Those users would have to guess whether they need to (do I need autocrypt? Why isn't it a default?). To be honest I don't think the usage output is very bad in its current form, but as a start for something that will evolve over the years I am not so sure.
- toyg 8y ago
  I'm sure you've already considered all the possible solutions, but why don't you run gpg in a subprocess as a different user, so it can list "Your" key (unless by "you" you mean "the user that originally encrypted the file")...?
- megous 8y ago
  Or, you know, you can contribute JSON output to GPG. I mean, opensource and stuff.
- ataturk 8y ago
  I'm not sure I follow you here. The whole point of public key encryption is that one key looks like any other key. If there is extra information available, such as knowledge of which keys can decrypt which files, isn't that defeating the whole purpose? A key is a key is a key. Some keys decrypt the original data, the rest decrypt into gobbledygook.
- yrro 8y ago
  I think the API is the GPGME library? https://gnupg.org/software/gpgme/index.html https://gnupg.org/software/gpgme/index.html ... which internally calls gnpg using the --with-colons argument which is how you're supposed to get machine-readable output. That said, maybe your use case isn't very accessible via the standard gpg commands. It sounds like you want to parse the ciphertext and extract the recipient keyids? You can do that with gpg --list-packets, but this is really intended for debugging, not automated consumption. That said it doesn't look too hard to parse, but who knows how stable it will be in the future.
  - yrro 8y ago
    (for example) gpg --list-only --list-packets foo | gawk '/^:pubkey\>/ { print $9 }'
- fanf2 8y ago
  I have a command-line wrapper around gpg for similar reasons - https://dotat.at/prog/regpg/ https://dotat.at/prog/regpg/ The magic you are missing is `--quiet --status-fd 1`, then look for ENC_TO lines - the documentation can be found in https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=doc/DETAILS;hb=HEAD https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;... Based on my testing this works with gnupg 2.1 and 2.2, so I think it should help with your problem.
  - klodolph 8y ago
    Yes, more people should know about the --status-fd option. I only wish there were a version that gave JSON output or something a little more foolproof to parse, the record syntax is easy to analyze with sed/awk/etc but you have to look up the docs for the meaning of each field and I wonder about the quoting sometimes.
- jandrese 8y ago
  Oh god this. GPG's commandline is so inconsistent and frustrating to use. Plus it has all of these concepts that hardly anybody cares about in real life. Like the "trust level" of a key in the system. There are 5 (maybe 6) trust levels and it would take someone really paranoid to use most of them. Of course imported keys default to the lowest (most useless) level so you have to change it, which is a pain in the ass to do from the commandline (you have to write an expect script or do a wholesale import of a "trust database"). And then there was Ubuntu 16 that couldn't seem to import private keys at all or must have required some kind of super secret commandline option to allow it. Honestly at this point I've been waiting for the inevitable article about how GPG has been maintained by one starving guy in his basement for the past 20 years and it turns out it's a total mess and nobody noticed because nobody was looking. Basically OpenSSL all over again.
  - Boulth 8y ago
    New GnuPG can use TOFU trust model that simplifies this flow (an example here: https://www.kernel.org/category/signatures.html#using-the-web-key-directory https://www.kernel.org/category/signatures.html#using-the-we... ). > Of course imported keys default to the lowest (most useless) level so you have to change it You don't need to adjust trust levels, just sign the key locally (lsign) and it'll be valid. (there is a difference between key validity and trust, check out this excellent resource https://www.linux.com/learn/pgp-web-trust-core-concepts-behind-trusted-communication https://www.linux.com/learn/pgp-web-trust-core-concepts-behi... ).
    - jandrese 8y ago
      That article makes the Web of Trust seem like an even bigger mistake. Once you have more than handful of keys in the system the interactions become complex, too complex for good security IMHO.
      - Boulth 8y ago
        Does it? For a key to be considered valid it must be either ultimately trusted, signed by ultimately trusted key or one fully trusted valid key or 3 marginally trusted valid keys. It seems to me there are only two properties to track and quite easy calculation to do (fizz buzz level).
- mjevans 8y ago
  Are you adding your own identity to the list of recipients? This works for gpg 2.1.18 gpg -u ${MYHEX} --batch --passphrase-file /path/to/some/hard-coded-passphrase --compress-level 1 --cipher-algo AES256 --sign --encrypt -r ${MYHEX} -r ${RECP1} -r ${RECP2} -r ${RECPn} -o ${OUTPUTFILE}.gpg ${INPUTFILE}
- eridius 8y ago
  Have you looked at Keybase? It offers a wrapper around the GPG commands. I know it can be used to encrypt/decrypt and sign stuff, but I haven't looked at it in detail so I don't know if it will suffice, but it might. `keybase help pgp` will list the commands. I'm also not sure if it's usable if you don't have a Keybase account (though those are free).
- danenania 8y ago
  EnvKey[1] might be interesting to you (disclaimer - I'm the founder). It's similar in principle to the homegrown system you've created, but has had a lot of time put into smoothing out the ux. It gives you a single place to manage configuration/secrets for all your projects. It uses OpenPGP.js (maintained by ProtonMail) and golang's crypto/x/openpgp instead of gpg. 1 - https://www.envkey.com https://www.envkey.com
nwalfield 8y ago
While at the Delta X gather last week, we recorded an introduction to Sequoia. The presentation covers our motivation for starting the project, an overview of Sequoia’s architecture, and the project’s status: https://www.youtube.com/watch?v=NBbtIZipeNI https://www.youtube.com/watch?v=NBbtIZipeNI The tl;dr is that we’re actually pretty far: Sequoia is already being tested with the p≡p engine, and other projects, like Delta Chat, have begun replacing GnuPG or NetPGP with Sequoia.
deleted 8y ago
[deleted]
tlamponi 8y ago
Maybe also interesting: https://neopg.io/ https://neopg.io/ It's (also) from a former GPG dev, bases on the GPG source where some of the targets are: * switch to C++, allowing to reuse the legacy code, with lots of code thrown out * move to a single binary (again) Now, C++ is naturally not your fancy new language and the rewrite-it-in-rust people may run to their pitchforks but he has a blog post entry where he argues his choice: https://neopg.io/blog/cplusplus/ https://neopg.io/blog/cplusplus/ TLDR: He can build upon the well established GPG, C++ is mature and it's flaws are known and can be avoided an worked around. He even mentions the Sequoia Project in the last paragraph, and envies them a bit as they can use Rust. (for the record, nothing against rust or sequoia, just wanted to show a related project)
- pjmlp 8y ago
  While C++17 is a pleasure to work with, versus C++98, this kind of thinking only works out in very small teams (<= 5), very focused on quality assessment tooling like analyzers. Making developers avoid C style coding on C++ code is a continuous fight.
fbender 8y ago
Does it go beyond the minimum and old set of ciphers in use by the usual implementations? I'm asking because I firmly believe that any GnuPG re-implementation should try to improve on the current state of mail crypto [0]. [0] https://blog.cryptographyengineering.com/2014/08/13/whats-matter-with-pgp/ https://blog.cryptographyengineering.com/2014/08/13/whats-ma...
- nwalfield 8y ago
  Let's go through Matt's major points: Key Exchange / Key Management This isn't really a problem with the OpenPGP protocol or an OpenPGP implementation. This is inherent to any system that tries to protect you from active adversaries. If you are willing to use centralization, then you can do something like X509 (what is what TLS uses), but there are many, many cases of CAs issuing bad certificates either by accident or maliciously, e.g., the TURKTRUST incident. You can also do something like Signal with its verified key servers. But, if you want to be decentralized, then somehow you have to get the user involved. So, in my opinion, this is more a criticism of decentralization than of OpenPGP. Now, that doesn't mean that OpenPGP tooling can't help. In fact, about 4 years ago, several initiatives began working on mechanisms to make key discovery much easier, and mostly transparent for users primarily concerned about privacy (as opposed to those whose threat model includes active adversaries, like activists, lawyers, or journalists). See, in particular, the work that pep (https://pep.foundation https://pep.foundation) and Autocrypt (https://autocrypt.org https://autocrypt.org) have been doing. Forward Secrecy As I've written before (https://arstechnica.com/information-technology/2016/12/signal-does-not-replace-pgp/ https://arstechnica.com/information-technology/2016/12/signa...), I don't think that forward secrecy is actually fixing a problem that most people have. Particularly in the case of OpenPGP where most people are interested in encryption of data at rest (messages stored on an IMAP server), which forward secrecy doesn't help (forward secrecy, because it throws away old key material, only makes sense for protecting data in motion). But, that doesn't mean that we haven't given some thought to the problem. In fact, at the very same gathering, Justus, who is also working on Sequoia, presented a proposal for adding forward secrecy to OpenPGP in a backwards compatible manner. You can watch the presentation (https://www.youtube.com/watch?v=an6oYjikAPY https://www.youtube.com/watch?v=an6oYjikAPY), or read an early version of the proposal (https://mailarchive.ietf.org/arch/msg/openpgp/mk8_FSS-n4DVGfh_VwuGtEOS2xk https://mailarchive.ietf.org/arch/msg/openpgp/mk8_FSS-n4DVGf...). The short version is: OpenPGP already has mechanisms to mark encryption keys as being appropriate for data at rest or data in motion. Until now, no implementation has bothered with this distinction. We propose creating two encryption-capable subkeys, one for data at rest, and one for data in motion, and rotating the one for data in motion once a week. To ensure that a sender has a non-expired encryption key we pre-generate keys, and distribute them via the keyserver network. The OpenPGP format and defaults suck It is true that OpenPGP has standardized a number of ciphers that are no longer sensible, includes compression support, etc. But, OpenPGP is over 30 years old. In that time there have been many improvements. But Matt is right that these improvements come slowly. This is partly due to the lack of funding: the industry choose S/MIME over OpenPGP. (Although S/MIME is cryptographically worse than OpenPGP. See EFAIL for a critical example of why.) A major difficult to deprecating old ciphers is that OpenPGP is used for data at rest. And people rightly expect, I think, to be able to decrypt data and verify signatures from X years ago. This means we can't completely drop support for, say, CAST5: people wouldn't be able to decrypt old messages. Matt seems to ignore this bit, and focuses primarily on real-time communication (e.g., Signal), which only needs encryption for data in motion, i.e., the encryption is stripped and only archived on a trusted device (e.g., not an IMAP server). One thing that we are consider in Sequoia is requiring the caller to provide a timestamp when verifying or decrypting a message. The timestamp can be used to choose defaults that are appropriate for when the message was allegedly created. The timestamp can be double checked with the timestamp in the signature. In this way, if someone tries to send you an email using a deprecated cipher, they'll also have to set the timestamp in the email to, say, 1997, which would hopefully be suspicious. Likewise, something like a can be shown when the message doesn't meet the current standard. I hope that helps! If you have any other questions, you're welcome to ask here, or on irc (#sequoia on freenode) or on our mailing list (devel@sequoia-pgp.org). :) Neal
dvdplm 8y ago
This uses the Nettle crypto library under the hood. Does anyone know how well viewed (or reviewed) it is? I'm curious to hear more from the devs on their reasoning for picking it (maybe it was the only one with the features needed and a suitable license?) https://www.lysator.liu.se/~nisse/nettle/ https://www.lysator.liu.se/~nisse/nettle/
- flanfly 8y ago
  Nettle implements most of the crypto needed for OpenPGP, it's small size and few dependencies makes it easy to wrap for Rust. I did review some, but not all of Nettle and it looks pretty solid[1]. GnuTLS uses Nettle, so you can expect there are people smarter than me trying to break it. Initially, I wanted to use Botan, but the fact that it's in C++ means you need to write two wrappers one from C++ to C and one from C to Rust. 1: I checked for proper RSA base blinding, a secure CPRNG, lack of Bleichenbacher Oracles and lack of invalid curve attack vectors. It uses GMP for bignum stuff so carry propagation bugs are unlikely. There are some things that aren't super nice. The CPRNG does not reseed on forks, the included AES doesn't look particularity time constant and the library doesn't use mlock() nor zeros secrets after use.
  - randombit 8y ago
    Alas, I just started working on a Rust wrapper for Botan https://crates.io/crates/botan https://crates.io/crates/botan The existing Botan C API is in fact sufficient for OpenPGP already, https://github.com/riboseinc/rnp https://github.com/riboseinc/rnp is in C++ now but was originally C and uses Botan's C API. But Nettle is IMO quite solid and the developer is very skilled, so full steam ahead. Is there any relation between Sequoia and the BoringPGP spec?
    - flanfly 8y ago
      Yes, I'm a co-author of BoringPGP[1]. Sequoia itself will probably support it as soon as Marcus and I get around finishing the spec but it's not part of Sequoia and I only work on it in my free time. 1: https://github.com/boring-pgp/spec https://github.com/boring-pgp/spec
mynewtb 8y ago
That name is unfortunate because most of the world has no clue how to pronounce or spell it.
- Thomashuet 8y ago
  How is that different from any other name? Actually Sequoia is an English noun and as such I expect it to be more familiar than many other names. Even better the same word exists in many other Latin script languages. I know that there are a many more languages in the World but none of them is as widespread as English.
  - EugeneOZ 8y ago
    > I know that there are a many more languages in the World but none of them is as widespread as English. You will be surprised. https://en.wikipedia.org/wiki/List_of_languages_by_number_of_native_speakers https://en.wikipedia.org/wiki/List_of_languages_by_number_of... https://www.babbel.com/en/magazine/the-10-most-spoken-languages-in-the-world/ https://www.babbel.com/en/magazine/the-10-most-spoken-langua...
    - jcranmer 8y ago
      If you count by L1 speakers, English is only third. If you count by number of people with working proficiency of the language, English has somewhere between 1 and 2 billion speakers, which is probably more than the number of Mandarin speakers. Second language stats are really sketchy, but English is unique for being a language which is among the top native languages and having many more non-native speakers than native speakers.
      - deleted 8y ago
        [deleted]
      - EugeneOZ 8y ago
        As you can see, I respect you more: I spend some of my time to provide links for you as proofs. But nevermind, it's offtopic anyway. And it's not so important for me to argue about :)
aorth 8y ago
What about opmsg as a GPG replacement? > opmsg is a replacement for gpg which can encrypt/sign/verify your mails or create/verify detached signatures of local files. Even though the opmsg output looks similar, the concept is entirely different. https://github.com/stealth/opmsg https://github.com/stealth/opmsg
- lmm 8y ago
  Your messages have perfect forward secrecy except when they don't, because it uses DH but falls back to RSA when it runs out of keys. That's a security failure waiting to happen; IMO no forward secrecy is a more user-friendly model than "perfect forward secrecy except sometimes not". Support for multiple recipients is inherently a mess in that kind of model. No effort is made to even try to solve the identity problem PFS aside it doesn't seem to do anything you couldn't do with GPG - e.g. there's nothing to stop you verifying GPG key fingerprints by hand or using different keys to communicate with different recipients. In particular it doesn't seem to offer any improvement on the big problem that this is about - good MUA integration. Ultimately that looks like a good project that takes those techniques as far as they can go, but also shows exactly why those techniques never made sense for an email-like environment.
maxtaco 8y ago
We at keybase developed a PGP replacement called Saltpack. It uses only modern crypto, with all the features you would expect like authenticated encryption and branch-free secret key operations (via the NaCl library). We have a better armoring format that won’t get mangled in modern markdown contexts. It is also integrated with our CLI and in the upcoming release we support encrypting for teams. https://saltpack.org https://saltpack.org
- nasredin 8y ago
  The web site design is so hipsterish :) I kept looking for "install" or "download". It's in "repos".
- jwr 8y ago
  The problem with keybase is that it has grown from a simple command-line tool (which I could perhaps trust) to a monster with a GUI, menu-bar icon, resident daemon, which does lots of things, and until recently failed to even properly start for me. The running process daemon is required even to use the CLI. I'm glad you are making a PGP replacement, but I'm worried that this will head in the same direction. I want simpler, auditable and understandable systems for crypto, not complex beasts with hidden interactions.
  - dbrgn 8y ago
    I fully share that opinion. I loved Keybase for its simplicity: It was a way to verify keys based on social media accounts and thus a more practical alternative to the web of trust. The client was optional, I could track someone by using bash and curl, and I kind of managed to understand how it works. Nowadays unfortunately it's a complex system of key management, account authentication, chat, file encryption, and more. I have no way to fully understand that system. Simplicity is an under-appreciated feature.
  - pornel 8y ago
    Oh yes! Keybase went full-Skype. I loved the concept of verifiable identity and that I could use it even with "plain" gpg commands without having to trust their client. Unsurprisingly, there was no way to monetize this, so they've had to pivot to being SlackDropboxIDontKnowWhat.app
xur17 8y ago
A bit of a tangent, but is something like BIP39 (seed words that can be used for backup for cryptocurrency wallets) possible for gpg? It would make backups 100x simpler.

305 points by 1wilkens 8y ago

I wish gpg had a decent cli/"api" At work, we use it to store shared secrets. We can encrypt a file that can be decrypted by multiple keys. It's a bit hard to remember all the commands so I made a webUI to manage everything. The feature I like the most is that I can list which files you can access and which files you cannot. The thing is, to do that, I need to pass tons of obscure and magic nonsense parameters IE: gpg --list-only --no-default-keyring --secret-keyring /dev/null ops.gpg and then parse the completely un-parsable output to know which keys can decrypt the file. So far so good. The problem is that; this magic trick only work with gpg 2.0.30 or lower. If you have the latest version, you can see every keys that can decrypt a file... except yours. There is no way to know if "You" can decrypt a file anymore ! (how great is this) I now have to tell people that if they want to use the nice UI they cannot have the latest version of gpg, which is troubling. I can't believe that in 27 years, it is still impossible to know which keys can decrypt a file. Or even just have some parsable output instead of the pile of crap the gpg tool can vomit out. So I'm pretty excited about Sequoia :)

sgift 8y ago
> then parse the completely un-parsable output to know which keys can decrypt the file. This reminds me so much about a tip in Effective Java .. 'Always provide an option for users to access every relevant part of your object. If not people will start to parse your toString output and you will have created an inofficial API that you have to support whether you want or not' (paraphrased from my faulty memory). That programmers make that mistake again and again is just sad. :(
- speedplane 8y ago
  This is what I love about Python. Every method is public, but methods that start with an underscore mean "use at your own risk". It suggests that the programmer use a preferred way, without strictly requiring it. Private methods treat programmers like infants.
  - sgift 8y ago
    IME if you allow someone to use your private API you can be sure they will do at some point. And then they will be unhappy when you change it. Sure, you can go with "I said it was private, your problem", but that is the road to zero users.
    - tjohns 8y ago
      So much this. I've seen it happen time and time again. At least in Java, the reflection API serves as a "break glass" barrier to make sure folks understand they're doing something they shouldn't. Someone will still do it, and they'll still blame you when their app breaks later... but I like to believe it at least scares some folks away.
      - speedplane 8y ago
        Honestly, I don't see people getting unhappy at breaking private API functionality. Most grab a library when they need and never upgrade it. They only do so when there's a necessary security risk or some wiz-bang new feature they need. The common example: programmer grabs a library to solve a problem; a few weeks later they realize it doesn't really solve the problem and requires modifications to the library to do some custom job; they make the modifications. That's normally the end of the story for several years. No point in upgrading the library unless it really solves a business problem. That constitutes the vast majority of developers. Of course there are other organizations that always want the latest and greatest version and are constantly upgrading. To them, I'd say sure, stick to the public methods, otherwise you're creating a big headache down the road. But I wouldn't require it of them.
  - simias 8y ago
    IMO there's a difference between "use at your own risk" and "this is actually not meant to be called from the outside and if it is it will violate some invariant in the code". Those are two different concepts and it makes sense to distinguish them. Of course in high level highly managed languages like python it makes sense that the difference between the two can be rather fuzzy at times but in low level code there's often a clear difference. Take for instance a socket class in C++, you might have a private method that deals with the low level details of the libc's socket calls. It's called at construction time and never later, and calling it would cause the current socket to be replaced by the new one (leaking the fd in the process) because it's only meant to be used at init time. Clearly it's not "use at your own risk", it's "code that calls this from the outside is fundamentally broken". Having the compiler enforce this invariant is a useful feature. Meanwhile you can also have "use at your own risk" methods, for instance "get_raw_fd" if you want to be able to access the underlying socket. It makes it easy to break things but has legitimate use cases. Of course you could say that you could just tag these private in a certain way and let coder discipline do the rest, but then again you could say that of pretty much all static validation (which, I suppose, makes sense if you like very dynamic languages like Python).
- zaarn 8y ago
  GPG is largely just this toString output parsing. Which has been the source of a number of bugs in various GPG clients in the past (a few even on the HN frontpage for a few moments) and probably will into the future until GPG is no longer used. tbh, GPG should just provide an RPC option so applications can securely pass data back and forth and receive proper error messages and codes. But I bet this won't happen because GNU fears that sort of things considering they won't split up the GCC compiler.
  - scandox 8y ago
    Well there is GPGME: https://gnupg.org/software/gpgme/index.html https://gnupg.org/software/gpgme/index.html But yes I mostly parse colon separated text.
  - admax88q 8y ago
    > But I bet this won't happen because GNU fears that sort of things considering they won't split up the GCC compiler. That's unfounded, there are plenty of GNU projects that have an API.
    - zaarn 8y ago
      It's not unfounded. The GCC compiler isn't splitting up because they fear someone would build a proprietary compiler using either backend or frontend API if they did it. I can see that the same reasoning here would be valid; someone could write a proprietary GPG frontend.
      - admax88q 8y ago
        You have one example of a project not providing an API, however there are tons of other GNU projects which do. Furthermore the GCC decision is well documented in mailing list posts, have you ever seen anyone involved in GPG development claim that they won't allow a library/frontend split for fear of someone writing a proprietary frontend?
- doesnt_know 8y ago
  Hyrum's Law With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody. http://www.hyrumslaw.com/ http://www.hyrumslaw.com/ I'm in a team where all the consumers are only other internal teams and yet this still happens. I've found that it doesn't matter if you explicitly state to not rely on a particular behavior in your documentation, clients still will. It's always your fault if you break it because "it was your change that broke this client" and "it was working fine yesterday".
  - Nae3Au5x 8y ago
    Some people may depend on them, but the difference between API guarantees and implementation details is that developers are far less reluctant to break your legs... I mean your application if you depend on the latter. For example in java the iteration order of hash maps or the behavior of sorts in presence of non-reflexive comparators changed and people did depend on that. Sun was able to change it because it was not part of the API contract.
    - pure-awesome 8y ago
      Man, depending on sort order with a non-reflexive comparator is a TERRIBLE idea. Almost on the level of https://xkcd.com/1172/ https://xkcd.com/1172/
Freak_NL 8y ago
Have you had a look at pass¹? It's a bash script that uses gnupg to encrypt secrets as gpg-encrypted plain text files. It has a very nice feature that allows you to specify a list of keys for all secrets in a specific directory (using a .gpg-id file). Once set up, accessing the secrets is a matter of using the pass command line tool: pass edit some/secret # Copy the first line of a secret; by convention # this is meant for a password: pass -c some/secret # Show the whole secret file: pass some/secret # Combined with git: pass git pull # Generate a 24-character random password: pass generate some/othersecret 24 pass git push We use pass to maintain a set of shared secrets with a small team. The (encrypted) files are pushed to private git repository (pass supports this out of the box). 1: https://www.passwordstore.org/ https://www.passwordstore.org/
- wuschel 8y ago
  Out of interest: How big of a threat is keeping diff files/versioned encrypted containers around when it comes to preventing breaking the encryption? I could imagine that the additional information will reduce the security of the information.
  - simias 8y ago
    The only problem I can foresee (assuming that the encryption scheme itself has no weaknesses to things like known plaintext attacks) is that it makes it harder to retire an old, potentially compromised key. You need to expunge the git history and any copies.
    - wuschel 8y ago
      Makes sense. Thank you.
- esseti 8y ago
  can you elaborate or point me to a resource how to use it to share secret for projects? i tried the pass, but it sotres the credentials in my home, i would rather prefer to have them in a file in the project, moreover, can also it encrypt .env files or some sort of it?
eterps 8y ago
Looking at the `sq` command line client doesn't instill hope to me that it is going to be friendly: https://docs.sequoia-pgp.org/sq/index.html https://docs.sequoia-pgp.org/sq/index.html But if it's at least going to be consistent that would already be a big win.
- dmoreno 8y ago
  Now it needs a --output=json option to make it awesome and usable from scripts and programs.
  - nwalfield 8y ago
    We've been considering this, but we'd rather have people use the library. We already have the start of a Python interface, which is pretty easy to use, IMHO. But, I suspect that some people will insist on a shell script. So, we'll probably go this route sooner rather than later to avoid developers trying to parse the output of sq in an ad-hoc manner.
- nwalfield 8y ago
  What would make a friendly interface in your opinion? The sq frontend uses git style subcommands to clearly separate actions from options. This is something that gpg doesn't do too well. For instance, commands (e.g., -e) look like options (e.g., -r). If no command is given, gpg tries to guess what you meant, which is perhaps good for users, but bad for programmers. And if an option isn't relevant to a command, it is often just ignored, which again, is perhaps reasonable for users, but bad for programmers.
  - eterps 8y ago
    I have nothing against the git style subcommands, in fact I think they are great. A friendly interface would in my opinion be from the perspective of an end user. In the case if GPG the end user can have a couple of goals in mind, to encrypt, decrypt or sign data. Although you could do a lot more things, for most users those would be secondary goals. I guess the average user doesn't necessarily know about autocrypt, ASCII armor, OpenPGP packets etc. Those users would have to guess whether they need to (do I need autocrypt? Why isn't it a default?). To be honest I don't think the usage output is very bad in its current form, but as a start for something that will evolve over the years I am not so sure.
toyg 8y ago
I'm sure you've already considered all the possible solutions, but why don't you run gpg in a subprocess as a different user, so it can list "Your" key (unless by "you" you mean "the user that originally encrypted the file")...?
megous 8y ago
Or, you know, you can contribute JSON output to GPG. I mean, opensource and stuff.
ataturk 8y ago
I'm not sure I follow you here. The whole point of public key encryption is that one key looks like any other key. If there is extra information available, such as knowledge of which keys can decrypt which files, isn't that defeating the whole purpose? A key is a key is a key. Some keys decrypt the original data, the rest decrypt into gobbledygook.
yrro 8y ago
I think the API is the GPGME library? https://gnupg.org/software/gpgme/index.html https://gnupg.org/software/gpgme/index.html ... which internally calls gnpg using the --with-colons argument which is how you're supposed to get machine-readable output. That said, maybe your use case isn't very accessible via the standard gpg commands. It sounds like you want to parse the ciphertext and extract the recipient keyids? You can do that with gpg --list-packets, but this is really intended for debugging, not automated consumption. That said it doesn't look too hard to parse, but who knows how stable it will be in the future.
- yrro 8y ago
  (for example) gpg --list-only --list-packets foo | gawk '/^:pubkey\>/ { print $9 }'
fanf2 8y ago
I have a command-line wrapper around gpg for similar reasons - https://dotat.at/prog/regpg/ https://dotat.at/prog/regpg/ The magic you are missing is `--quiet --status-fd 1`, then look for ENC_TO lines - the documentation can be found in https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=doc/DETAILS;hb=HEAD https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;... Based on my testing this works with gnupg 2.1 and 2.2, so I think it should help with your problem.
- klodolph 8y ago
  Yes, more people should know about the --status-fd option. I only wish there were a version that gave JSON output or something a little more foolproof to parse, the record syntax is easy to analyze with sed/awk/etc but you have to look up the docs for the meaning of each field and I wonder about the quoting sometimes.
jandrese 8y ago
Oh god this. GPG's commandline is so inconsistent and frustrating to use. Plus it has all of these concepts that hardly anybody cares about in real life. Like the "trust level" of a key in the system. There are 5 (maybe 6) trust levels and it would take someone really paranoid to use most of them. Of course imported keys default to the lowest (most useless) level so you have to change it, which is a pain in the ass to do from the commandline (you have to write an expect script or do a wholesale import of a "trust database"). And then there was Ubuntu 16 that couldn't seem to import private keys at all or must have required some kind of super secret commandline option to allow it. Honestly at this point I've been waiting for the inevitable article about how GPG has been maintained by one starving guy in his basement for the past 20 years and it turns out it's a total mess and nobody noticed because nobody was looking. Basically OpenSSL all over again.
- Boulth 8y ago
  New GnuPG can use TOFU trust model that simplifies this flow (an example here: https://www.kernel.org/category/signatures.html#using-the-web-key-directory https://www.kernel.org/category/signatures.html#using-the-we... ). > Of course imported keys default to the lowest (most useless) level so you have to change it You don't need to adjust trust levels, just sign the key locally (lsign) and it'll be valid. (there is a difference between key validity and trust, check out this excellent resource https://www.linux.com/learn/pgp-web-trust-core-concepts-behind-trusted-communication https://www.linux.com/learn/pgp-web-trust-core-concepts-behi... ).
  - jandrese 8y ago
    That article makes the Web of Trust seem like an even bigger mistake. Once you have more than handful of keys in the system the interactions become complex, too complex for good security IMHO.
    - Boulth 8y ago
      Does it? For a key to be considered valid it must be either ultimately trusted, signed by ultimately trusted key or one fully trusted valid key or 3 marginally trusted valid keys. It seems to me there are only two properties to track and quite easy calculation to do (fizz buzz level).
mjevans 8y ago
Are you adding your own identity to the list of recipients? This works for gpg 2.1.18 gpg -u ${MYHEX} --batch --passphrase-file /path/to/some/hard-coded-passphrase --compress-level 1 --cipher-algo AES256 --sign --encrypt -r ${MYHEX} -r ${RECP1} -r ${RECP2} -r ${RECPn} -o ${OUTPUTFILE}.gpg ${INPUTFILE}
eridius 8y ago
Have you looked at Keybase? It offers a wrapper around the GPG commands. I know it can be used to encrypt/decrypt and sign stuff, but I haven't looked at it in detail so I don't know if it will suffice, but it might. `keybase help pgp` will list the commands. I'm also not sure if it's usable if you don't have a Keybase account (though those are free).
danenania 8y ago
EnvKey[1] might be interesting to you (disclaimer - I'm the founder). It's similar in principle to the homegrown system you've created, but has had a lot of time put into smoothing out the ux. It gives you a single place to manage configuration/secrets for all your projects. It uses OpenPGP.js (maintained by ProtonMail) and golang's crypto/x/openpgp instead of gpg. 1 - https://www.envkey.com https://www.envkey.com

nwalfield 8y ago

While at the Delta X gather last week, we recorded an introduction to Sequoia. The presentation covers our motivation for starting the project, an overview of Sequoia’s architecture, and the project’s status: https://www.youtube.com/watch?v=NBbtIZipeNI https://www.youtube.com/watch?v=NBbtIZipeNI The tl;dr is that we’re actually pretty far: Sequoia is already being tested with the p≡p engine, and other projects, like Delta Chat, have begun replacing GnuPG or NetPGP with Sequoia.

deleted 8y ago

[deleted]

tlamponi 8y ago

Maybe also interesting: https://neopg.io/ https://neopg.io/ It's (also) from a former GPG dev, bases on the GPG source where some of the targets are: * switch to C++, allowing to reuse the legacy code, with lots of code thrown out * move to a single binary (again) Now, C++ is naturally not your fancy new language and the rewrite-it-in-rust people may run to their pitchforks but he has a blog post entry where he argues his choice: https://neopg.io/blog/cplusplus/ https://neopg.io/blog/cplusplus/ TLDR: He can build upon the well established GPG, C++ is mature and it's flaws are known and can be avoided an worked around. He even mentions the Sequoia Project in the last paragraph, and envies them a bit as they can use Rust. (for the record, nothing against rust or sequoia, just wanted to show a related project)

pjmlp 8y ago
While C++17 is a pleasure to work with, versus C++98, this kind of thinking only works out in very small teams (<= 5), very focused on quality assessment tooling like analyzers. Making developers avoid C style coding on C++ code is a continuous fight.

fbender 8y ago

Does it go beyond the minimum and old set of ciphers in use by the usual implementations? I'm asking because I firmly believe that any GnuPG re-implementation should try to improve on the current state of mail crypto [0]. [0] https://blog.cryptographyengineering.com/2014/08/13/whats-matter-with-pgp/ https://blog.cryptographyengineering.com/2014/08/13/whats-ma...

nwalfield 8y ago
Let's go through Matt's major points: Key Exchange / Key Management This isn't really a problem with the OpenPGP protocol or an OpenPGP implementation. This is inherent to any system that tries to protect you from active adversaries. If you are willing to use centralization, then you can do something like X509 (what is what TLS uses), but there are many, many cases of CAs issuing bad certificates either by accident or maliciously, e.g., the TURKTRUST incident. You can also do something like Signal with its verified key servers. But, if you want to be decentralized, then somehow you have to get the user involved. So, in my opinion, this is more a criticism of decentralization than of OpenPGP. Now, that doesn't mean that OpenPGP tooling can't help. In fact, about 4 years ago, several initiatives began working on mechanisms to make key discovery much easier, and mostly transparent for users primarily concerned about privacy (as opposed to those whose threat model includes active adversaries, like activists, lawyers, or journalists). See, in particular, the work that pep (https://pep.foundation https://pep.foundation) and Autocrypt (https://autocrypt.org https://autocrypt.org) have been doing. Forward Secrecy As I've written before (https://arstechnica.com/information-technology/2016/12/signal-does-not-replace-pgp/ https://arstechnica.com/information-technology/2016/12/signa...), I don't think that forward secrecy is actually fixing a problem that most people have. Particularly in the case of OpenPGP where most people are interested in encryption of data at rest (messages stored on an IMAP server), which forward secrecy doesn't help (forward secrecy, because it throws away old key material, only makes sense for protecting data in motion). But, that doesn't mean that we haven't given some thought to the problem. In fact, at the very same gathering, Justus, who is also working on Sequoia, presented a proposal for adding forward secrecy to OpenPGP in a backwards compatible manner. You can watch the presentation (https://www.youtube.com/watch?v=an6oYjikAPY https://www.youtube.com/watch?v=an6oYjikAPY), or read an early version of the proposal (https://mailarchive.ietf.org/arch/msg/openpgp/mk8_FSS-n4DVGfh_VwuGtEOS2xk https://mailarchive.ietf.org/arch/msg/openpgp/mk8_FSS-n4DVGf...). The short version is: OpenPGP already has mechanisms to mark encryption keys as being appropriate for data at rest or data in motion. Until now, no implementation has bothered with this distinction. We propose creating two encryption-capable subkeys, one for data at rest, and one for data in motion, and rotating the one for data in motion once a week. To ensure that a sender has a non-expired encryption key we pre-generate keys, and distribute them via the keyserver network. The OpenPGP format and defaults suck It is true that OpenPGP has standardized a number of ciphers that are no longer sensible, includes compression support, etc. But, OpenPGP is over 30 years old. In that time there have been many improvements. But Matt is right that these improvements come slowly. This is partly due to the lack of funding: the industry choose S/MIME over OpenPGP. (Although S/MIME is cryptographically worse than OpenPGP. See EFAIL for a critical example of why.) A major difficult to deprecating old ciphers is that OpenPGP is used for data at rest. And people rightly expect, I think, to be able to decrypt data and verify signatures from X years ago. This means we can't completely drop support for, say, CAST5: people wouldn't be able to decrypt old messages. Matt seems to ignore this bit, and focuses primarily on real-time communication (e.g., Signal), which only needs encryption for data in motion, i.e., the encryption is stripped and only archived on a trusted device (e.g., not an IMAP server). One thing that we are consider in Sequoia is requiring the caller to provide a timestamp when verifying or decrypting a message. The timestamp can be used to choose defaults that are appropriate for when the message was allegedly created. The timestamp can be double checked with the timestamp in the signature. In this way, if someone tries to send you an email using a deprecated cipher, they'll also have to set the timestamp in the email to, say, 1997, which would hopefully be suspicious. Likewise, something like a can be shown when the message doesn't meet the current standard. I hope that helps! If you have any other questions, you're welcome to ask here, or on irc (#sequoia on freenode) or on our mailing list (devel@sequoia-pgp.org). :) Neal

dvdplm 8y ago

This uses the Nettle crypto library under the hood. Does anyone know how well viewed (or reviewed) it is? I'm curious to hear more from the devs on their reasoning for picking it (maybe it was the only one with the features needed and a suitable license?) https://www.lysator.liu.se/~nisse/nettle/ https://www.lysator.liu.se/~nisse/nettle/

flanfly 8y ago
Nettle implements most of the crypto needed for OpenPGP, it's small size and few dependencies makes it easy to wrap for Rust. I did review some, but not all of Nettle and it looks pretty solid[1]. GnuTLS uses Nettle, so you can expect there are people smarter than me trying to break it. Initially, I wanted to use Botan, but the fact that it's in C++ means you need to write two wrappers one from C++ to C and one from C to Rust. 1: I checked for proper RSA base blinding, a secure CPRNG, lack of Bleichenbacher Oracles and lack of invalid curve attack vectors. It uses GMP for bignum stuff so carry propagation bugs are unlikely. There are some things that aren't super nice. The CPRNG does not reseed on forks, the included AES doesn't look particularity time constant and the library doesn't use mlock() nor zeros secrets after use.
- randombit 8y ago
  Alas, I just started working on a Rust wrapper for Botan https://crates.io/crates/botan https://crates.io/crates/botan The existing Botan C API is in fact sufficient for OpenPGP already, https://github.com/riboseinc/rnp https://github.com/riboseinc/rnp is in C++ now but was originally C and uses Botan's C API. But Nettle is IMO quite solid and the developer is very skilled, so full steam ahead. Is there any relation between Sequoia and the BoringPGP spec?
  - flanfly 8y ago
    Yes, I'm a co-author of BoringPGP[1]. Sequoia itself will probably support it as soon as Marcus and I get around finishing the spec but it's not part of Sequoia and I only work on it in my free time. 1: https://github.com/boring-pgp/spec https://github.com/boring-pgp/spec

mynewtb 8y ago

That name is unfortunate because most of the world has no clue how to pronounce or spell it.

Thomashuet 8y ago
How is that different from any other name? Actually Sequoia is an English noun and as such I expect it to be more familiar than many other names. Even better the same word exists in many other Latin script languages. I know that there are a many more languages in the World but none of them is as widespread as English.
- EugeneOZ 8y ago
  > I know that there are a many more languages in the World but none of them is as widespread as English. You will be surprised. https://en.wikipedia.org/wiki/List_of_languages_by_number_of_native_speakers https://en.wikipedia.org/wiki/List_of_languages_by_number_of... https://www.babbel.com/en/magazine/the-10-most-spoken-languages-in-the-world/ https://www.babbel.com/en/magazine/the-10-most-spoken-langua...
  - jcranmer 8y ago
    If you count by L1 speakers, English is only third. If you count by number of people with working proficiency of the language, English has somewhere between 1 and 2 billion speakers, which is probably more than the number of Mandarin speakers. Second language stats are really sketchy, but English is unique for being a language which is among the top native languages and having many more non-native speakers than native speakers.
    - deleted 8y ago
      [deleted]
    - EugeneOZ 8y ago
      As you can see, I respect you more: I spend some of my time to provide links for you as proofs. But nevermind, it's offtopic anyway. And it's not so important for me to argue about :)

aorth 8y ago

What about opmsg as a GPG replacement? > opmsg is a replacement for gpg which can encrypt/sign/verify your mails or create/verify detached signatures of local files. Even though the opmsg output looks similar, the concept is entirely different. https://github.com/stealth/opmsg https://github.com/stealth/opmsg

lmm 8y ago
Your messages have perfect forward secrecy except when they don't, because it uses DH but falls back to RSA when it runs out of keys. That's a security failure waiting to happen; IMO no forward secrecy is a more user-friendly model than "perfect forward secrecy except sometimes not". Support for multiple recipients is inherently a mess in that kind of model. No effort is made to even try to solve the identity problem PFS aside it doesn't seem to do anything you couldn't do with GPG - e.g. there's nothing to stop you verifying GPG key fingerprints by hand or using different keys to communicate with different recipients. In particular it doesn't seem to offer any improvement on the big problem that this is about - good MUA integration. Ultimately that looks like a good project that takes those techniques as far as they can go, but also shows exactly why those techniques never made sense for an email-like environment.

maxtaco 8y ago

We at keybase developed a PGP replacement called Saltpack. It uses only modern crypto, with all the features you would expect like authenticated encryption and branch-free secret key operations (via the NaCl library). We have a better armoring format that won’t get mangled in modern markdown contexts. It is also integrated with our CLI and in the upcoming release we support encrypting for teams. https://saltpack.org https://saltpack.org

nasredin 8y ago
The web site design is so hipsterish :) I kept looking for "install" or "download". It's in "repos".
jwr 8y ago
The problem with keybase is that it has grown from a simple command-line tool (which I could perhaps trust) to a monster with a GUI, menu-bar icon, resident daemon, which does lots of things, and until recently failed to even properly start for me. The running process daemon is required even to use the CLI. I'm glad you are making a PGP replacement, but I'm worried that this will head in the same direction. I want simpler, auditable and understandable systems for crypto, not complex beasts with hidden interactions.
- dbrgn 8y ago
  I fully share that opinion. I loved Keybase for its simplicity: It was a way to verify keys based on social media accounts and thus a more practical alternative to the web of trust. The client was optional, I could track someone by using bash and curl, and I kind of managed to understand how it works. Nowadays unfortunately it's a complex system of key management, account authentication, chat, file encryption, and more. I have no way to fully understand that system. Simplicity is an under-appreciated feature.
- pornel 8y ago
  Oh yes! Keybase went full-Skype. I loved the concept of verifiable identity and that I could use it even with "plain" gpg commands without having to trust their client. Unsurprisingly, there was no way to monetize this, so they've had to pivot to being SlackDropboxIDontKnowWhat.app

xur17 8y ago

A bit of a tangent, but is something like BIP39 (seed words that can be used for backup for cryptocurrency wallets) possible for gpg? It would make backups 100x simpler.