Support of/bridge to GnuPG

[novoid]

I would like to sign/encrypt Bitmessage with GnuPG as well.

In order to do this in a user friendly way, PyBitmessage could offer functionality to quickly sign, encrypt, sign+encrypt, check signatures, and decrypt message body accordingly.

[gits7r]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 4/9/2014 10:59 PM, novoid wrote:

I would like to sign/encrypt Bitmessage with GnuPG as well.

In order to do this in a user friendly way, PyBitmessage could
offer functionality to quickly sign, encrypt, sign+encrypt, check
signatures, and decrypt message body accordingly.

— Reply to this email directly or view it on GitHub
#659.

You can do this via some other tool, external of PyBitmessage like
gpg4usb or any other PGP implementation. Then just copy / paste the
PGP encrypted text and send it via BitMessage as a regular message.

Bitmessage, as it was designed it eliminates the need of PGP/GPG since
messages are encrypted and to end and even the metadata is hidden. if
you want an additional layer of encryption, like PGP/GPG you are free
to do it via something externally, but I don't think it's useful to
mobilize developers efforts in implementing PGP on top of bitmessage.
It's too complicated and bitmessage eliminates the need of it by design.

---

PGP Public key: http://www.sky-ip.org/s7r@sky-ip.org.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)

iQEcBAEBCAAGBQJTRafVAAoJEIN/pSyBJlsRqXEH/12YqgcUFMi9PfCKjijpoc+b
zkODBx0jgHYl+TPBlhaveKPMK9Sc+yj94xMHfvxulDxaoNItkEneoIqPcUcG11FX
6qF+OthLM0WJ7xfZmeMOYndi/FVojlGxrfw4pA5aezSsiykdOlXX/+jgX6690XO1
CY9fAGlTNlKwZZlfydfW/Pqh47++jkuKnvX/5mliF5tljPrasNF6g4F43F8tQ57k
hOjJ9eWobeCNCUYne6mmmx1tth1WuTynDTX8aK+BuI+Qaq9T+IW7kNfKbhaijlDl
88i3C3gf94fFMYgAyJjGZ+fqRsAbCHZ+Y2wPedZFMFCak9aTX2W2Q/yhIurNJPo=
=kvb2
-----END PGP SIGNATURE-----

[novoid]

Wow, quick response :-)

I am doing GnuPG by copying to clipboard and pasting so far. But this is a tedious job. Therefore, I wanted to see a method to quickly push the content to the command line version of GnuPG and visualize the result. No need to re-implement GnuPG, just a bridge to the current tool.

Yes, Bitmessage has its crypto-layer. However, there is a lack of migration support for current GnuPG-users and their Web of Trust. Everybody can generate Bitmessage-IDs and pretend to be me. However, by using GnuPG-signed Bitmessage content, I can use my working infrastructure and Web of Trust to authenticate the person.

So much for signing messages. For really paranoid people, it would be very handy to be able to add GnuPG encryption support (via the simple interface mentioned above, not much of an implementation!) in order to provide a second layer of security. This is not a matter of distrust to Bitmessage but a matter of easy combining two different methods to provide maximum security.

To put it in simple words: I personally would like to have following: In the compose window, I would like to have a sign-button and a sign+encrypt-button. Whenever I press one of them, I would like to be asked about my private key passphrase (it's more than OK with me if this is a terminal window) and the compose window content gets replaced with the result of this operation (signed/encrypted message). In the message read window, I would like to have a check signature and a decrypt button. Signature check ends up with some window telling me the correctness of the signature according to my GnuPG keyring. Decrypting a message should ask me for my passphrase (terminal window is fine) and provide me the plain text in the message read window. When I close the decrypted message, I should see the encrypted message the next time. So please do not replace the GnuPG-encrypted Bitmessage with the plain text version. For the sake of security, GnuPG-encrypted messages should be stored encrypted in PyBitmessage.

Yes, this is the extra mile, many (paranoid) folks are going to like.

[stefan2904]

Why not use your e-mail client for this?

For the more advanced users, something like this may be useful:
https://bitmessage.org/forum/index.php?topic=2565.0

[novoid]

I copy this idea: a more or less transparent bridge to current email clients (using a wrapper tool) would be the best solution for this issue.

This way, Bitmessage does not necessarily need to maintain its compose/read UI (the rest will still be necessary) and is able to re-use existing implementations. Other benefits would be: spell checking, address book, message history and search, ...

I would focus on this wrapper that intercepts BM-messages and redirects the rest to the MTA.

[Atheros1]

Indeed; Bitmessage exists because PGP/GPG is too difficult for many users to use. Also, I don't believe that Web of Trust actually works because highly trusted nodes just devolve into certificate authorities.

[ghost]

Agree with @novoid

[ghost]

Yes, Bitmessage has its crypto-layer. However, there is a lack of migration support for current GnuPG-users and their Web of Trust. Everybody can generate Bitmessage-IDs and pretend to be me.

@novoid Why can't you simply sign your Bitmessage address with your GPG key. You can then publish this online, or just include it at the bottom of every message, and everyone will know it's you. Or am I missing something here?

[novoid]

@mirrorwish: Yes, you right. I can.

However, this is (another) workaround. I tried to suggest a in-between solution which offers a better user experience.

Manually copying things to other tools, handling it there and manually copying back: that's not what I do consider good usability. So from my point of view this thread is about usability and not about possibilities.