PGP/Inline support

[w4]

Having a quick look at the source, it doesn't look like PGP/Inline is supported. PGP/Inline is used a lot more now that Keybase is a thing. You encrypt your message as you normally would, and then sign the encrypted text with your private key. kbpgp handles everything to do with unboxing the signed text when you call unbox.

Would you like me to add support?

[mbilker]

Thanks for my first report! Yes I would like a PR to add this. I didn't know kbpgp supports that. I am still writing the list component for the composer view. Also a better key management system using RPC with the worker process.

[mbilker]

For clarification, this is PGP message signing, not encryption. Right?

[w4]

The way it normally works is: you encrypt a message with my public key and then sign it, which gives the receiver proof of the person who sent it too. For example if you wanted to send an email to me, you'd run:

gpg -se -r "Jordan Doyle" -a

and then copy the output to your email window. Once I receive the email, I get both proof of the person who sent the email (since you signed with your private key) plus the encrypted email contents.

[mbilker]

Okay then. I saw the GPGTools emails sign the emails then encrypt the whole thing. Facebook does this similarly except they embed a One Pass Signature in the decrypted packets, which is signed with their own key.

[mbilker]

@w4 An example for the Facebook encrypted message:

gpg: encrypted with 4096-bit RSA key, ID 0x131249839084B390, created 2015-06-02
      "keybase.io/mbilker <[email protected]>"
# off=0 ctb=85 tag=1 hlen=3 plen=524
:pubkey enc packet: version 3, algo 1, keyid 131249839084B390
    data: [4096 bits]
# off=527 ctb=d2 tag=18 hlen=2 plen=0 partial new-ctb
:encrypted data packet:
    length: unknown
    mdc_method: 2
# off=548 ctb=a3 tag=8 hlen=1 plen=0 indeterminate
:compressed packet: algo=2
# off=550 ctb=90 tag=4 hlen=2 plen=13
:onepass_sig packet: keyid C472470ADA25FF20
    version 3, sigclass 0x00, digest 10, pubkey 1, last=1
# off=565 ctb=cb tag=11 hlen=2 plen=0 partial new-ctb
:literal data packet:
    mode b (62), created 1450135326, name="",
    raw data: unknown length

Notice the onepass_sig signed with Facebook's subkey. So I get this output from GPG:

gpg: Signature made Mon 14 Dec 2015 06:22:06 PM EST
gpg:                using RSA key 0xC472470ADA25FF20
gpg: Good signature from "Facebook, Inc." [full]

[mbilker]

@w4 For a GPGTools message, the signature packet is embedded in the raw plaintext of the message. Here is the packet that is returned:

gpg: encrypted with 4096-bit RSA key, ID 0x5A8775F9A7E91295, created 2015-04-08
      "Zlatko Bijelic (Zlatko Bijelic @ Gmail) <[email protected]>"
gpg: encrypted with 4096-bit RSA key, ID 0xA50BA4DEB9B3B2DA, created 2015-11-24
      "keybase.io/mbilker <[email protected]>"
# off=0 ctb=89 tag=2 hlen=3 plen=540
:signature packet: algo 1, keyid 5C7B53BB7CFF2F57
    version 4, created 1450060896, md5len 0, sigclass 0x01
    digest algo 10, begin of digest f5 36
    hashed subpkt 2 len 4 (sig created 2015-12-14)
    subpkt 16 len 8 (issuer key ID 5C7B53BB7CFF2F57)
    data: [4096 bits]

I still do not know if the message is encrypted with both keys to allow decryption by both parties.

[mbilker]

Though, Facebook encodes v3 signatures. GPGTools encodes v4 signatures.

[w4]

I suppose it wouldn't be too hard to tell if it was encrypted or signed first, although signed first sort of makes more sense now I come to think of it

[mbilker]

I may try to develop a GPG node native module. Though, this requires N1's apm to be used to build the native extension and then ship the native extension bundled in the publicly available package download the road.

[mbilker]

There is a Node native extension that utilizes GPG's library, and I could extend off that if GPG's native API is not too terrible to analyze.