K-9: Feature request: provide an option to disable Autocrypt

[ljn917]

I want to have an option to disable Autocrypt key discovery and fallback to the old method. The possibility of man-in-the-middle attack makes me unconfortable. Thanks.

[besendorf]

You can still verify the fingerprints and I would recommend to do so, but there is no disadvantage to autocrypt, if there is a man-in-the-middle its the same as sending unecrypted what would be the old method

[ljn917]

I think I want a strict mode that forces signature check and rejects to
send if there is no valid signature.

The issue occurred to me was with a revoked signature. There was one email
address that had two non-expired pub keys. Both of them had my signatures,
but the signature on the old one had been revoked. (the key was still
valid) When I replied to old emails signed by the old key with my revoke
signature, k9 mail used the old key to encrypt. I was expecting k9 mail
should find my signature on the old key had been revoked and either find
the new key or reject to send.

On Dec 31, 2017 3:03 AM, "besendorf" [e-mail] wrote:

You can still verify the fingerprints and I would recommend to do so, but
there is no disadvantage to autocrypt, if there is a man-in-the-middle its
the same as sending unecrypted what would be the old method

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/k9mail/k-9/issues/3000#issuecomment-354590886, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABY5nrdP_1JqWOoVojBhgao1buHZgPPuks5tFz_NgaJpZM4RPVVj
.

[ghost]

I concur with the option request. I do not want my email client to handle any part of key negotiation silently in the background, via headers no less (unneccessarily exposing capabilities)... I chose K9 because it _could_ be easily configured to do proper encryption, not because it follows the latest "but crypto is hard" ideas...

[ghost]

I concur also with this option request!
It is very impotant for security to be able in diabling autocrypt

Look here for a comment toward autocrypt in german: https://privacy-handbuch.de/diskussion.htm

[xandro0777]

Why was this closed?

Autocrypt is worse than not using any email encryption - it gives users wrong sense of security.
According to the Autocrypt standard my manually verified keys can be replaced at any time by an attacker - will I be asked to verify the newly supplied key?

[vitgum]

Why was this closed?

Autocrypt is worse than not using any email encryption - it gives users wrong sense of security.
According to the Autocrypt standard my manually verified keys can be replaced at any time by an attacker - will I be asked to verify the newly supplied key?

I absolutely agree with this. Autocrypt implementation in K9 v 5.717 allows attacker to send an email with the new FAKE pubkey, and K9 (1) does not check the signature of the new email against the stored and verified pubkey, (2) does not inform the user about pubkey replacement in Open Keychain.

This means that attacker, who has access to the SMTP server , which allows to send emails with arbitrary email addresses in the Form: field of the message , CAN now send you an email formed according to autocrypt spec with the new FAKE pubkey, and you will never know about this attack. This completely spoils the original idea of Pretty Good Privacy where you can make sure that you are communicating to the right person by automatic signature verification against pubkeys which you trust. Where is the logic?