This article is rated Start-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||
|
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)
While Autocrypt may make encryption easier in some cases, it has some problems:
In detail
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)
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)
Felixbecker2 ( talk) 21:18, 14 May 2021 (UTC)
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)
This article is rated Start-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||
|
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)
While Autocrypt may make encryption easier in some cases, it has some problems:
In detail
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)
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)
Felixbecker2 ( talk) 21:18, 14 May 2021 (UTC)
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)