Talk:Autocrypt

Regarding the Proposed Deletion

On June 22nd, this article was proposed for deletion by User:Winner 42 because of concerns it didn't meet the WP:GNG.

I would like to contest the deletion proposal. Full disclosure, I was involved in writing the specification.

Addressing the lack of external sources, Autocrypt recently received an independent multi-page feature in iX Magazine, a renown German technical printed magazine. This Article is available (in German) online, however I didn't have a good place to use it as a source in the English article, which is why I didn't include it. There is also an upcoming article in the XRDS printed magazine. With respect to longevity of notability, Autocrypt has been supported in Enigmail and K-9 Mail since March this year, so it is deployed and in use at scale in applications that have been around for a long time (and can be expected to last). We also have word that support in Gpg4win's "GpgOL" Outlook plugin is on their roadmap.

Thanks for considering

--Valodim (talk) 17:24, 29 June 2018 (UTC)

I agree that Autocrypt is notable and the deletion should be contested.

Autocrypt is notable because it has been discussed for several years in relevant technical forums and it is being implemented in several mainstream software. Since it is a technical solution, it is not expected to turn up in the mainstream news media. It is also in active development so it will not go away for the foreseeable future.

Most recently Autocrypt was demonstrated and discussed at the Internet Freedom Festival, a major meeting of users and developers that focus on digital security.

Source: https://platform.internetfreedomfestival.org/en/IFF2018/public/schedule/custom/238

Autocrypt received exposure in several Chaos Communication Congresses, the biggest yearly hacker conference that provides a highly visible forum where some of the most notable security problems are regularly exposed and prospective security solutions are debated.

Examples from 33c3:

https://fossil.net2o.de/33c3/doc/trunk/wiki/panel.md

https://fossil.net2o.de/33c3/doc/trunk/wiki/autocrypt.md

--Maxigas (talk) 22:59, 29 June 2018 (UTC)

I also support contending the deletion. I am involved in a three year long EU research project, see https://nextleap.eu . We recently published extensive work on how to counter active attacks against Autocrypt, see https://countermitm.readthedocs.io . Discussions and the Autocrypt community ar every active and there are several upcoming meetups in 2018 to further the Autocrypt specification.

--hpk42 (talk) 22:59, 30 June 2018 (UTC)

Unsafe and dangerous

While Autocrypt may make encryption easier in some cases, it has some problems:

• the provided security is virtually worthless because not even TOFU is implemented, repeatedly accepting any key anytime without ever asking user
• there is a considerable risk that pre-established "safe connections" with manually verified OpenPGP keys will be degraded to non-encrypted connections or attacker supplied keys will be substituted. Because OpenPGP itself is a highly regarded trusted encryption standard this may cause considerable damage.
• in practice the layering of an extremely week key exchange standard on top of an established safe standard will necesarilly cause any number of logical and programming bugs.
• experience shows that Autocrypt actively breaks previously established "secure connections", downgrading them to non-encrypted [1] [2] - even before someone tried to attack it

In detail

1. "initial key exchange" is in no way protected. Unlike many reasonable TOFU implementations, the standard wants it that the user is not asked to accept a key for a new peer/connection.
2. worse - an already accepted and trusted key may be replaced anytime later any number times with zero verification by an attacker supplied key without even asking or notifying the user (yes, the standard explicitly wants that as I read to docs). A fake peer key can be substituted by anyone who can forge an email sender address or has MITM capabilities: [3] [4] [5]
3. worse yet (if at all possible), even a properly encrypted and signed email may carry poisoned email headers with a fake peer key (eg previously manually verified keys, MITM attack by email provider who inserts fake autocrypt header). So even if a cautious MUA happens (against recommendation of the standard) to ask the user whether to replace a previously valid key by a new fake one, the user is likely to be tricked very easily to accept the new fake one because the message was signed and verified. This is because the autocrypt key is deliberately not part of the signed message [6] and the headers unlike message body and attachments are never encrypted or signed and thus can be manipulated in any way while the receiving MUA will still successfully verify the message
4. the docs have only a very vague recommendation to prefer traditional verified OpenPGP keys over autocrypt keys ([7]). In programming practice this will probably lead to many wrong implementations making traditional trusted OpenPGP encryption completely unsafe. Some (most?) implementations don't give the user the choice to disable Autocrypt and use only traditional OpenPGP.

That is before cryptoanalysis started - and I think it is unlikely anyone will ever waste time to cryptoanalyse such a weak standard. 2.247.255.214 (talk) 20:50, 7 December 2019 (UTC)

This is original research, which is not considered a reliable source. Unless reliable secondary sources are found that specifically state that Autocrypt is insecure, that paragraph is considered either a POV or original research. That being said, I do agree with what has been said here, but do not agree with placing this content in a Wikipedia page until RS is found. Would (oldosfan) 06:56, 8 December 2019 (UTC)

Aren't most statements above fully backed by the cited Autocrypt documentation? Anyway.. the article is backed pretty much by only one source - the autocrypt documentation itself which is not ideal as a reliable source. There is a number of statements which are rather daring.. take the first sentence for example: "Autocrypt is a standardized guideline for e-mail clients, enabling end-to-end encryption." . Really - end-to-end encryption? What is the justification for this claim given that the authors of the standard freely admit there is zero protection against MITM attacks and any mail service provider is in the ideal position to perform this attack? Since connections to/from the mail service provider are typically TLS encrypted anyway what security does it add at all? 2.247.252.196 (talk) 19:30, 8 December 2019 (UTC)

The Autocrypt documentation is a primary source, and the points made are still a) an interpretation of the documentation, and b) still original research. WP:RS states that reliable secondary sources must be found that directly state the insecurity of the protocol. WP:NOTTHEM is also worth reading. The article itself also lacks reliable citations, which is also something I'll be fixing in the next few days. Would (oldosfan) 00:31, 9 December 2019 (UTC)

FYI [8] and specifically [9]. I know that a mailing list is not WP:RS but Kai Engert is a senior security guy at Mozilla and perhaps his opinion could be quoted. 2.247.253.51 (talk) 21:09, 9 December 2019 (UTC)

A quote would probably be in order Would (oldosfan) 03:23, 2 January 2020 (UTC)

Poorly sourced statement

Regarding [10]: specifically the claim "This type of attack can be detected (but not prevented) by the user with a manual out of band verification...". I did read the FAQ and some other docs and they don't mention that or how it can be supposedly detected. I think it is possible - if both peers store all outgoing and incoming mails, meet each other and compare those stored mails and know what to look for. However, this seems a pretty high hurdle in practice? 2.247.255.214 (talk) 21:02, 7 December 2019 (UTC)

I think the claim that it "can be detected" is a little too vague and doesn't say how practical it might is in reality. Maybe there could be forensic tools looking for that but not aware of anything? 2.247.255.214 (talk) 21:28, 7 December 2019 (UTC)

Claw mail also seems to support autocrypt

• Just seen on my machine in conjunction with posteo,
• references: https://systemausfall.org/wikis/howto/ClawsMailActions.

Felixbecker2 (talk) 21:18, 14 May 2021 (UTC)

the reference has a bash script to import to extract the keys from the header and import it into gnupg.. not exactly support by claws mail? 178.24.242.196 (talk) 00:59, 17 January 2022 (UTC)

Dead project with significant security concerns

I came across this while reading about Delta Chat, and would like to second the concerns listed under "Unsafe and dangerous": the scheme defined by Autocrypt can be most accurately described as an weak Opportunistic encryption scheme, with additional downgrade and MiTM modes due to the scheme's willingness to accept any key given to it by a third party. In other words: the only attacker that this scheme prevents is a fully passive one; even the weakest active adversary can force downgrades or even substitute an attacker-controlled encryption key.

In addition to the problems mentioned above, it's probably worth noting that the Autocrypt project itself appears to be dead/largely inactive: several of the integrations/libraries listed on their status page currently 404 (like the Python and Emacs ones), and others than not received significant development attention since circa 2019.

Given the above, I believe this page deserves a significant rewrite (or possibly even merging into a sub-section of a larger PGP/GPG article). The academic and corporate cryptographic communities are in broad agreement that email encryption schemes are generally flawed and not worth individual academic rebuttal, so I'm not sure that we'll ever see an academic paper that can be cited here. Yossarian flew (talk) 19:45, 3 July 2023 (UTC)