Add new output format: "signify"

[KAction]

This is BSD tool used to sign release, with simpler interface and without support of old key types. It does not do encryption.

This is how signify can be used:

$ signify -G -p new.pub -s new.key $ signify -S -s new.key -m message.txt # creates message.txt.sig $ signify -V -p new.pub -m message.txt # checks signature

Now first step can be replaced with

$ passphrase2pgp -f signify > new.combined

First two lines in generated file are public key, next two -- secret key. Note that first line in both starts with "untrusted comment: ". signify(1) insists for it to be the case.

[skeeto]

Thanks, Dmitry! I'm interested in accepting this, and I've pushed some additional changes reflecting how I plan to do so. They make no actual changes to the output.

However, I don't like the keynum derivation. If two people happen to pick the same User ID, they'll have the same keynum, which defeats the purpose of the keynum as a unique key identifier. Instead it should be derived from the public key, itself derived from the ID and passphrase. If two people pick the same passphrase, then the game is already lost.

With zero KDF rounds, the salt is unused, right? It could simply be zeroes. If this output format supported --protect (-e) — which is currently not the case — then the salt matters, but it should also be randomly generated, not derived from the ID or even the key. Protection encryption shouldn't be deterministic.

So for keynum I'm thinking hash the public key, just a straight SHA-512 truncated to 8 bytes. SHA-224 which is merely SHA-512 truncated (well, plus a different initial state), and truncating twice instead of once seems arbitrary.

What do you think?

[KAction]

Thanks, Dmitry! I'm interested in accepting this, and I've pushed some additional changes reflecting how I plan to do so. They make no actual changes to the output.

Looks fine. I don't have much to say about style of go code.

However, I don't like the keynum derivation. If two people happen to pick the same User ID, they'll have the same keynum, which defeats the purpose of the keynum as a unique key identifier. Instead it should be derived from the public key, itself derived from the ID and passphrase. If two people pick the same passphrase, then the game is already lost.

Makes sense. I am sure I can do this.

With zero KDF rounds, the salt is unused, right? It could simply be zeroes. If this output format supported --protect (-e) — which is currently not the case — then the salt matters, but it should also be randomly generated, not derived from the ID or even the key. Protection encryption shouldn't be deterministic.

This format supports passphrase that protects key. I was not exactly correct in my commit message. Actually, signify -G asks you for passphrase unless you also pass -n. So I guess I can also respect --protect part of config. You suggest that I do 64 rounds, like with ssh, or it should be configurable?

So for keynum I'm thinking hash the public key, just a straight SHA-512 truncated to 8 bytes. SHA-224 which is merely SHA-512 truncated (well, plus a different initial state), and truncating twice instead of once seems arbitrary.

Wasn't aware of this relation. Sure, sounds easy.

[skeeto]

That new keynum looks good.

You suggest that I do 64 rounds, like with ssh, or it should be configurable?

Looks like signify uses 42 rounds, unconfigurable. It makes the most sense to me to just match this.

https://github.com/aperezdc/signify/blob/7960f78/signify.c#L876

[skeeto]

Since there wasn't much to it, I added --protect support for signify keys in 757a5a9. I'm happy with things at this point, so if you're satisfied then I'll merge it.

[KAction]

Looks good to me. Took some time to understand that it works because arrays are zero-initialized.

[skeeto]

Merged as ed7f62f079ca3265484a971ab25a4d17f5a6ef00 and cf2aee7c1e5a2ccf438141fbd3deccb457def47e. Thanks! I also tagged v1.3.0 with the new feature, so it's now "live."