Feature request: display decryption result as text.

[dscotese]

Expected Behavior

Once the decryption feature has completed decryption, in addition to providing all the existing ways of using it, display the result as text iff it's all text, in a box that allows editing, copy, and paste.

Current Behavior

Currently there is no obvious way to view the decryption result without saving it first, which seems like bad opsec.

Possible Solution

If you don't want to crowd the result screen, add "View as Text" to the context menu. For convenience, that could present the encryption page with the key already selected and the text-to-encrypt would be the result. That makes it easy to open, decrypt, edit, re-encrypt, and save.

• Android Version: 8.0.0
• Device Model: Samsung G930AZ
• OpenKeychain Version: 5.5
• From Google Play or F-Droid?: GP

[Valodim]

This should already happen. Quick test: When I go to "encrypt text", put my own key as recipient, encrypt to clipboard, and then go to "decrypt from clipboard", the text is immediately displayed.

Here's the logic: https://github.com/open-keychain/open-keychain/blob/master/OpenKeychain/src/main/java/org/sufficientlysecure/keychain/ui/DecryptListFragment.java#L368

Perhaps your data isn't recognized as text/plain?

[dscotese]

That makes sense. I felt that the feature was there somewhere and I just couldn't find it.

I was decrypting a file, not the clipboard, and I believe that is why it doesn't happen. I could open the file and put its contents on the clipboard, but I don't think the file is ASCII, so I'm not sure how the clipboard would handle it. Plus, keeping the decrypted text off the clipboard by using a file seems like good opsec.

[Valodim]

Decrypting from file or clipboard makes no difference for this. But OpenPGP encrypted data doesn't contain much info about the file type, so we are doing a whole lot of guesswork to determine what's in there.

If you are using gnupg on the other side, you could try passing --textmode (or -t), and see if that helps. Alternatively, if the files you encrypt have a ".txt" extension (and that name is included in the encrypted data), they'll also more likely be recognized as text files.

[dscotese]

Can you explain what you mean by "Decrypting from file or clipboard makes no difference for this."?

Have you seen the behavior on an Android? If I decrypt a file, I get no text. If I decrypt what's on the clipboard, I get the plaintext. If I decrypt the file and then save it, the file I save is full of text. If I have to dig into the code to find out where it decides what to do with the decrypted text, so be it. I just figured someone else might already know and be able to offer to "Display as text" the result.

As you point out, it would make sense to run through the result to make sure it doesn't have obviously-not-text data in it, like NULs. But even then, "DIsplay as text" could still be useful, so maybe it makes more sense not to bother with any checking.

[Valodim]

Can you explain what you mean by "Decrypting from file or clipboard makes no difference for this."?

I meant that the logic that decides whether decrypted content is displayed as text or not is independent of the origin of the encrypted data.

If I have to dig into the code to find out where it decides what to do with the decrypted text, so be it. I

I linked to it, see above. The condition to display data as text is isSingleMetadata && isText && !isOverSized. We can be reasonably sure your input is only one piece of decrypted data, and that it isn't oversized, so it's apparently not recognized as text.

As you point out, it would make sense to run through the result to make sure it doesn't have obviously-not-text data in it, like NULs.

We do this already

I wonder, in the log of your decryption operation, what's the mime type it says?

[dscotese]

Application/octet-stream

[dscotese]

If I encrypt it to ASCII, ("-----BEGIN PGP MESSAGE----- ...") then this works as you described. If I just encrypt the text file (with the latest version of Kleopatra, which NO LONGER offers "encrypt to ASCII"), then it encrypts to an "octet-stream" (opening the file in a text editor shows me garbage). I see you linked to code that could be used to update the mime-type from "application/octet-stream" to "text/plan" if it fits, but I guess it isn't doing that. From the log, it looks like this is a "feature" of Kleopatra, indicating the Mimetype (and thereby misleading whatever decrypts it). I will bug them about it. Thanks for your help.

Still, since "application/octet-stream" is relatively useless, an option indicating "Mimetype says this isn't text. Would you like to try treating it as text anyway?" would be handy in case other encryption software also pretends to know that a file that is encrypted to another file must be "application/octet-stream", or for other users of Kleopatra.

Dave.