Does Delta Chat encrypt messages using PGP hidden recipient? In most cases there’s probably not much benefit, but it seems to me that in the case of email address porting, or if Delta Chat ever supports features like multihoming or sealed sender, using hidden recipient could provide a modest privacy improvement.
If you mean zeroing out fingerprints, currently they are not zeroed out. This will need to be done when we protect the addresses in the To field.
I mean hiding/throwing away the key ID of the recipient, which is normally included in the encrypted message.
This sounds like it’s on the roadmap then, which is good to know. Now I’m curious, what do you have planned for protecting addresses in the To field?
Anyway it seems to me that hiding/throwing away the key ID could already offer a privacy improvement for people using AEAP, making it more difficult for third parties to link the old and new address.
Key IDs are replaced with fingerprints in RFC 9580 where possible. But yes, key IDs are currently not zeroed out.
There is a WIP PR at feat: hide the Date and To headers in encrypted messages by link2xt · Pull Request #6649 · chatmail/core · GitHub
Some fixes that need to be done before this is possible have been merged, waiting for them to get into releases and for users to upgrade. Also there are some unresolved problems with chat assignment for large messages, this is postponed until WIP: PGP-contacts by link2xt · Pull Request #6683 · chatmail/core · GitHub
We also have a flag to protect Autocrypt header which is not enabled yet.
This is not very useful by itself if Autocrypt header is not hidden.
Thanks for this information!
I filed an issue at Use anonymous recipient for generated packets · Issue #507 · rpgp/rpgp · GitHub because it does not seem to be supported in rPGP yet and we will need it.
Great to know this is being looked into and taken care of!
I’m still trying to understand conceptually how hiding the To header will work. How will the email server know where to send a message without the To header/address?
There is a list of recipients in the “envelope” (RCPT TO
commands in SMTP protocol). To:
header that goes into IMF message plays no real role, you can put anything there. This is how Bcc works, you put the recepients into RCPT TO
but not in the To:
field. Basically we can just Bcc everyone.