kr icon indicating copy to clipboard operation
kr copied to clipboard

gpg-agent

Open madjam002 opened this issue 7 years ago • 4 comments

Just taking a look at this project and it looks really interesting.

I know there are some other issues open around PGP/GPG but I thought I'd open one specifically regarding gpg-agent. I currently use a Yubikey 4 as a PGP smart card and use it daily for things such as:

  • Git commit / tag signing
  • SSH authentication
  • Password manager (using passwordstore.org)
  • PKCS11 emulation for authentication to internal web servers using Scute [0]

Whilst gpg-agent does have its quirks, it works well for the above and is also useful for using the GPG keys on remote hosts by doing GPG agent forwarding over SSH [1].

I'm just wondering what your thoughts are on gpg-agent and potentially having a compatible daemon which worked with Krypton? By doing this, Krypton would theoretically work with GPG and the wide range of applications that use GPG and GPG agent. I have to be honest I have very minimal knowledge of the GPG agent protocol so it could be an absolute minefield, but I just wanted to float the idea to spark some discussion!

Cheers

[0] https://github.com/gpg/scute [1] https://wiki.gnupg.org/AgentForwarding

madjam002 avatar Jan 14 '18 23:01 madjam002

Thank you for sharing your PGP use cases! We already support Git commit/tag signing (and of course SSH authentication). Regarding pass, we actually have an issue open already regarding this as it requires decryption (we only currently support PGP signatures).

Regarding PKCS11, some PKCS11-compatible applications only provide the hash of the data to be signed, preventing the PKCS11 module from displaying to the user any useful information about what is actually being signed. We'd be happy to brainstorm what a Scute (or other SSL client cert) integration would look like, especially if useful authentication data is presented to the PKCS11 module.

kcking avatar Jan 17 '18 01:01 kcking

I'd like to start working on this feature, but I have a few questions.

Can I confirm the preferred behaviour is going to be using the gpg command as if the private key were stored locally?

And that this can be accomplished by writing a Krypton GPG daemon?

If so, could anyone give some rough steps on how this should be implemented?

Thanks! :)

fmckeogh avatar Jun 12 '18 19:06 fmckeogh

@chocol4te A GPG daemon probably makes the most sense to start with. There will be some additional work in adding appropriate request/response protocols for these delegated PGP operations to the iOS/Android app. Another potentially useful feature is to duplicate some of these commands into kr to do PGP operations with a Krypton-backed key without installing gpg.

agrinman avatar Jun 12 '18 19:06 agrinman

That's what I thought the alternative would be. Implement a few essential operations, but have the GPG daemon available for more complex stuff.

Agent forwarding seems to be the right option here? So I need to create a new Krypton-specific socket and write the iOS/Android agent.

fmckeogh avatar Jun 12 '18 20:06 fmckeogh