Open gauteh opened 7 years ago
maybe one should write down astroids understanding of this concept. mainly i see the benefit of sending and receiving pubkeys with the email which replaces the use of key servers.
their hard rules on simplified user experience is a bit rough. not being able to negotiating a key hash, not being able to switch off encryption if someone sneeked in a pubkey and other stuff already mentioned on their side are alredy better solved by astroid + a keyringtool today.
it should not be that complicated to prepare the Autocrypt: header. receiving and storing would involve some new stuff i assume.
Yeah, I think if we do implement it there should be some way to handle the full spec (but we might rely on external utilities). Seeing that use of Autocrypt is very small atm, we might consider other systems as well. Maybe we talked about this on IRC, but is it possible to use existing GPG keys with this system?
I think I'm going to close this issue for now, if/when autocrypt becomes more mature and there are more users (other MUAs) then we can make it a priority. If someone feels like giving it a shot, please go ahead!
Clients supporting autocrypt:
At Autocrypt Level 1, a MUA must be capable of parsing 2048-bit and 3072-bit RSA public keys. So if your existing public key is 2048-bit or 3072-bit RSA, and you can import it into your MUA, it will be parseable by Autocrypt-enabled MUAs.
details: https://autocrypt.org/level1.html#openpgp-based-key-data
Hey there, greetings from Autocrypt!
not being able to negotiating a key hash
You mean some kind of verification mechanism? This is not included at the moment, but it will be in the future.
The trust model will likely be similar to signal's - unverified keys will just be switched out if the correspondent sends a new one, verified keys will interrupt the user and tell them that something is up and the key dropped to unverified status just now. The verification itself will probably happen by some number comparison ("safety number") or optionally qr mechanism.
The reason we didn't include this in level 1 is that there are a bunch of pain points that we couldn't solve at a level of complexity we felt comfortable with, particularly multi-client synchronization. Existing implementations also typically already have a way to do this (e.g. k-9/openkeychain, and anything gpg-based)
l-10
To be fair, this is only a client used for demo purposes at IFF ;)
Anyways, please do feel free to get back to us about any problems you encounter or ideas that come up. We believe that email encryption can only really improve if we figure out the actual workflows in a way that works uniformly across clients, and with as little required user knowledge as possible.
Hi, thanks for the info! Are there any APIs available that can work with C/C++ / GMime or possibly Python/Lua (which is easy to plugin)?
GMime has some Autocrypt support itself, contributed by @dkg while working on notmuch
https://developer.gnome.org/gmime/stable/gmime-gmime-autocrypt.html
For python, there are 2 WIP projects:
Vincent Breitmoser writes on mars 13, 2018 12:18:
GMime has some Autocrypt support itself, contributed by @dkg while working on notmuch
https://developer.gnome.org/gmime/stable/gmime-gmime-autocrypt.html
Excellent, will check out these.
fwiw, i am hoping to put some autocrypt support into libnotmuch itself; i'd hope that astroid would be able to use that, rather than inventing its own autocrypt layer that would be distinct from libnotmuch.
if you want to collaborate on a libnotmuch autocrypt implementation that astroid could make use of, i'd be happy to brainstorm with you.
--dkg
Absolutely, is this something notmuch wants? And, if not, perhaps it could be made as a super-thin library on top. Is this something for use within the regular notmuch emacs client?
imho, this is something notmuch itself wants. i'd much rather do it in libnotmuch than do it in some extra add-on library.
other notmuch devs might not currently agree -- i haven't canvassed them all -- but i suspect we can convince them with sensible arguments and functional code :)
--dkg
dkg writes on mars 16, 2018 10:46:
imho, this is something notmuch itself wants. i'd much rather do it in libnotmuch than do it in some extra add-on library.
other notmuch devs might not currently agree -- i haven't canvassed them all -- but i suspect we can convince them with sensible arguments and functional code :)
functional code is usually very convincing.
I (probably) got my first AutoCrypt-crypted email today (remember i'm the guy with the mailbox where a procmail-filter encrypts all mails that arent)
Point is: Astroid wasnt able to decrypt that AutoCrypt-mail:
[M] [error] crypto: unsupported protocol:
[M] [error] chunk: no crypto ready.
I tried gpg directly which worked fine.
The mail contains the header Content-Type: multipart/encrypted; boundary="GNp5lgJf66cwvLlPhSvPwZHzv3HH0T6FL"; micalg="pgp-sha256"; protocol="application/pgp-encrypted"
, so the protocol seems to be correctly set.
Where can i start digging?
crypto.cc, search for protocol. It seems like it should match, but is empty? Maybe increase debug level.
lør. 25. jan. 2020, 19:42 skrev M. Dietrich notifications@github.com:
I (probably) got my first AutoCrypt-crypted email today (remember i'm the guy with the mailbox where a procmail-filter encrypts all mails that arent)
Point is: Astroid wasnt able to decrypt that AutoCrypt-mail:
[M] [error] crypto: unsupported protocol: [M] [error] chunk: no crypto ready.
I tried gpg directly which worked fine.
The mail contains the header Content-Type: multipart/encrypted; boundary="GNp5lgJf66cwvLlPhSvPwZHzv3HH0T6FL"; micalg="pgp-sha256"; protocol="application/pgp-encrypted", so the protocol seems to be correctly set.
Where can i start digging?
— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/astroidmail/astroid/issues/358?email_source=notifications&email_token=AAAN364FBXKZZVYGFJFESCLQ7SB2TA5CNFSM4DPEQQ4KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJ5CT2Y#issuecomment-578431467, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAN364RCUFMJDAHB4QFMFLQ7SB2TANCNFSM4DPEQQ4A .
This is the log including debug:
[15:54:18] [0x00007fd0648b6180] [M] [info] msg: loading mid: 5e7f9ddc-cfcd-bc06-ac58-98db2bcac21a
[15:54:18] [0x00007fd0648b6180] [M] [info] msg: filename: /home/me/Maildir/cur/new/1580054317.17124_3
[15:54:18] [0x00007fd0648b6180] [M] [debug] chunk (60): content-type: multipart/encrypted
[15:54:18] [0x00007fd0648b6180] [M] [debug] chunk: multi part
[15:54:18] [0x00007fd0648b6180] [M] [debug] crypto: gpg: /usr/bin/gpg2
[15:54:18] [0x00007fd0648b6180] [M] [warning] chunk: is encrypted.
[15:54:18] [0x00007fd0648b6180] [M] [debug] crypto: decrypting and verifiying..
[15:54:18] [0x00007fd0648b6180] [M] [debug] cr: encrypted for: () [] [2A7380FB903FF637]
[15:54:18] [0x00007fd0648b6180] [M] [info] crypto: successfully decrypted message.
[15:54:18] [0x00007fd0648b6180] [M] [debug] chunk (62): content-type: multipart/signed
[15:54:18] [0x00007fd0648b6180] [M] [debug] chunk: multi part
[15:54:18] [0x00007fd0648b6180] [M] [debug] crypto: gpg: /usr/bin/gpg2
[15:54:18] [0x00007fd0648b6180] [M] [error] crypto: unsupported protocol:
[15:54:18] [0x00007fd0648b6180] [M] [error] chunk: no crypto ready.
[15:54:18] [0x00007fd0648b6180] [M] [debug] chunk: alternative: false
[15:54:18] [0x00007fd0648b6180] [M] [debug] chunk (64): content-type: multipart/mixed
[15:54:18] [0x00007fd0648b6180] [M] [debug] chunk: multi part
[15:54:18] [0x00007fd0648b6180] [M] [debug] chunk: alternative: false
[15:54:18] [0x00007fd0648b6180] [M] [debug] chunk (65): content-type: text/plain
[15:54:18] [0x00007fd0648b6180] [M] [debug] chunk: preferred.
[15:54:18] [0x00007fd0648b6180] [M] [debug] chunk: is part (viewable: true, attachment: false)
[15:54:18] [0x00007fd0648b6180] [M] [debug] chunk: multi part end
[15:54:18] [0x00007fd0648b6180] [M] [debug] chunk (66): content-type: application/pgp-signature
[15:54:18] [0x00007fd0648b6180] [M] [debug] chunk: is part (viewable: false, attachment: true)
[15:54:18] [0x00007fd0648b6180] [M] [debug] chunk: multi part end
[15:54:18] [0x00007fd0648b6180] [M] [debug] chunk: multi part end
https://autocrypt.org/en/latest/