7 ms·

I saw people starting to use `age` as a replacement to gpg. Can someone speak to that?

• wolf550e 6y ago
  gpg does too many things. minisign does digital signatures (like for releases). age does encryption (like for backups).
  • SAI_Peregrinus 6y ago
    Age and Minisign also don't have the ability to misconfigure them to use insecure primitives. GPG does.
    • gravitas 6y ago
      Age is new to me, I immediately find there's a Go (age) and Rust (rage) implementation - which one is the encryption community at large favoring more? (stability, code quality, etc.) https://github.com/FiloSottile/age https://github.com/FiloSottile/age https://github.com/str4d/rage https://github.com/str4d/rage
      • woodruffw 6y ago
        I'm not involved with either, but I've looked at both for other projects[1]. The Rust implementation's CLI mirrors that of the reference (Go) implementation, and I haven't had stability issues with either. I found the Rust implementation's source code readable and decently documented. [1]: https://github.com/woodruffw/kbs2 https://github.com/woodruffw/kbs2
    • georgyo 6y ago
      At the time there were implemented in GPG they were not insecure. If age and minisign are around 10 or 20 years for now, we'll see if your statement is still true.
      • wolf550e 6y ago
        Obviously Filippo Valsorda will release a new version that fixes whatever the issue is and will deprecate the old version immediately. The new code might retain ability to decrypt the old version but not encrypt with the old version, for compatibility with old backup files or whatever. If he thinks it's safe to do.
        • georgyo 6y ago
          Okay, so you're trust is completely in one person having perfect design decisions and that he chooses to continue to maintain these tools in perpetuity. You also state that tool may or may not be able interact with past files. Which means it might be useless. Git is in the process of deprecating sha1, and you end up having the put flexibility in after a tool expands. It will likely keep supporting sha1 even after it is much more trivial to create collisions.
          • wolf550e 6y ago
            No one is getting locked out of their files created by an old version. There will be a migration path. The old code will be in git. Worst case, the spec is open, I can implement the spec myself in python, using pycryptodome and pyca/cryptography, it wouldn't be hard. I trust his judgement much more than I trust the group that maintains gpg. Of course, actually, there is a community, Filippo is not working in a vacuum. Worst case, if Filippo stops maintaining it or makes bad decisions, someone else (or a group of people) will maintain it.
    • upofadown 6y ago
      Well neither does GPG. Insecure stuff gets removed. Stuff that people just have a funny feeling about gets retained.
      • XMPPwocky 6y ago
        Well, yes, this bridge is built out of LEGO, and yes, it does bend a lot and make concerning noises every time a car drives over it, but it hasn't actually come apart yet, so we'll keep sending traffic over it.
      • wolf550e 6y ago
        current versions of gpg support insecure settings and the defaults are not what you want.
        • somedude11 6y ago
          Simply not true. Defaults are cryptographically strong.
    • dependenttypes 6y ago
      The simple fact that they are not integrated together makes it easy to misuse them. http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html
  • oauea 6y ago
    Can I store my key on a smartcard for either?
    • wolf550e 6y ago
      I guess you can use https://github.com/FiloSottile/yubikey-agent https://github.com/FiloSottile/yubikey-agent to store an ssh key on a yubikey, and then use age to encrypt to the ssh key. Getting minisign to sign using a key in a ubikey is not supported out of the box, but should be possible in the same way yubikey-agent works (after all, that's what it does when you authenticate an ssh session using a yubikey). You can ask Filippo Valsorda.
    • Snawoot 6y ago
      From project page: https://github.com/FiloSottile/age#ssh-keys https://github.com/FiloSottile/age#ssh-keys > (ssh-agent is not supported.) There is no way it integrates with smartcards.
  • melvyn2 6y ago
    I can't seem to use minisign with git, which is my main use for gpg.
    • dependenttypes 6y ago
      Signing git commits is broken anyway as you are basically signing the commit hash (which is a sha1, whose collision resistance is broken).
      • cordite 6y ago
        I recall hearing github is planning on Sha-256 some time
        • some_furry 6y ago
          They're more likely to employ counter-cryptanalysis [1] in the meantime. [1] https://github.com/cr-marcstevens/sha1collisiondetection https://github.com/cr-marcstevens/sha1collisiondetection
• parliament32 6y ago
  It's not a replacement: age is purely a file encryption tool. GPG is encryption, signing services, key management, web-of-trust, smartcard compat, and all sorts of bells and whistles. If you're just encrypting files and don't care about any of the other stuff it's probably a solid bet though.
  • soohyung 6y ago
    The argument for people using age to replace GnuPG (PGP really) is that there are better signing tools that you really should be using (minisign/signify) and PGP should not be used for the web-of-trust anymore anyway. There are many good arguments against PGP for all of these things.
• upofadown 6y ago
  Age has authenticated encryption so it is slightly more convenient for stuff like encrypting backups that you think might undergo some sort of known plain text attack. To prevent that with gpg you have to also sign the backup. This recent security thing makes it seem that GPG has also gained authenticated encryption. Dunno how I feel about that. OpenPGP stuff gets its security and reliability from simplicity. Adding stuff takes away from that. This security thing kind of supports that.
  • dependenttypes 6y ago
    GPG adds something that they call MDC, which is kinda similar to a mac in authenticated encryption schemes. It is enabled by default.
    • XMPPwocky 6y ago
      The MDC scheme exists- it's also sketchy as all hell. Wouldn't trust it if serious adversaries are a reasonable threat for you. https://github.com/gpg/gnupg/blob/master/g10/mainproc.c https://github.com/gpg/gnupg/blob/master/g10/mainproc.c
      • upofadown 6y ago
        Yeah, MDC was added as something better than nothing for unsigned messages/files. It has ended up being remarkably robust over the years, considering. The biggest deal is that you can entirely remove it. As a result stuff these days tends to consider a missing MDC as an invalid MDC.
• na85 6y ago
  GnuPG has a lot of legacy cruft like two key parsers and support for CAST5. The trend seems to be towards bespoke, tailored tools for specific purposes and away from unified crypto tools that do many things. Mostly I feel like gpg is too broad for one guy to maintain and needs to drop support for stuff to keep the scope manageable.
  • signal11 6y ago
    I’m looking forward to trying Sequoia PGP[1], a new OpenPGP implementation using Rust. Its opinionated high-level API and removal of MD5 and IDEA might just be the do-over OpenPGP needs. [1] https://sequoia-pgp.org/talks/2018-08-introduction/sequoia-introduction-deltax.pdf https://sequoia-pgp.org/talks/2018-08-introduction/sequoia-i...
    • upofadown 6y ago
      Both IDEA and MD5 are depreciated in the published OpenPGP standard. So implementations don't have to implement them. If they do it doesn't make any difference other than a bit better backwards compatibility. Since everything these days prefers better algorithms there are no negative security aspects to supporting IDEA and MD5.
      • tialaramex 6y ago
        Aside: The word you wanted was "deprecated" not "depreciated" Supporting obsolete and perhaps insecure algorithms can give your user false confidence. Adversaries do not prefer the better algorithms, they get to choose whatever suits their purpose and so by supporting an obsolete algorithm you let your adversary choose that if it suits them. So don't. The diediedie draft (now more respectably named https://datatracker.ietf.org/doc/draft-ietf-tls-oldversions-deprecate/ https://datatracker.ietf.org/doc/draft-ietf-tls-oldversions-... instead) deliberately tells people not just to support newer TLS versions but to stop supporting old ones, for exactly this reason.
        • upofadown 6y ago
• the8472 6y ago
  Nice, It supports encrypting with SSH keys. I was looking for something just like that.
  • dependenttypes 6y ago
    May I ask why?
    • the8472 6y ago
      Sending a newly created secret to a colleague. I already have his pubkey so I wouldn't have to worry about how trusted a channel is.
• tzs 6y ago
  Age is a bit awkward if you want to store your private key encrypted. $ age-keygen -o key $ grep public key | cut -f ' ' -f 4 > key.pub $ age -p -a -o key.prv key (enter passphrase to protect private key) $ rm key OK, now we have key.pub with a copy of our public key, and key.prv with the private key encrypted with a passphrase. Now suppose we receive a file, msg.sec, that was encrypted using our public key. If our key file were not encrypted, we could decrypt the message as so: $ age -d -i key.prv msg.sec With the private key encrypted, we need to decrypt it into a file, use the file with the above command, and then presumably get rid of the decrypted private key file. There are a few ways to do this on Unix and Unix-like systems. 1. Use an actual file. $ age -d key.prv -o key.tmp (enter passphrase) $ age -d -i key.tmp msg.sec $ rm key.tmp I dislike this. What if something like Time Machine happens to take a snapshot right as I'm doing this, and key.tmp gets into the backup? 2. Use a named FIFO. $ mkfifo f $ age -d -i f -o msg msg.sec & $ age -d key.prv > f (enter passphrase) 3. It has been suggested that process substitution could be used instead of a named FIFO: $ age -d -i <(age -d key.prv) -o msg msg.sec but this fails for me both on my Mac with bash or zsh, and on a Debian Stretch system with bash. On the Mac, with either shell, I get prompted for the passphrase, but it does not actually get read. If I kill the "age -d key.prv", the shell tries to execute my passphrase as a command. On the Debian system as soon as age prompts for the passphrase it them says "Error: could not read passphrase: could not read passphrase: input/output error" and exits. 4. On the Mac, use the clipboard. $ age -d key.prv | pbcopy $ age -d -i <(pbpaste) msg.sec; pbcopy < /dev/null (If you want the plaintext of the message on the clipboard, you could try this for the second line: $ age -d -i <(pbpaste) msg.sec | pbcopy That works most of the time, but occasionally I see it fail saying that there is a malformed key on /dev/fd/<some_number>). Note that this does show that there is no inherent problem with using process substitution to provide the key "file" to age for decryption. The problem in #3 seems to be when age is used for the command within the substitution and it has to prompt for a passphrase. 6. Similar awkwardness arises if rather than storing you private key in an age passphrase encrypted file you store it in a password manager, such as in a 1Password secure note. If you copy the private key, you need to find a way to paste it to age. Process substitution works: $ age -i <(echo AGE-SECRET-KEY-18CP0EEC6QAZ09FG9R423JMMWRFSGVR32ANET54EHQ7ZHW690DVKSR07ZHQ) -d msg.sec You might not want the key echoed on the terminal. This would work to avoid that: $ mkfifo f $ SAVE=$(stty -g) $ age -d -i f msg.sec & $ stty -echo $ cat > f (paste the private key, hit return, hit ctrl-d) $ stty $SAVE $ rm f It would be a lot less awkward if -i simply accepted encrypted key files.