x/crypto/openpgp: new entities cannot be encrypted to by default

[zenazn]

The key returned by openpgp.NewEntity (https://godoc.org/golang.org/x/crypto/openpgp#NewEntity) does not express hash algorithm preferences, and by default openpgp.Encrypt (and perhaps others) default to using the RIPEMD160 algorithm (https://github.com/golang/crypto/blob/173ce04bfaf66c7bb0fa9d5c0bfd93e773909dbd/openpgp/write.go#L205), which is not compiled in unless one explicitly requests it. This means that the "obvious" way to generate keys and encrypt to them fails with the largely-inscrutible error message openpgp: invalid argument: cannot encrypt because no candidate hash functions are compiled in. (Wanted RIPEMD160 in this case.)

There are more than a few ways around this (populating PreferredHash being one obvious option, and defaulting to e.g., SHA-256 being another), but this seems like an awfully sharp edge to leave lying around.

[ianlancetaylor]

CC @agl @hanwen

[jessfraz]

I opened a patch with one solution for this here: https://go-review.googlesource.com/#/c/23209/ but unsure if it's too opinionated

[gopherbot]

CL https://golang.org/cl/23209 mentions this issue.

[ProtoFly]

Has this issue been resolved?

[jessfraz]

Not yet

On Friday, July 1, 2016, ProtoFly [email protected] wrote:

Has this issue been resolved?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#12153 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/ABYNbFND53R0hwCAlpHaCew-i-iOcACPks5qRTmIgaJpZM4FsAME
.

Jessie Frazelle
4096R / D4C4 DD60 0D66 F65A 8EFC 511E 18F3 685C 0022 BFF3
pgp.mit.edu http://pgp.mit.edu/pks/lookup?op=get&search=0x18F3685C0022BFF3

[ProtoFly]

My -sort of- fix was to use
_"golang.org/x/crypto/ripemd160"
in my imports.

Alas, still unsuccessful, as the code then generates:
openpgp: invalid argument: cannot encrypt to public key of type 17

Digging further (and showing my ignorance, most likely), the culprit is that this public key I am using is a DSA key, not RSA.

Perhaps not germane to this issue, but the error might be more useful if it indicated that DSA keys cannot be used for encryption, only signing.

As an aside, I'm new to Go, and your examples are very helpful jfrazelle. Thank you.

(Adding more - forgive if this isn't the right place): I've discovered that DSA keys -usually- have ElGamal sub keys, which can be used for encryption. However, the default 'Encrypt' won't work unless you promote the ElGamal sub key up to the top, and then it works.

Would a reasonable feature request be that if the DSA key is used AND it has an ElGamal sub key, that the Encrypt should attempt to use that, rather than return 'Cannot encrypt...type 17'?

[odeke-em]

Hello @jessfraz, I see that your CL was merged in September 2016, does this mean that this issue is then resolved?

[jessfraz]

Yes

…

On Sat, Feb 18, 2017, 02:26 Emmanuel T Odeke ***@***.***> wrote: Hello @jessfraz <https://github.com/jessfraz>, I see that your CL was merged in September 2016, does this mean that this issue is then resolved? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#12153 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABYNbNYKMzAGcODUL-LQVVMlQ6PWsVIdks5rdp0RgaJpZM4FsAME> .

[odeke-em]

Thank you for the confirmation @jessfraz. In that case I'll close this issue. @zenazn and @ProtoFly please get the latest crypto go get -u golang.org/x/crypto.