Saltpack – A modern crypto messaging format | Hacker News Reader

Saltpack – A modern crypto messaging format

github.com

101 pointsniksmac23 comments

The https://saltpack.org/ web-site links to a insightful post about authenticated encryption with associated data (AEAD) and the shortcomings addressed by saltpack: https://www.imperialviolet.org/2015/05/16/aeads.html

The streaming AEAD problem is being solved in http://age-tool.com/

Vaguely related for people who want simple secure encryption tools is Age: https://github.com/FiloSottile/age

How are people handling private keys in age?

I don't really want my private key file just sitting around in plaintext.

One obvious thing to do is to use age to encrypt that file with a passphrase. I had hoped that if you gave age a passphrase encrypt file in place of a plaintext private key file, it would recognize it and ask for the passphrase, but alas, it does not.

So far, the only way I've found to do this without making a temporary copy of the plaintext private key on disk is to use a FIFO. Given a file, "input", encrypted to my public key, a file, "key.dat" containing my age private key encrypted with a passphrase, this decrypts "input" to the file "output":

  $ mkfifo f
  $ age -d -i f input > output &
  $ age -d key.dat > f
  ...age prompts for the key.dat passphrase...

Another approach would be to make and mount a RAM disk, decrypt the public key to that, decrypt input, and then unmount and destroy the RAM disk, but that seems more bother, and also less portable. The FIFO trick should work on any modern Unix or Unix-like system.

This is assuming I even want a key file. Age keys are quit small. Here's a private key it just made for me: "AGE-SECRET-KEY-15KMEW7TZY2T02V33ZM0MPH65CTTGHFY34DP2PDQDXFZGT3JU8GQQ5GDAYU"

That's small enough that I'd be happy to store all my private keys in my password manager, and copy/paste from there when I need one. The FIFO trick can work with that:

  $ age -d -i f input > output &
  $ cat > k
  ...paste in the key...

That echos the private key to the terminal, though, so maybe something like this?

  $ SAVE=$(stty -g)
  $ stty -echo
  $ age -d -i f input > output &
  $ echo "Paste the key, press RETURN, then control-D"
  $ cat > k
  $ stty $SAVE

I suppose that can be turned into a little shell script, so not having direct support for encrypt private key files is not too annoying--at least on Unix and Unix-like systems.

Is there a reasonable way to do this on Windows?

process substitution might help you avoid an explicit fifo; it should work for this example but in general handling stdin can be tricky when using process substitutions.

    age -i <(age -d key.dat) -d input > output

if you're using gnu pass to store private keys, you could do something like

    age -i <(pass age-key-personal) -d input > output

Not my areas to comment on the technical details, but have things improved since the first time this was on HN [1]?

Seems like some of the choices they made were getting bashed, though I'm not sure the reasons were more than personal preferences.

[1] https://news.ycombinator.com/item?id=14067003

Edit:typo

Finally, some attempt to rebuild the transparent, copypastable, text-based crypto message format. Binary messaging is not a replacement.

Cannot comment on the crypto part yet, but the general idea is excellent, we need this.

It's NaCl plus Base62 encoding with a fairly simple framing method, that should be fairly rocksolid as far as crypto goes. Internally it's messagepack with binary data for the internal payload, so that's also pretty good and solid.

Every messagepack library I’ve encountered is optimized for speed and not memory or type safety. That’s a bit concerning in a secure messaging format.

That shouldn't matter much here, as long as the underlying crypto is fine, baring any very bad exploits in the message pack library, any manipulated message should fail authentication.

They memory safety and type safety of the messagepack library do matter I think: as with PGP, there’s nothing to stop a bad guy from obtaining your public key and sending you encrypted messages. In fact, distribution of public keys is encouraged.

Unlike PGP, this library is interfaced with a FFI interface or you can write your own lib without too much effort. PGP requires understanding it's stdio RPC format. That is the source of some issues related to malicious messages. And of course that PGP doesn't much care where it finds them.

The later very much depends on the email client but the former is less of an issue.

In a worst case using this, you'll be looking at a crash in your client. Code execution is an unlikely issue in Go. The lib doesn't care much about the inside format of the message so that should be a non-issue as well.

I think PGP just gave this sort of messaging format a bad rep because PGP has a bunch of issues related to "being able to cleanly decrypt and encrypt a message".

Shameless plug: https://github.com/gsliepen/packmsg. I tried to create a very fast C implementation (the C implementation of MessagePack is quite slow actually), but also one that is very safe to use, given the constraints of the language.

Can anyone security minded comment on how this tool compares to the Scuttlebutt Secure Handshake[1]?

Notably I've been looking at various modern "safe and easy" crypto tools and found Scuttlebutts handshake interesting. Yet, the entire protocol was a bit difficult to use, and left me with the impression that I'd have to write a lot myself in my preferred language (Rust) to get a batteries included experience. And, for good reason, I'm always hesitant to write anything about crypto hah.

... though, now that I'm looking for a Rust salt pack lib, it doesn't seem to exist in Rust either. Humm.

[1]: https://ssbc.github.io/scuttlebutt-protocol-guide/#handshake

More interesting details can be found here: https://saltpack.org/encryption-format-v2

This is excellent! We need more work like this that is standardized and stable.

From the protocol end, I heard good things about noise [1] but I haven't seen acual apps make use of it(Edit: It literaly says "Noise is currently used by WhatsApp, WireGuard, Lightning, and I2P." On their page). I highly encourage the author of saltpack to keep a reference list of projects that make use of saltpack.

[1] http://noiseprotocol.org/

Noise is a bit different in that it's mostly for creating DH protocols with a reduced chance of shooting oneself in the foot. Saltpack seems like it's a wrapper for AEAD encryption w/nacl's secretboxes that also does serialization via messagepack? I'm not sure I see the point of a "crypto messaging format" that pastes nacl and messagepack together and calls it a standard.

I think they're similar in that as you pointer out they reduce the chance of you shooting yourself in the foot. Perhaps a project using noise for data-in-motion and saltpack for data-at-rest(and before transmission) would involve less foot shooting?

I haven't seen any references of Saltpack being used by anybody yet.

don't know about references but in the footer of the website it says "Saltpack's been in active development by Keybase and collaborators since 2017."

How does it compare to age-encryption.org?

I believe Age doesn't have the dependency on messagepack.

I do like Saltpack's ASCII armour format better, though.

It's fairly similar.

Reply on news.ycombinator.com