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)

Poorly sourced statement

Regarding [8]: 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)